[ID3 Dev] Poll: Forum demand

[Wan-Hi]

Hello.

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.

Thanks.

Wan-Hi

Ben Bennett wrote:

>[I have cc'ed info at getid3.org 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:
>  
>
>>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.
>>    
>>
>
>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.
>
>  
>
>>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 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.
>
>  
>
>>I'd like to know, where would I find the 'text encoding' description 
>>byte in text frames?
>>    
>>
>
>It is first byte in the actual frame payload.
> 
>  
>
>>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.
>>
>>    
>>
>
>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: http://sourceforge.net/projects/id3lib/ (C / C++ parser)
> - getid3: http://www.getid3.org/ (PHP parser)
>           (the code in question is here:
>	    http://getid3.sourceforge.net/module.tag.id3v2.phps)
>
>
>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: 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/738f0855/attachment.html>