MusicBrainz Picard quite often doesn't write the `albumartist` tag

Even though the correct Album Artist is visible in the Metadata pane, it’s not always saved as a tag in the output file. However, the sorted version is always saved.

Here’s an example for Deserve You (intro mix) by Jordin Post from Anjunabeats, Volume 16 where the tag was written:

Metadata pane in MusicBrainz Picard:
Screenshot from 2022-08-09 12-34-01

Quod Libet > Track Properties:
Screenshot from 2022-08-09 12-33-36

Here’s an example for Neokaidan by Acryl Madness from I’m Madness where the tag was not written:

Metadata pane in MusicBrainz Picard:
Screenshot from 2022-08-09 12-17-42

Quod Libet > Track Properties:
Screenshot from 2022-08-09 12-24-11

Why is that? How can I make MusicBrainz Picard always write the albumartist tag?

Maybe quodlibet just can’t read the data.

  • What file formats are those examples?
  • Is this happening only with specific file format?
  • What happens if you load a saved file again into Picard and move it into the left side of unmatched files. If you select this file, is the albumartist tagged filled? If yes, the data got saved to the file
1 Like
  • What file formats are those examples?

Both examples are Opus files.

  • Is this happening only with specific file format?

No, I see this happening with MP3’s, too.

  • What happens if you load a saved file again into Picard and move it into the left side of unmatched files. If you select this file, is the albumartist tagged filled? If yes, the data got saved to the file

Yes, it is filled. Perhaps, that’s indeed a problem with Quod Libet. I will report to them. Thank you.

UPD: see quodlibet#4084.

1 Like

Anecdotally, I think I’ve also seen this with FLAC files. However, I’m not sure if the album artist even makes it into the preview pane for all tracks in a release.

The only tagger script I can think of related to this that I use is,

$if(%_multiartist%,,
$unset(albumartist)
$unset(albumartistsort)
)```

It’s all a bit odd as Vorbis tags are of the more simple ones and quod libet and Picard both use the mutagen library (which is developed by the quod libet developers) to read and write tags. So I don’t really see a reason why Picard would read a tag back while QL can’t.

Maybe of you can provide a file affected by this me or one from the QL team could take a look.

I was about to send you a file when I noticed that I was mistaken, and the second example above is actually an MP3. My bad. Upon further investigation, I found out that indeed only MP3’s are affected. Meaning, all of them (855 files) for some reason seem not to have the albumartist tag when viewing in Quod Libet (and, consequently, in Ex Falso).

Here’s an example of one of them. Unfortunately, I didn’t find a free release to share, but this file is basically a scrapped version of the YouTube video, so I think it should be fine…

Anyway, here’s My Stick! by Bad Lip Reading.

1 Like

Thanks for the update. I checked Quod Libet’s source, and for MP3 (or other formats using ID3) it does not support an albumartist tag, but instead will load the value saved by Picard as performer.

Why? Because history. ID3 does not directly have a frame for album artist. When Apple needed a field for the album artist in iTunes they decided to use a frame called TPE2. ID3 defines this as:

The ‘Band/Orchestra/Accompaniment’ frame is used for additional information about the performers in the recording.

Anyway, Apple used this for album artist, many players and tools followed their example and storing album artist in TPE2 became the de facto standard.

But Quod Libet called this frame performer internally. :person_shrugging:

5 Likes

Thank you for the investigation. Using these terms, I found out that there is a long-standing issue about this in the Quod Libet’s repository: quodlibet#1179. Seems like remapping tags is quite challenging.

2 Likes