[frankvw]

I'm confused.

The official party line states that "Kodi has strong support for MusicBrainz tagging. It is highly recommended that users tag their music files using MusicBrainz Picard." Fine. But then why does Kodi use the " / " (space-slash-space) sequence to separate multiple values in one field, while Musicbrainz Picard uses the ";" (semicolon-slash) sequence for the same purpose?

Yes, Kodi's default separator can be overridden in advancedsettings.xml, but "strong support" and "mismatched default settings" don't strike me as a sensible combination! Shouldn't this be changed?

More flexibility in the separator sequence would be ideal; multiple separators would help (e.g. "/", " / " and "; " combined) could help to make it less of a PITA.

Then there's the fact that Musicbrainz is a user-populated database that uses free-form fields for a number of features, which compounds the problem considerably since this is a recipe for errors, inconsistencies and contradicting entries. Artist sort order, is a good example. A track that has "Above & Beyond feat. Zoë Johnston" in the artists field should not have "Beyond, Above feat. Johnston, Zoë" in its artist sort order field! (I imagine that Above & Beyond / Johnston, Zoë" would be the correct format.) Granted, that is essentially a MB issue and not a Kodi issue, but parsing these free-form entries better might help.

Just a few gripes thoughts... 

// FvW

[jjd-uk]

Historical I would guess. Kodi has been around for 20 years and for all that time been the separator has been space slash space, however the Musicbrainz support is less that 10 years old. So I would guess the existing seperator was not changed in order to not to force exisiting users to have to retag their music files.

[scott967]

Picard is not Musicbrainz, though it is a recommended tagger.  But the point I think is that the visual field separator in a tagging app is generally designed to be tag-format agnostic, with the actual tag contents being managed "behind the scenes".  I prefer formats like ID3v2.4, APEv2, and Xiph which specify "out of band" methods of providing multiple values for fields.

scott s.
.

[frankvw]

Picard is not Musicbrainz, though it is a recommended tagger. 

Granted, although one would be forgiven for not quite understanding the separation. Picard lives at https://picard.musicbrainz.org/ and is intimately integrated with the MB back-end. So to all intents and purposes Picard is as much a Musicbrainz client as it is a tagger. It also is the only tagger I know of that includes the specific MB id tags that Kodi relies on.

The point I'm trying to make in my OP, though, is that the recommended method of using Picard and relying on Kodi's strong Musicbrainz support (not to say integration) could be improved.

[scott967]

OK, but my real point is you have to look at the actual tag format spec.  The historical problem is mp3v2.3, where only 3 tags had allowed multiple values, and the only allowed separator was the solidus "/" giving rise to the AC/DC problem.  That led to informal separators like "; " that aren't spec compliant and so may not be interoperable between devices.  That's why mp3v2.4 with utf-8 encoding is recommended for Picard settings.

scott s.
.

[frankvw]

OK, but my real point is you have to look at the actual tag format spec.  The historical problem is mp3v2.3, where only 3 tags had allowed multiple values, and the only allowed separator was the solidus "/" giving rise to the AC/DC problem.  That led to informal separators like "; " that aren't spec compliant and so may not be interoperable between devices.  That's why mp3v2.4 with utf-8 encoding is recommended for Picard settings.

I see. Your point about the "AC/DC problem" is well taken, I had not considered that.

I was entirely unaware of the mp3v2.3 vs mp3v2.4 options in Picard. On my system this was set to mp3v2.3 with '/' (no spaces) as the separator.  Thanks for pointing that out! (However, I still have no clue as to why Picard still uses '; ' for some of my MP3 files. I assumed this was due to whatever data had been entered when the track was included in the MB database, but that's obviously a wrong assumption on my part.)

What also confuses me is that Picard will let me choose between ID3v2.3 in either UTF-16 or ISO8859-1 encoding, in which case I can adapt the '/' slash separator to ' / ' as required by Kodi, or ID3v2.4 in UTF-8 encoding, but then the option to edit the separator sequence is grayed out. Or means using id3v2.4 that the separator sequence will be automatically ' / ' since I can't change it? I understand that the ID3v2.3 standard does not allow UTF-8, but why will Picard not let me change the separator sequence as soon as I use ID3V2.4?

Also, I believe that Kodi needs the MP3 tags to be encoded as UTF8 and not UTF16, is that correct? I've heard about problems with UTF16 coded tags that contain special characters.

// FvW