From fiji at ayup.limey.net Tue Apr 3 08:09:07 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 3 Apr 2007 11:09:07 -0400 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <46126822.50409@fastmail.fm> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> <46126822.50409@fastmail.fm> Message-ID: <20070403150907.GA30769@ayup.limey.net> On Tue, Apr 03, 2007 at 03:43:46PM +0100, Paul Taylor wrote: > Ben thanks for the example but not sure that I follow shouldnt it be > > 00000000 00000000 0000011*1* *0*0111000 > > ,i.e bit 7 is always zero and what would be bit7 is shifted into the the > next byte. You are absolutely correct. I am clearly doing too many things at once today :-( > >The hell part arises because some software (iTunes) does not implement > >the spec correctly and reads and writes regular integers rather than > >unsyncronized ones when dealing with 2.4. :-( > > > > > Oh dear, what have others done about this then. It also leads me to > wonder whether I should even write v24Frame syncsafe integers by > default. For ID3v23 I always unsynced the tag where required but because > this caused a problem for Itunes Ive changed the default so that it > doesnt write them unsynced. Yes you should write syncsafe integers it is not optional in 2.4, and not doing so would break a bunch of other software. There is a bug in with Apple about this and someone was being pretty responsive about other issues for a while... hopefully that will get fixed. I would prefer unsynced 2.3 tags where possible for the widest compability. If you need to write a 2.4 tag, then I would try to order the frames so that the large ones are at the end of the tag... if the size is misinterpreted they over-read the length, and iTunes at least stopes when it hits the end of the frame. Since these large frames are usually images, iTunes interprets the contents correctly and displays the image and then ignores any trailing stuff from where it overread. Note that when reading a 2.4 tag, you need to implement heuristics to pick up on iTunes' messed up frames. You can look at the size and see if it could be syncsafe (i.e. if any high bits are set on the 4 bytes then you know it is not syncsafe), and if it could be syncsafe then you will need to read to the end of the frame then check to see if the next data looks like a frame (or if you have hit the end of the buffer). In which case you need to try it as a non-syncsafe length and see if you find a valid frame. This is all assuming the frame length is 255 or more, if it's less then you are all set. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Sun Apr 15 04:10:09 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Sun, 15 Apr 2007 11:10:09 +0000 (GMT) Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio Message-ID: <188244.3133.qm@web27004.mail.ukl.yahoo.com> Hello, for this exact reason there is the unsynchronisation scheme. If you parse the ID3 tag for any FF E0 patterns, you may find false MPEG frame headers within the tag data. For such non-ID3 compliant implementations the tag MUST be unsynchronised. If it is not, the parser usually can't handle the file. Old MP3 implementations have the same problem. I don't know any solution for this problem and I really suggest to don't use this method to determine the ID3 tag size. The ID3 tag size is written correctly by most programs anyway (I didn't encounter any problems with reading the tag size so far). Cheers. Mathias ----- Urspr?ngliche Mail ---- Von: Paul Taylor An: id3v2 at id3.org Gesendet: Sonntag, den 15. April 2007, 12:14:48 Uhr Betreff: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio Hi, in my id3 library I made the decision to find the start of the MP3Audio first, and then read the ID3tag starting from the start of the file upto the start of the MP3Audio. I did it this way rather than reading the ID3Tag Size from the ID3 tag header and using this size as the basis of the tag. I did this because there are so many application that make mistakes when writing ID3 tags, whereas applications that encode mp3s do the encoding correctly, so as long as I identify the start of the mp3 correctly there is no problem with accidently overwriting mp3 info with the ID3 tag. This is how I find the MP3 Audio WHILE BYTES EXIST { Get next byte IF match two bytes:0xFF and 0xE0 (or greater) { IF can map these and next two bytes to a MPEG frame header (mapping to valid values (BitRate,Samplingrate ....) { IF can map this frame to a XING Frame { FOUND MATCH Break } ELSE { skip to end of this MPEG frame as reported in header IF( can map next four bytes to a MPEG frame header) { FOUND MATCH Break } ELSE { No match Found CONTINUE } } } ELSE { No match Found CONTINUE } } ELSE { No match found CONTINUE } } So in summary I find a potental match, map it to an MPEG frame if it maps to a Xing frame I'm done, if not I try to match the next frame to see if its an audio frame, if it I'm done, if not these are not valid mp3 audio so carry on searching. The only time I find a potential invalid match is when the ID3 tag is not unsynchronised, now I thought this happened quite rarely for just frames such as APIC frames but Ive now realised that if the text frames are encoded as UTF16 with Little Endian BOM then every text frame will start with FF FE and if it isnt unsychronised there is a real chance that the size read in the text frame (when read as an MPEG frame) could endup with me getting an invalid match to a second frame. So my question is is there something about the byte combination FF FE that would allow me to identify that it is definently NOT the start of MP3 Audio frame. thanks paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org __________________________________ Kennt man wirklich jeden ?ber 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From bam at iis.fraunhofer.de Wed Apr 11 05:53:31 2007 From: bam at iis.fraunhofer.de (Oliver Baum) Date: Wed, 11 Apr 2007 14:53:31 +0200 Subject: [ID3 Dev] Hardware MP3 Player with SYLT Support? Message-ID: <461CDA4B.2000209@iis.fraunhofer.de> Hello list, is anyone of You aware of a hardware MP3 player that supports the SYLT (synchronized lyrics) ID3v2.3/2.4 tag? Thank You for Your help in advance! Best regards, Oliver -- Dipl.-Ing. Oliver Baum Multimedia Transport Group, Audio Department Fraunhofer Institute for Integrated Circuits IIS Am Wolfsmantel 33 91058 Erlangen Germany Phone: +49 9131 776-319 Fax: +49 9131 776-398 --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Thu Apr 5 16:46:27 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Thu, 5 Apr 2007 19:46:27 -0400 Subject: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? In-Reply-To: <195049.65523.qm@web27004.mail.ukl.yahoo.com> References: <195049.65523.qm@web27004.mail.ukl.yahoo.com> Message-ID: <20070405234627.GA28963@ayup.limey.net> On Thu, Apr 05, 2007 at 09:56:40PM +0000, Mathias Kunter wrote: > ...why should iTunes NOT write null terminated strings?? > > >From the 2.2 / 2.3 text frame specs: > > "If the textstring is followed by a termination ($00 (00)) all the following > information should be ignored and not be displayed." > > So I would say it even is good practice to write a terminating 00 (or > 00 00 in Unicode) to a text frame. Or did I misunderstand you? Consensus from previous discussions was that this was not great practice in 2.4. A dumb implementation might consider the 0-length string between the terminator and the end of the frame data as a second value. I think the smart implementation would be to omit the trailing terminator (so only use it to separate lists) when writing. When reading they should ensure that a trailing terminator is not treated as a 0-length item. In 2.3, it is less of a concern. I omit it in my writer if the frame is changed. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Sun Apr 15 14:42:16 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Sun, 15 Apr 2007 17:42:16 -0400 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <4622686A.2070700@fastmail.fm> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> <20070415154136.GA32704@ayup.limey.net> <4622686A.2070700@fastmail.fm> Message-ID: <20070415214216.GA24868@ayup.limey.net> On Sun, Apr 15, 2007 at 07:01:14PM +0100, Paul Taylor wrote: > Ben Bennett wrote: > It seems a bit arbitary, my original method wont work because we may get > false synchronisations in the ID3 tag, Note that the false sync is not due to any bugs, the person writing the tag may have chosen not to unsynchronize it (in fact, I would recommend that most people _not_ unsync the tags). > yet we can trust the ID3 header size because it is always calculated > correctly. Well, the tag size part of the spec has not changed in a long long time. > Well I guess you are ther authority on the subject Ha! > thanks for your advice I think I will rework my code to read from > the ID3 header upto the size reported, and then check that MP3Audio > starts immediately afterwards for peace of mind. But IF the mp3 > header does not start then we have a problem, Ill let you know if I > have any files that fall into that category. That sounds like a good sanity check... but I would not be surprised if you found strange new tags... -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Tue Apr 3 05:54:12 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 3 Apr 2007 08:54:12 -0400 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <4611E77E.3020308@fastmail.fm> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> Message-ID: <20070403125412.GA24721@ayup.limey.net> On Tue, Apr 03, 2007 at 06:34:54AM +0100, Paul Taylor wrote: > Its V24, what are their different ways of writing frame sizes ? Welcome to syncsafe size hell. Basically, in 2.4 the frame sizes are written as syncsafe integers, whereas in 2.3 they were normal integers. http://id3.org/id3v2.4.0-structure has the full details (see section 4 for the frame header info, and section 6.2 for the unsync integer info). The short version is: If the size is 1000, then that is 0x03e8 (hex) which is: 00000000 00000000 00000011 10111000 But syncsafe numbers are basically spread out so they never put values in the high bit of a byte (e.g. X0000000). So the above becomes: 00000000 00000000 00000110 10111000 ^-- added Which is the number 0x06e8 which is 1768 (decimal). The hell part arises because some software (iTunes) does not implement the spec correctly and reads and writes regular integers rather than unsyncronized ones when dealing with 2.4. :-( -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From Brian at schif.org Tue Apr 3 09:07:28 2007 From: Brian at schif.org (Brian Schiffhauer) Date: Tue, 3 Apr 2007 12:07:28 -0400 Subject: [ID3 Dev] How do I deal with this problem COMM frame References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> <002e01c775f1$40b106a0$7b55503f@useronewin2klt> <461252ED.6000604@kde.org> <20070403142823.GA27122@ayup.limey.net> Message-ID: <006c01c7760a$2e489e10$7b55503f@useronewin2klt> ty, good explanation! ;) ----- Original Message ----- From: "Ben Bennett" To: Sent: Tuesday, April 03, 2007 10:28 Subject: Re: [ID3 Dev] How do I deal with this problem COMM frame > On Tue, Apr 03, 2007 at 03:13:17PM +0200, Scott Wheeler wrote: >> Brian Schiffhauer wrote: >> >I was just wondering ... what is the purpose of a syncsafe integer? >> >> To avoid false MPEG synchs (a pattern of 11 true bits). > > To expand a bit, soemthing reading an MPEG stream needs to know where > the frames start (if it is picking up in the middle, or if there is > unexpected leading or trailint stuff, etc). So it looks for the synch > information (and can use some othe things to sanity check... but it is > not perfect) by scanning the stream until it sees 11 true bits (or if > it has byte level framing information, one byte with all bits set > true, followed by one with the first three set true) then it assumes > it has an MPEG frame and treats the rest as something to decode. So > if your tag contains something that matches that pattern, and your > player doesn't know how to parse ID3v2 tags, there is a risk of treating > the ID3v2 data as mpeg data and making the decoded stream contain a > burst of noise. > > So the ID3v2.3 spec implemented tag level unsynchronization for the > tag body (i.e. all the frames) and used synchsafe integers in the tag > header, but that is not particularly efficient to decode (i.e. you > need to hold the whole thing in memory and then apply the rules to > remove the unschronization). So in 2.4 they added frame-level unsynch > (and changed the meaning of the tag level unsynch flag) which > necessitated the change to syncsafe integers for the length (and > rejiggering of flags, etc.) in the frame headers since they are no > longer protected by whole-tag unsynch. > > I hope I haven't befuddled you... > > -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 paul_t100 at fastmail.fm Wed Apr 25 02:20:52 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 25 Apr 2007 10:20:52 +0100 Subject: [ID3 Dev] Comments Frame questions Message-ID: <462F1D74.8090907@fastmail.fm> A couple of questions about the COMM frame: I keep on coming across COMM frames which have a language code of ' ' (three space characters), is this valid and if not would it be acceptable/desirable for a tag editor to just set it to 'eng' (on the basis that this is most common language for recorded songs). In the compliance issues it says 'Winamp does not take into account the Description field of the Comments (COMM) frame when reading a tag with more than one COMM frame. Instead of using the COMM frame where the Description field is blank to set the "Comment" field on the "MPEG file info + ID3 tag editor", Winamp displays whichever COMM frame happens to be read *last*. So, if another app writes two COMM frames to a tag, one without a Description value followed by one with a Description, Winamp will ignore the first generic COMM frame and use the second. This was can happen when using MusicMatch Jukebox to edit a tag (which properly uses COMM frames with Description values to store its Preference, Mood, Situation, and Tempo fields) and using Winamp to read tag. (Fixed as of Winamp 5.2)' I cant find anything in the spec that says that a Comment with an empty description is the default/genreci comment is this actually in the spec. thanks Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jwhite at cdtag.com Tue Apr 3 00:15:56 2007 From: jwhite at cdtag.com (Jud White) Date: Tue, 03 Apr 2007 02:15:56 -0500 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <4611E77E.3020308@fastmail.fm> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> Message-ID: <4611FF2C.20805@cdtag.com> ID3v2.4 uses syncsafe frame sizes, the same way the tag size is written. The COMM frame you're talking about may not be corrupt. Paul Taylor wrote: > Its V24, what are their different ways of writing frame sizes ? > Jud White wrote: >> Have you tested to see if it's written with a syncsafe frame size? >> What ID3 version? >> >> Paul Taylor wrote: >>> In my ID3 Tag library I am having problems with a particular tag. I >>> have a tag with a problem COMM frame, the COMM frame says that it is >>> 1000 bytes long, whereas in fact it is only about 500 bytes long. >>> The end result is that next 500 bytes of the ID3 tag are assumed to >>> be part of the Comment description when in fact they are other >>> frames, and no more frames are loaded after the COMM frame because >>> immediately after 1000 bytes after the COMM frame there is not a >>> valid frame identifier. There are lots of valuable frames after the >>> COMM frame and I would like my tag library to load as much >>> information as I can. >>> >>> Any ideas how I should: >>> Deal with frames in general that have an invalid size in their >>> header, >>> Determine in the */COMM.The actual text field/* the end of the >>> real data, I thought I could look for null terminaters because there >>> should be any in this field >>> >>> thanks Paul >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> >> > > > --------------------------------------------------------------------- > 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 Thu Apr 5 13:58:02 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 05 Apr 2007 21:58:02 +0100 Subject: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? In-Reply-To: <46156F62.20402@coe.neu.edu> References: <46156027.8050201@fastmail.fm> <46156F62.20402@coe.neu.edu> Message-ID: <461562DA.1080205@fastmail.fm> Brian Mearns wrote: > Well, if you look at the specification, it says that ALL text frames > support multiple strings, in the form of a null separated list. This > could be the reason they're doing it, though I'd say it's still pretty > superfluous. But that's my best guess. Not until v2.4 is this the case --------------------------------------------------------------------- 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 Fri Apr 6 01:41:30 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 09:41:30 +0100 Subject: AW: AW: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? In-Reply-To: <4615EBB3.5070509@fastmail.fm> References: <231573.63393.qm@web27002.mail.ukl.yahoo.com> <4615EBB3.5070509@fastmail.fm> Message-ID: <461607BA.7070508@fastmail.fm> Am I going mad, for a particular file Ive been looking at I'm now seeing these square characters actually in Itunes (Itunes 7/Windows), as if Itunes isn't expecting them ! Paul Taylor wrote: > Mathias Kunter wrote: >> I meant you should never display a null terminator in an user interface >> (how would you actually do that?) >> >> cheers >> Mathias >> > Yeah I think my problem has been that I was displaying the > terminator, as I viewed it as part of the String when found in places > where a terminator was not requested by spec, in my application it > just looked like > a small square, because as you say it cannot be displayed properly. I > think I will change things to strip out these characters when reading, > and on writing the tag I will not write them. > > Paul > >> >> >> >> >> >> >> >> >> ___________________________________________________________ Der fr?he >> Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: >> http://mail.yahoo.de >> >> >> > > > --------------------------------------------------------------------- > 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 Tue Apr 3 07:43:46 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 03 Apr 2007 15:43:46 +0100 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <20070403125412.GA24721@ayup.limey.net> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> Message-ID: <46126822.50409@fastmail.fm> Ben Bennett wrote: > On Tue, Apr 03, 2007 at 06:34:54AM +0100, Paul Taylor wrote: > >> Its V24, what are their different ways of writing frame sizes ? >> > > Welcome to syncsafe size hell. > > Basically, in 2.4 the frame sizes are written as syncsafe integers, > whereas in 2.3 they were normal integers. > > http://id3.org/id3v2.4.0-structure has the full details (see section 4 > for the frame header info, and section 6.2 for the unsync integer info). > The short version is: > If the size is 1000, then that is 0x03e8 (hex) which is: > 00000000 00000000 00000011 10111000 > But syncsafe numbers are basically spread out so they never put > values in the high bit of a byte (e.g. X0000000). So the above > becomes: > 00000000 00000000 00000110 10111000 > ^-- added > Which is the number 0x06e8 which is 1768 (decimal). > Ben thanks for the example but not sure that I follow shouldnt it be 00000000 00000000 0000011*1* *0*0111000 ,i.e bit 7 is always zero and what would be bit7 is shifted into the the next byte. > The hell part arises because some software (iTunes) does not implement > the spec correctly and reads and writes regular integers rather than > unsyncronized ones when dealing with 2.4. :-( > > -ben > Oh dear, what have others done about this then. It also leads me to wonder whether I should even write v24Frame syncsafe integers by default. For ID3v23 I always unsynced the tag where required but because this caused a problem for Itunes Ive changed the default so that it doesnt write them unsynced. paul --------------------------------------------------------------------- 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 Fri Apr 6 07:58:52 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 15:58:52 +0100 Subject: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <20070406145046.GA21559@ayup.limey.net> References: <896838.69373.qm@web27010.mail.ukl.yahoo.com> <46165BCE.3050105@fastmail.fm> <20070406145046.GA21559@ayup.limey.net> Message-ID: <4616602C.2010905@fastmail.fm> Ben Bennett wrote: > On Fri, Apr 06, 2007 at 03:40:14PM +0100, Paul Taylor wrote: > >> Mathias Kunter wrote: >> >>> >>> >> This is what I was trying to get at. Is a frame unsynchronized IF it >> doesnt contain FF FE patterns or ONLY IF it has actually been >> unsynchronized meaning that FF 00 >> > > If the tag unsync flag is set, then each frame unsync flag must be > set. > > If a frame unsync flag is set, then you need to un-unsync the contents > to read it. Yeah ok, but then that means that the flag is only set if every frame has actually been unsynchronized. Surely the odds chances of every frame having an FF FE combination requiring them to be unsynchronized is extremely small, simple text frames like TALB and TIT2 are not going to need unsynchronization. --------------------------------------------------------------------- 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 Tue Apr 3 08:46:10 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 03 Apr 2007 16:46:10 +0100 Subject: [ID3 Dev] Is the DataLengthIndicator included in the Frame Size? Message-ID: <461276C2.7020208@fastmail.fm> In ID3v24 if there is 4 byte DataLengthIndicator field after the header is it included in the size of the frame. I know the header is not included when calculating the size and the body is, but where does this field fit in. With regard to Unsynced frames Im not sure what Im meant to do with the value once I read it,is it meant to equal the un-unsynced length of the framebody ? --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Fri Apr 6 08:17:28 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 6 Apr 2007 15:17:28 +0000 (GMT) Subject: AW: [ID3 Dev] Forum Message-ID: <446223.88421.qm@web27010.mail.ukl.yahoo.com> I would also appreciate a forum! Mathias ----- Urspr?ngliche Mail ---- Von: Jim An: id3v2 at id3.org Gesendet: Freitag, den 6. April 2007, 16:17:37 Uhr Betreff: Re: [ID3 Dev] Forum I think a forum would be a big improvement over the mailing list as long as you can find a couple people willing to help with the administration of it. I think it would really help with searching for answers to questions that have been asked a lot...maybe even lead to creating some sticky posts with an updated FAQ of sorts. Jim ----- Original Message ----- From: "Jud White" To: Sent: Friday, April 06, 2007 9:55 AM Subject: [ID3 Dev] Forum Not sure if there's a historical reason behind the mailing list... but.. Would anyone prefer a phpBB or vBulletin forum? There seem to be a lot of repeat questions on the list lately. And currently messages to the list are removed after 90 days.. ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > 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 ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- 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 Tue Apr 3 08:19:35 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 03 Apr 2007 16:19:35 +0100 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <20070403150907.GA30769@ayup.limey.net> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> <46126822.50409@fastmail.fm> <20070403150907.GA30769@ayup.limey.net> Message-ID: <46127087.8010107@fastmail.fm> Ben Bennett wrote: > Yes you should write syncsafe integers it is not optional in 2.4, and > not doing so would break a bunch of other software. There is a bug in > with Apple about this and someone was being pretty responsive about > other issues for a while... hopefully that will get fixed. > > I would prefer unsynced 2.3 tags where possible for the widest > compability. If you need to write a 2.4 tag, then I would try to > order the frames so that the large ones are at the end of the > tag... if the size is misinterpreted they over-read the length, and > iTunes at least stopes when it hits the end of the frame. Since these > large frames are usually images, iTunes interprets the contents > correctly and displays the image and then ignores any trailing stuff > from where it overread. > > Note that when reading a 2.4 tag, you need to implement heuristics to > pick up on iTunes' messed up frames. You can look at the size and see > if it could be syncsafe (i.e. if any high bits are set on the 4 bytes > then you know it is not syncsafe), and if it could be syncsafe then > you will need to read to the end of the frame then check to see if the > next data looks like a frame (or if you have hit the end of the > buffer). In which case you need to try it as a non-syncsafe length > and see if you find a valid frame. This is all assuming the frame > length is 255 or more, if it's less then you are all set. > > -ben > Ok, all make sense I will do as you say. This kind of information would be very as some kind of companion document to the ID3 Specifications, providing advise on the best way to implement the specification in the real world, anybody agree ? --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Tue Apr 3 07:28:23 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 3 Apr 2007 10:28:23 -0400 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <461252ED.6000604@kde.org> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> <002e01c775f1$40b106a0$7b55503f@useronewin2klt> <461252ED.6000604@kde.org> Message-ID: <20070403142823.GA27122@ayup.limey.net> On Tue, Apr 03, 2007 at 03:13:17PM +0200, Scott Wheeler wrote: > Brian Schiffhauer wrote: > >I was just wondering ... what is the purpose of a syncsafe integer? > > To avoid false MPEG synchs (a pattern of 11 true bits). To expand a bit, soemthing reading an MPEG stream needs to know where the frames start (if it is picking up in the middle, or if there is unexpected leading or trailint stuff, etc). So it looks for the synch information (and can use some othe things to sanity check... but it is not perfect) by scanning the stream until it sees 11 true bits (or if it has byte level framing information, one byte with all bits set true, followed by one with the first three set true) then it assumes it has an MPEG frame and treats the rest as something to decode. So if your tag contains something that matches that pattern, and your player doesn't know how to parse ID3v2 tags, there is a risk of treating the ID3v2 data as mpeg data and making the decoded stream contain a burst of noise. So the ID3v2.3 spec implemented tag level unsynchronization for the tag body (i.e. all the frames) and used synchsafe integers in the tag header, but that is not particularly efficient to decode (i.e. you need to hold the whole thing in memory and then apply the rules to remove the unschronization). So in 2.4 they added frame-level unsynch (and changed the meaning of the tag level unsynch flag) which necessitated the change to syncsafe integers for the length (and rejiggering of flags, etc.) in the frame headers since they are no longer protected by whole-tag unsynch. I hope I haven't befuddled you... -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Fri Apr 6 07:08:22 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 6 Apr 2007 10:08:22 -0400 Subject: [ID3 Dev] Forum In-Reply-To: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> References: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> Message-ID: <20070406140822.GB19474@ayup.limey.net> Can we just archive things for a longer time? I prefer email to forums since I never remember to check in on a forum... I have been meaning to update the wiki with some of this, but... time has been tight recently. -ben On Fri, Apr 06, 2007 at 08:55:32AM -0500, Jud White wrote: > Not sure if there's a historical reason behind the mailing list... but.. > > Would anyone prefer a phpBB or vBulletin forum? > > There seem to be a lot of repeat questions on the list lately. And currently messages to the list are removed after 90 days.. > > > > --------------------------------------------------------------------- > 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 fiji at ayup.limey.net Fri Apr 6 07:06:03 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 6 Apr 2007 10:06:03 -0400 Subject: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <46164D7D.7040801@fastmail.fm> References: <46164D7D.7040801@fastmail.fm> Message-ID: <20070406140603.GA19474@ayup.limey.net> On Fri, Apr 06, 2007 at 02:39:09PM +0100, Paul Taylor wrote: > >From IDv3v24 Spec ' Bit 7 in the 'ID3v2 flags' indicates whether or not > >unsynchronisation is applied on all frames (see section 6.1 for > >details); a set bit indicates usage.' > > What exactly does this mean, and what is its purpose? If I have a tag with > 10 frames, and only one of those frames actually contains a FF FE pattern, > and this frame is synchronized, and there is nothing to for the other nine, > does that mean the tag unsynchronisation flag is on/off. The rule is defined in http://id3.org/id3v2.4.0-structure section 3.1: a - Unsynchronisation Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is applied on all frames (see section 6.1 for details); a set bit indicates usage. So, unless all frames have the unsync flag set, this should not be set. > Or if one of the other frames does not contain a FF FE pattern but does > contain a FF 00 pattern should that frame be unsynchronized (even though it FF 00 is fine and will not cause a sync problem. Note that the unsynchronization algorithm is different from a syncsafe integer. A syncsafe integer is one that just skips the high bits in its 4 bytes (so it only stores 28 bits of data, so the max is 268435455). Whereas the unsync algorithm is needed if you have the byte pattern: %11111111 111xxxxx If you do, only then should you do unsync (if requested). If you are performing unsync then any $FF is replaced by $FF 00... so you actually uncynchronize more than what is strictly necessary to be syncsafe. e.g., if you had the frame data: $FF 00 If uncync is requested by the user, you should not do it on this frame since it is unnecessary. But if the frame data is: $FF 00 FF FF Then if unsync was requested, then you need to do it on this frame, which results in: $FF 00 00 FF 00 FF 00 > creates more work at decoding and encoding ends) and only if all these > cases were covered would the tag unsynchronisation flag be on. It depends who you think will be using the final file. Unsync is only ever needed if you are dealing with software that does not understand how to skip over ID3v2 tags and instead might go into "scan for an MPEG sync" mode. Frankly, modern software knows how to skip ID3v2 frames, so I would avoid unsync. There may well be hardware players, or older software that still breaks, so you have to think of who will be using the file. I try to avoid setting any of the header flags since I suspect the options are not well supported, and also, the flag byte format changed (the bits indicating which is which) moved around between 2.3 and 2.4 and I have seen iTunes mess up the flags when converting a tag from 2.3 to 2.4. (I am not sure if that is current behavior or not, it may have been fixed). > If the tag contains 10 frames and non of the frames contain an FF FE or FF > 00 pattern, then unsynchronization would have no effect should the flag be > on/off I would set it off if possible. I bet not all players support it correctly, and even if they do, not having to do unsync is faster. Of course... I do not trust the tag level flag in 2.4, I look at the frames regardless. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From bmearns at coe.neu.edu Thu Apr 5 14:51:30 2007 From: bmearns at coe.neu.edu (Brian Mearns) Date: Thu, 05 Apr 2007 16:51:30 -0500 Subject: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? In-Reply-To: <46156027.8050201@fastmail.fm> References: <46156027.8050201@fastmail.fm> Message-ID: <46156F62.20402@coe.neu.edu> Well, if you look at the specification, it says that ALL text frames support multiple strings, in the form of a null separated list. This could be the reason they're doing it, though I'd say it's still pretty superfluous. But that's my best guess. Paul Taylor wrote: > Most people on this list knows that Itunes writes null terminated > strings, but does anyone know why - did they just make a mistake or is > there a reason for it ? > I ask because I would like to know what you would expect a tag editor to > do with these values. > > It could display these null terminators but this doesnt make much sense > to user using the tag editor > It could silently hide these null terminators from view, but they they > would remain in the file possibly causing problems for other applications > It could provide an option to explicity remove these null terminators > when the records are loaded, and remove them when they are saved, but > would this cause any kind of problem for Itunes > > thanks Paul > > > --------------------------------------------------------------------- > 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 jmartin92 at comcast.net Fri Apr 6 07:17:37 2007 From: jmartin92 at comcast.net (Jim) Date: Fri, 6 Apr 2007 10:17:37 -0400 Subject: [ID3 Dev] Forum References: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> Message-ID: <002101c77856$92264290$6501a8c0@xp1800desk> I think a forum would be a big improvement over the mailing list as long as you can find a couple people willing to help with the administration of it. I think it would really help with searching for answers to questions that have been asked a lot...maybe even lead to creating some sticky posts with an updated FAQ of sorts. Jim ----- Original Message ----- From: "Jud White" To: Sent: Friday, April 06, 2007 9:55 AM Subject: [ID3 Dev] Forum Not sure if there's a historical reason behind the mailing list... but.. Would anyone prefer a phpBB or vBulletin forum? There seem to be a lot of repeat questions on the list lately. And currently messages to the list are removed after 90 days.. ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > 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 dalepres at msn.com Fri Apr 6 18:58:08 2007 From: dalepres at msn.com (Dale Preston) Date: Fri, 6 Apr 2007 20:58:08 -0500 Subject: [ID3 Dev] Forum In-Reply-To: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> References: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> Message-ID: The number of posts in the mailing list is very manageable. In other lists where there are dozens or even hundreds of posts a day, a forum is much nicer but I like the list for ID3 because it is manageable. Dale -----Original Message----- From: Jud White [mailto:jwhite at cdtag.com] Sent: Friday, April 06, 2007 8:56 AM To: id3v2 at id3.org Subject: [ID3 Dev] Forum Not sure if there's a historical reason behind the mailing list... but.. Would anyone prefer a phpBB or vBulletin forum? There seem to be a lot of repeat questions on the list lately. And currently messages to the list are removed after 90 days.. --------------------------------------------------------------------- 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 Sun Apr 8 03:26:49 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 08 Apr 2007 11:26:49 +0100 Subject: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <20070406174533.GA27656@ayup.limey.net> References: <955474.21459.qm@web27006.mail.ukl.yahoo.com> <20070406174533.GA27656@ayup.limey.net> Message-ID: <4618C369.10107@fastmail.fm> ok i'll summarize, you have three options on a frame basis 1. Dont unsynchronize it, (the preferred option) 2. Unsynchronize it regardless of its contents and set the flag 3. Unsynchronize it only if unsynchronization is required, and set the flag Only set the tag flag if you did option 2 (3 is theoretically possible but unlikely) However it never occurred to me that you could unsynchronize by simply replace all occurences of FF with FF 00. What I do is iterate though the data looking for an 0xFF, then if the next byte is 0xE0 (or greater) I insert an Ox00, or if the next byte is 0x00 I insert an additional 0x00, this method seems to be what the Spec describes. This method increases the time to encode but reduces the time to decode but I cant see that it matters which way you do. Paul Ben Bennett wrote: > On Fri, Apr 06, 2007 at 03:16:30PM +0000, Mathias Kunter wrote: > >> It is safe to insert a 00 byte after every FF byte WHEN applying the >> unsync scheme. As Ben said, this may also inserts a 00 byte where >> not really nescessary, but it is easier to implement and also works >> fine because a decoder has to replace EVERY $FF $00 byte sequence. >> > > Just to clarify what I think we are both trying to get across... > > If you are doing unsync... then you MUST insert $00 after all $FFs. > This is mandatory regarless of whether it is needed. The only point I > was trying to make was unsync may change places that are actually > syncsafe. > > -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 jwhite at cdtag.com Mon Apr 2 14:39:08 2007 From: jwhite at cdtag.com (Jud White) Date: Mon, 02 Apr 2007 16:39:08 -0500 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <46117420.8000004@fastmail.fm> References: <46117420.8000004@fastmail.fm> Message-ID: <461177FC.1010600@cdtag.com> Have you tested to see if it's written with a syncsafe frame size? What ID3 version? Paul Taylor wrote: > In my ID3 Tag library I am having problems with a particular tag. I > have a tag with a problem COMM frame, the COMM frame says that it is > 1000 bytes long, whereas in fact it is only about 500 bytes long. The > end result is that next 500 bytes of the ID3 tag are assumed to be > part of the Comment description when in fact they are other frames, > and no more frames are loaded after the COMM frame because immediately > after 1000 bytes after the COMM frame there is not a valid frame > identifier. There are lots of valuable frames after the COMM frame and > I would like my tag library to load as much information as I can. > > Any ideas how I should: > Deal with frames in general that have an invalid size in their header, > Determine in the */COMM.The actual text field/* the end of the real > data, I thought I could look for null terminaters because there should > be any in this field > > thanks Paul > > > > --------------------------------------------------------------------- > 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 Fri Apr 6 03:42:51 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 11:42:51 +0100 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <20070403150907.GA30769@ayup.limey.net> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> <46126822.50409@fastmail.fm> <20070403150907.GA30769@ayup.limey.net> Message-ID: <4616242B.5070602@fastmail.fm> Ben Bennett wrote: > Note that when reading a 2.4 tag, you need to implement heuristics to > pick up on iTunes' messed up frames. You can look at the size and see > if it could be syncsafe (i.e. if any high bits are set on the 4 bytes > then you know it is not syncsafe), and if it could be syncsafe then > you will need to read to the end of the frame then check to see if the > next data looks like a frame (or if you have hit the end of the > buffer). In which case you need to try it as a non-syncsafe length > and see if you find a valid frame. This is all assuming the frame > length is 255 or more, if it's less then you are all set. > > -ben > > Actually I think the safe limit is 127 (01111111), any higher than that and sysncsafe/nonsyncsafe vary, although if the value is between 127 and 255 you can guarantee it is NOT sync safe. paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Sun Apr 15 13:02:20 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Sun, 15 Apr 2007 20:02:20 +0000 (GMT) Subject: AW: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio Message-ID: <95628.15393.qm@web27005.mail.ukl.yahoo.com> >I will rework my code to read from the ID3 header upto the size reported, and >then check that MP3Audio starts immediately afterwards for peace of >mind. But IF the mp3 header does not start then we have a problem, Ill >let you know if I have any files that fall into that category. Yes, that would be interesting to know. Mathias Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie?s mit dem neuen Yahoo! Mail. www.yahoo.de/mail --------------------------------------------------------------------- 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 Fri Apr 6 07:40:14 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 15:40:14 +0100 Subject: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <896838.69373.qm@web27010.mail.ukl.yahoo.com> References: <896838.69373.qm@web27010.mail.ukl.yahoo.com> Message-ID: <46165BCE.3050105@fastmail.fm> Mathias Kunter wrote: > If the TAG header unsync bit is set this means that ALL frames within this tag have > been unsynced, and that ALL frames MUST contain the unsync bit set in the > FRAME header flags therefore (as defined by the specs). In my current ID3 implementation > I de-unsync a frame if either the TAG flag is set or if the FRAME flag is set for > the particular frame. > > Note that if a frame has been unsynced this doesn't mean that this frame actually got > modified. (Well, the specs say that the flag SHOULD only be set if the frame became > actually modified because of a false sync, but you can't rely on that). > This is what I was trying to get at. Is a frame unsynchronized IF it doesnt contain FF FE patterns or ONLY IF it has actually been unsynchronized meaning that FF 00 will become FF 00 00 even if there were no FF FE Patterns in the existing data. You seem to be saying you follow the first case, but point out the spec says the second case. > So if the frame header flag is set it is guaranteed that this frame (or all frames, if the > tag header flag is set) contain no false sync signal in it. It does NOT mean that the > frame content actually became modified, as mentioned before. From the decoder > point of view, this doesn't matter anyway. Just de-unsync the frame by replacing all > $FF $00 byte sequences with $FF bytes. > From the decoder point of view it DOES MATTER because if you had a frame with a $FF $00 combination and you didnt unsynchronize the frame because there was no $FF $FE combinations and then a decoder tried to de-unsync the frame it would remove the 00, and your data will be modified > Cheers. > Mathias > Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From Brian at schif.org Tue Apr 3 06:09:01 2007 From: Brian at schif.org (Brian Schiffhauer) Date: Tue, 3 Apr 2007 09:09:01 -0400 Subject: [ID3 Dev] How do I deal with this problem COMM frame References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> Message-ID: <002e01c775f1$40b106a0$7b55503f@useronewin2klt> I was just wondering ... what is the purpose of a syncsafe integer? ----- Original Message ----- From: "Ben Bennett" To: Sent: Tuesday, April 03, 2007 08:54 Subject: Re: [ID3 Dev] How do I deal with this problem COMM frame > On Tue, Apr 03, 2007 at 06:34:54AM +0100, Paul Taylor wrote: >> Its V24, what are their different ways of writing frame sizes ? > > Welcome to syncsafe size hell. > > Basically, in 2.4 the frame sizes are written as syncsafe integers, > whereas in 2.3 they were normal integers. > > http://id3.org/id3v2.4.0-structure has the full details (see section 4 > for the frame header info, and section 6.2 for the unsync integer info). > The short version is: > If the size is 1000, then that is 0x03e8 (hex) which is: > 00000000 00000000 00000011 10111000 > But syncsafe numbers are basically spread out so they never put > values in the high bit of a byte (e.g. X0000000). So the above > becomes: > 00000000 00000000 00000110 10111000 > ^-- added > Which is the number 0x06e8 which is 1768 (decimal). > > The hell part arises because some software (iTunes) does not implement > the spec correctly and reads and writes regular integers rather than > unsyncronized ones when dealing with 2.4. :-( > > -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 paul_t100 at fastmail.fm Tue Apr 3 02:31:23 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 03 Apr 2007 10:31:23 +0100 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <4611FF2C.20805@cdtag.com> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <4611FF2C.20805@cdtag.com> Message-ID: <46121EEB.1030908@fastmail.fm> Oh gosh, you're right Id never noticed this difference between v23 and v24, at least this is only a problem for 'larger' frames thanks Paul Jud White wrote: > ID3v2.4 uses syncsafe frame sizes, the same way the tag size is > written. The COMM frame you're talking about may not be corrupt. > > > Paul Taylor wrote: >> Its V24, what are their different ways of writing frame sizes ? >> Jud White wrote: >>> Have you tested to see if it's written with a syncsafe frame size? >>> What ID3 version? >>> >>> Paul Taylor wrote: >>>> In my ID3 Tag library I am having problems with a particular tag. I >>>> have a tag with a problem COMM frame, the COMM frame says that it >>>> is 1000 bytes long, whereas in fact it is only about 500 bytes >>>> long. The end result is that next 500 bytes of the ID3 tag are >>>> assumed to be part of the Comment description when in fact they are >>>> other frames, and no more frames are loaded after the COMM frame >>>> because immediately after 1000 bytes after the COMM frame there is >>>> not a valid frame identifier. There are lots of valuable frames >>>> after the COMM frame and I would like my tag library to load as >>>> much information as I can. >>>> >>>> Any ideas how I should: >>>> Deal with frames in general that have an invalid size in their >>>> header, >>>> Determine in the */COMM.The actual text field/* the end of the >>>> real data, I thought I could look for null terminaters because >>>> there should be any in this field >>>> >>>> thanks Paul >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> 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 > > > --------------------------------------------------------------------- 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 Sun Apr 15 03:14:48 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 15 Apr 2007 11:14:48 +0100 Subject: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio Message-ID: <4621FB18.7040206@fastmail.fm> Hi, in my id3 library I made the decision to find the start of the MP3Audio first, and then read the ID3tag starting from the start of the file upto the start of the MP3Audio. I did it this way rather than reading the ID3Tag Size from the ID3 tag header and using this size as the basis of the tag. I did this because there are so many application that make mistakes when writing ID3 tags, whereas applications that encode mp3s do the encoding correctly, so as long as I identify the start of the mp3 correctly there is no problem with accidently overwriting mp3 info with the ID3 tag. This is how I find the MP3 Audio WHILE BYTES EXIST { Get next byte IF match two bytes:0xFF and 0xE0 (or greater) { IF can map these and next two bytes to a MPEG frame header (mapping to valid values (BitRate,Samplingrate ....) { IF can map this frame to a XING Frame { FOUND MATCH Break } ELSE { skip to end of this MPEG frame as reported in header IF( can map next four bytes to a MPEG frame header) { FOUND MATCH Break } ELSE { No match Found CONTINUE } } } ELSE { No match Found CONTINUE } } ELSE { No match found CONTINUE } } So in summary I find a potental match, map it to an MPEG frame if it maps to a Xing frame I'm done, if not I try to match the next frame to see if its an audio frame, if it I'm done, if not these are not valid mp3 audio so carry on searching. The only time I find a potential invalid match is when the ID3 tag is not unsynchronised, now I thought this happened quite rarely for just frames such as APIC frames but Ive now realised that if the text frames are encoded as UTF16 with Little Endian BOM then every text frame will start with FF FE and if it isnt unsychronised there is a real chance that the size read in the text frame (when read as an MPEG frame) could endup with me getting an invalid match to a second frame. So my question is is there something about the byte combination FF FE that would allow me to identify that it is definently NOT the start of MP3 Audio frame. thanks paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Tue Apr 3 13:46:31 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 3 Apr 2007 16:46:31 -0400 Subject: [ID3 Dev] Is the DataLengthIndicator included in the Frame Size? In-Reply-To: <461276C2.7020208@fastmail.fm> References: <461276C2.7020208@fastmail.fm> Message-ID: <20070403204631.GA8452@ayup.limey.net> On Tue, Apr 03, 2007 at 04:46:10PM +0100, Paul Taylor wrote: > In ID3v24 if there is 4 byte DataLengthIndicator field after the header > is it included in the size of the frame. I know the header is not > included when calculating the size and the body is, but where does this > field fit in. 4.1 of the 2.4.0 spec says: These additions affects the 'frame size' field, but are not subject to encryption or compression. > With regard to Unsynced frames Im not sure what Im meant to do with the > value once I read it,is it meant to equal the un-unsynced length of the > framebody ? It is intended to allow you to pre-allocate space for the results of the un-unsync, decryption, etc. I suggest you ignore it when reading. I would not write one by default. -ben --------------------------------------------------------------------- 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 Sun Apr 15 04:51:03 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 15 Apr 2007 12:51:03 +0100 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <188244.3133.qm@web27004.mail.ukl.yahoo.com> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> Message-ID: <462211A7.5040300@fastmail.fm> Mathias Kunter wrote: > I don't know any solution for this problem and I really suggest to don't use this method > to determine the ID3 tag size. The ID3 tag size is written correctly by most programs > anyway (I didn't encounter any problems with reading the tag size so far). Well there are some things I can do, I could check more than two mpeg frames to reduce the chances of a match, and I expect there is something else I could do to invalidate the specific FF FE combination but I havent found it (yet). I appreciate what you are saying but if only a few program overestimate the length of the ID3tag then that is enough to make this method unsafe. I would much rather overwrite tag data than mp3 data, but of course i dont want to overwrite anything. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From longjan at hotmail.com Mon Apr 16 11:19:22 2007 From: longjan at hotmail.com (Jan De Kock) Date: Mon, 16 Apr 2007 20:19:22 +0200 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <20070416175154.GA24335@ayup.limey.net> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> <20070415154136.GA32704@ayup.limey.net> <4622686A.2070700@fastmail.fm> <20070415214216.GA24868@ayup.limey.net> <4623A078.5040607@fastmail.fm> <20070416175154.GA24335@ayup.limey.net> Message-ID: <4623BE2A.9060109@hotmail.com> I know what he means, it's just some bugs in some MP3-encoders. Lame 3.92 has it (if i'm correct). Mostly they're only zeroes (0x00). Ben Bennett wrote: >> Well, Ive done it and only found a few tags whose size does not match >> the start of the audio, unfortunately the files were not created myself >> so I dont know their history. In all cases the size recorded in smaller >> than the >> actual audio starting location, so no harm would have been done. But in >> these cases I search again in the file for the start of audio starting >> from the beginning of the file, if value returned is the same as when >> search starting from the >> end of the tag location then we are ok, if it is different all I can do >> is use the new value and log a warning that this may possibly not be correct > > Interesting. How much smaller? > > Can you mail out the tag + data up to the first MPEG frame header for > one of these files please? > > -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 paul_t100 at fastmail.fm Mon Apr 2 14:22:40 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 02 Apr 2007 22:22:40 +0100 Subject: [ID3 Dev] How do I deal with this problem COMM frame Message-ID: <46117420.8000004@fastmail.fm> In my ID3 Tag library I am having problems with a particular tag. I have a tag with a problem COMM frame, the COMM frame says that it is 1000 bytes long, whereas in fact it is only about 500 bytes long. The end result is that next 500 bytes of the ID3 tag are assumed to be part of the Comment description when in fact they are other frames, and no more frames are loaded after the COMM frame because immediately after 1000 bytes after the COMM frame there is not a valid frame identifier. There are lots of valuable frames after the COMM frame and I would like my tag library to load as much information as I can. Any ideas how I should: Deal with frames in general that have an invalid size in their header, Determine in the */COMM.The actual text field/* the end of the real data, I thought I could look for null terminaters because there should be any in this field thanks Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Fri Apr 6 07:50:46 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 6 Apr 2007 10:50:46 -0400 Subject: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <46165BCE.3050105@fastmail.fm> References: <896838.69373.qm@web27010.mail.ukl.yahoo.com> <46165BCE.3050105@fastmail.fm> Message-ID: <20070406145046.GA21559@ayup.limey.net> On Fri, Apr 06, 2007 at 03:40:14PM +0100, Paul Taylor wrote: > Mathias Kunter wrote: > > > This is what I was trying to get at. Is a frame unsynchronized IF it > doesnt contain FF FE patterns or ONLY IF it has actually been > unsynchronized meaning that FF 00 If the tag unsync flag is set, then each frame unsync flag must be set. If a frame unsync flag is set, then you need to un-unsync the contents to read it. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jwhite at cdtag.com Fri Apr 6 06:55:32 2007 From: jwhite at cdtag.com (Jud White) Date: Fri, 6 Apr 2007 08:55:32 -0500 Subject: [ID3 Dev] Forum Message-ID: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> Not sure if there's a historical reason behind the mailing list... but.. Would anyone prefer a phpBB or vBulletin forum? There seem to be a lot of repeat questions on the list lately. And currently messages to the list are removed after 90 days.. -------------- next part -------------- --------------------------------------------------------------------- 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 Thu Apr 5 23:41:55 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 07:41:55 +0100 Subject: AW: AW: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? In-Reply-To: <231573.63393.qm@web27002.mail.ukl.yahoo.com> References: <231573.63393.qm@web27002.mail.ukl.yahoo.com> Message-ID: <4615EBB3.5070509@fastmail.fm> Mathias Kunter wrote: > I meant you should never display a null terminator in an user interface > (how would you actually do that?) > > cheers > Mathias > Yeah I think my problem has been that I was displaying the terminator, as I viewed it as part of the String when found in places where a terminator was not requested by spec, in my application it just looked like a small square, because as you say it cannot be displayed properly. I think I will change things to strip out these characters when reading, and on writing the tag I will not write them. Paul > > > > > > > > > ___________________________________________________________ > Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Thu Apr 5 14:56:40 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Thu, 5 Apr 2007 21:56:40 +0000 (GMT) Subject: AW: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? Message-ID: <195049.65523.qm@web27004.mail.ukl.yahoo.com> ...why should iTunes NOT write null terminated strings?? From the 2.2 / 2.3 text frame specs: "If the textstring is followed by a termination ($00 (00)) all the following information should be ignored and not be displayed." So I would say it even is good practice to write a terminating 00 (or 00 00 in Unicode) to a text frame. Or did I misunderstand you? A null terminator has never ever lost anything in an user interface by the way. Cheers. Mathias ----- Urspr?ngliche Mail ---- Von: Paul Taylor An: id3v2 at id3.org CC: Paul Taylor Gesendet: Donnerstag, den 5. April 2007, 22:46:31 Uhr Betreff: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? Most people on this list knows that Itunes writes null terminated strings, but does anyone know why - did they just make a mistake or is there a reason for it ? I ask because I would like to know what you would expect a tag editor to do with these values. It could display these null terminators but this doesnt make much sense to user using the tag editor It could silently hide these null terminators from view, but they they would remain in the file possibly causing problems for other applications It could provide an option to explicity remove these null terminators when the records are loaded, and remove them when they are saved, but would this cause any kind of problem for Itunes thanks Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- 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 Sun Apr 15 11:01:14 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 15 Apr 2007 19:01:14 +0100 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <20070415154136.GA32704@ayup.limey.net> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> <20070415154136.GA32704@ayup.limey.net> Message-ID: <4622686A.2070700@fastmail.fm> Ben Bennett wrote: > I have to second Mathias. I have never seen an incorrect tag size > from any of the apps I have tested, or from any of the files I have > found in the wild. Note, the previous discussions have been of the > bad _frame_ sizes. But the overall tag size has always been correct. > > Anyway, I think scanning for MPEG frames is frought with peril since > a MPEG data can be embedded within an ID3 tag (see the ID3 accessibility spec http://id3.org/id3v2-accessibility-1.0). > This spec does mention the need for synchronisation quite a few times, so if written properly should not cause a problem, but i see that it could. > I would trust the tag size if you hit an ID3v2 header, then scan for > MPEG frames following that. > > -ben It seems a bit arbitary, my original method wont work because we may get false synchronisations in the ID3 tag, yet we can trust the ID3 header size because it is always calculated correctly. Well I guess you are ther authority on the subject , thanks for your advice I think I will rework my code to read from the ID3 header upto the size reported, and then check that MP3Audio starts immediately afterwards for peace of mind. But IF the mp3 header does not start then we have a problem, Ill let you know if I have any files that fall into that category. thanks Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Mon Apr 16 10:51:54 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Mon, 16 Apr 2007 13:51:54 -0400 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <4623A078.5040607@fastmail.fm> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> <20070415154136.GA32704@ayup.limey.net> <4622686A.2070700@fastmail.fm> <20070415214216.GA24868@ayup.limey.net> <4623A078.5040607@fastmail.fm> Message-ID: <20070416175154.GA24335@ayup.limey.net> > Well, Ive done it and only found a few tags whose size does not match > the start of the audio, unfortunately the files were not created myself > so I dont know their history. In all cases the size recorded in smaller > than the > actual audio starting location, so no harm would have been done. But in > these cases I search again in the file for the start of audio starting > from the beginning of the file, if value returned is the same as when > search starting from the > end of the tag location then we are ok, if it is different all I can do > is use the new value and log a warning that this may possibly not be correct Interesting. How much smaller? Can you mail out the tag + data up to the first MPEG frame header for one of these files please? -ben --------------------------------------------------------------------- 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 Fri Apr 6 08:40:41 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 16:40:41 +0100 Subject: AW: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <955474.21459.qm@web27006.mail.ukl.yahoo.com> References: <955474.21459.qm@web27006.mail.ukl.yahoo.com> Message-ID: <461669F9.90507@fastmail.fm> Mathias Kunter wrote: >> Is a frame unsynchronized IF it doesnt contain FF FE patterns >> > > No. I don't know why you keep talking about the FF FE pattern, this has > nothing to do with the unsync scheme. As Ben said, unsync is only relevant > to a bit sequence of > Sorry for the confusion I mean E0 I was just on autopilot, In understand the unsynchronization algorithm works I have implemented it very successful for v22 and v23 tags quite some time ago. > %11111111 (which is == FF) > %111xxxxx (which is >= E0) > > So, if you encounter this bit sequence within the data of a frame AND you > decide to unsyc the frame, you HAVE to insert a 00 byte after the FF > byte. You HAVE to set the frame header flag now. > > If you decide to don't unsync the frame content, do nothing. You MUST > NOT set the frame header flag. This also implies that the tag header flag > MUST NOT be set. > > If you don't detect the mentioned bit sequence, you can still decide to > unsync the frame and set the flag in the frame header. However, this > would be silly as the unsync would have no effect for this frame. It is > just allowed from the specs point of view, but you shouldn't do that. > > It is safe to insert a 00 byte after every FF byte WHEN applying the > unsync scheme. As Ben said, this may also inserts a 00 byte where > not really nescessary, but it is easier to implement and also works > fine because a decoder has to replace EVERY $FF $00 byte sequence. > > > >> if you had a frame with a $FF $00 combination and you didnt unsynchronize >> the frame, [...], and then a decoder tried to de-unsync the frame it would >> remove the 00, and your data will be modified >> > > The point is, if I didn't unsync the frame, the flag is NOT set. Therefore, a > decoder MUST NOT de-unsync the frame, of course. Therefore, it doesn't > matter from the decoder point of view. > > Thanks for your help but we are still at cross purposes here though, this is what you said earlier 'Note that if a frame has been unsynced this doesn't mean that this frame actually got modified. (Well, the specs say that the flag SHOULD only be set if the frame became actually modified because of a false sync, but you can't rely on that). So if the frame header flag is set it is guaranteed that this frame (or all frames, if the tag header flag is set) contain no false sync signal in it. It does NOT mean that the frame content actually became modified, as mentioned before. From the decoder point of view, this doesn't matter anyway. Just de-unsync the frame by replacing all $FF $00 byte sequences with $FF bytes.' You say above the frame flag being set means 'it contains no false sync signal. It does NOT mean that the frame content actually became modified' whereas in your latest post you say 'If you decide to don't unsync the frame content, do nothing. You MUST NOT set the frame header flag.' These two statements seem to be the opposite of each other You also say 'If you don't detect the mentioned bit sequence, you can still decide to unsync the frame and set the flag in the frame header. However, this would be silly as the unsync would have no effect for this frame. It is just allowed from the specs point of view, but you shouldn't do that.' Wouldnt it? if there were any FF 00 patterns there would be an effect. Replacing FF 00 with FF 00 00 is part of unsynchronization (it is not optional) > Hope it is clear now. > > Mathias > > > > > > > > > > > ___________________________________________________________ > Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de > > --------------------------------------------------------------------- > 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 fiji at ayup.limey.net Sun Apr 15 08:41:36 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Sun, 15 Apr 2007 11:41:36 -0400 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <462211A7.5040300@fastmail.fm> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> Message-ID: <20070415154136.GA32704@ayup.limey.net> On Sun, Apr 15, 2007 at 12:51:03PM +0100, Paul Taylor wrote: > Mathias Kunter wrote: > >I don't know any solution for this problem and I really suggest to don't > >use this method > >to determine the ID3 tag size. The ID3 tag size is written correctly by > >most programs > >anyway (I didn't encounter any problems with reading the tag size so far). > > Well there are some things I can do, I could check more than two mpeg > frames to reduce the chances of a match, and I expect there is something > else > I could do to invalidate the specific FF FE combination but I havent > found it (yet). I appreciate what you are saying but if only a few > program overestimate the length of the ID3tag then that is enough > to make this method unsafe. I would much rather overwrite tag data than > mp3 data, but of course i dont want to overwrite anything. I have to second Mathias. I have never seen an incorrect tag size from any of the apps I have tested, or from any of the files I have found in the wild. Note, the previous discussions have been of the bad _frame_ sizes. But the overall tag size has always been correct. Anyway, I think scanning for MPEG frames is frought with peril since a MPEG data can be embedded within an ID3 tag (see the ID3 accessibility spec http://id3.org/id3v2-accessibility-1.0). I would trust the tag size if you hit an ID3v2 header, then scan for MPEG frames following that. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Fri Apr 6 10:45:33 2007 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 6 Apr 2007 13:45:33 -0400 Subject: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? In-Reply-To: <955474.21459.qm@web27006.mail.ukl.yahoo.com> References: <955474.21459.qm@web27006.mail.ukl.yahoo.com> Message-ID: <20070406174533.GA27656@ayup.limey.net> On Fri, Apr 06, 2007 at 03:16:30PM +0000, Mathias Kunter wrote: > It is safe to insert a 00 byte after every FF byte WHEN applying the > unsync scheme. As Ben said, this may also inserts a 00 byte where > not really nescessary, but it is easier to implement and also works > fine because a decoder has to replace EVERY $FF $00 byte sequence. Just to clarify what I think we are both trying to get across... If you are doing unsync... then you MUST insert $00 after all $FFs. This is mandatory regarless of whether it is needed. The only point I was trying to make was unsync may change places that are actually syncsafe. -ben --------------------------------------------------------------------- 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 Thu Apr 5 13:46:31 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 05 Apr 2007 21:46:31 +0100 Subject: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? Message-ID: <46156027.8050201@fastmail.fm> Most people on this list knows that Itunes writes null terminated strings, but does anyone know why - did they just make a mistake or is there a reason for it ? I ask because I would like to know what you would expect a tag editor to do with these values. It could display these null terminators but this doesnt make much sense to user using the tag editor It could silently hide these null terminators from view, but they they would remain in the file possibly causing problems for other applications It could provide an option to explicity remove these null terminators when the records are loaded, and remove them when they are saved, but would this cause any kind of problem for Itunes thanks Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wholcomb at gmail.com Fri Apr 6 07:14:49 2007 From: wholcomb at gmail.com (Will Holcomb) Date: Fri, 6 Apr 2007 10:14:49 -0400 Subject: [ID3 Dev] Forum In-Reply-To: <20070406140822.GB19474@ayup.limey.net> References: <9255045CE05945C7A4C5518CC7937871.MAI@cdtag.com> <20070406140822.GB19474@ayup.limey.net> Message-ID: <605EABEB-1FC1-4BC7-9DAF-86E4C6ED438B@gmail.com> I noted on Google Groups now that you can use their groups to archive email lists now. I use them for some other things and their interface works pretty well. Will Holcomb On Apr 6, 2007, at 10:08 AM, Ben Bennett wrote: > Can we just archive things for a longer time? > > I prefer email to forums since I never remember to check in on a > forum... > > I have been meaning to update the wiki with some of this, but... time > has been tight recently. > > -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From hornalot at yahoo.ca Wed Apr 11 11:30:08 2007 From: hornalot at yahoo.ca (Ryan Horn) Date: Wed, 11 Apr 2007 14:30:08 -0400 (EDT) Subject: [ID3 Dev] Hardware MP3 Player with SYLT Support? In-Reply-To: <461CDA4B.2000209@iis.fraunhofer.de> Message-ID: <969005.20224.qm@web55111.mail.re4.yahoo.com> > is anyone of You aware of a hardware MP3 player that > supports the SYLT > (synchronized lyrics) ID3v2.3/2.4 tag? I just installed rockbox on my ipod nano. I can see great things from this project. Nice to be free from iTunes. I'm not sure if it supports the feature you inquire about, but I'm sure it can. http://www.rockbox.org/ cross platform project, open source, google summer of code... You're welcome Stockholm! http://www.rockbox.org/twiki/bin/view/Main/DevCon2007 HOrn --- Oliver Baum wrote: > Hello list, > > is anyone of You aware of a hardware MP3 player that > supports the SYLT > (synchronized lyrics) ID3v2.3/2.4 tag? > > Thank You for Your help in advance! > > > Best regards, > > Oliver > > -- > Dipl.-Ing. Oliver Baum > > Multimedia Transport Group, Audio Department > Fraunhofer Institute for Integrated Circuits IIS > > Am Wolfsmantel 33 > 91058 Erlangen > Germany > > Phone: +49 9131 776-319 > Fax: +49 9131 776-398 > > --------------------------------------------------------------------- > 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 mathiaskunter at yahoo.de Fri Apr 6 09:24:22 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 6 Apr 2007 16:24:22 +0000 (GMT) Subject: AW: AW: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? Message-ID: <889171.11872.qm@web27012.mail.ukl.yahoo.com> >You say above the frame flag being set means 'it contains no false sync signal. It does NOT mean that the >frame content actually became modified' >whereas in your latest post you say 'If you decide to don't unsync the frame content, do nothing. You MUST >NOT set the frame header flag.' >These two statements seem to be the opposite of each other They are not :) Look at this: ***DECODER POINT OF VIEW*** IF the flag is set, the frame content MIGHT became modified by the unsync scheme and you MUST de-unsync it to get the correct data. In the case that the content actually didn't became modified it's no problem as the de-unsync process is going to simply have no effect then. IF the flag is NOT set, you MUST NOT de-unsync the frame content as this COULD produce corrupted data. ***ENCODER POINT OF VIEW*** IF you want to unsync the content, replace all FF >=E0 byte sequences with FF 00 >=E0 bytes. In the case that there is no FF >=E0 byte sequence, you CAN set the flag, although you SHOULDN'T. If there was a FF >=E0 byte sequence in the data, you MUST set the flag. I explained earlier that it is sufficient to replace FF bytes with FF 00 only, without checking for the entire FF >=E0 sequence. IF you DON'T want to unsync the content, you MUST NOT set the flag and MUST NOT change the frame data in any way, of course. >>'If you don't detect the mentioned bit sequence, you can still decide to >>unsync the frame and set the flag in the frame header. However, this >>would be silly as the unsync would have no effect for this frame. It is >>just allowed from the specs point of view, but you shouldn't do that.' >if there were any FF 00 patterns there would be an effect. Replacing FF 00 with FF 00 00 is part of >unsynchronization (it is not optional) This is correct. However, when I wrote "you can still decide to unsync the frame" I meant that you also have to care about the FF 00 combinations then (just because you're applying the unsync scheme). Therefore, the decoder also reads the correct byte sequence again. Mathias ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --------------------------------------------------------------------- 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 Thu Apr 5 15:15:48 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 05 Apr 2007 23:15:48 +0100 Subject: AW: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? In-Reply-To: <195049.65523.qm@web27004.mail.ukl.yahoo.com> References: <195049.65523.qm@web27004.mail.ukl.yahoo.com> Message-ID: <46157514.8060003@fastmail.fm> Mathias Kunter wrote: > ...why should iTunes NOT write null terminated strings?? > > From the 2.2 / 2.3 text frame specs: > > "If the textstring is followed by a termination ($00 (00)) all the following > information should be ignored and not be displayed." > But what should be done with the termination itself ? > A null terminator has never ever lost anything in an user interface by > the way. > > Sorry can you rephrase it, I dont understand this sentence Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Fri Apr 6 04:23:32 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 6 Apr 2007 11:23:32 +0000 (GMT) Subject: AW: [ID3 Dev] How do I deal with this problem COMM frame Message-ID: <539144.86229.qm@web27014.mail.ukl.yahoo.com> >Actually I think the safe limit is 127 (01111111), any higher than that >and sysncsafe/nonsyncsafe vary, although if the value >is between 127 and 255 you can guarantee it is NOT sync safe. Between 128 and 255. Correct, man. Mathias ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Thu Apr 5 15:48:25 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Thu, 5 Apr 2007 22:48:25 +0000 (GMT) Subject: AW: AW: [ID3 Dev] Why does Itunes write null terminated strings (v2.2/v2.3) ? Message-ID: <231573.63393.qm@web27002.mail.ukl.yahoo.com> >But what should be done with the termination itself ? Well, nothing. :) What would you want to do with a terminator? Just read the string until the terminator appears, and stop then (in ID3 2.2 and 2.3). In 2.4, the terminators are treated as separators (as discussed some days ago on this list). >> A null terminator has never ever lost anything in an user interface by >> the way. >Sorry can you rephrase it, I dont understand this sentence I meant you should never display a null terminator in an user interface (how would you actually do that?) cheers Mathias ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- 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 Mon Apr 2 22:34:54 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 03 Apr 2007 06:34:54 +0100 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <461177FC.1010600@cdtag.com> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> Message-ID: <4611E77E.3020308@fastmail.fm> Its V24, what are their different ways of writing frame sizes ? Jud White wrote: > Have you tested to see if it's written with a syncsafe frame size? > What ID3 version? > > Paul Taylor wrote: >> In my ID3 Tag library I am having problems with a particular tag. I >> have a tag with a problem COMM frame, the COMM frame says that it is >> 1000 bytes long, whereas in fact it is only about 500 bytes long. The >> end result is that next 500 bytes of the ID3 tag are assumed to be >> part of the Comment description when in fact they are other frames, >> and no more frames are loaded after the COMM frame because >> immediately after 1000 bytes after the COMM frame there is not a >> valid frame identifier. There are lots of valuable frames after the >> COMM frame and I would like my tag library to load as much >> information as I can. >> >> Any ideas how I should: >> Deal with frames in general that have an invalid size in their >> header, >> Determine in the */COMM.The actual text field/* the end of the >> real data, I thought I could look for null terminaters because there >> should be any in this field >> >> thanks Paul >> >> >> >> --------------------------------------------------------------------- >> 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 > > > --------------------------------------------------------------------- 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 Fri Apr 6 06:39:09 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 06 Apr 2007 14:39:09 +0100 Subject: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? Message-ID: <46164D7D.7040801@fastmail.fm> In the IDv3v24 Spec ' Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is applied on all frames (see section 6.1 for details); a set bit indicates usage.' What exactly does this mean, and what is its purpose? If I have a tag with 10 frames, and only one of those frames actually contains a FF FE pattern, and this frame is synchronized, and there is nothing to for the other nine, does that mean the tag unsynchronisation flag is on/off. Or if one of the other frames does not contain a FF FE pattern but does contain a FF 00 pattern should that frame be unsynchronized (even though it creates more work at decoding and encoding ends) and only if all these cases were covered would the tag unsynchronisation flag be on. If the tag contains 10 frames and non of the frames contain an FF FE or FF 00 pattern, then unsynchronization would have no effect should the flag be on/off thanks paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Tue Apr 3 06:13:17 2007 From: wheeler at kde.org (Scott Wheeler) Date: Tue, 03 Apr 2007 15:13:17 +0200 Subject: [ID3 Dev] How do I deal with this problem COMM frame In-Reply-To: <002e01c775f1$40b106a0$7b55503f@useronewin2klt> References: <46117420.8000004@fastmail.fm> <461177FC.1010600@cdtag.com> <4611E77E.3020308@fastmail.fm> <20070403125412.GA24721@ayup.limey.net> <002e01c775f1$40b106a0$7b55503f@useronewin2klt> Message-ID: <461252ED.6000604@kde.org> Brian Schiffhauer wrote: > I was just wondering ... what is the purpose of a syncsafe integer? To avoid false MPEG synchs (a pattern of 11 true bits). -Scott --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Fri Apr 6 08:16:30 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 6 Apr 2007 15:16:30 +0000 (GMT) Subject: AW: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? Message-ID: <955474.21459.qm@web27006.mail.ukl.yahoo.com> >Is a frame unsynchronized IF it doesnt contain FF FE patterns No. I don't know why you keep talking about the FF FE pattern, this has nothing to do with the unsync scheme. As Ben said, unsync is only relevant to a bit sequence of %11111111 (which is == FF) %111xxxxx (which is >= E0) So, if you encounter this bit sequence within the data of a frame AND you decide to unsyc the frame, you HAVE to insert a 00 byte after the FF byte. You HAVE to set the frame header flag now. If you decide to don't unsync the frame content, do nothing. You MUST NOT set the frame header flag. This also implies that the tag header flag MUST NOT be set. If you don't detect the mentioned bit sequence, you can still decide to unsync the frame and set the flag in the frame header. However, this would be silly as the unsync would have no effect for this frame. It is just allowed from the specs point of view, but you shouldn't do that. It is safe to insert a 00 byte after every FF byte WHEN applying the unsync scheme. As Ben said, this may also inserts a 00 byte where not really nescessary, but it is easier to implement and also works fine because a decoder has to replace EVERY $FF $00 byte sequence. >if you had a frame with a $FF $00 combination and you didnt unsynchronize >the frame, [...], and then a decoder tried to de-unsync the frame it would >remove the 00, and your data will be modified The point is, if I didn't unsync the frame, the flag is NOT set. Therefore, a decoder MUST NOT de-unsync the frame, of course. Therefore, it doesn't matter from the decoder point of view. Hope it is clear now. Mathias ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- 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 Apr 18 03:00:15 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 18 Apr 2007 11:00:15 +0100 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <20070416175154.GA24335@ayup.limey.net> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> <20070415154136.GA32704@ayup.limey.net> <4622686A.2070700@fastmail.fm> <20070415214216.GA24868@ayup.limey.net> <4623A078.5040607@fastmail.fm> <20070416175154.GA24335@ayup.limey.net> Message-ID: <4625EC2F.3060303@fastmail.fm> Sent one of these direct to Ben I was sent three of these files and they all had the following in common, they were all unsynchronized and they all have an APIC frame where the frame size is one shorter than it needs to be in order to read the image data correctly. Ben Bennett wrote: >> Well, Ive done it and only found a few tags whose size does not match >> the start of the audio, unfortunately the files were not created myself >> so I dont know their history. In all cases the size recorded in smaller >> than the >> actual audio starting location, so no harm would have been done. But in >> these cases I search again in the file for the start of audio starting >> from the beginning of the file, if value returned is the same as when >> search starting from the >> end of the tag location then we are ok, if it is different all I can do >> is use the new value and log a warning that this may possibly not be correct >> > > Interesting. How much smaller? > > Can you mail out the tag + data up to the first MPEG frame header for > one of these files please? > > -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 mathiaskunter at yahoo.de Fri Apr 6 07:14:29 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Fri, 6 Apr 2007 14:14:29 +0000 (GMT) Subject: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? Message-ID: <896838.69373.qm@web27010.mail.ukl.yahoo.com> If the TAG header unsync bit is set this means that ALL frames within this tag have been unsynced, and that ALL frames MUST contain the unsync bit set in the FRAME header flags therefore (as defined by the specs). In my current ID3 implementation I de-unsync a frame if either the TAG flag is set or if the FRAME flag is set for the particular frame. Note that if a frame has been unsynced this doesn't mean that this frame actually got modified. (Well, the specs say that the flag SHOULD only be set if the frame became actually modified because of a false sync, but you can't rely on that). So if the frame header flag is set it is guaranteed that this frame (or all frames, if the tag header flag is set) contain no false sync signal in it. It does NOT mean that the frame content actually became modified, as mentioned before. From the decoder point of view, this doesn't matter anyway. Just de-unsync the frame by replacing all $FF $00 byte sequences with $FF bytes. Cheers. Mathias ----- Urspr?ngliche Mail ---- Von: Paul Taylor An: id3v2 at id3.org Gesendet: Freitag, den 6. April 2007, 15:39:09 Uhr Betreff: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? From IDv3v24 Spec ' Bit 7 in the 'ID3v2 flags' indicates whether or not unsynchronisation is applied on all frames (see section 6.1 for details); a set bit indicates usage.' What exactly does this mean, and what is its purpose? If I have a tag with 10 frames, and only one of those frames actually contains a FF FE pattern, and this frame is synchronized, and there is nothing to for the other nine, does that mean the tag unsynchronisation flag is on/off. Or if one of the other frames does not contain a FF FE pattern but does contain a FF 00 pattern should that frame be unsynchronized (even though it creates more work at decoding and encoding ends) and only if all these cases were covered would the tag unsynchronisation flag be on. If the tag contains 10 frames and non of the frames contain an FF FE or FF 00 pattern, then unsynchronization would have no effect should the flag be on/off thanks paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Sun Apr 8 07:18:22 2007 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Sun, 8 Apr 2007 14:18:22 +0000 (GMT) Subject: AW: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ? Message-ID: <992101.17266.qm@web27014.mail.ukl.yahoo.com> >ok i'll summarize, you have three options on a frame basis > >1. Dont unsynchronize it, (the preferred option) >2. Unsynchronize it regardless of its contents and set the flag >3. Unsynchronize it only if unsynchronization is required, and set the flag Yup. You could also write it this way in pseudo code: FOR EACH frame that should be written { IF { //the following IF is optional, you actually don't HAVE to check, //but it's better coding. IF { do the unsync set the frame header flag } ELSE { don't do the unsync don't set the frame header flag } } ELSE { don't do the unsync don't set the frame header flag } } IF { set the unsync flag for the TAG header too } ELSE { don't set the TAG header unsync flag } >However it never occurred to me that you could unsynchronize by simply >replace all occurences of FF with FF 00. >What I do is iterate though the data looking for >an 0xFF, then if the next byte is 0xE0 (or greater) I insert an Ox00, >or if the next byte is 0x00 I insert an additional 0x00, this method >seems to be what the Spec describes. Sounds correct, this would be the "strict" way to do the unsync. However, if you just replace FF with FF 00, it is also sufficient, because this also replaces FF 00 with FF 00 00, and the decoder just correctly replaces FF 00 with FF back again. As I said, you may insert 00 bytes where not really nescessary then, but this doesn't matter. >This method increases the time to encode but reduces the time to >decode but I cant see that it matters which way you do. Well, yes. Given the fact that you have to re-write the entire file in the worst case (if the padding gets too small) I think the speed criteria isn't important at all in this case. The difference won't be noticeable by an end-user. Best regards. Mathias (Magic Tagger developer) ___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de --------------------------------------------------------------------- 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 Mon Apr 16 09:12:40 2007 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 16 Apr 2007 17:12:40 +0100 Subject: AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio In-Reply-To: <20070415214216.GA24868@ayup.limey.net> References: <188244.3133.qm@web27004.mail.ukl.yahoo.com> <462211A7.5040300@fastmail.fm> <20070415154136.GA32704@ayup.limey.net> <4622686A.2070700@fastmail.fm> <20070415214216.GA24868@ayup.limey.net> Message-ID: <4623A078.5040607@fastmail.fm> Ben Bennett wrote: >> thanks for your advice I think I will rework my code to read from >> the ID3 header upto the size reported, and then check that MP3Audio >> starts immediately afterwards for peace of mind. But IF the mp3 >> header does not start then we have a problem, Ill let you know if I >> have any files that fall into that category. >> > > That sounds like a good sanity check... but I would not be surprised > if you found strange new tags... > > -ben > > Well, Ive done it and only found a few tags whose size does not match the start of the audio, unfortunately the files were not created myself so I dont know their history. In all cases the size recorded in smaller than the actual audio starting location, so no harm would have been done. But in these cases I search again in the file for the start of audio starting from the beginning of the file, if value returned is the same as when search starting from the end of the tag location then we are ok, if it is different all I can do is use the new value and log a warning that this may possibly not be correct Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org