[ID3 Dev] Syncsafe integers and 2.3/2.4

[Ion Todirel]

If you wont to understand how something works you mast broks it in parts. Play with Mirosoft Windows Media Player SDK 10 or with Windows Media Format 9.5 SDK (in .NET), check winamp, way iTunes is so important for you? its more important to support standards! When in some case something doesn't work its best to not do it, in this case heuristical algoritm, in some cases it will not work. Like i say, way iTunes?

Ben Bennett <fiji at ayup.limey.net> wrote:On Mon, Aug 22, 2005 at 03:00:37PM +0100, Ion Todirel wrote:
> First you cannot determine if is syncsafe or not! based on MSB in
> all bytes. Second in your library you only can put an option to read
> frame size as syncsafe or as normal integers, you cannot read

Unfortunately that won't do it since iTunes leaves frames alone if it
hasn't changed them, so you may have a mix.

I have a heuristic in my parser that looks at the unsynchronized frame
size and check to see if there is a legal frame identifier following
it or if we have hit padding or the end of the file. I also check the
size of the following frame to make sure it is less than the tag
size. If either the frame id or the size are invalid I sanity check
the original size to see if it leads to a valid frame. If that check
fails too, I give up and go with the unsynchronized size.

It is clearly not perfect, but this seems to do a decent job of
catching the errors.

> ID3v2.3 or ID3v2.4 as normal because iTunes write these information
> as normal integers, look how WindowsMedia Player or Winamp write
> these, if what you say is true then iTunes does'n support ID3v2
> standard.

I agree. I have checked a few tools and some follow the spec... sadly
iTunes doesn't.


Anyway, you can get the tag I was playing with from:
http://limey.net/~fiji/t/id3v2.4_itunes-4.9.0.17.mp3
As the name suggests, that is an ID3v2.4 tag written by the latest
version of iTunes for Windows: 4.9.0.17.

The COMM frame is where the issue arises in that frame since it is the
only one long enough to trigger the issue. But it happens with any
frame larger than 127 bytes.

The frame in question looks like:
Header (10 Bytes):
43 4f 4d 4d Frame ID $xx xx xx xx (four characters)
00 00 01 05 Size 4 * %0xxxxxxx
00 00 Flags $xx xx

Payload (261 bytes):
00 Text encoding $xx
65 6e 67 Language $xx $xx $xx
00 Short content $00 (00)
(256 bytes) The actual text 

This frame is followed by padding out to the end of the tag.


The Frame ID is "COMM", and there are no special flags. I will get to
the size in a minute. The text encoding is $00 which means ISO-8859-1
(Latin1). There is no short content so you just see $00 indicating
the end of the string (since ISO-8859-1 is not a wide char there is no
second $00). Finally the actual text is 1234567890 repeated 25 times,
followed by 12FOO for a total of 255 characters + 1 byte for the null
at the end.

So Looking more closely at the size, the hex values:
00 00 01 05
Are the bit strings:
00000000 00000000 00000001 00000101
Which if syncsafe would drop the most significant bit from each byte:
0000 00000000 00000000 10000101
Which when converted to base-10 is 134.

However if we don't unsynchronize the number it is 261. Which matches
the actual frame payload size.

Hopefully this proves to you that iTunes is totally borked in the
2.4 frame length handling.

-ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



		
---------------------------------
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20050827/3c4cb53c/attachment.html>