From fiji at ayup.limey.net Tue Jul 1 04:36:55 2008 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 1 Jul 2008 07:36:55 -0400 Subject: [ID3 Dev] id3 tag extraction In-Reply-To: <57341.122.167.166.13.1214890025.squirrel@www.webmail.nextbitcpu.com> References: <57341.122.167.166.13.1214890025.squirrel@www.webmail.nextbitcpu.com> Message-ID: <20080701113655.GA1064@ayup.limey.net> It can be both since the ID3v2 tags are usually at the start and the ID3v1 tags must be at the end. Often taggers will add both to provide backwards compatability. In that case, I would rely on the ID3v2 tag not the ID3v1. In fact there could be an ID3v2.3 tag at the start, and an ID3v2.4 tag at the end followed by an ID3v1 tag. There could also be APE tags, LYRICS tags and other stuff... all of which define overlapping metadata. -ben On Mon, Jun 30, 2008 at 10:27:05PM -0700, dhanraj at nextbitcpu.com wrote: > Hi, > I want know how to find whether it is id3v1 or id3v2 tag while parsing > .MP3 File. > > > Please reply me... > > Thank u........ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From paul_t100 at fastmail.fm Wed Jul 2 04:40:24 2008 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 02 Jul 2008 12:40:24 +0100 Subject: [ID3 Dev] APIC frame without PictureType field Message-ID: <486B6928.4080409@fastmail.fm> I have some files with an ID3v23 tag that seem to contain an APIC frame without a PictureType field or with an invalid PictureType. According to the Spec this doesnt seem valid, but have I misread it and/or does anyone know what application it is that is doing this. here an excert of the frame 0x41 0x50 0x49 0x43 0x00 0x11 0xCF 0x20 0x00 0x00 0x00 0x69 A P I C i 0x6D 0x61 0x67 0x65 0x2F 0x70 0x6E 0x67 00x00 0xD0 0x00 0x89 0x50 0x4E 0x47 0x0D m a g e / p n g P N G So my code is currently reading the 0xD0 as an invalid Picture Type (208), but I think the file that created this has actually written the 0xD0 0x00 as the value of Description,and hasnt written a Picture Type at all. thanks Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From munish.katoch at gmail.com Tue Jul 1 00:41:16 2008 From: munish.katoch at gmail.com (Munish Katoch) Date: Tue, 1 Jul 2008 16:41:16 +0900 Subject: [ID3 Dev] Re: id3v2 ext In-Reply-To: <50816.122.167.166.13.1214896822.squirrel@www.webmail.nextbitcpu.com> References: <50816.122.167.166.13.1214896822.squirrel@www.webmail.nextbitcpu.com> Message-ID: <81e70d1d0807010041o371e8627m8c239c211e7246ac@mail.gmail.com> Hi dhanraj, Ans in lined in RED. ccing id3v2 at id3.org. And one more doubt is some mp3 file contains both id3v1 and id3v2 tag. -yes Can u tell me which one would be better to extract -You may have to parse both tags(id3v2x and id3v1x). But first priority is given to id3v2x( for a particular meta data(like title etc)). For common meta data( Common to id3v2x and id3v1x) ==> First check if meta data is present in id3v2x. If found, do not check the particular meta data in id3v1x. if not found, check the particular meta data in id3v1x. Can u tell how to decide Thanks, Munish On 7/1/08, dhanraj at nextbitcpu.com wrote: > > hi Munish, > > Thanks for the reply. > > i have written the code for extraction of id3v1 tag seperately and id3v2 > tag separately. > > but what i want to do is > if(id3v1tag) > { > extractid3v1tag();//for v1 tag > } > else > { > extractid3v2tag(); //for v2 tag > } > Can u tell how to decide........ > And one more doubt is some mp3 file contains both id3v1 and id3v2 tag. > Can u tell me which one would be better to extract > Can u tell how to decide > > Thank you............... > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fiji at ayup.limey.net Mon Jul 14 06:20:28 2008 From: fiji at ayup.limey.net (Ben Bennett) Date: Mon, 14 Jul 2008 09:20:28 -0400 Subject: [ID3 Dev] Reading the MCDI frame In-Reply-To: <32888aab0807140127l16bdd08am31bb716186023a9f@mail.gmail.com> References: <32888aab0807140127l16bdd08am31bb716186023a9f@mail.gmail.com> Message-ID: <20080714132027.GA4671@ayup.limey.net> On Mon, Jul 14, 2008 at 06:27:04PM +1000, Troy Watson wrote: > typedef struct { > char name[4]; > unsigned int size; > char flags[2]; > } ID3_FRAME; > ID3_FRAME id3_frame; This is the start of a problem. The size is not a uint in 2.4, see http://id3.org/id3v2.4.0-structure section 4: Frame ID $xx xx xx xx (four characters) Size 4 * %0xxxxxxx Flags $xx xx The frame ID is followed by a size descriptor containing the size of the data in the final frame, after encryption, compression and unsynchronisation. The size is excluding the frame header ('total frame size' - 10 bytes) and stored as a 32 bit synchsafe integer. So you need to do some bitshifting. From your example below, the size is 0x00 0x00 0x01 0x38. Ignoring the first two zero bytes you have: 0x01: 0000 0001 0x38: 0011 1000 Dropping the first column gives: *000 0001 *011 1000 And re-packing into bytes: 1011 1000 Which is 0xB8 (184 decmal). BUT BEWARE. iTunes makes the same error you made when writing 2.4 tags. They do not write syncsafe sizes so you have to be aware of that and sanity check to see if you got something that looks like a valid frame header and be prepared to try the un-syncsafe version to see if it is better. (Some small notes are at http://id3.org/iTunes) -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From drtwox at gmail.com Mon Jul 14 01:27:04 2008 From: drtwox at gmail.com (Troy Watson) Date: Mon, 14 Jul 2008 18:27:04 +1000 Subject: [ID3 Dev] Reading the MCDI frame Message-ID: <32888aab0807140127l16bdd08am31bb716186023a9f@mail.gmail.com> Hello everyone. I'm asking for some help reading (or more precisely, skipping over) the MCDI frame in id3v2.3 and id3v2.4 tagged mp3 files. I'm just starting out learning C, and as a learning exercise I've written a small metadata reader for various audio formats. However, there is one frame in some mp3s I can't, no matter how much I bang my head, work out how to skip over. My program reads the id3 header and finds the offset for the first frame in the file. From there the frame header is read into a struct like this: typedef struct { char name[4]; unsigned int size; char flags[2]; } ID3_FRAME; ID3_FRAME id3_frame; I do a strcmp against id3_frame->name to see if this is a frame I'm interested in reading. If it is I read and process it, and it it isn't, fseek forward the value from id3_frame->size. Repeat until the end of the id3 tag. This works perfectly for the few thousand mp3 files I have *except* any file with the MCDI frame. From what I can work out, the size I'm reading for the MCDI frame is way off, and any fseek moves too far into the tag, causing the next fread to get the wrong data. However, the same code works for every other file if there is no MCDI frame. Here's a hex dump of one tag as an example. 0000000: 49 44 33 04 00 00 00 00 15 0d 54 49 54 32 00 00 ID3.......TIT2.. 0000010: 00 13 00 00 03 4d 61 64 20 4d 61 78 20 28 42 61 .....Mad Max (Ba 0000020: 64 20 4c 69 66 65 29 54 52 43 4b 00 00 00 02 00 d Life)TRCK..... 0000030: 00 03 32 54 43 4f 4e 00 00 00 03 00 00 03 32 30 ..2TCON.......20 0000040: 54 41 4c 42 00 00 00 10 00 00 03 43 6f 6d 6d 65 TALB.......Comme 0000050: 72 63 69 61 6c 20 5a 6f 6e 65 4d 43 44 49 00 00 rcial ZoneMCDI.. 0000060: 01 38 00 00 46 00 2b 00 39 00 36 00 2b 00 34 00 .8..F.+.9.6.+.4. 0000070: 44 00 45 00 45 00 2b 00 39 00 36 00 30 00 30 00 D.E.E.+.9.6.0.0. 0000080: 2b 00 44 00 42 00 32 00 34 00 2b 00 31 00 31 00 +.D.B.2.4.+.1.1. 0000090: 42 00 30 00 32 00 2b 00 31 00 35 00 38 00 38 00 B.0.2.+.1.5.8.8. 00000a0: 38 00 2b 00 31 00 39 00 43 00 38 00 30 00 2b 00 8.+.1.9.C.8.0.+. 00000b0: 31 00 43 00 44 00 42 00 38 00 2b 00 32 00 30 00 1.C.D.B.8.+.2.0. 00000c0: 41 00 41 00 38 00 2b 00 32 00 33 00 37 00 43 00 A.A.8.+.2.3.7.C. 00000d0: 36 00 2b 00 32 00 37 00 31 00 43 00 38 00 2b 00 6.+.2.7.1.C.8.+. 00000e0: 32 00 42 00 45 00 38 00 41 00 2b 00 32 00 46 00 2.B.E.8.A.+.2.F. 00000f0: 41 00 34 00 45 00 2b 00 33 00 34 00 34 00 32 00 A.4.E.+.3.4.4.2. 0000100: 32 00 2b 00 33 00 41 00 43 00 36 00 45 00 2b 00 2.+.3.A.C.6.E.+. 0000110: 33 00 45 00 34 00 41 00 45 00 00 00 50 52 49 56 3.E.4.A.E...PRIV 0000120: 00 00 00 0e 00 00 50 65 61 6b 56 61 6c 75 65 00 ......PeakValue. 0000130: 27 69 00 00 50 52 49 56 00 00 00 11 00 00 41 76 'i..PRIV......Av 0000140: 65 72 61 67 65 4c 65 76 65 6c 00 ac 09 00 00 50 erageLevel.....P 0000150: 52 49 56 00 00 00 27 00 00 57 4d 2f 4d 65 64 69 RIV...'..WM/Medi 0000160: 61 43 6c 61 73 73 50 72 69 6d 61 72 79 49 44 00 aClassPrimaryID. 0000170: bc 7d 60 d1 23 e3 e2 4b 86 a1 48 a4 2a 28 44 1e .}`.#..K..H.*(D. 0000180: 50 52 49 56 00 00 00 29 00 00 57 4d 2f 4d 65 64 PRIV...)..WM/Med 0000190: 69 61 43 6c 61 73 73 53 65 63 6f 6e 64 61 72 79 iaClassSecondary 00001a0: 49 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ID.............. 00001b0: 00 00 00 50 52 49 56 00 00 00 1c 00 00 57 4d 2f ...PRIV......WM/ 00001c0: 55 6e 69 71 75 65 46 69 6c 65 49 64 65 6e 74 69 UniqueFileIdenti 00001d0: 66 69 65 72 00 3b 00 00 00 54 50 45 32 00 00 00 fier.;...TPE2... 00001e0: 12 00 00 03 50 75 62 6c 69 63 20 49 6d 61 67 65 ....Public Image 00001f0: 20 4c 54 44 2e 54 50 45 31 00 00 00 15 00 00 03 LTD.TPE1....... 0000200: 50 75 62 6c 69 63 20 49 6d 61 67 65 20 4c 69 6d Public Image Lim 0000210: 69 74 65 64 54 4c 45 4e 00 00 00 07 00 00 03 32 itedTLEN.......2 0000220: 34 36 30 30 30 00 00 00 00 00 00 00 00 00 00 00 46000........... 0000230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Here's the output when run against this file: Detected MP3, id3v2.4 frame_id: TIT2, size: 19 frame_id: TRCK, size: 2 frame_id: TCON, size: 3 frame_id: TALB, size: 16 frame_id: MCDI, size: 312 frame_id: dary, size: 1229193216 The MCDI frame size is read as 312, which is plainly NOT where the MCDI frame ends, and as such the next fread into the struct is reading from the wrong place. I've tried to find a spec for the TOC information that the MCDI frame holds, but that hasn't turned up anything useful either. The spec on id3.org has this to say: "The frame consists of a binary dump of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and then 8 bytes/track on the CD plus 8 bytes for the 'lead out',". Unless I'm reading it wrong, this file doesn't say how many tracks are on the CD, so I can't calculate the MCDI frame size this way either. Other software (Amarok for example) can read these files just fine, so the file(s) can't be corrupt. I *could* retag them all and save the headache, but I really want to know what I'm doing wrong. Please help! Note: If I've overlooked something totally obvious, or have made a bad assumption, feel free to headbut me ;) --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From drtwox at gmail.com Mon Jul 14 19:54:08 2008 From: drtwox at gmail.com (Troy Watson) Date: Tue, 15 Jul 2008 12:54:08 +1000 Subject: [ID3 Dev] Reading the MCDI frame In-Reply-To: <20080714132027.GA4671@ayup.limey.net> References: <32888aab0807140127l16bdd08am31bb716186023a9f@mail.gmail.com> <20080714132027.GA4671@ayup.limey.net> Message-ID: <32888aab0807141954y34a7551cq1804f4eae9451b78@mail.gmail.com> On 7/14/08, Ben Bennett wrote: > On Mon, Jul 14, 2008 at 06:27:04PM +1000, Troy Watson wrote: >> typedef struct { >> char name[4]; >> unsigned int size; >> char flags[2]; >> } ID3_FRAME; >> ID3_FRAME id3_frame; > > This is the start of a problem. The size is not a uint in 2.4, see > http://id3.org/id3v2.4.0-structure section 4: > > Frame ID $xx xx xx xx (four characters) > Size 4 * %0xxxxxxx > Flags $xx xx > > The frame ID is followed by a size descriptor containing the size > of > the data in the final frame, after encryption, compression and > unsynchronisation. The size is excluding the frame header ('total > frame size' - 10 bytes) and stored as a 32 bit synchsafe integer. > > So you need to do some bitshifting. From your example below, the size > is 0x00 0x00 0x01 0x38. Ignoring the first two zero bytes you have: > 0x01: 0000 0001 > 0x38: 0011 1000 > Dropping the first column gives: > *000 0001 > *011 1000 > And re-packing into bytes: > 1011 1000 > Which is 0xB8 (184 decmal). Thank you very much. I knew it was a simple thing. > BUT BEWARE. iTunes makes the same error you made when writing 2.4 > tags. They do not write syncsafe sizes so you have to be aware of > that and sanity check to see if you got something that looks like a > valid frame header and be prepared to try the un-syncsafe version to > see if it is better. (Some small notes are at http://id3.org/iTunes) > > -ben > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jmartin_92 at verizon.net Mon Jul 7 08:00:55 2008 From: jmartin_92 at verizon.net (Jim) Date: Mon, 07 Jul 2008 11:00:55 -0400 Subject: [ID3 Dev] RVA2 frame peak format In-Reply-To: <486B6928.4080409@fastmail.fm> References: <486B6928.4080409@fastmail.fm> Message-ID: <48722FA7.5020008@verizon.net> Hi. I know the RVA2 frame has been discussed before. However, was any consensus ever reached about how to handle the peak value? I've tried checking the source of a number of open source software that read or write this frame but all of them I have found so far seem to ignore or skip trying to deal with the peak value. Should it be considered an integer representation of the peak value? Or should it be considered a floating point scaled value where 1.0 would be full scale? I am leaning toward writing a 32 bit floating point value and since most other software seems to skip this value I probably wouldn't break support with whatever I write. But if there is some other standard for how this value should be handled I would like to stick with that. Thanks for any help. Jim --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org