I am 
And I believe they make a perfect case for having the albumartistS tag available by default.
I may be misunderstanding your use case, but have you looked at the āAdditional Artistsā Variablesā plugin? It is available as one of Picardās standard plugins, and the User Guide explains the additional variables that are made available to both tagging and file naming scripts.
1 Like
This is very interesting indeed!
Still not sure on what to do though, since it is quite intrusive to ask people to add tags to their collection.
Will have to think about that.
Sorry, I misunderstood. I had assumed that you were talking about your collection, but I now see that youāre talking about software that youāre developing (or have developed) that others are using.
1 Like
Iāll repost what I wrote on github:
You guys should reconsider this as itās inconsistent in my opinion that artist has itās plural version and albumartist doesnāt when we already have mbid for both anyway.
Making this tag sort of standard is cool idea and makes music library handling much easier in software.
Example is funkwhale which now has pretty big problems with handling multiple artists and big mess which could probably be handled more easily when decisions like this would be done long time ago: !1279 #1170
Also Kodi already adapted and uses this tag to make library browsable: https://kodi.wiki/view/Music_tagging#albumartists
Thereās a need for this tag!
1 Like
Ok, several people want this tag. How can we move on now?
1 Like
Iāll see whether we will make this available for Picard 2.7
6 Likes
Great! Donāt forget albumartistssort too 
From the KODI world a BIG Thank You 
I can agree with this 100%.
Also as of now, I have encountered one issue related to this tag when using scripting. The issue is with Vorbis tags specifically. When using $setmulti(ALBUMARTISTS,%_albumartists%) , Picard does not match it to my uppercase ALBUMARTISTS tag properly, but loads it as albumartists (lowercase) instead and would write a second set of this tag after pressing save. ID3 is properly matched to TXXX:ALBUMARTISTS.
Here is a screenshot from the Vorbis (FLAC) file to showcase this issue:
Before that, I was using $setmulti(albumartists,%_albumartists%) , for which the Vorbis tag was matched correctly and only one set of this tag (ALBUMARTISTS) would be written, however in this case Picard did not match it to my TXXX:ALBUMARTISTS ID3 tag properly and would write another TXXX:albumartists tag instead (obviously).
Since ARTISTS tag does not have this issue I assume that this is only related to mapping tags via scripting, but I just wanted to mention this in case it would be somehow relevant to ALBUMARTISTS tag specifically.
@outsidecontext Keep up the good work and I canāt wait having this tag as a default tag (hopefully) at some point in the future!
FYI Another scenario whereby albumArtists is useful is for proper parsing when importing data into Roon.
Note currently an additional step is needed here to actually store albumArtist field as multiple values rather than albumArtists field, but having multiple values in albumArtists is useful starting point so users could manually copy from albumArtists to albumArtist if required, but I am going to request that Roon start to support albumArtists directly.
Please ALBUMARTISTS field should always be written as uppercase ALBUM_ARTISTS for all formats for comptability with Jaikoz/SongKong
I would prefer it to be written without an underscore, since that is consistent within Picard:
ALBUMARTIST
ALBUMARTISTSORT
CATALOGNUMBER
COMPOSERSORT
DISCSUBTITLE
ENCODERSETTINGS
MOVEMENTNAME
ORIGINALFILENAME
ORIGINALDATE
ORIGINALYEAR
Also:
Kodi, MusicBee, foobar2000, and MP3Tag do not use underscores.
I take your point but there is no real consistency, things evolve over time, the following fields all use underscores in Picard in the Vorbis mapping (as used by OggVorbis/Flac)
ACOUSTID_FINGERPRINT
ACOUSTID_ID
MUSICBRAINZ_ARTISTID
MUSICBRAINZ_DISCID
MUSICBRAINZ_ALBUMARTISTID
MUSICBRAINZ_ALBUMID
MUSICBRAINZ_RELEASE_GROUPID
MUSICBRAINZ_RELEASETRACKID
MUSICBRAINZ_TRACKID
MUSICBRAINZ_WORKID
MUSICBRAINZ_ORIGINALALBUMID
MUSICBRAINZ_ALBUMSTATUS
MUSICBRAINZ_ALBUMTYPE
Surely the key thing is compatability with existing applications, and MusicBee, foobar2000, and MP3Tag do not have this tag.
If Kodi does , well then yes that does undermine my point a bit, but Iām certainly not trying to force anyone to my system just purely to try and stop divergence for maximum interoprabilty.
Those are proprietary tags, and I think it is useful and makes sense to separate the proprietary part from the rest.
And they are consistent in the latter part, and not written as:
MUSICBRAINZ_ORIGINAL_ALBUM_ID
MUSICBRAINZ_ALBUM_STATUS
MUSICBRAINZ_ALBUM_TYPE
etc.
edit:
I notice you wrote MUSICBRAINZ_RELEASE_GROUPID, but there is no second underscore in it.
In case your software has that, you might need to make an adjustment?
True, but then if you look at the ID3 equivalents they use spaces, including in the latter part
TXXX:MusicBrainz Artist Id
TXXX:MusicBrainz Disc Id
TXXX:MusicBrainz Album Artist Id
TXXX:MusicBrainz Album Id
TXXX:MusicBrainz Release Group Id
TXXX:MusicBrainz Release Track Id
UFID:http://musicbrainz.org
TXXX:MusicBrainz Work Id
TXXX:MusicBrainz Original Album Id
so its all very inconsistent
But my point was really just about interopability.
You are right MUSICBRAINZ_RELEASE_GROUPID was a typo in a list I took it from, I will correct that list.
1 Like
KODI has used this version for many years now. Itās why I joined MB back in 2017 and I know it was in place long before that.
$setmulti(albumartists,%_albumartists%)
Would be good if we donāt reinvent the wheel as I would not be the only one with a lot of retagging to do. 
1 Like
As a foobar2000 and Mp3Tag user myself, I have also been tagging my files with ALBUMARTISTS for now, and as @hiccup mentioned, Picard uses Vorbis tags without underscores (except for MB specific tags), so imho it would be a little odd if we got ALBUMARTIST / ALBUMARTISTSORT and ALBUM_ARTISTS / ALBUM_ARTISTS_SORT.
2 Likes
I have been doing the same in MusicBee for a couple of years now.
I wouldnāt be enthusiastic if I have to review and change my existing scripts and mappings.
1 Like