[ID3 Dev] question about compressed unsynchronized frames

[Ben Bennett]

[I have cc'ed info at getid3.org to try to get them to weigh in on
interpreting the 2.4 spec since they seem to have a robust parser]

On Fri, May 13, 2005 at 02:40:19AM +0200, Wan-Hi wrote:
> But in my opinion you are wrong when saying that frame information 
> fields are not unsynced. 4.1 says that additional frame information 
> fields are inserted between the frame header and the actual frame data. 
> These fields are not subject to encryption or compression. However, they 
> are subject to unsynchronisation (4.1.2 'Frame Format Flag' - Subject 
> 'Unsynchronisation') because they follow the frame header and 
> technically they are part of the following frame data.

Ah... yes in 4.1.2 it says "If this flag is set all data from the end
of this header to the end of this frame has been unsynchronised.", so
I think you are right.  I was confused because the data length
indicator is stored as a syncsafe integer.

> So I think this 
> would be a more adequate procedure:
> 
> 1) read in data of [frameSize] bytes
> 2) undo unsync, if unsync has been applied
> 3) retrieve grouping info of the first byte, if grouping flag is set
> 4) retrieve data length of the next four bytes, if compression flag is set
> 5) retrieve encryption info byte, if encryption flag is set
> 6) decrypt data from here, if encryption flag is set
> 7) decompress, if compression flag ist set

I think that is incorrect since the compression just mandates that the
data length flag be set.  But the data length indicator can be present
even if compression is set and that would change the ordering you
proposed above.

> I'd like to know, where would I find the 'text encoding' description 
> byte in text frames?

It is first byte in the actual frame payload.
 
> Ben, to answer your question about the flag order. Whatever is most left in
> 
> %0abc0000 %0h00kmnp
> 
> comes first. It's Big Endian; the most significant bit is left.
> 

That is my reading too... but everything would make far more sense if
the data length indicator was read first giving something parsing the
frame an idea of how big the result would be so it could allocate
memory for it.  Since the DLI is syncsafe it will not be affected by
unsync.  Then unsync can happen on the remainder of the frame data.
Then decryption and uncompression.  These are the stated order in the
spec, but it is reversed from the order of the bitfield.  Hence my
confusion.

I suppose the "right" answer is to dig through the code of a couple of
projects that purport to implement this:
 - id3lib: http://sourceforge.net/projects/id3lib/ (C / C++ parser)
 - getid3: http://www.getid3.org/ (PHP parser)
           (the code in question is here:
	    http://getid3.sourceforge.net/module.tag.id3v2.phps)


I realized something new when reading the 2.4 spec and changes
document again.  The unsync flag in the tag header just indicates that
all frames have unsync set _not_ that unsync should be applied on a
tag level.  In fact it seems that in 2.4 that flag can basically be
ignored.


Thank you for replying and helping make sense of this tangled spec.

	      -ben

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