Cover Art Archive Setting "Use the first image type as the filename" Behavior Inverted

According to the help section:

When checked, Picard will use the type of the first image retrieved as the filename when saving all images. If left unchecked, each file will be named according to its image type.

In practice, the opposite behavior is true. In other words, when the box is checked, the file type (front, booklet, etc) becomes the file name for all downloads. When unchecked, all files will be named the same according to the first image type.

1 Like

You are right, this documentation is not correct. What is meant with first image type is the first type of the respective image (in case an image has multiple types). So as you said checking this will cause the image type to be used for naming. Unchecked it uses the file name as configured.

I’m in general a bit unhappy about this option. It is rather unclear how this behaves in combination with other options, e.g. the configured name. And as one can use scripting in the cover art name one can replicate this behavior of using the type for name with scripting also.

1 Like

Thanks for pointing this out. I’ve entered a ticket to make the correction.

3 Likes

Is something like the following clearer?

When checked, Picard will use the type of the image (e.g.: front, back, booklet, etc.) as the filename when saving. If the image has been assigned multiple types, then the first type will be used. For example, if the image is of types “Front” and “Raw”, then “front” will be used for the filename. If unchecked, Picard will use the file name specified in the “Use the following file name for images” setting in the “Location” section of the “Cover Art Options” settings.

Any suggestions that might clarify it further?

2 Likes

My comment on https://github.com/rdswift/picard-docs/pull/86#issuecomment-788685043 might be interesting for this discussion. I think we’ll need to change this option anyway. For now try to get this explained right, but actually I’ll see to get this a bit more understandable in the UI as well.

1 Like

Just wanted to note that in order to make this more clear and fix the issues with this setting in general we have restructured the cover art options a bit. See also the screen shots at https://github.com/metabrainz/picard/pull/1757

No change in functionality, but clearer presentation of the available settings. It really was misleading that some global settings had been placed in Options > Cover > Cover Art Archive, even though they applied for all cover art sources. We’ll also update the docs to reflect this and at the same time correct the wrong description of this particular setting.

Thanks for pointing out the issue.

5 Likes

Glad to help! Honestly, I’m having difficulty to seeing the advantages to having this option at all.

I’m a bit of a datahoader and a completist, so I when I’m fixing an album, I like to get the front, back, booklet and basically all the things. To that end, where’s the advantage to naming all of the files the same way?

I propose changing the option completely to something more useful. To make file searching more effective, how about appending %albumartist% - %originalyear% - %album% to the beginning of the filetype?

So instead of a zillion Front.jpg files, you’d have something like:

The Beatles - 1966 - Revolver - Front.jpg

While we’re at it, in the interest of housecleaning, maybe an option to have all of the artwork downloaded to a subfolder titled Artwork?

I’d code this myself, but my skills lie more in system and network administration than actual coding.

Yes, the option is not really needed, as you also can solve it using a script for the cover art name like e.g.

$if($eq(%coverart_maintype%,front),cover,%coverart_maintype%)

But the option predates the possibility to do this with scripting. Also I don’t want to break users configuration here, and fix everything with scripting isn’t always a solution. If we really change this it would probably be something like having the option to either name images by type or alternatively use a custom naming string.

You can do this with something like this for the cover art name:

%albumartist% - %originalyear% - %album% - %coverart_maintype%

Also possible:

Artwork/%albumartist% - %originalyear% - %album% - %coverart_maintype%

That one can use full scripting in cover art file names is probably little known, we should improve the documentation around this.

1 Like

If the following properly covers this, I’ll create a PR to change the documentation accordingly:


In the file name mask you can use any variable or function from Picard Tags and Picard Scripting Functions. The mask should not contain a file extension; this is added automatically based on the actual image type. The default value is “cover”. If you change this to “folder”, Windows will display the image as a preview of the containing directory.

In addition to scripting variables already available for a track, you can use the following cover art specific variables:

  • coverart_maintype: The primary type (e.g.: front, medium, booklet). For front images this will always be “front”.
  • coverart_types: Full list of all types assigned to this image.
  • coverart_comment: The cover art comment.

For example, specifying a file naming mask such as:

%albumartist% - %originalyear% - %album% - %coverart_maintype%

will preface the file name with the album artist, original release year and album title.

You can also have Picard save the images to a subdirectory by including this in the file naming mask. For example:

Artwork/%albumartist% - %originalyear% - %album% - %coverart_maintype%

which will place the images in a subdirectory called “Artwork”.


4 Likes

Works great --thank you so much! This is saving me hours of manual labor.

2 Likes