AW: [ID3 Dev] UTF16LE BOM FF FE incorrectly being identified as start of MP3 Audio

[Ben Bennett]

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