<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello.<br>
<br>
I believe a forum would be a great help for developers who are
interested in the ID3vX. Therefor I ask everyone to support the idea so
the specs team considers the a forum setup. If you find the idea useful
send Martin Nilsson an e-mail please.<br>
<br>
Thanks.<br>
<br>
Wan-Hi<br>
<br>
Ben Bennett wrote:
<blockquote cite="mid20050513023147.GA26834@ayup.limey.net" type="cite">
<pre wrap="">[I have cc'ed <a class="moz-txt-link-abbreviated" href="mailto:info@getid3.org">info@getid3.org</a> to try to get them to weigh in on
interpreting the 2.4 spec since they seem to have a robust parser]
On Fri, May 13, 2005 at 02:40:19AM +0200, Wan-Hi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Ah... yes in 4.1.2 it says "If this flag is set all data from the end
of this header to the end of this frame has been unsynchronised.", so
I think you are right. I was confused because the data length
indicator is stored as a syncsafe integer.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
I think that is incorrect since the compression just mandates that the
data length flag be set. But the data length indicator can be present
even if compression is set and that would change the ordering you
proposed above.
</pre>
<blockquote type="cite">
<pre wrap="">I'd like to know, where would I find the 'text encoding' description
byte in text frames?
</pre>
</blockquote>
<pre wrap=""><!---->
It is first byte in the actual frame payload.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
That is my reading too... but everything would make far more sense if
the data length indicator was read first giving something parsing the
frame an idea of how big the result would be so it could allocate
memory for it. Since the DLI is syncsafe it will not be affected by
unsync. Then unsync can happen on the remainder of the frame data.
Then decryption and uncompression. These are the stated order in the
spec, but it is reversed from the order of the bitfield. Hence my
confusion.
I suppose the "right" answer is to dig through the code of a couple of
projects that purport to implement this:
- id3lib: <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/id3lib/">http://sourceforge.net/projects/id3lib/</a> (C / C++ parser)
- getid3: <a class="moz-txt-link-freetext" href="http://www.getid3.org/">http://www.getid3.org/</a> (PHP parser)
(the code in question is here:
<a class="moz-txt-link-freetext" href="http://getid3.sourceforge.net/module.tag.id3v2.phps">http://getid3.sourceforge.net/module.tag.id3v2.phps</a>)
I realized something new when reading the 2.4 spec and changes
document again. The unsync flag in the tag header just indicates that
all frames have unsync set _not_ that unsync should be applied on a
tag level. In fact it seems that in 2.4 that flag can basically be
ignored.
Thank you for replying and helping make sense of this tangled spec.
-ben
---------------------------------------------------------------------
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>