[ID3 Dev] question about compressed unsynchronized frames

[Ben Bennett]

[Apologies for the last partial message... my fingers got confused and
sent rather than saved.  (The Shame!)]

The date_length_indicator is not appended to the frame data, it comes
before the frame data.  (It follows the frame header but preceeds the
data).

Also these bytes indicated by the frame header flags are not subject
to unsync, encryption or compression (section 4.1: These additions
affects the 'frame size' field, but are not subject to encryption or
compression.)  But since only the data_length_indicator is specified
as being syncsafe there could be sync problems with the grouping byte
and the encryption byte.

Also note that in section 4.1 it says "This information is added after
the frame header and before the frame data in the same order as the
flags that indicates them. I.e. the four bytes of decompressed size
will precede the encryption method byte."  However in the flag order
below the data length indicator seems to follow the encryption flag.
Unles I am misunderstanding how they are numbering the flag bits, but
since the spec gave them letters I assume the ordering is correct.
PLEASE tell me if I have the bit ordering backwards here, the spec
(section 2) says "The most significant bit (MSB) of a byte is called
'bit 7' and the least significant bit (LSB) is called 'bit 0'.", but
then doesn't discuss how it descrives bit fields (i.e. whether bit 0
is on the right or left of the string).

This is how I parse a 2.4.0 frame:
 1) Read the frame header
 2) Read the flag data bytes if the flags are set:
    A) Grouping identity (1 byte)
    B) Encryption (1 byte)
    C) Data length indicator (4 bytes)
 3) Read the remaining frame data (i.e. the size given - the flag data
    size)
 4) Transform the frame data read in step 3 in the following order (if
    the flag indicating that transformation is set):
    A) Remove unsynchronisation
    B) Decrypt
    C) Uncompress

Then you can do whatever you need to do to handle the frame data.

Of course, I would recommend not writing 2.4 since Apple appears to
have messed up their writer and do not write the frame size as an
unsynchronised integer whereas other conforming applications do.
Also Apple appears to write the flag fields in a 2.4 frame in 2.3
format AUGH.  :-(

I handle this by checking the flag fields to see if the high bit is
set and falling back to the 2.3 format if it is.  Similarly in the
un-unsynchronisation code I check to see if the high bit is set on any
of the bytes and if it is I treat it as if it is already
un-unsynchronised.

	     -ben

On Wed, May 11, 2005 at 12:01:42PM +0200, Wan-Hi wrote:
> hello.
> 
> can anyone tell me how a compressed and synchronized frame is intended 
> to get processed? if i understand the v4.0 informal standard correctly, 
> the size noted in the frame header includes the syncsafe 32bit integer 
> appended to the frame content. so this is what i would do:
> 
> 1) read the frame header
> 2) if the unsync flag is set, i undo unsync the content of the next 
> 'size' bytes ( which should include 32bit syncsafe data length indicator 
> int)
> 3) decompress the resynced content without the last 32 bits.
> 4) look up the first byte of the decompressed data, to see if the 
> content is ascii or unicode (if i know before that it's a text document)
> 
> is this the right way to deal with compressed frames? i'd appreciate any 
> help.
> 
> thx.
> 
> wan-hi
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org

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