Nasty ID3V2 tag bug

Question

This is for any of the Apple team. I discovered a pretty bad ID3V2 bug in iTunes for Windows, 6.0.4.2.
It has to do with the way the frame data length is encoded, or rather, in this case, not encoded. The result is that any tag data>127 bytes in length will likely break the entire tag.
The length of the data for a 2.4 version tag is the first 4 bytes after the ID field(TPE1, TIT1, etc). These bytes are syncsafe, meaning that the highest bit is always 0. So each byte actually encodes 7 bits. I had a frame that was 467 bytes in length. Its length was stored as "0x01d3". That equals 467. But it is supposed to be sync-safed, so it should actually be 0x0363. As a result, 0x01d3 actually decodes to only 211 bytes. When a tag parser jumps 211 to what should be the next tag, t'aint nothing there! So all subsequent frames are then lost.
This can get pretty nasty on Unicode tags which can then only store 64 characters before it breaks things.
iTunes and presumably the iPod and any other Apple supplied tools will probably read that data correctly as I am assuming they use a common library. But...it will break any third party tools. Not good.
Mac Mini   Windows XP Pro  

Answer 1

This is quite possibly the most annoying iTunes/iPod bug, and it's still kicking around in the latest iTunes version.
Note that all ID3v2 frames found in the tag prior to a frame with length greater than 127 bytes are read just fine. Once iTunes hits the syncsafe integer it gets lost.
ID3v2 frames can appear in the tag in any order. This means if you have a tag editor that lets you specify the order the frames appear in the ID3v2 tag and set it to put all frames which are "most likely" to be larger than 127 bytes (e.g. APIC, TIPL, TMCL), you can at least get iTunes/iPod to recognize a larger subset of the information. But granted, as you stated, that doesn't really help the unicode case.
  Windows XP