catalog update : ampache reads artistinfo wrong if 2 artists performing as duet or similar

[SePHTaN]

Description

Describe the bug

Adding an album containing songs with featured artists Ampache misinterprets the Interpret info .
Example (Data from Musicbrainz picard):
Album : Rock Christmas, Volume 7
artist : David Bowie & Bing Crosby
artists : David Bowie/Bing Crosby
mb-albumid: 5e41e7eb-9dd5-432b-83c8-e6c772931286
MB-artistid: 5441c29d-3602-4898-b1a1-b77fa23b8e50/2437980f-513a-44fc-80f1-b90d9d7fcf8f

After the Update i have 3 Artists in my Catalog:
Bing Crosby, mb-artistid: 2437980f-513a-44fc-80f1-b90d9d7fcf8f
David Bowie, mb-artistid: 5441c29d-3602-4898-b1a1-b77fa23b8e50
David Bowie & Bing Crosby, mb-artistid: 5441c29d-3602-4898-b1a1-b77fa23b8e50

Wenn i now look at my David Bowie albums i there always have the artist info : David Bowie & Bing Crosby

To reproduce

Steps to reproduce the behavior:

1. Add an album to the catalog with a song from 2 artists performing together tagged with 2 mb-artistid's
2. There have to be additional albums in the catalog from the first tagged artist as this seems to be the only one ampache recognizes.

Expected behavior

Ampache reads both mb-artistids and adds this song to those two artist in the catalog.
If one or both doesn't exist adds this artist to the catalog.
So what to do with the info in the artist tag: David Bowie & Bing Crosby
So i could be happy when ampache decides to throw away this info and build it by itself from the tagged mb-artistid's.
In a way like this : the first mb-artistid as main artist und the second one as featured artist
Means ampache would display : David Bowie feat. Bing Crosby

Screenshots

Can be provided when necessary.

Environment

• Ampache version: 4.2.6-release
• Web server + version: Apache 2.4.38 +PHP7.3-fpm
• Server operating system: Debian 10 Buster
• Client operating system: Win10

Client type

• Web
• Ampache
• SubSonic
• DAAP
• UPnP
• WebDAV

Settings

Mostly default

Logs

Can be provided when necessary.

[kuzi-moto]

This may be a duplicate, see my issue: #1911

I would be quite happy if we could get it sorted out though!

[SePHTaN]

Hi kuzi-moto,

have been looking roughly through the issues of the last year not seeing your issue being almost 2 years old.
Just checked it on music brains and indeed i think it's exactly the same issue.

I am in deed greatly interested to get this sorted out, its anoying to see the wrong artist names in the library not beeing able to work around, except removing MusicBrainz and other online Databases from the scraping sources and put all info in the folders of the respective artist.
Even than you have to provide "wrong" informations to ampache to get it as near as possible to how it should be in the library. Aslong ampache isn't able to "correctly" respect the informations Musicbrainz (my favority since years) delivers, i believe this won't work.

I will do some examinations (Database structure i am not aware of) and report my results here trying to present a way that can be gane to achieve the disered improvements without to much need to alter the database structure.

Greets
Stephan

[SePHTaN]

Hi again,

I tried to look a little bit deeper into the underlying problem.

What i have been seeing in one of my cases Track 13, Rock Christmas Volume 7 Musicbrainz delivers the correct Tagging data, which i embedded with Musicbrainz Picard into the songs.
Mainly these Tags are for interest i think (for track 13 mentioned above) :
artist : David Bowie & Bing Crosby
artists: David Bowie/Bing Crosby
mb-artistid: 5441c29d-3602-4898-b1a1-b77fa23b8e50/2437980f-513a-44fc-80f1-b90d9d7fcf8f

Ampache don't handels this artist information correctly (my opinion).
What Ampache does is taking the Artist name (David Bowie & Bing Crosby) checks against the Library doesn't find this artist in the database hence adding it to the database. Up to this point one can but must not judge this as wrong, but looking to the associated musicbrainz-artistid (5441c29d-3602-4898-b1a1-b77fa23b8e50), the mb-artistid from David Bowie, it is definitly wrong.

In the musicbrainz-artistid field of the song are two artistid's stored separated by "/" :
mb-artistid=(5441c29d-3602-4898-b1a1-b77fa23b8e50/2437980f-513a-44fc-80f1-b90d9d7fcf8f)
This leads to my conclusion that ampache (or the tag reader id3?) strips the second id from the tag and disregards it.

This leads to the fact the album "Rock Christmas, Volume 7" exits in "Various Artists" due to the AlbumArtist and in "David Bowie" due to the arzist info in the database, but not in "Bing Crosby" whats wrong.

From my examination this seems to be a limitation of the database structure.
There you have artist, album , song and maybee movie which should be considerd as a unit.
The link between these is song -> album song-> artist, only allowing ONE connection between those.

When it comes to artist this is definitly not sufficient to reflect all thinkable relations.
When i think of Duets, LiveConcerts with Gueststars Think of BandAid uso. there is clearly a possibility needed the get those cases into the database.
Nobody wants to break everything apart bringing to much changes into the database so how to keep changes minimal to the existing database tables and also bring in the needed extension ?
What we have is 1 special case ! Song has more than 1 Artist.
How about storing a normally not existing artist number into the database like -1 or 0 indicating that more than 1 Artist exist.
Now we have an indicator, what is missing is the information what to do, here we can extend the database table for songs or
create a new table herefor.
What to store there :
Mandatory : Songid
Number of Artists ?
Artists with delimiter stored ( may lead to problems with long artist names or many artists)
Mandatory : Artistid's stored with fixed delimiter lets say "/"
Delimiter (the one in the artist name in the original tag, "&" in my case above may also be ft., feat. ...)

So if it comes to an "multiple artist tagged song" one can store the INDICATOR insted of the artistid and hence let ampache look for that information in the additional table.

I hope my thoughts are not to far from the existing database structure, as this was my first look into this today.

Greets
Stephan

[wagnered]

Hello @SePHTaN

After doing some research, the separator used seems to be dependent on the tagger/player. For example Musicbee requires a semicolon. I have found at least one album that uses the semicolon to separate artists. And Picard recommends the "/" or ";" but allows any character to be the separator.

Your issue is with Ampache. It is conforming to id3v2.3 specs. So your issue is actually a feature request.

Also, there is at least one situation that the "/" character would be a problem with the artist: AC/DC.🙂

[lachlan-00]

I've thought about this before and the only way to safely separate them is by mbid which can be split up by regex and separator will not matter.

Doing it by name/string is next to impossible compared to using codes like mbid.

Vainfo right now will strip any secondary mbids from the tags so that would need to change.

But. I think we can group albums and tracks from separate/groups or artists using the mbids pretty easily in the SQL.

[lachlan-00]

When grouping songs with multiple artist you can essentially duplicate the row with a different artist id

So a track with two artists would have two rows on the song table. The queries would have to be distinct on file to make them unique but it could very easily fit in the existing structure of the db without large structural change

[SePHTaN]

When grouping songs with multiple artist you can essentially duplicate the row with a different artist id

So a track with two artists would have two rows on the song table. The queries would have to be distinct on file to make them unique but it could very easily fit in the existing structure of the db without large structural change

I have very limited insight how ampache gathers all the info from database and then displays it for example in Artist View.
I assume when clicking on an artist to view his albums, there is an sql query then running through the albums table collecting all albums WHERE album_artist=artistid-of-ampache.
(The artistid-of-ampache simply starts by 1 increasing by 1 with every new artist added to the catalog i assumed.)
The same i assume for songs, when showing for example "Various Artists" und the click on any of those albums to show its songs.
There is an sql query then running like "select track, title, artist, time from songs" plus joins for additional data from other tables like tags for example.
How you think to decide to read for the additional artist. ? Extend the query with artist2 ?
What if there is more than one additional artist ? Store all additional artists in "artist2" with delimeter ?
Shure the number of songs with more than 2 artists will be fairly very limited but why not make it failsafe and avoid future feature requests and bloating of the songs table with to much artist information. That would be my concern.

Looking again at the tagged data from my example above (:
artist : David Bowie & Bing Crosby
artists : David Bowie/Bing Crosby
mb-artistid : 5441c29d-3602-4898-b1a1-b77fa23b8e50/2437980f-513a-44fc-80f1-b90d9d7fcf8f

The disregarding of the second artist from tags leads to the fact that "David Bowie & Bing Crosby" gets added as new artist with the first musicbrainz_artistid: 5441c29d-3602-4898-b1a1-b77fa23b8e50 what in fact is the id from David Bowie itself.
Now when i view my albums from David Bowie they are all from "David Bowie & Bing Crosby".

If you only store the artistid-of-ampache with the song the artistname can be retrieved from artist table, but what happens to the separator in the artist tag the ampersand in this case ? Could also be "feat." or "ft." (both for featuring) with an other artist !
If you do not store the artist(name) from the artist tag and i think thats not really needed because you should have after adding an album with such an dual/multi artist tagged song both/all of the accuring artists in the artist table.
Hence when you store the artistid-of-ampache with the song the name can come from the artist table, whats not in there is the delimiter how they where mentioned on the cover of the album.
Under the assumption that with dual/multi artist songs the name of the artist needed for the view has to be retrieven from the artists table then the delimeter "&", "feat." needs also to be stored in the songs table.

Greets
Stephan

[manuelglez86]

I think that one option will be to mimic to behavior of genres (tags), when a song has comma separated genres on th ID3 ID Tag Ampache separete them in two, lets say we have a song which genre is Electronic and House if the ID3 GENRE TAG HAS Electronic, House Ampache identifies the two tags.

Obviously this will need some work for the user also who will need to edit the artist tag like in your case artist : David Bowie, Bing Crosby.

Is just an idea, but I remember that multiple artist are not implemented yet on Ampche.

Also althoug I dont like it, the large companies begin to use this method:

The artist on the tags will always be the album artist or the main artist of the song, in your case lets say

Artist: David Bowie

And they put the featuring artist on the name of the song like this:

Song: Name of the song (Featuring Bing Crosby)

Is they way Spotify, Itunes, Apple Music and all of tthe services solved that issue.

[SePHTaN]

Is just an idea, but I remember that multiple artist are not implemented yet on Ampche.

Also althoug I dont like it, the large companies begin to use this method:

The artist on the tags will always be the album artist or the main artist of the song, in your case lets say

Artist: David Bowie

And they put the featuring artist on the name of the song like this:

Song: Name of the song (Featuring Bing Crosby)

Is they way Spotify, Itunes, Apple Music and all of tthe services solved that issue.

I know that multiple artist isn't yet implemented in ampache. Thats why i wrote this issue.
When your catalog grows, and mine is actually at around 48000 songs, it gets more and more screwed up due to this fact.
All my Albums from David Bowie are from "David Bowie & Bing Crosby" only because i have a Christmas Sampler with one Song where they performed together. And this is only one example from many others.

I don't care much about how spotify, itunes or anyone else solves this.
My Tagging Data mostly (99,9%) is from Musicbrainz and i like their quality and completeness.
And the musicbrainz tagging data dosn't have this problem, only ampache isn't currently able to completly reflect those
tagging data correctly in the database.

I posted this issue also to get a rough estimation how easy or fast it might be to get a solution.
I'm also not totaly new to programming, but have only very little insight to the code of ampache yet.
Due to the corona pandemic i do have a little more time at home, and i am willing to look into this by myself.
I am thinking about to fork ampache and try to add the missing feature.
What i am missing is how the way back to ampache has top be done, if i am able to implement this.

[manuelglez86]

Other feature that ampache has is that it can take into account The "Artist Album" tag on the ID3 ID TAG, filling this on your files will help Ampache to show the right Artist of the album regardless if a song on the album has a as an artist like "David Bowie & Bing Crosby"

If I understand you correctly, filling the "Artist Album" on your files will fix part of your issue.

[wagnered]

Multlple artists per song could be tracked using foreign keys in a one-to-many relationship (or is it many-to-one?). it would take major changes and i would suggest implementing in v5.x.x. Ampache will be converted to an object relational model (ORM) which, I believe should make complicated searches much faster.

I'm sure it also complicates other features such as searching for artist art and probably database searches.

[SePHTaN]

As multiartist per song/album is a feature i am really missing, began looking into how ampache handles this all.
I started looking into with 4.2.2 and moved this week to 5.00 as @wagnered suggested.

After having a little bit of insight to how ampache stores all this into the database , i began thinking about how this could
be extended to achive what i expect from ampache.

Frist idea (baddest of all):
Store multiple Artists serialized in the artist column of song
Bad because : how to do a mysql SELECT id FROM song WHERE 'artist' = $id

Second Idea :

When grouping songs with multiple artist you can essentially duplicate the row with a different artist id

How many duplicates are allowed ? I have at least one Song performed by 6 Artists together.

At last i came to the same conclusion like @wagnered :

Multlple artists per song could be tracked using foreign keys in a one-to-many relationship (or is it many-to-one?).

Best way for my opinion would be an extra table song_artists storing song_id, artist_id
I wouldn't be limited in any way, easy possibility to extends existing database querys by joining this table.
The artist column in song table could be used to store the Artist-Name, in the way it is mentioned on the album cover.
Not storing it seperatly anywhere would throw away the "styling" ex. A&B, C with D, E feat. F,G,H,I and J.

Though to get all this together there have to be many changes done in ampache and the only part i have had time to get a bit insight into are src/Module/Util/VaInfo.php, /src/Model/Artist,php and /src/Model/Song.php.

[lachlan-00]

Within the SQL i don't really see anything limiting duplication. The first artist as a primary song artist but the other artists would still be searchable. I think that my only requirement for multiples would be based on MBID to avoid the issue with strings.

I've got this as one of my todo's now that other things are stabilising.

[lachlan-00]

@SePHTaN i got your email but was blocked returning by my response. i'll send you some info from gmail instead of my personal mail tomorrow but we can get started on this.

[lachlan-00]

hey @SePHTaN just FYI the develop branch is going into a mini freeze while we work on source-changes merge,

Work on this will start again after that. i'll email you when things are clearing up and we can start again

[lachlan-00]

Not going to get done for 5.0

[ghost]

Not going to get done for 5.0

Any updates on this?

[lachlan-00]

it's basically done in develop. 5.3 coming probably within a week depending on my work

[ghost]

it's basically done in develop. 5.3 coming probably within a week depending on my work

Awesome! Looking forward to the update!

[lachlan-00]

it's a really requested feature and it helps actually speed up a few things too and just in general fixes up a lot of bugs so i'm really excited for this one to be closed.

[ghost]

it's a really requested feature and it helps actually speed up a few things too and just in general fixes up a lot of bugs so i'm really excited for this one to be closed.

You've got this bro, just looking at the commits you put out everyday!

I just did a quick test on the latest develop branch and my artist info stayed the same, did I miss something? I also noticed that in the change log you mentioned MusicBrainz ID, is it a must for this to work?

[SePHTaN]

Yes, for good and working identification of Artists Ampache relies on the Musicbrainz ID's.
You can read about this in the news for ampache: Ampache Readme

For my own Catalog i can say that i have always been tagging my music with musicbrainz picard.
What shloud i say, its really working excellent now for MultiArtist.
Some minor wishes exist, that may be coming in future, but the basic stuff is functional.

[ghost]

Thank you! This has been very informative!

[lachlan-00]

there are a few things to fix up and to document, the function is all correct so that won't be changing significantly before release

initial wiki doc here
https://github.com/ampache/ampache/wiki/multi-artist

[ghost]

I couldn't get it to work for some reason.

Docker setup, tasted with default configuration. MusicBrainz enabled.
For example the tags for this song are:

TITLE Roses
AlbumArtist Adam Lambert
ARTIST Adam Lambert & Nile Rodgers
ARTISTS Adam Lambert, Nile Rodgers
MUSICBRAINZ_ARTISTID ABCD1234, EFGH5678
MUSICBRAINZ_ALBUMARTISTID ABCD1234

This song is being showed in library with Song Artist as Adam Lambert & Nile Rodgers, Album Artist as Adam Lambert. However I thought the Song Artist section would be presented with both artists being separated, selectable entries?

[SePHTaN]

Your MB_ArtistID's are definivly wrong:
Adam Lambert: e942594a-91cc-427a-8beb-6815c28e9254
Nile Rodgers: c6d571dd-c0ae-4ac8-9500-780b1b9b25e5
You can't fake those ID's, Screenshot from an Example in my Catalog.

[ghost]

Your MB_ArtistID's are definivly wrong:
Adam Lambert: e942594a-91cc-427a-8beb-6815c28e9254
Nile Rodgers: c6d571dd-c0ae-4ac8-9500-780b1b9b25e5
You can't fake those ID's, Screenshot from an Example in my Catalog.

Oh no, sorry I meant to use ABCD1234 and such just as dummy IDs for the purpose of demonstration, The actual IDs in the file are identical to the ones you provided.

Could you maybe show you config file and the metadata of the music? Maybe there's something misconfigured on my side.

[SePHTaN]

Sure
first the config parts:
`;#########################################################
; Metadata #
;#########################################################

; This determines the tag order for all cataloged
; music. If none of the listed tags are found then
; Ampache will randomly use whatever was found.
; POSSIBLE VALUES: ape asf avi id3v1 id3v2 lyrics3 matroska mpeg quicktime riff
; vorbiscomment
; DEFAULT: vorbiscomment id3v2 id3v1 quicktime matroska ape asf avi mpeg riff
getid3_tag_order = "vorbiscomment,id3v2,id3v1,quicktime,matroska,ape,asf,avi,mpeg,riff"

; This determines whether we try to autodetect the encoding for id3v2 tags.
; May break valid tags.
; DEFAULT: "false"
;getid3_detect_id3v2_encoding = "true"

; This determines if we write the changes to files (as id3 tags) when modifying metadata, or only keep them in Ampache (the default).
; DEFAULT: "false"
;write_id3 = "true"

; This determines if we write the changes to files (as id3 tags) when modifying album art, or only keep them in Ampache (the default)
; as id3 metadata when updated.
; DEFAULT: "false"
;write_id3_art = "true"

; This determines the order in which metadata sources are used (and in the
; case of plugins, checked)
; POSSIBLE VALUES (builtins): filename and getID3
; POSSIBLE VALUES (plugins): MusicBrainz,TheAudioDb, plus any others you've installed.
; DEFAULT: getID3 filename
metadata_order = "getID3,MusicBrainz,TheAudioDb,filename"

; This determines the order in which metadata sources are used (and in the
; case of plugins, checked) for video files
; POSSIBLE VALUES (builtins): filename and getID3
; POSSIBLE VALUES (plugins): Tvdb,Tmdb,Omdb, plus any others you've installed.
; DEFAULT: filename getID3
metadata_order_video = "filename,getID3"

; This determines if extended metadata grabbed from external services should be deferred.
; If enabled, extended metadata is retrieved when browsing the library item.
; If disabled, extended metadata is retrieved at catalog update.
; Today, only Artist information (summary, place formed, ...) can be deferred.
; DEFAULT: "true"
deferred_ext_metadata = "true"

; Some taggers use delimiters other than \0 for fields
; This list specifies possible delimiters additional to \0
; This setting takes a regex pattern. TODO: explain that this is not just for genres until we can replace this safely
; DEFAULT: // / \ | , ;
additional_genre_delimiters = "[/]{2}|[/|,;]"

; Enable importing custom metadata from files.
; This will need a bit of time during the import. So you may want to disable this
; if you have troubles with huge databases.
; DEFAULT: "false"
;enable_custom_metadata = "true"

;#########################################################
; File Tags #
;#########################################################

; This determines if we write metadata to files when modifying metadata, or only keep them in Ampache (the default).
; DEFAULT: "false"
;write_tags = "true"

;#########################################################
; Catalog #
;#########################################################

; File Pattern
; This defines which file types Ampache will attempt to catalog
; You can specify any file extension you want in here separating them with a |
; DEFAULT: mp3|mpc|m4p|m4a|aac|ogg|oga|wav|aif|aiff|rm|wma|asf|flac|opus|spx|ra|ape|shn|wv
catalog_file_pattern = "mp3|mpc|m4p|m4a|aac|ogg|oga|wav|aif|aiff|rm|wma|asf|flac|opus|spx|ra|ape|shn|wv"

; Video Pattern
; This defines which video file types Ampache will attempt to catalog
; You can specify any file extension you want in here separating them with
; a | but Ampache may not be able to parse them
; DEAFULT: avi|mpg|mpeg|flv|m4v|mp4|webm|mkv|wmv|ogv|mov|divx|m2ts
catalog_video_pattern = "avi|mpg|mpeg|flv|m4v|mp4|webm|mkv|wmv|ogv|mov|divx|m2ts"

; Playlist Pattern
; This defines which playlist types Ampache will attempt to catalog
; You can specify any file extension you want in here separating them with
; a | but Ampache may not be able to parse them
; DEFAULT: m3u|m3u8|pls|asx|xspf
catalog_playlist_pattern = "m3u|m3u8|pls|asx|xspf"

; Prefix Pattern
; This defines which prefix Ampache will ignore when importing tags from
; your music. You may add any prefix you want separating them with a |
; DEFAULT: The|An|A|Die|Das|Ein|Eine|Les|Le|La
catalog_prefix_pattern = "The|An|A|Die|Das|Ein|Eine|Les|Le|La"

; Ignore Pattern
; Ignore files that match this pattern
; You can specify any file extension you want in here separating them with a |
; DEFAULT: None
; catalog_ignore_pattern = "(HTOA)"

; Catalog disable
; This defines if catalog can be disabled without removing database entries
; WARNING: this increase sensibly sql requests and slow down Ampache a lot
; DEFAULT: "false"
;catalog_disable = "true"

; Catalog filter
; This defines if catalog can be filtered per user.
; The filters are set in the catalog management pages.
; WARNING: this increase sensibly sql requests and slow down Ampache a lot
; DEFAULT: false
;catalog_filter = "true"

; Delete from disk
; This determines if catalog manager users can delete media from disk.
; DEFAULT: "false"
;delete_from_disk = "true"

; Catalog verify by time
; Only verify the files that have been modified since the last verify.
; For large catalogs the verify process can be terribly long so this will help
; speed things up by checking modification date using filemtime() before loading
; DEFAULT: "false"
catalog_verify_by_time = "false"
`
next a screenshot of musicbrainz-picard with the tagging of the song in the screenshot above:

as you can see the musicbrainz-database got some updates since i tagged this album

[ghost]

Thank you for taking time to help me, really appreciate it:), finally figured out what went wrong with my files(rather silly): for separator in the ARTISTS I used , instead of ;, once I changed it everything showed up correctly.

[manuelglez86]

Hello.

First of all thanks for all that work, it is a cool feature.

I was reading the wiki and I read this

The reason the regular artist and albumartist tags are ignored (for now) is due to how awful these fields can be. If you don't use these tags nothing will change and will function as normal.

If it is because of the separators artist Tag could have? (Like feat ft. , ;)

If thats the problem i think it could be an option in the configuration file like theres is now for genres:

additional_genre_delimiters = "[/]{2}|[/\\|,;]"

Where we could put the artists separators that ampache could use, and also the administrators could change.

If thats the issue and you want to implement something like that in future releases, let me know and I can make a deep research and propose which separators can we take into account.

Thanks

[SePHTaN]

Identifying Artist correctly is a bit more complicated than splitting Artist names.

• Multiartist songs not always have the MainArtist mentioned first in Artist Tag
• There exist a lot of Artists with the same name
• more things i can think of ...
  to correctly identify an Artist therefor Ampache needs an unique identifier and this is for instance musicbrainz_artist_id,
  there exist more possible identifiers from other databases (discogs or TheAudioDB for example).

It would be possible to identify song artists with an musicbrainz-database lookup during catalog scan.
BUT !!!
This works only then almost 100% correct if searching for full-albums or samplers, because you have to search for releases.
If you have single songs put together as your own "Sampler" then there is almost no chance to identify songs/artists correct.

Another BUT !!!
Full lookup during catalog scan is extremely time consuming as you have to do several lookup of musicbrainz for each album !
I though have a musicbrainz plugin modification in development that can do this, and its almost finished.
But testing is very time consuming and thats what i don't have due to real life stuff at the moment.
Some time i will make this available, but a full scan with complete musicbrainz lookup will slow down catalog scan at least by a factor of 2 or 3.
My own catalog takes already about 36 hours for a full verify, what would be 108 hours !
Lachlans told me his took about 1 week, what would be 3 weeks !

The option to do a full lookup may be a nice feature to have when its about to check a single album or maybe even all albums of a single artist.
I personally couldn't think of doing it as a general part of a full verify or add.

[SePHTaN]

So best way is to use a tagger like picard, and tag your albums before adding to your catalog.
Downside:
currently there exist some compatability problems between Musicbrainz picard and the tagreader of ampache (getid3) when it comes to mp4/m4a tags with multi-value fields (artist, genres ...)
Solution:
After tagging with picard, which has a very decent and comfortable method for finding the correct album and therefor is my favorite, you can reopen your m4a album with mp3tag (configured to delete existing tags before rewriting them) and just save the tags again.
Mp3tag writes the multi-value fields in a different structure than picard and doesn't have compatability issues with getid3.

[lachlan-00]

Closing this as the 5.2+ releases have fully supported this and it's not presenting any issues for a while and the pull for 6 is almost ready.