What do you do? Do you manually change all affected files? I noticed a pull request or two to address this issue, but as far as I understand it, there’s no way to actually manually change the album art Picard appends/embeds, is that correct? For me, dragging and dropping only adds two images to the album, and the corrected one I put in doesn’t actually get used in any meaningful way, just dumped into the folder after the fact.
Actually the IMHO best way to solve is to upload the correct album cover art to MusicBrainz / Cover Art Archive, especially if the one already provided via MB is wrong or is just sourced from Amazon.
This sounds like a bug, but I currently don’t know whether it is known and /or worked on by somebody. But manual cover art in Picard sadly was never very well supported.
1 Like
Of course, that is a perfectly good idea and I’ll do it immediately. That said, there may be people who prefer some covers to others, and while those covers may not be strictly “correct”, they may be accurate enough that they could be considered, so, etc., which would not be addressed by this method. It may also be outside of the scope of the program, so…
2 Likes
What do you mean by incorrect album cover art ? Do you have any specific examples ?
If cover art is incorrect on MB, it has to be fixed on MB.
If cover art comes from Amazon, ASIN may be incorrect on MB side or just amazon has an incorrect cover art, third party cover art providers aren’t very reliable, this is why we prefer MB/CAA.
If it needs to be fixed, fix it on MB.
FYI, latest development version (upcoming 1.4) of Picard improves things a bit, allowing to use local files as cover art source.
1 Like
That’s absolutely true. I personally have seen cases were I would have preferred a different cover art from the version I actually had, e.g. without some overly huge ugly stickers. I noticed that when using cover art from e.g. fanart.tv it is often not quite “correct” but way more beautiful 
1 Like
Do we have support for using Release Group art yet?
I’m a huge proponent of only uploading the ‘correct’ cover art for a specific release (annoying stuff like digipak format shouldn’t be square etc!) but always with the expectation that the ‘cleanest’ cover art would be set as the art for the group, and that eventually Picard could tag with that if wanted
During my inexperienced time many of my voted down edits stem from adding the best looking cover art (I could find) with which some editors wouldn’t agree because it didn’t have a sticker or whatever. I also wasn’t aware of personal statistics 
I’m more inclined towards quality…
Annoying, true. In Windows the folders showing cover art aren’t all consistent image-wise in width and height.
Although many digipak covers are somewhat different than a jewel-CD cover, the former being somewhat skewed at times and present different lettering, etc. At AAX we have normally 2 ratios for wide-format or digipaks: 600528 or 600540.
fanart.tv is a AAX wannabe
But fanart.t.v has an API using MusicBrainz identifiers which allows us to have a nice Picard plugin
Also on AAC the about page shows PHP errors and the blog redirects to some parked domain with ads. Not very promising…
I get plenty of album art from AAX don’t worry, love that resource!!
But if the art is wrong for a release, then quality doesn’t really come into it unfortunately! But that’s a limit of the tagger, which should let people use the release group art, which ideally would be the most ‘quality’ picture overall.
1 Like
The current development version of Picard provides a “Cover Art Archive Release Group” provider to load cover art. And since one can finally select which source to prefer the user can decide whether to use the release group cover art as a fallback or as the preferred source. Thanks goes to @zas for most of this work
1 Like
Woo, awesome!
In that case there is NO reason to have the wrong art on a release, as you can use the nicest best quality AAX cover for the release group 
Thanks @zas, now I can remove or replace incorrect cover art with a guilt-free conscience!
1 Like
Code aside, what matters is the chewy-guey inside 
@aerozol I hope my last post didn’t come forward as I being an editor that uploads quality images but incorrect ones…
or none at all
2 Likes
Sometimes I think having more options helps end users but at times hinder Musicbrainz.
If the release has art for any other source other than CAA for the release the user is discouraged from contributing.
It all depends on the goals of Picard and its overall relationship with MB.
Likely ease of tagging outweighs encouraging Musicbrainz data additions but with the new releases being added to Musicbrainz outpacing the cover art added to any release, I do worry about the long term future of CAA at times.
3 Likes