mad-dev January 2002

mad-dev@lists.mars.org

16 participants
12 discussions

Re: bitrate addition to libid3tag ?
by Bastien Nocera 26 Jan '02

26 Jan '02

Hi, After getting my mail nicely rejected ;) I tried the nice advice of using the TLEN frame. However very few (actually in my collection, none) mp3 files have such a frame. Would anybody have some code snippet that I could use to get the nominative bitrate of a file, by using the id3_tag ? Cheers On Sat, 2002-01-26 at 05:06, mad-dev-admin(a)lists.mars.org wrote: <snip> > To answer your question, "bitrate detection" would not be an > appropriate feature to add to libid3tag. However, you may be able to > approximate the average bitrate using the file size and the TLEN frame > from the ID3 tag. > > Calculating the actual bitrate requires decoding MPEG audio frames, > which is done by libmad (not libid3tag.)" -- /Bastien Nocera http://hadess.net

2 2

libid3tag demystified
by Rob Leslie 26 Jan '02

26 Jan '02

The following is an attempt to provide a quick-start for using libid3tag to read ID3 tags. (Sorry this is long -- using the library *is* fairly simple, but the background will probably help. See madplay.c for a concrete usage example.) The libid3tag file API will read all tags (v1 and v2) from a file and give access to a single tag structure which you can treat as though it were v2.4 regardless of the actual tag version(s) in the file. If the file has both v1 and v2 tags, the v2 tag will have precedence. struct id3_file *id3_file_open(char const *path, enum id3_file_mode mode); struct id3_file *id3_file_fdopen(int fd, enum id3_file_mode mode); Pass either a pathname or a file descriptor for an already-open file. If you pass a file descriptor and the open succeeds, the descriptor becomes "owned" by libid3tag and you should only close it with id3_file_close(). `mode' will usually be ID3_FILE_MODE_READONLY but eventually ID3_FILE_MODE_READWRITE will also be supported. int id3_file_close(struct id3_file *file); Use this to close a file handle opened with either of the above routines. It frees all the internal tag structures, so you should not still have a reference to any. struct id3_tag *id3_file_tag(struct id3_file const *file); Use this to obtain a tag structure for the file which you can further query/manipulate. Don't delete the tag; use id3_file_close() instead. If you want to manipulate v1 and v2 tags independently, you shouldn't use the file API -- you'll have to read the tags yourself. The following routines will help: signed long id3_tag_query(id3_byte_t const *data, id3_length_t length); Pass a block of memory and this routine will tell you if it begins with an ID3 tag -- and if so, its length. For example, if you read the last 128 bytes from a file containing a v1 tag and pass it to this routine, it should return 128. You must pass at least ID3_TAG_QUERYSIZE (10) bytes. To read a v2 tag, read at least 10 bytes from the beginning of the file and pass them to this routine to determine the full tag length. Then read the full tag and parse using the next routine below. If id3_tag_query() returns a negative number, it means the block you passed contains an ID3v2.4 footer, and the beginning of the tag is located at this offset. This is useful for reading v2 tags from the end of a file. The value 0 is returned when the block you pass doesn't begin with an ID3 tag header or tag footer. struct id3_tag *id3_tag_parse(id3_byte_t const *data, id3_length_t length); This is the heart of libid3tag: pass a block of memory containing a COMPLETE tag and this routine creates and returns a tag structure for easy access. It parses ID3v1, ID3v1.1, ID3v2.2, ID3v2.3, and ID3v2.4 tags, but the structure returned should always be treated as an ID3v2.4 tag, i.e. all the frames and fields use ID3v2.4 semantics. void id3_tag_delete(struct id3_tag *tag); Use this to delete a tag structure when you're done with it. If you're using the file API, use id3_file_close() instead. To access the data in a tag, you retrieve ID3 "frames" that contain "fields". A reference for all the ID3v2.4 frames is useful: http://www.id3.org/id3v2.4.0-frames.txt Each frame is identified by four characters. The following routine can either be used to fetch a single frame or to walk through a number of matching frames: struct id3_frame *id3_tag_findframe(struct id3_tag const *tag, char const *frameid, unsigned int index); Use an `index' of 0 for the first matching frame. Increment as desired; a null pointer is returned if the requested frame doesn't exist. `frameid' can be the full frame identifier like "TCON", or a prefix like "T" for all text frames, or "" or a null pointer to walk through all frames. The following are ID3v1 convenience macros for various frame IDs: ID3_FRAME_TITLE "TIT2" ID3_FRAME_ARTIST "TPE1" ID3_FRAME_ALBUM "TALB" ID3_FRAME_YEAR "TDRC" ID3_FRAME_TRACK "TRCK" ID3_FRAME_GENRE "TCON" ID3_FRAME_COMMENT "COMM" Once you have the frame, you can query its fields. struct id3_frame { char id[]; /* frame ID */ char const *description; /* English frame description */ unsigned int nfields; /* number of contained fields */ union id3_field *fields; /* array of fields */ }; Each field has a type. The following field types exist: enum id3_field_type { ID3_FIELD_TYPE_TEXTENCODING, /* small int; used internally */ ID3_FIELD_TYPE_LATIN1, /* single-line Latin-1 string */ ID3_FIELD_TYPE_LATIN1FULL, /* Latin-1 plus newlines allowed */ ID3_FIELD_TYPE_LATIN1LIST, /* Latin-1 string list */ ID3_FIELD_TYPE_STRING, /* single-line Unicode string */ ID3_FIELD_TYPE_STRINGFULL, /* Unicode plus newlines allowed */ ID3_FIELD_TYPE_STRINGLIST, /* Unicode string list */ ID3_FIELD_TYPE_LANGUAGE, /* 3-char language ID */ ID3_FIELD_TYPE_FRAMEID, /* 4-char frame ID */ ID3_FIELD_TYPE_DATE, /* 8-char date field */ ID3_FIELD_TYPE_INT8, /* 1-byte integer */ ID3_FIELD_TYPE_INT16, /* 2-byte integer */ ID3_FIELD_TYPE_INT24, /* 3-byte integer */ ID3_FIELD_TYPE_INT32, /* 4-byte integer */ ID3_FIELD_TYPE_INT32PLUS, /* variable-length integer */ ID3_FIELD_TYPE_BINARYDATA /* raw binary data */ }; The types for all fields in a frame are fixed; see libid3tag/frametype.gperf for the field types of each frame. For example: FIELDS(UFID) = { ID3_FIELD_TYPE_LATIN1, ID3_FIELD_TYPE_BINARYDATA }; So, a frame with ID "UFID" has two fields; the type of frame->fields[0] is ID3_FIELD_TYPE_LATIN1, and the type of frame->fields[1] is ID3_FIELD_TYPE_BINARYDATA. Use the ID3v2.4 frame reference document to make sense of the actual contents. All text frames (any frame ID beginning with "T") look like this: FIELDS(text) = { ID3_FIELD_TYPE_TEXTENCODING, ID3_FIELD_TYPE_STRINGLIST }; You may ignore frame->fields[0] in this case; it just identifies the encoding used in the original raw tag for the Unicode strings which follow. All Unicode strings have a standard representation in libid3tag so the original encoding is unimportant. There are two basic string types, Latin-1 (aka ISO-8859-1) and Unicode (aka UCS-4). Latin-1 strings are represented by normal C strings. Unicode strings have a special representation (an array of large integers) and so can't be manipulated as normal C strings. The basic character/string types are: typedef unsigned char id3_latin1_t; /* Latin-1 character */ typedef unsigned long id3_ucs4_t; /* Unicode character */ Therefore id3_latin1_t is compatible with the C string functions, but id3_ucs4_t is not. You can use a number of encoding routines to transform Unicode strings into something perhaps more useful: id3_latin1_t *id3_ucs4_latin1duplicate(id3_ucs4_t const *ucs4); id3_utf16_t *id3_ucs4_utf16duplicate(id3_ucs4_t const *ucs4); id3_utf8_t *id3_ucs4_utf8duplicate(id3_ucs4_t const *ucs4); Each of the above allocates new memory and so must be free()'d when you are finished. The encoding formats are Latin-1 (which will lose all non-Latin-1 characters), UTF-16, and UTF-8. If you're familiar with Unicode encodings, the latter two are pretty much what you think they are. The UTF-16 encoding is based on short ints, so the endianness depends on your platform. OK, back to field types. To access a field, you must use the access function for the field's type. These are: signed long id3_field_getint(union id3_field const *field); This accesses an ID3_FIELD_TYPE_INT{8,16,24,32} field. id3_ucs4_t const *id3_field_getstring(union id3_field const *field); This accesses an ID3_FIELD_TYPE_STRING field. id3_ucs4_t const *id3_field_getfullstring(union id3_field const *field); This accesses an ID3_FIELD_TYPE_STRINGFULL field. unsigned int id3_field_getnstrings(union id3_field const *field); This returns the number of strings in an ID3_FIELD_TYPE_STRINGLIST field. id3_ucs4_t const *id3_field_getstrings(union id3_field const *field, unsigned int index); This returns a (0-based) indexed string from an ID3_FIELD_TYPE_STRINGLIST field. char const *id3_field_getframeid(union id3_field const *field); This returns a frame ID from an ID3_FIELD_TYPE_FRAMEID field. id3_byte_t const *id3_field_getbinarydata(union id3_field const *field, id3_length_t *length); This returns a block of raw binary data from an ID3_FIELD_TYPE_BINARYDATA field. In addition, the length of the block is placed in `*length'. There are perhaps some accessor functions missing. If so, let me know. :-) I've not covered any of the routines for creating and rendering tags, adding or removing frames, or changing field contents. That's probably best saved for another post. Cheers, -- Rob Leslie rob(a)mars.org

1 0

libid3tag v1/v2 tags
by Kendall Shaw 26 Jan '02

26 Jan '02

What is the simplest way to read just the v1 tag if it's there, and just the v2 tag if it's there? Kendall

2 1

patch for MP3 decoding support in SoX
by fabrizio.ge＠tiscali.it 23 Jan '02

23 Jan '02

Hello. Enclosed is a patch that adds MP3 decoding support to SoX, based on the external libmad library for decoding. It is based on madlld, a decoder-tutorial written by Bertrand Petit (http://www.bsd-dk.dk/~elrond/audio/madlld/). After applying the patch, it is necessary to run autoconf in order to rebuild the configure script. Bye Fabrizio Gennari P.S. Does anybody have any info about MP3-encoded WAV files (format tag 0x55)? __________________________________________________________________ Abbonati a Tiscali! Con Tiscali By Phone puoi anche ascoltare ed inviare email al telefono. Chiama Tiscali By Phone all' 892 800 http://byphone.tiscali.it

2 1

MAD in LAME
by Steve Lhomme 23 Jan '02

23 Jan '02

Hi, I saw in the LAME "TODO" file this : 3. modify mpglib to output floating point and have finaly quantization step a easy-to-change module so it can output other than 16bit. (replace mpglib with MAD? MAD has agreed to write a call back which will return all data needed by the frame analyzer) I wonder what is the progress of this, and if there are any license issue with using MAD (libmad ?) in LAME (MAD is GPL and LAME is LGPL, that means AFAIK that some part of the MAD code can be used in LAME). My concern is that I want to integrate the decoding part in the LAME ACM codec. And since mpglib might be replaced by libmad someday it would be easier to make the move now. Otherwise, is there any good reason to you the mpglib_interface instead of calling directly mpglib ?

2 1

max mp3 frame size?
by Joshua Haberman 20 Jan '02

20 Jan '02

Currently Audacity uses a 64k input buffer when reading mp3s with libmad. This has worked great for the most part, but I've received a report that one particular mp3 will put Audacity into an infinite loop upon import. Since a trace revealed that the input callback was looping endlessly, I suspected that the buffer wasn't big enough to hold an entire frame, and the input callback was sending libmad the same partial frame over and over. I suggested that this user double the input buffer size, and that fixed the problem. Earlier when I asked you about this issue, you said mp3 frames are relatively small (around 418 bytes) so I'm very surprised that 64k wasn't big enough to hold an entire frame. Can you think of any other reason why increasing the buffer size would solve this problem? Is there a maximum size for mp3 frames that I could safely set as the buffer size, or would I have to dynamically size the buffer to be completely safe? Thanks, Joshua -- Joshua Haberman <joshua(a)haberman.com>

5 7

Re: Port to MIPS
by Rajneesh Kumar 18 Jan '02

18 Jan '02

> > When I run the program on the target, it gives undefined symbols > > "dpmul", "dpdiv", "dpadd", "dptoi". These symbols are from the > > floating point library. I do have Math/C/GCC library loaded. Can > > anyone out there has some experience of dealing with this kind of > > error or some other workaround. Any pointers will be greatly > > appreciated. > > Where are you getting your cross-compiler? I have my own cross compiler, GCC 2.95.3. > If you're building gcc by hand, well, things are a little more > complicated. If you are, could you tell us how your configuring >gcc? I am configuring the GCC as... working in gcc-build> and have /usr/local/toshiba/bin in my path. ../gcc-2.95.3/configure --nfp --target=mipstx39-linux --prefix=/usr/local/toshiba --enable-shared --with-gnu-ld --with-gnu-as --with-newlib cd libiberty ../../gcc-2.95.3/configure --nfp --target=mipstx39-linux --prefix=/usr/local/toshiba --enable-shared --with-gnu-ld --with-gnu-as --with-newlib cd .. make cross make install-cross Then build GLIBC and again revisiting GCC by configurinng the GCC the same way except removing option --with-newlib and adding --with-headers=/usr/local/toshiba/include --with-libs=/usr/local/toshiba/lib > Jay Thanks Rajneesh

4 3

seeking to a time location and outputting an mp3
by Wayne F Davis 15 Jan '02

15 Jan '02

Hello, I want to use madplay via command line to chop an mp3 based on a time location. madplay -s allows me to seek to a location in the file. However, I cannot find a way to have madplay output the remainder of the mp3; it wants to decode the file. Is there a simple work around for this? Or should I just modify madplay or use libmad to write up a simple program to do this? Thank you, Wayne Davis -- Wayne Davis - wfdavis(a)seas.upenn.edu - PGP Key Available

2 1

Port to MIPS
by Rajneesh Kumar 13 Jan '02

13 Jan '02

Hi all, I am working onto to porting MAD to TX3903 MIPS processor on a custom board. As through the mail archive and from my experience with MAD, the configuration for the cross compilation of the package has some problems but that can be easily played around. In a nutshell I am able to compile the package with few modifications to my custom board. Now if I use standard Makefile's linking, it aborts with an error of relocation truncation which is due to the global data table limit for the mips processor. So changing the value to linker option G helps in that case (default is 8). I have also compiled with the -msoft-floats. When I run the program on the target, it gives undefined symbols "dpmul", "dpdiv", "dpadd", "dptoi". These symbols are from the floating point library. I do have Math/C/GCC library loaded. Can anyone out there has some experience of dealing with this kind of error or some other workaround. Any pointers will be greatly appreciated. Thanks in advance -Raj

2 1

(no subject)
by Horace Lee 10 Jan '02

10 Jan '02

I crosscompiled the madplay for strongarm successfully.but when I run it to play the mp3. the following problem displayed on the screen: "/dev/tty:no such device or addr" could anybody tell me what is the reason? what is the use of tty? if you need more details about this problems,just ask me.ok? thanks a lot. Horace _________________________________________________________ Do You Yahoo!? 登录免费雅虎电邮! http://mail.yahoo.com.cn <font color=#6666FF>无聊？郁闷？高兴？没理由？都来聊天吧！</font>―― 雅虎全新聊天室! http://cn.chat.yahoo.com/c/roomlist.html

5 8

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 January 2002