I have MP3 files with Mp3Tag options set to read ID3v2 and APE and write ID3v2.3 UTF-16 and APEv2. For multi-value field entries, when Mp3Tag writes the ID3v2.3 tag, it is writing hex 00 00 FE FF as a separator. Is there anyway to modify this? In particular having that BOM in the middle of the ID3 field is causing problems for me in other software (it's treating the 00 00 as a separator and FE FF as part of the value string). The APEv2 tags work perfectly.
scott s.
.
Are you asking whether this is currently an option (not that I'm aware of), or requesting an enhancement to make it an option?
I don't believe that ID3v2.3 is even supposed to use null byte separators. Doesn't the spec say / is the separator in v2.3?
Several things I've found over the years with ID3v2 tags:
ID3v2.3 is much better supported and safer than ID3v2.4.
ISO-8859-1 encoding is simpler and safer than using UTF.
Few applications support multiple values in a field using a separator of any kind.
Sorry I am just getting back to this now. Spent forever cleaning up some problems in my collection and getting it to work in my library/player (XBMC12 FWIW). Here I think is what the problem is that I had (might not be 100% correct, need to unwind a bit after working like a dog on tagging). The source of my problem is with "album artist" and "genre" but probably has general applicability. In my case most music has multiple album artist and many files have multiple genre. This is a big problem with ID3v2.3, because the spec doesn't really support it, so every app has its own approach to the problem, typically with some sort of "in band" separator (eg, in MP3Tag \\). I found the separator problem insurmountable, but it turns out XBMC will also read APEv2 tags in MP3, and for these (also FLAC Vorbis comments) you avoid separator issues by repeating a field name .
So I used MP3Tag to read all my ID3V2.3 tags and write them out as APEv2, after working to get the MP3Tag \\ separator into the fields. That all worked outstanding, no problems. Note that I have to have unicode support.
My problem came, in that I wanted to back-fill the ID3v2.3 tag frames from the (now correct) APEv2 tags, for use by other apps that can't read APE. MP3Tag was happy to read the APEv2 and write out the ID3v2.3 in the form artist1\\artist2 or genre1\\genre2. But when I read those tags in other apps I was getting duplicates of artist2 and genre2. After hunting through the files, what seems to be happening is that when MP3Tag writes the APEv2 tags, it is in format (0xfeff) . When MP3Tag reads the APEv2 tag and writes the ID3v2.3 tag (in the case where it must concatenate multiple APE tag instances into a single ID3v2.3 frame) , it is in the format \\. It looks fine visually but what I find is that when apps read that ID3v2.3 tag, the second (third etc) occurrence of the is treated as valid data. What makes it more annoying is that I thought I might use a regex to get rid of the but I tried \xFE\xFF and \uFEFF in a couple different regex engines and it never worked for me. The only way to get rid of it that worked for me was to "backspace" across the in a text edit field. You can't see what tags have that "extra" visually, but after a while I could see that if I did a sort some apps would sort out the tags with the . So after a lot of work editing out the s from tags (and also folder names that got corrupted with s) I am now OK, and I now know better than to have MP3Tag write ID3v2.3 tags from APEv2 so I don't expect a repeat. I do think it is a bug, though, as ISTM that the should only be written as the first unicode char in a unicode string.
I agree that ISO 8859-1 was nice, if only we could get the world to agree to use only that char set life would be easy.
scott s.
.