Is %_multiartist% broken or my file naming script incorrect?

MusicBrainz Picard
1

Hello, this is the naming script I use which I’ve never had any issues with, till I noticed my files not being named correctly today:

$if2(%albumartistsort%)/
$if2(%albumartist%,%artist%) - %album% (%date%)/
$if($gt(%totaldiscs%,1),%discnumber%-,)$if($and(%albumartist%,%tracknumber%),$num(%tracknumber%,2) ,)$if(%_multiartist%,%artist% - ,)%title%

If I’m not mistaken, the expected outcomes for an album with multiple %artist% values across its various tracks should therefore resemble:

D:\Music\Doe, John\John Doe - Album (2022-10-10)\01 John Doe - Track 1.flac
D:\Music\Doe, John\John Doe - Album (2022-10-10)\02 John Doe feat. Jane Doe - Track 2.flac

However, all I’m getting is:

D:\Music\Doe, John\John Doe - Album (2022-10-10)\01 Track 1.flac
D:\Music\Doe, John\John Doe - Album (2022-10-10)\02 Track 2.flac

Is this an issue on my end or with %_multiartist%? My Picard version is 2.8.3.

2

First off, your test “$if(%_multiartist%,” will always return true if the %_multiartist% variable is set by Picard because (according to the documentation) it will return either “0” or “1” (we should probably fix that), and the $if() test checks if the value is blank. The correct test in this case would be “$if($eq(%_multiartist%,1),”.

However; judging by the results that you posted, it appears that Picard is not setting the “%_multiartist%” variable, which leads me to believe that you might saving your files directly from the clustering pane rather than matching them up to tracks on an album in the release pane. Note that if you’re saving from the clustering pane, Picard will only have access to the tags already existing in the files. If this is the case, what happens if you try saving after matching the files to tracks in the release pane? If this is not the case, then we’ll have to look a bit further to see what might be happening. In that case could you please provide a link to a release on MusicBrainz that doesn’t seem to be working for you?

3

Apart from the idea that files on the left pane are stored, also consider that _multiartist is only set if tracks of one album actually have different artist tags.

The docs are wrong on this. Like other such variables Multiartist gets set to 1 or is left empty.

1 Like
4

Okay, thanks for confirming. I’ll enter a PR to make the correction in the docs.

5

I am indeed saving the album from the release pane, and the album does have tracks with different artist tags.

I installed 2.8.2 to see if the issue persisted, and it did, but only for this album specifically; other multi-artist albums were named as anticipated. The release in question is one that, on MB, all tracks currently (and incorrectly) have the same artist credit for. As my edit to fix this hasn’t yet been approved, I manually added multiple artists to my local files by editing %artist%, %artistsort%, %artists%, and %musicbrainz_artistid%. Could the issue be that Picard is getting the info needed for %_multiartist% from MB, as opposed to from local tags?

6

If I understand you correctly, the issue seems to be specific to the 2.8.3 version of Picard? That’s interesting because I just did a quick look at the changes between the two versions and didn’t see anything obvious that would cause the change. Maybe a detailed look (by someone more familiar with the code base) will turn something up.

Yes, I believe it sets that variable based on the information retrieved from MusicBrainz.

7

On second thought, I’m likely mistaken. I was editing the script in an attempt to figure out the problem or fix it, and probably got confused at some point.

Well, that explains a lot. The edit has been approved now (thanks chaban), so the problem has been resolved.

Thanks everyone for your help.

2 Likes
8

Try this:

$if($and(%_multiartist%,$or(%compilation%,%_artists_album_additional_id%)),%artist% - ,)

but you also need @rdswift Additional Artists Variables plugin.