mad-dev

mad-dev@lists.mars.org

682 discussions

Announce: MAD now included in the Comprehensive Source Database (CSDB)
by Enrico Weigelt 03 Aug '06

03 Aug '06

Hi folks, I'd like you to know that the MAD packages are now included in the comprehensive source database (CSDB): http://sourcefarm.metux.de/ regards, -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact(a)metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------

1 0

Libid3tag documentation, again
by Alexander Thomas 05 Jul '06

05 Jul '06

I have started writing a little program that uses libid3tag to read id3 tags, add a few tags, and write the result back to the mp3 file. This seemed trivial, but it took me about 2 days and tons of segfaults and weird behavior to come up with something that starts to go in the right direction. Google sent me to about 10 different websites during my quest for information, with each site giving a small piece of the puzzle. At many times I suspected id3tag to be full of bugs, but I soon realized that the 'bugs' were just due to the way I (mis)interpreted the functions. If someone has the time for it, I would really suggest to write some documentation, and bundle it with the software. A few well-documented simple demo programs which read, modify, and write tags would already be incredibly useful. It would also be nice if the id3tag.h file would be a bit more 'verbose', i.e. if the function prototypes would use actual argument names which make sense, and a short description and caveats for each function. It seems like libid3tag is not widely used, although it has a lot of potential. I think the lack of documentation is a major cause of this... Alexander

1 0

Strange libid3tag.lib crash
by Adam Davison 01 Jul '06

01 Jul '06

I'm a developer from the mixxx project (http://mixxx.sf.net) which uses libid3tag. On linux the library works perfectly. On windows however, we're having a strange problem. Linking against libid3tag-release.lib on MSVC Express causes a segfault when we call id3_file_close, however, linking against the debug version seems to work fine. For the previous release of mixxx, we linked against the release library using a previous version of MSVC and it worked fine. I've tried rebuilding the newest release of the libid3tag source and got the same result. I'm hoping someone on the list has seen this kind of problem before or can at least give me some kind of insight into why this might be happening. Is linking with MSVC Express a known problem? Any help at all would be very much appreciated. Adam D

1 0

libid3tag: Prevent infinite loop when parsing invalid utf-16
by Kurt Roeckx 18 Jun '06

18 Jun '06

Hi, When there is an UTF-16 sequence with an odd number of bytes, which is clearly broken, libid3tag will keep in an infinite loop trying to parse the last byte. The attached patch fixes it by saying we actually parsed the last byte, and seems to work without problems so far. Kurt

1 0

libmad configure error on Windows's Cygwin
by Jun Guo 18 Jun '06

18 Jun '06

When ran configure on Windows's Cygwin,I got the follow errors. The libmad is libmad-0.15.1b.Cygwin is full installed. Any ideas? $ ./configure --host=mingw32 configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for mingw32-strip... no checking for strip... strip checking build system type... i686-pc-cygwin checking host system type... i386-pc-mingw32 checking for mingw32-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... nm checking whether ln -s works... yes checking how to recognise dependent libraries... file_magic file format pei*-i38 6(.*architecture: i386)? checking how to run the C preprocessor... /lib/cpp configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details.

1 0

Decode the UCS4 to the current locale instead of latin1.
by Kurt Roeckx 17 Jun '06

17 Jun '06

Hi, madplay currently always converts the id3 tag information to latin1. The attached patch converts it to the currently codeset based on nl_langinfo(CODESET). It seems the configure script already checks for nl_langinfo and iconv with the automake macro's, so I didn't have to patch configure for this. Maybe those function belong in libid3tag instead, it would be more logical. It would also not require us to use non-exported functions. The reason I just put it in madplay is that this only require me to change one source package. There is one problem with this patch that I know of, and that is that it doesn't properly deal with (argualby broken) iconv() implementations saying the input sequence is invalid when it can't map a valid input character to the output encoding, and I'm not sure how to deal with it, see the comment. Kurt

1 0

per-entity ID3v2/ID3v1 information?
by Mikhail Gusarov 17 Jun '06

17 Jun '06

Hello, Is it possible to add to libid3tag either disabling ID3v1 tags parsing during tag parse or fine-grained information about where the tag part was read? The use-case is the file with non-Latin encoding in id3v1 and ID3v2 To properly decode such a tag the info is needed what part of tag was read from v1 (now it's only coarse grained flag "there is id3v1 in file", which does not indicate what part of tag is actually read from the v1 tags). Another option is disabling id3v1 parsing: application may read and encode/decode v1 tags on it's own. -- JID: dottedmag(a)jabber.dottedmag.net

1 0

How to compile sox with libmad?
by Jun Guo 16 Jun '06

16 Jun '06

Hi all: I want sox to support mp3,and try to compile them with VC++6,but failed. Does anyone knows how to compile them or provide the compiled sox to be shared?

1 0

Handling ID3 tags with non-latin1 encoding
by s.huelswitt＠gmx.de 07 Jun '06

07 Jun '06

Hi, I have a question regarding handling of ID3 tags which are non-latin1 encoded e.g. iso-8859-5. I think I can get ucs4 strings from libid3tag and convert them with iconv to whatever codeset originaly was used. How can I get information about the original codeset? Is there another designated way to handle these cases? My current code to get a string for an ID3 tag is (FYI: it's VDR-MP3 player plugin): void cScanID3::ParseStr(const struct id3_tag *tag, const char *id, char * &data) { const struct id3_frame *frame=id3_tag_findframe(tag,id,0); if(!frame) return; free(data); data=0; const union id3_field *field=&frame->fields[1]; if(id3_field_getnstrings(field)>0) { const id3_ucs4_t *ucs4=id3_field_getstrings(field,0); if(!ucs4) return; if(!strcmp(id,ID3_FRAME_GENRE)) ucs4=id3_genre_name(ucs4); id3_latin1_t *latin1=id3_ucs4_latin1duplicate(ucs4); if(!latin1) return; data=strdup((char *)latin1); free(latin1); } } Obviously the code yields bad results, if the string wasn't in latin1 originaly. TIA. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

3 4

Madplay fails to build on OSX x86
by ObjM2 09 May '06

09 May '06

I tried building madplay under OSX 10.4.6 both on PPC and Intel. The PPC build failed with a duplicate declaration of function wait() which I was able to fix by simply commenting that function out in audio_carbon.c. However, the Intel build fails with a whole bunch of errors which I was unable to work around. has anybody managed to build madplay on OSX for Intel yet? thanks in advance ___________________________________________________________ Yahoo! Photos � NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
69
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev