I've read through the ID3 specs what feels like hundreds of times now, and I just don't think I'm getting when to unsynchronize certain values, tags, frames, etc. Tell me if I got this right:

If the tag is v2.2 or v2.3
1. If the tag header indicates unsynchronization, unsynchronize the entire tag excluding the header, but including the extended header (if it exists) and all frames...and padding?
2. Always convert the tag size in the header to a synchsafe integer

If the tag is v2.4 (this is the grey area)
1. If the tag header indicates unsynchronization, all frames need unsychronization. This means I should unsynchronize every frame, but not the extended header (if it exists)
2. All sizes (header, extended header, frame) need to be converted to synchsafe integers

Now, in 2.4, if I unsynchronize a certain frame before reading it, do I still need to convert it's size to a synchsafe integer? Do I convert it before unsynchronizing the entire frame? I wish the documentation was just a LITTLE more straight forward...

Thanks a lot for your help,
MR

It's problems like this that finally forced me to take the leap into using libraries (I like libid3tag personally, but it's not for everybody).

Here's my interpretation.
For v2.2 and v2.3:
1) You have this correct. The value of the padding bytes MUST be $00 so it doesn't need to be unsynch'd.
2) Yes, because the spec says that each size byte must be %0xxxxxxx so by definition it must always be a synch safe int.

For 2.4
1) I'm not sure. The spec doesn't mention the extended header, but it also doesn't explicitly say that the extended header should not be unsynch'd. My guess is that it would work like v2.3 and should be unsynch'd.
2) Yes for the same reasons mentioned above.

Additionally in 2.4 individual frames have an unsynch bit which can be set. I can't tell whether this should be set when the flag in the header is set, but I would assume so.


As stated above, its size is already a synchsafe integer. You'll need to convert to a normal integer to get the size of the frame. This size is calculated AFTER unsynchronization, so just unsynchsafe the int, read the number of bytes specified, then synchronize the data.

A word of warning if you're writing a tag writer and not just reader, Winamp has problems reading unsynchronized tags. Foobar and Mp3tag can read them just fine, but Winamp chokes on them. I tried to let the developers know, but I haven't heard back from them. I just disabled unsynchronization for this reason.

I have experienced problems with iTunes, which has a bug which gets tickled for certain unsynchronized ID3v2.3 tags containing embedded album art. In this particular context Winamp performed well however. (Tested programs were: foobar2000, iTunes, MediaMonkey, Tag&Rename, dBpoweramp, Winamp, Mp3Tag, EasyTAG)

I too would disable unsynchronizing to be on the safe side. Who needs it anyway today? (I'm curious!)

Any device capable of parsing ID3v2.3 (or v2.4) tags will work just fine without it. Actually it doesn't even need to be ID3v2.3-capable; it just needs to be able to extract the tag length from the header and jump to where the music starts.

I actually retested my program again with Winamp and it appears the bug is in 2.4 tags with unsynch turned on for the tag and album art embedded. It seems to read only a frame or two from the v2.4 tags before stopping. Remove artwork and the entire tag appears* to be read just fine.

It's possible it's a problem with the libid3tag implementation but as I said foobar and Mp3Tag can read it just fine.

You are definitely correct about it being completely unnecessary in this day and age. If a player can't recognize tags, you should probably upgrade to one written this decade

* - I did not do exhaustive testing, but every field Winamp natively displays showed up in my test MP3.

I am writing a tag reader/writer. Flash's implementation of ID3 is crap, so I thought I'd so a little better (AS3 FTW)...anyway, it only needs to be able to write v2.3/2.4 tags, but I'd like it to read anything. Obviously, when the program I'm writing writes tags, it will have an option to "Clean" the tag to get rid of any of this unsync crap. Complicated, and seems unnecessary these days

I just wanted to say that the problems I experienced was with iTunes 7.6.

After installing the most recent version (8.2) of iTunes, my unsynced sample files with 'problematic' embedded art now parse correctly. The bug has been fixed.