[ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ?

Ben Bennett fiji at ayup.limey.net
Fri Apr 6 07:06:03 PDT 2007


On Fri, Apr 06, 2007 at 02:39:09PM +0100, Paul Taylor wrote:
> >From IDv3v24 Spec ' Bit 7 in the 'ID3v2 flags' indicates whether or not 
> >unsynchronisation is applied on all frames (see section 6.1 for   
> >details); a set bit indicates usage.'
> 
> What exactly does this mean, and what is its purpose? If I have a tag with 
> 10 frames, and only one of those frames actually contains a FF FE pattern, 
> and this frame is synchronized, and there is nothing to for the other nine, 
> does that mean the tag unsynchronisation flag  is on/off. 

The rule is defined in http://id3.org/id3v2.4.0-structure section 3.1:
   a - Unsynchronisation

     Bit 7 in the 'ID3v2 flags' indicates whether or not
     unsynchronisation is applied on all frames (see section 6.1 for
     details); a set bit indicates usage.

So, unless all frames have the unsync flag set, this should not be set.


> Or if one of the other frames does not contain a FF FE pattern but does 
> contain a FF 00 pattern should that frame be unsynchronized (even though it 

FF 00 is fine and will not cause a sync problem.  Note that the
unsynchronization algorithm is different from a syncsafe integer.  A
syncsafe integer is one that just skips the high bits in its 4 bytes
(so it only stores 28 bits of data, so the max is 268435455).

Whereas the unsync algorithm is needed if you have the byte pattern:
 %11111111 111xxxxx
If you do, only then should you do unsync (if requested).

If you are performing unsync then any $FF is replaced by $FF 00... so
you actually uncynchronize more than what is strictly necessary to be
syncsafe.

e.g., if you had the frame data:
 $FF 00 
If uncync is requested by the user, you should not do it on this frame
since it is unnecessary.

But if the frame data is:
 $FF 00 FF FF
Then if unsync was requested, then you need to do it on this frame,
which results in:
 $FF 00 00 FF 00 FF 00


> creates more work at decoding and encoding ends) and only if all these 
> cases were covered would the tag unsynchronisation flag be on. 

It depends who you think will be using the final file.  Unsync is only
ever needed if you are dealing with software that does not understand
how to skip over ID3v2 tags and instead might go into "scan for an
MPEG sync" mode.  Frankly, modern software knows how to skip ID3v2
frames, so I would avoid unsync.  There may well be hardware players,
or older software that still breaks, so you have to think of who will
be using the file.

I try to avoid setting any of the header flags since I suspect the options
are not well supported, and also, the flag byte format changed (the
bits indicating which is which) moved around between 2.3 and 2.4 and I
have seen iTunes mess up the flags when converting a tag from 2.3 to
2.4.  (I am not sure if that is current behavior or not, it may have
been fixed).


> If the tag contains 10 frames and non of the frames contain an FF FE or FF 
> 00 pattern, then unsynchronization would have no effect should the flag be 
> on/off

I would set it off if possible.  I bet not all players support it
correctly, and even if they do, not having to do unsync is faster.

Of course... I do not trust the tag level flag in 2.4, I look at the
frames regardless.

		    -ben

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



More information about the ID3v2 mailing list