Picard Artwork Choices - how does it choose a cover?

MusicBrainz Picard
,
1

When I use Picard I have it set to download ALL cover art available from CAA. I like artwork with my music files.

I have noticed an issue that can occur. Sometimes Picard selects the “wrong” front image to use as the front cover.

Often there is an obvious “front” image. A square image of the front cover.

And then there is a shot of the open booklet available, that gets downloaded. This shot is often marked “front, booklet”.

This leaves Picard with a choice of “front” covers.

What algorithm will Picard use to pick a front cover when it has more than one to choose from? Does it know to prioritise the “front” image over a “front, booklet” image?

Or does it download in the order they are shown on the MB CAA page?

Or just “how it comes” order?

2

Picard is using first image with front type as front cover. CAA allows multiple types, if you have 2 images, one with front type only, and another with front + booklet, it all depends on the order: if front only image is first, it will use as cover art, if you have front+booklet image first it will use it instead. This is why one can re-order images in CAA cover art tab.
It should be noted Picard has also a way to restrict image types to consider.

3 Likes
3

Thanks for confirming the order this works. :slight_smile:

So is that “first” as in what I see when I look at the CAA art page at MB?

Weird… I wonder what happened to me the other day. Maybe it was when the CAA Hamsters were having hiccups.

A classic page where “front” gets confusing is one I have uploaded myself just a few moments ago.

Ummagumma is a double album. This is a pair of CDs in a box. So we have a box front, and two CD fronts. Which are technically also page one of the booklet.

If I understand correctly, Picard will see all those “fronts” but pick the Green one as this first “front” it gets to see?

I’ll get to confirm that shortly when use Picard to tag this disk…

4

Sure enough… as you predicted… the “cover.jpg” is the first green image from that example page. The first of the fronts.

I assume what I was seeing earlier this week was a figment of my imagination combined with lazy hamsters. There was a couple of times CAA was spluttering so hard it made Picard give up on downloading art.

5

Yes, with default options and CAA source selected.

2 Likes
6

You can actually configure what types Picard will use. Under Options > Cover Art > Cover Art Archive > Select Types you can configure which types Picard should consider (the include list).

You can also blacklist certain types completely. Artwork with a blacklisted type will never be used, even if one of its types is set to a inlcuded type.

3 Likes
7

Thanks. I have spotted that option. I tick “all” and then sort it out later…

I generally do it that way due to the slightly confused way that people will tick the art types. I’d rather get too much art and throw away the spares later. The most important bit for me is getting “cover.jpg” selected right.

8

It has done it again. It is the front.jpg that I am having troubles with.

Can I give you an example and ask why it does what it does and how I need to tweak things at my end?

The eleven images saved to the fresh folder are named:

cover.jpg - which is the first “front” image.
back.jpg - yep, the correct rear cover
medium.jpg - the CD image
front.jpg - this is “wrong” for me and has saved the “front,booklet” image in this filename.
booklet.jpg, booklet(1).jpg to booklet(6).jpg - only Seven of the Eight booklet pages saved. This is missing that “front,booklet” image from the booklet set.

When I look at that list I see cover, back and medium are exactly what I want.

But front is stealing that first booklet page. Is that intentional?

I’m ending up with a booklet made of front, booklet, booklet(1), … , booklet(6)

In my case I’d like to drop “front.jpg” here and just have “cover.jpg” for the front image. And then the booklet all be named as booklet.

Or I’d be happy to see “front.jpg” as a duplicate of something. As long as I managed to get the booklet to be saved all with the same name.

With the filenames like that it is hard to quickly rename them to put “front” back as page 1.

( Yes I am aware that the (n) numbers are OS based… )

My Settings (some are plain default due to lack of understanding)

image
image922×467 19 KB

9

This is behaving as expected, but you can tweak it to your needs.

First this is exactly how Picard will behave when you leave the file name empty: The first image with type “front” will be taken as the cover image and saved with the name “cover”. For all other images Picard will use what it considers the main type for that image. The main type is simply the first type the image has or, if the image includes the type “front” it is always “front”. That is why your image with type “front,booklet” is saved as front.

You can use scripting in the file name (see documentation). This allows you to tweak the naming. First the following script would be roughly the same as Picard’s default behavior (there is one difference, it saves every image with type “front” as “cover”):

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

Now let’s tweak it to always save the image as “booklet” if it contains the type “booklet” (ignoring the main type):

$if($inmulti(%coverart_types%,booklet),booklet,$if($eq(%coverart_maintype%,front),cover,%coverart_maintype%))

See https://picard.musicbrainz.org/docs/scripting/#coverart_naming_examples for some more examples.

2 Likes
10

Excellent… Much Thanks. I’ll have a bit of a play with that script. Slap it into compliance.

I keep slowly stepping into the scripts to take more control. Very powerful - which is also why I step into them carefully.

-=-=-

I may have spotted a different issue while messing around with images. Might as well use this thread for something positive. An actual Picard 2.1 bug report (maybe).

Using Picard 2.1 on Win10 with a 200Mbps line available. I am working on this release:

Ripped my CD and then noticed the artwork was plain wrong (four images). So I scanned in the correct artwork and uploaded it to MB (five images). Then marked the original four images to delete.

So this means we have NINE images available at this time.

(I am repeating this test four hours later… so this is not just a delay between upload and availability)

Yet I get all kinds of odd numbers from Picard. Sometimes only one image, other times four, but it doesn’t seem to follow any logic.

If I drag my already tagged files in I get only 4 images.

I hit refresh and now I am down to 1 image.

If I use Look Up in Browser to get to the entry then press the TAGGER button I get another different combination.

ARGH! - and clearly it is listening in to this thread as now I hit Refresh and I have the full set of nine images…

Weird. I’ll keep looking at this and see if I can spot a pattern. Maybe this is just the CAA Hamsters having hiccups again.

11

Nice to see my scans are useful to someone :wink:

4 Likes
12

Yay! My scanner has also been chugging away today too. I find it funny how we are putting virtual copies of our own collections onto other people’s digital shelves. Sharing is cool. :sunglasses::+1:

4 Likes
13

Following up my own report… here are some Bug Reports for Picard v2.1 (downloaded from main site) on Win7 Pro and a 200Mbps broadband line.

This morning I upgraded another PC to v2.1 Picard.

Bug Report #1: Installer issues. I thought v2 was going to auto-uninstall v1? Instead I got x64 v2.1 trying to install in the 32-bit folder again. I corrected the path mid-install… and ended up with both x32 and x64 editions still installed. So I uninstalled them both and started again. (I needed to go into Program File (x86)\Musicbrainz to manually run uninst.exe to remove the 32bit version. The uninstall entry in add\remove programs had been replaced with the x64 version)

All fine next run.

-=-=-

Bug Report #2: Something weird with the image counts.

Yesterday I tagged up an album as noted above. Delicate Sound of Thunder There are NINE images online but Picard would not get all the nine images reliably.

I picked up that same tagged folder today, dragged into Picard. It said 2 images. (?) Manually went into the folder and deleted all the JPG files in there.

Did a REFRESH on the album in picard… now it lists 0 images.

Did a Look up in Browser, and then pressed the Tagger button. Now it says 2 images. (Both the same front cover)

Tried a Refresh again - and now I am offered 9 images. So I hit SAVE quick. :wink:

Weird. Lets try another album. A Momentary Lapse of Reason I wanted to test the booklet script above. So I started by manually deleting the JPGs from the folder. Then dragged the already tagged folder into Picard. It immediately Jumped to the Right and did the Time Warp… and told me there was ONE image available.

But there are 14 images available… weird

Tries a REFRESH… still only ONE.

Tries the LOOKUP IN BROWSER \ TAGGER shuffle… still stuck at ONE.

tries another REFRESH… still ONE image.

goes into Options and unticks all sources except Cover Art Archive.

Hits REFRESH… 0 images.

Okay. What am I missing? Something not right… ARGH!! And now it jumps to the full 14 images.

I will kick this around more. Was it that I had Local Files selected? Did that cause trouble?

-=-=-

Booklet came out named in a sensible way this time. Thanks for the script. Even better it allows me to see how to tweak it further for my needs.

-=-=-

Edit: And yes, do note that both of the example albums here have multiple fronts, backs, mediums as they are both in the middle of edits to replace incorrect images with more correct ones… but I don’t think that is relevant to the issue. Just mentioning it in case someone tries to “tidy up” :wink:

14

Providing debug log would help to know what is going on :wink:

1 Like
15

How do I enable that? It seems fairly repeatable at the moment. Just dragged the two albums back in… again only 2 images each.

16

There are two ways: one is to start Picard from command line using -d option, the other is to enable the debug log from the interface in Help > View error/debug logs > Verbosity, set it to debug.

2 Likes
17

I went with the - d option.

Drag and dropped in the two previously tagged albums.

2 images available.

Refresh - still only two.

Lookup in browser and then tagger button on AMLOR - still 2

Goes back to turn off local art and CAA Release Group - now I have the 9 images.

What is “Local Art” - am I just confusing things? This is PEBCAK isn’t it?

-=-=-

Here is a log… following the above patterns of testing.

https://pastebin.com/VEF767ed

While you read this I’ll go read the manual on Local Files… Well… that was one of those quick reads. I think the section on “Local Files” in the artwork is lost in one of those hidden appendixes…

What is noticable is that when I have it ticked, I don’t get the full choice of artwork.

Now I have unticked it, Picard is back to giving me 14 and 9 images each time again.

ARGH - my fault for randomly ticking features that sound good. Clear PEBCAK issue. False alarm.

I think my mistake was assuming that the list of choices was a “trickle down” type thing. Getting art from each location in turn.

I guess Local Files is doing something to block this hunt for alternates.

1 Like
18

Local cover art are files locally stored with your files. According to your config you have all cover art providers in the order Local Files, Cover Art Archive, CAA Release Group, Amazon, Whitelist.

The way this currently works is that Picard will use the providers in the order listed. The first one returning any cover art will be used, the rest does not get called. In your case you have Local Files as a first provider (which often makes sense). This means as soon as Picard finds local cover art with your files those will be used and CAA will not even get queried. If you always want to have the latest CAA files move the “Cover Art Archive” to the top or disable the Local Files provider.

Also Local Files does not find all files since it only consider files matching the pattern configured in Options > Cover Art > Local Files.

4 Likes
19

Thank you for explaining that. I now can understand how that interacts with that Local Art regex - that previously had me confused as to where it was used.

I do feel a little stupid on this one as I only fiddled with the order a little earlier when trying to trace another puzzle I had…

20

Little bit of a followup…

I have been freshly ripping and tagging a few albums. I went back to that task again today. That same Picard 2.1 which I had forgotten about “Local Files” still being selected first.

Are you aware that Picard also sees files downloaded but not saved as “local”?

Example:

When I started my re-rip\retag of this release today the artwork was a mess at MB and in the wrong order in the database. The “front” wasn’t tagged as “front”, instead it was “other”. There was no “front” type. And the CDs were not correctly listed as “medium”.

I spotted this mess when Picard offered me the wrong images in the wrong order and a number of “other” files.

So, with Picard left open, I went online to correct the order in MB. These changes were taken in immediately, along with a few more corrections to “booklet” type etc.

Now I had not hit SAVE in Picard at this stage. I just had done the initial step of getting the release ready on the right hand side. No other files sitting in the folder with my re-ripped files.

BUT because “local files” was still set first, Picard now refused to refresh and re-download the MB Release Artwork. Even though there were no “Local Files” Picard now refused to let go of that badly ordered set of images it had cached away somewhere.

Then i remembered I was an idiot, went to options an unticked Local Files, and now the refresh worked.

So the question - why is “Local Files” treating the cached downloaded images as files to preserve?