[ID3 Dev] Syncsafe integers and 2.3/2.4

[Ion Todirel]

To Ben Bennett:
 
Both 2.3 and 2.4 use Syncsafe integers. ID3v2.4 its a nice one, i recommend you to implement yourself ID3v2.4/Reader-Writer and threat there your syncsafe problems, also if you you have problems with syncsafe email me, i develop some nice methods.


Robert Crowell <crowell at MIT.EDU> wrote:I am working on a python library to read (and possibly write) id3v2 tags.

Reading over the specification several times, I wasn't able to determine whether
or not id3v2.3 frames use the 'synchsafe integers' that 2.4 frames do. (I
understand that both 2.3 and 2.4 use synchsafe ints for the _tag_ size, but I
couldn't determine what the _frame_ behavior is.)

While the specification seems to indicate that v2.3 frames DO NOT use synchsafe
ints and v2.4 frames DO use synchsafe integers, I am encountering some odd
behavior. Using the 'convert ID3 tags' feature in iTunes 4.9, I convert a v2.3
tag to v2.4, but the frame size bytes don't seem to be any different in the 2.3
and 2.4 versions. There is a long USER tag in one of my mp3 files (that was
created by an unknown application) that contains 370 ASCII characters.

The 4 size bytes in this frame header seem to be encoding this value as a
NON-synchsafe integer. In my code, when 2.3 is detected it expects
non-synchsafe integers for frame sizes and everything is fine. However, after
converting this tag to 2.4 in iTunes, it interprets the size as a synchsafe
integer, and because iTunes did not modify the size bytes when converting from
2.3 to 2.4, it gets the frame size wrong. It decides the frame is only 242
bytes long rather than the correct 370. (size:0,0,1,114 -> 370 normal, 242
synchsafe)

This causes a huge problem because not only is the USER tag not read completely,
but my code mistakenly interprets the next 10 bytes as a new frame header. 
Because the size portion of this header is clearly invalid (since this isn't a
real header at all), my code believes the size of the next frame is huge,
interpreting 'manc' as the frame size bytes.

size bytes: $00 00 01 72 (for both 2.3 and 2.4)
2.3 size: 370 (correct, assuming non-synchsafe int)
2.4 size: 242 (incorrect, assuming synchsafe int)

Is iTunes at fault for not converting the USER frame's size to a synchsafe
integer when converting a tag to 2.4? Am I mis-reading the ID3v2
specification? If it turns out that iTunes is doing something silly, how would
I detect it in my code?

Thanks for your help.

-Rob Crowell

P.S. I have also tested the tags generated by the Media Rage application for
Mac. The behavior is the same. What am I doing wrong?



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



		
---------------------------------
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20050822/21a91d9f/attachment.html>