[ID3 Dev] question about compressed unsynchronized frames

[Wan-Hi]

Hello.

Thanks, that was helpful. The 2v4.0 specs confused me a little.

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. 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'd like to know, where would I find the 'text encoding' description 
byte in text frames?

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.



Thanks.

Wan-Hi




Ben Bennett wrote:

>[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
>
>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20050513/4cc6ccd7/attachment.html>