<DIV>
<DIV><STRONG>To Ben Bennett:</STRONG></DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV>Both 2.3 and 2.4 use Syncsafe integers. ID3v2.4 its a nice one, i recommend you to implement yourself ID3v2.4/Reader-Writer and threat there your syncsafe problems, also if you you have problems with syncsafe email me, i develop some nice methods.</DIV><BR><BR><B><I>Robert Crowell <crowell@MIT.EDU></I></B> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">I am working on a python library to read (and possibly write) id3v2 tags.<BR><BR>Reading over the specification several times, I wasn't able to determine whether<BR>or not id3v2.3 frames use the 'synchsafe integers' that 2.4 frames do. (I<BR>understand that both 2.3 and 2.4 use synchsafe ints for the _tag_ size, but I<BR>couldn't determine what the _frame_ behavior is.)<BR><BR>While the specification seems to indicate that v2.3 frames DO NOT use synchsafe<BR>ints and v2.4 frames DO use synchsafe integers, I am encountering some odd<BR>behavior. Using the 'convert ID3 tags' feature in iTunes 4.9, I convert a v2.3<BR>tag to v2.4, but the frame size bytes don't seem to be any different in the 2.3<BR>and 2.4 versions. There is a long USER tag in one of my mp3 files (that was<BR>created by an unknown application) that contains 370 ASCII characters.<BR><BR>The 4 size bytes in this frame
 header seem to be encoding this value as a<BR>NON-synchsafe integer. In my code, when 2.3 is detected it expects<BR>non-synchsafe integers for frame sizes and everything is fine. However, after<BR>converting this tag to 2.4 in iTunes, it interprets the size as a synchsafe<BR>integer, and because iTunes did not modify the size bytes when converting from<BR>2.3 to 2.4, it gets the frame size wrong. It decides the frame is only 242<BR>bytes long rather than the correct 370. (size:0,0,1,114 -> 370 normal, 242<BR>synchsafe)<BR><BR>This causes a huge problem because not only is the USER tag not read completely,<BR>but my code mistakenly interprets the next 10 bytes as a new frame header. <BR>Because the size portion of this header is clearly invalid (since this isn't a<BR>real header at all), my code believes the size of the next frame is huge,<BR>interpreting 'manc' as the frame size bytes.<BR><BR>size bytes: $00 00 01 72 (for both 2.3 and 2.4)<BR>2.3 size: 370 (correct, assuming
 non-synchsafe int)<BR>2.4 size: 242 (incorrect, assuming synchsafe int)<BR><BR>Is iTunes at fault for not converting the USER frame's size to a synchsafe<BR>integer when converting a tag to 2.4? Am I mis-reading the ID3v2<BR>specification? If it turns out that iTunes is doing something silly, how would<BR>I detect it in my code?<BR><BR>Thanks for your help.<BR><BR>-Rob Crowell<BR><BR>P.S. I have also tested the tags generated by the Media Rage application for<BR>Mac. The behavior is the same. What am I doing wrong?<BR><BR><BR><BR>---------------------------------------------------------------------<BR>To unsubscribe, e-mail: id3v2-unsubscribe@id3.org<BR>For additional commands, e-mail: id3v2-help@id3.org<BR><BR></BLOCKQUOTE></DIV><p>
                <hr size=1><font face="Arial" size="2">To help you stay safe and secure online, we've developed the all new <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/security_centre/*http://uk.security.yahoo.com/"><b>Yahoo! Security Centre</b></a>.</font>