[ID3 Dev] How do I deal with this problem COMM frame

[Paul Taylor]

Ben Bennett wrote:
> Yes you should write syncsafe integers it is not optional in 2.4, and
> not doing so would break a bunch of other software.  There is a bug in
> with Apple about this and someone was being pretty responsive about
> other issues for a while... hopefully that will get fixed.
>
> I would prefer unsynced 2.3 tags where possible for the widest
> compability.  If you need to write a 2.4 tag, then I would try to
> order the frames so that the large ones are at the end of the
> tag... if the size is misinterpreted they over-read the length, and
> iTunes at least stopes when it hits the end of the frame.  Since these
> large frames are usually images, iTunes interprets the contents
> correctly and displays the image and then ignores any trailing stuff
> from where it overread.
>
> Note that when reading a 2.4 tag, you need to implement heuristics to
> pick up on iTunes' messed up frames.  You can look at the size and see
> if it could be syncsafe (i.e. if any high bits are set on the 4 bytes
> then you know it is not syncsafe), and if it could be syncsafe then
> you will need to read to the end of the frame then check to see if the
> next data looks like a frame (or if you have hit the end of the
> buffer).  In which case you need to try it as a non-syncsafe length
> and see if you find a valid frame.  This is all assuming the frame
> length is 255 or more, if it's less then you are all set.
>
> 	  -ben
>   
Ok, all make sense I will do as you say.

This kind of information would be very as some kind of companion 
document to the ID3 Specifications, providing  advise on  the best way 
to implement the specification in the real world, anybody agree ?

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org