[ID3 Dev] question about compressed unsynchronized frames

Ben Bennett fiji at ayup.limey.net
Wed May 11 04:29:04 PDT 2005


Yes the field size includes any bytes added to support the frame
header flags (group id and data length).

I think your processing makes sense.  I am not sure why the
data_length_indicator is syncsafe since compression follows

			-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



More information about the ID3v2 mailing list