Problems with TXXX Compatibility between Windows and other Apps


I'm having a really annoying time with Microsoft Windows/Zune and my ID3v2.3 tags. I've tried both UTF-16 and ISO-8859 with the same problems.

I used MusicBrainz Picard and MP3Tag to methodically go through my collection and add a set of information to the tags. There are a number of custom TXXX text frames used by MusicBrainz to contain their information and some other identifying information for the track-- stuff like "MusicBrainz Track ID" and "ASIN". With MP3Tag I also added the frame TXXX:ALBUM ARTIST (as opposed to "ALBUMARTIST") which is used by Foobar.

When the tag is first written everything is perfect in MP3Tag and Foobar. Unfortunately if Windows or Zune update the tag (and you can't keep Zune from adding stuff to the tag even if you disable automatic updating of metadata, and I need it to load my ZuneHD) it rewrites the TXXX frames and screws up the data. What happens is that the TXXX tag title overwrites the data-- what I end up with is a frame like this:


Where the original data ("official") has been overwritten with the equivalent characters in the TXXX title starting at the second letter. I assume this is some kind of Unicode shenanigans, were the NULLs in the unicode rendering of the title are getting confused with the termination of the title-- but how do I prevent this from happening? Is there some alternate encoding I can use? ID3v2.4 has even worse problems, and I just want all my programs and devices to play nicely together.




Okay, I've found a couple of other references to Windows 7 and Windows Media Player 12 wreaking havoc with TXXX tags ( and To the list of those two programs, I would probably add Zune as a possible culprit-- perhaps it is using the Win7 libraries is why. Unfortunately I am seeing no indications of a fix.

But Windows writes it's own TXXX frames that aren't ruined-- what is it doing that MP3Tag does differently. MP3Tag does Unicode. Is this like a byte order problem or something? The ID3Tag spec says something about changing the order by modifying the BOM at the start of the Unicode string-- could MS be using a different byte order than other programs?