And why are there no separaters between the artist names in the composer tag? Should I open a separate issue for that?

And why, when I modify the tag in iTunes to add in the separaters, do I then lose all the other artists in that field other than the first artist? Very weird. It's like iTunes is saying there is no more room available for that field, so is just then truncating it to the first artist. However, if I then put the complete set of artists back in, it works OK. So iTunes must be fixing the tag somehow (this is an MP3 file with ID3v2.4 UTF-8 tags) and Picard is perhaps not writing it in a way that is compatible with iTunes (10.6.3).

I don't believe iTunes supports editing/rendering ID3v2.4 multi-valued tags properly at all - never has. There are probably no separators because in ID3v2.4 such multi-valued tags are supposed to have values NUL-separated. iTunes is supposed to understand this (it's the standard) but doesn't, and just removes them from the string.

See http://www.id3.org/iTunes and many other places around the web. When you manually edit it, it probably changes the encoding from UTD-8 to ISO-8859-1 (it really shouldn't, but meh, iTunes is weird) which bizarrely iTunes appears to handle differently; only displaying the first one. You should use a decent independent tag editor to see what's really going inside the files (mp3tag, for example).

I'd either use ID3v2.3, use Picard tagger script to co-erce multiple values to a single one with whatever separator you want - or just stop using iTunes if you want support for this kind of stuff. People have been asking for it for years.

In any case, it's not really relevant to this ticket. If you have random questions, the forum is a better place than a bug tracker ticket.

Thanks for the information. I mentioned this problem in the comments as I noticed it around the same time as I was wondering why "Composer Sort Order" wasn't being populated and thought there may have been a connection. I guess there is still some relevance in that to support this tag in MP3s one would have to use the iTunes custom TSOC tag, which would have to be a single-valued tag, like the TCOM tag that iTunes writes into ID3v2.4 files. Perhaps if one is going to write TSOC tags in this format, one may as well also write TCOM as single-valued tags, for consistency.

PS: Your explanation is exactly correct; here's what the Picard-written ID3v2.4 UTF-8 tag, displayed as 'Ian CurtisJoy Division' in iTunes, looks like in mutagen:

>>> from mutagen.mp3 import MP3
>>> MP3("05 New Dawn Fades.mp3")["TCOM"]
TCOM(encoding=3, text=[u'Ian Curtis', u'Joy Division'])

Now, if I break the field up comma-separated in iTunes and save the file, iTunes then displays the tag as 'Ian Curtis', this is as you said because the encoding was changed and hence the display behaviour changed:

TCOM(encoding=0, text=[u'Ian Curtis', u', Joy Division'])

Editing the field in iTunes again it displays correctly, because it makes the tag into a single-value tag (why it didn't do this the first time I haven't a clue):

TCOM(encoding=0, text=[u'Ian Curtis, Joy Division'])

If I write the tag in Picard as a ID3v2.3 UTF-16 tag it displays in iTunes as 'Ian Curtis/Joy Division'.

TCOM(encoding=1, text=[u'Ian Curtis/Joy Division'])

PPS: Also possibly related as a workaround to this improvement request; is it possible to populate the TSOC tags with something meaningful via a Picard tagger script? I wouldn't know how to start to do that. It would also be nice to know how to write a Picard tagger script that would provide a single-valued TCOM tag with comma-separated values instead of slash-separated.

I guess what this ticket is leaning towards is a request to have, in addition to the somewhat obscure ID3v2 tag compatibility options, a simpler iTunes tag compatibility option that automatically selects ID3v2.3 UTF-16 tags (disabling other options) for MP3 files as well as enabling the population of the iTunes "TSOC" tag in MP3 files and the "soco" iTunes MP4 tag. This I think would be more meaningful and more useful to iTunes users, without taking away Picard's aspiration to be a general-purpose tagger.

Also, although iTunes has a tendency to always switch UTF-8 & UTF-16 encodings to ISO-8859-1, it does stick with UTF-16 in ID3v2.3 tags if there is text that is not supported by ISO-8859-1, so UTF-16 does still make sense for the Picard's default.