[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