<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello.<br>
<br>
Thanks, that was helpful. The 2v4.0 specs confused me a little.<br>
<br>
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:<br>
<br>
1) read in data of [frameSize] bytes<br>
2) undo unsync, if unsync has been applied<br>
3) retrieve grouping info of the first byte, if grouping flag is set<br>
4) retrieve data length of the next four bytes, if compression flag is
set<br>
5) retrieve encryption info byte, if encryption flag is set<br>
6) decrypt data from here, if encryption flag is set<br>
7) decompress, if compression flag ist set<br>
<br>
I'd like to know, where would I find the 'text encoding' description
byte in text frames?<br>
<br>
Ben, to answer your question about the flag order. Whatever is most
left in <br>
<pre>%0abc0000 %0h00kmnp
comes first. It's Big Endian; the most significant bit is left.
Thanks.
Wan-Hi
</pre>
<br>
<br>
<br>
Ben Bennett wrote:
<blockquote cite="mid20050511134014.GA18643@ayup.limey.net" type="cite">
<pre wrap="">[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:
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:id3v2-unsubscribe@id3.org">id3v2-unsubscribe@id3.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:id3v2-help@id3.org">id3v2-help@id3.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:id3v2-unsubscribe@id3.org">id3v2-unsubscribe@id3.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:id3v2-help@id3.org">id3v2-help@id3.org</a>
</pre>
</blockquote>
</body>
</html>