Why sync-safe integer?

Question

I'm recently working on ID3v2.4.0. Reading 2.4.0 document, i found a particular part that i can't understand - sync-safe integer. Why does the ID3v2 use this method?

Of course, i know why the ID3v2 uses Unsynchronization scheme, which is used to keep MPEG decoder from considering ID3 tag as a MPEG sync data. But what i couldn't understand is that why sync-safe integer instead of Unsynchronization Scheme (= inserting $00).

Is there any reason why they adopt sync-safe integer when expressing tag size instead of inserting $00? These two method result in completely same effect. 

ID3v2 document says that the size of unsynchronized data is not known in advance. But that statement does not make sense. If tag data is stored in buffer, one can know the size of unsynchronized data after simply replacing the problematic character with $FF 00.

Is there anyone who can help me?

Answer 1

I would presume for simplicity, and the unsynch/synch scheme only makes sense when used on an mpeg file.

It is trivial to read in the four bytes and convert them to a regular integer:

// pseudo code
uint32_t size;
file.read( &size, sizeof(uint32_t) );
size =   (size & 0x0000007F) |
       ( (size & 0x00007F00) >> 1 ) |
       ( (size & 0x007F0000) >> 2 ) |
       ( (size & 0x7F000000) >> 3 );

If they used the same unsynch scheme as frame data you would need to read each byte separately, look for the FF00 pattern, and reconstruct the integer byte by byte. Also, if the ‘size’ field in the header could be a variable number of bytes, due to unsynch bytes being inserted, the entire header would be a variable number of bytes. Simpler for them to say 'the header is always 10 bytes in size and it looks like this...'.

ID3v2 document says that the size of unsynchronized data is not known in advance. But that statement does not make sense. If tag data is stored in buffer, one can know the size of unsynchronized data after simply replacing the problematic character with $FF 00.

You are correct, it doesn't make sense. The size written in the id3v2 header and frame headers is the size after unsynchronisation, if any, was applied. However, it is permissible to write frame data without unsynching as id3v2 may be used for tagging files other than mp3, where the concept of unsynch/synch makes no sense. I think what section 6.2 was trying to say is 'regardless of whether this is an mp3 file, or a frame is written unsynched/synched, the frame size is always written in a mpeg synch-safe manner'.

ID3v2.4 frames can have the ‘Data Length Indicator’ flag set in the frame header, in which case you can find out how big a buffer is after synchronisation. Refer to section 4.1.2 of the spec.

Is there anyone who can help me?

Some helpful advice from someone who has written a conforming id3v2 tag reader: Don't try make sense of the spec. It surely was written by madmen and sadists. Just looking at it again is giving me nightmares.