[ID3 Dev] How do I deal with this problem COMM frame

[Ben Bennett]

On Tue, Apr 03, 2007 at 03:13:17PM +0200, Scott Wheeler wrote:
> Brian Schiffhauer wrote:
> >I was just wondering ... what is the purpose of a syncsafe integer?
> 
> To avoid false MPEG synchs (a pattern of 11 true bits).

To expand a bit, soemthing reading an MPEG stream needs to know where
the frames start (if it is picking up in the middle, or if there is
unexpected leading or trailint stuff, etc).  So it looks for the synch
information (and can use some othe things to sanity check... but it is
not perfect) by scanning the stream until it sees 11 true bits (or if
it has byte level framing information, one byte with all bits set
true, followed by one with the first three set true) then it assumes
it has an MPEG frame and treats the rest as something to decode.  So
if your tag contains something that matches that pattern, and your
player doesn't know how to parse ID3v2 tags, there is a risk of treating
the ID3v2 data as mpeg data and making the decoded stream contain a
burst of noise.

So the ID3v2.3 spec implemented tag level unsynchronization for the
tag body (i.e. all the frames) and used synchsafe integers in the tag
header, but that is not particularly efficient to decode (i.e. you
need to hold the whole thing in memory and then apply the rules to
remove the unschronization).  So in 2.4 they added frame-level unsynch
(and changed the meaning of the tag level unsynch flag) which
necessitated the change to syncsafe integers for the length (and
rejiggering of flags, etc.) in the frame headers since they are no
longer protected by whole-tag unsynch.

I hope I haven't befuddled you...

		    -ben


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