In the specification for id3v2.4 the frame size is described as "32 bit synchsafe integer". In id3v2.3 this it not mentioned. Is there really a different?
i guess it is so, but i find it strange since the id3v2.3 tag size (the size for alle the frames) is a 32 bit synchsafe integer
There is a difference since unsynchronization is only an ID3v2.4 feature. In ID3v2.3 I think the size is simply stored as 32 bit integer.
Looks like unsynchronization is an ID3v2.3 feature too:
http://www.id3.org/id3v2.3.0#head-c632e494...6911f949bbb2586 (http://www.id3.org/id3v2.3.0#head-c632e49403443283c464955b36911f949bbb2586)
and even in ID3v2.2 too:
http://www.id3.org/id3v2-00 (http://www.id3.org/id3v2-00)
There is a difference between unsynchronization in frames and synchsafe integers. It seems that id3v2.3 is using synchsafe integers for the tag size but not for the frame size. Can anyone confirm this?
No, read 1st link above.
There is a difference between unsynchronization in frames and synchsafe integers. It seems that id3v2.3 is using synchsafe integers for the tag size but not for the frame size. Can anyone confirm this?
True.
Funny to have unsynchronization mechanism and then not dealing with unsynchronization in the 4 bytes describing the size!!?? Bad design or am I missing something?
ID3v2 tag header size is always unsynchronized.
Yes, but not the frame size bytes.
Does anyone have a mp3 with "grouping identity"?
Well, what a mess this all is! I have just tripped over the self same thing, writing code to embed album art in MP3 files in a way that Windows Media Player (bletch) can handle.
The situation seems to be that files marked (in the ID3 header) as ID3V2.4 use synchsafe integers in frame headers whereas files marked as ID3V2.3 or earlier do not. This is born out by the specifications themselves.
If you refer to theID3V2.3 spec, here:
http://www.id3.org/id3v2.3.0#head-1a37d4a1...950f77e47000bca (http://www.id3.org/id3v2.3.0#head-1a37d4a15deafc294208ccfde950f77e47000bca)
you will see that there is no mention of using synchsafe integers in frame headers. The ID3V2.4 spec, on the other hand, state explicitly that the frame size is a synchsafe integer:
http://www.id3.org/id3v2.4.0-structure (http://www.id3.org/id3v2.4.0-structure)
Just to share, Windows Media player 10 (and, possibly, 11) seems unable to handle synchsafe frame sizes even if the file is marked as ID3V2.4, so don't go there. Life is just too short for all this cr@p really. I'm sure it was all just an oversight in the original spec. I plan to use the ID3V2.3 format (I have no choice really) and pad any tags which happen to generate a synch pattern in the frame size bytes. I also plan to use 'unsynchronisation', which is indeed a completely different thing, for the image data itself, once I have tested that WMP can handle it.
Unsynchronization can only be applied to the entire tag in 2.3, whereas you can apply it to individual frames in 2.4. This means that in 2.3, the tag size field is stored as syncsafe, while the frame sizes aren't. In 2.4 all sizes are stored as syncsafe.
You can read a syncsafe integer by ignoring the MSB of each byte (which should always be 0), and shifting over it, giving you the equivalent of a 28-bit integer (which is why ID3 tags can't be larger than 256MB).
Like Paul said, don't actually USE unsyncronization if you want your tags to be read properly. I can't think of a reason to ever use such a feature.
Funny to have unsynchronization mechanism and then not dealing with unsynchronization in the 4 bytes describing the size!!?? Bad design or am I missing something?
The idea is that in 2.3, IF the tag is unsynchronized, the frame size fields would all get padded with unsync bytes (so there is no point in explicitely making them syncsafe).
Thanks for your response.