Does the cover art filename field still accept a scripted filename?

MusicBrainz Picard
1

TLDR: I’ve just updated to 2.8.4 from 2.8.3. I’ve used a little script in the cover art filename field in the settings for a few years, however it now seems to be ignored when I process albums.

I’ve had this snippet in my Cover Art options, in the field labelled “Use the following file name for images”, for quite a while now:

$if($gte(%totaldiscs%,2),../Artwork/,Artwork/)$if(%coverart_types%,$join(%coverart_types%, + ),front)$if(%coverart_comment%, \(%coverart_comment%\),)

It should put album artwork files into directories like this:

/Single disc album/
  Artwork/file.jpg
  01. Track.flac

/Multi disc album/
  Artowork/file.jpg
  Disc 1/01-01. Track.flac
  Disc 2/02-01. Track.flac

But what seems to happen now, is that the artwork gets put into the same directory as the audio files, so if there are four discs, then I get a copy of the artwork in each disc directory, exactly what the snippet is supposed to prevent :slight_smile:

Audio files get moved as expected, just that little script in the cover art filename field seems to be ignored. Perhaps there’s something I’ve missed? If it does turn out to be a bug, I’m running macOS Monterey (12.6.1), and my setup hasn’t changed beyond updating Picard.

1 Like
2

It’s a bug. We had some change in this release which makes sure all the normal rules for file naming compatibility and file name shortening get applied also for cover art files. But this patch drops the relative paths you use, this was not considered :frowning:

I’ll get this fixed for next release. A workaround can be that your script outputs an absolute path, then it should still work. Not sure if that’s possible in your use case. You probably need to replicate the parts of your normal file naming script that decides for the album directory.

4 Likes
3

Ah ha, thanks.

I’ll have a look—it’s been a while since I’ve wrangled my scripts—but I’ll probably just roll back for now.

1 Like