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

[Ben Bennett]

On Tue, Apr 03, 2007 at 03:43:46PM +0100, Paul Taylor wrote:
> Ben thanks for the example but not sure that I follow shouldnt it be
> 
> 00000000 00000000 0000011*1* *0*0111000
> 
> ,i.e bit 7 is always zero and what would be bit7 is shifted into the the 
> next byte.

You are absolutely correct.  I am clearly doing too many things at
once today :-(

 
> >The hell part arises because some software (iTunes) does not implement
> >the spec correctly and reads and writes regular integers rather than
> >unsyncronized ones when dealing with 2.4.  :-(
> >
> >  
> Oh dear, what have others done about this then. It also leads me to 
> wonder whether I should even write v24Frame syncsafe integers by 
> default. For ID3v23 I always unsynced the tag where required but because 
> this caused a problem for Itunes Ive changed the default so that it 
> doesnt write them unsynced.

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

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