There is some debate about Picard’s default Cover Art Provider settings and I’m unsure how to proceed.
Picard offers two distinct cover art providers based on the Cover Art Archive (CAA):
Cover Art Archive: Release: This loads cover art for exactly the loaded release. It is ideal if you want to make sure you get exactly the cover art for your physical version. By default this is set as the primary provider.
Cover Art Archive: Release Group: This loads the cover art as set for the release group. Usually this is supposed to be set to one of the release cover arts in the release group that is representative for the entire group and has the hightest quality.
The debate is about changing the defaults for new installs and use Cover Art Archive: Release Group as the primary provider, see PICARD-2125. The reasoning is that the majority of new users most likely just want a nice looking cover for their files and don’t care about the specific release. On the other hand users expecting exactly the cover for their release might be disappointed by this.
I know most here are tweaking their settings with much details anyway and probably don’t care much about new user installs. Still, I’d like to get more community feedback, as we had no clear concensus in the small core development team (@zas, @rdswift, myself and in this case @aerozol).
What do you think should be the default for a new installation of Picard?
Keep “Cover Art Archive: Release” as the default primary provider
Change the default primary provider to “Cover Art Archive: Release Group”
0voters
Note: Changing the defaults has no impact on existing installations. If you update your current settings will be kept.*
Although it is unclear what the intention was (really getting the release specific art, but the quality was bad, or generic RG art would have been preferred). Also the default settings had already been changed there, otherwise the art in question wouldn’t have been loaded (due to “raw/unedited” being excluded by default).
Since it is about changing the default, it will not impact existing installations.
I think we should have a “new user” mode for cover art: when a release needs an image for the first time display a dialog and let the user choose, point him at cover art options, etc.. Kinda tutorial mode.
Same goes for choosing a specific release.
If we have a tutorial mode with questions (“Do you prefer…”) we can solve this and please all users.
But in the meantime, I think we can change the default, so most users get a nice cover art (using rg one)
I have seen a fair share of RG cover art use a photo that is not representative of the release group as a whole, and I think cases like this would be harder for a new user to understand and troubleshoot than the cover art having 1:1 parity with the release they’ve selected in Picard.
If the automatic RG cover selection was better at preferring artwork from digital releases then I think my opinion would be towards RG being the default.
With the types of music I edit, there are sometimes multiple variations of a release within a release group—for example, a CD single with versions that have different B sides, or a special “first print” edition with a bonus—and they often have different cover art, and are marketed such that collectors will try to buy both versions. For this particular case, you really want the cover art matching a specific release. The release group cover is normally picked to be the “standard” mass market version of the release and collectors might end up having either a non-representative cover, or two releases that should have different covers sharing the same cover.
(I should note that the default filename pattern can’t really handle having two releases with the same release artist and title, so I have a custom filename pattern which adds the disambiguation comment to the directory name.)
I think @Zas is on the right track here, and ideally we’d have a setup/tutorial at first start up to set things up like that, as well as file naming, where to move tagged files to, stuff like that. that said, I know that is likely too much to add to the upcoming Picard release…
I think it makes sense to change the default here, as I feel like the average user would more likely want the best image for their releases over the specific
I’m probably not representative at all, but for how I’ve used Picard, RG probably makes more sense. When I first started out (before NGS or CAA, so this was all moot), I didn’t pay any attention to which specific release I had, and I didn’t care about cover art because none of my media players supported it. Later when the media players started to support cover art (and post-NGS), I used Picard to get cover art, but I didn’t want to spend the time to figure out which specific release I had. In that case, RG cover art would probably have made more sense. Later still, I started caring about specific releases, but by that point I noticed how many small details there were to differentiate releases. At that point, I didn’t trust MB or Picard to get the cover art for me because whoever added it might have missed a detail. So I scanned my own cover or found it online and compared the details closely. Which means Picard’s behavior didn’t matter to me at that point.
TL;DR: For me, I either didn’t care which release it was and RG would be better, or I didn’t trust MB/Picard to get it right so it didn’t matter. There’s no point where I would have preferred Picard to pick release art.
Since I monitor community-related stuff for MeB, I keep an eye on general internet MetaBrainz (including Picard) chatter. My request and vote for release-group as default reflects common issues and complaints faced by the casual user - in my opinion the vast majority of users.
Does a group of hardcore MetaBrainz users (if you are reading this poll, that’s you) think release-specific cover art is important? Yes. That includes me - but are hardcore MusicBrainz editors also going to be more comfortable and willing to dig into Picard settings? Yes.
To me it does not make sense to require more technical know-how and tinkering to simplify the output for casual users, it should be the other way round.
Since MusicBrainz Picard has no incentive to be more casual-user friendly, no sales targets, it’s not exactly wrong to keep going down the path of niche-user and developer wants. But if it’s a goal to make Picard more user friendly, then it’s time to look over the garden wall. A user poll in these forums exacerbates that problem - assuming that the Picard team sees it as a problem, which is their prerogative.
I voted for release over RG. But I’ll be honest, I don’t even trust release. I’m very picky about my cover art and will go download directly from an ideal source (I usually get mine from bugs.co.kr) to make sure mine isn’t from a service like spotify/deezer/etc where it’s been resized or re-encoded.
When I was new to everything I didn’t realize there was specific releases and just went with whatever picked by default though, and I imagine most users are like that. So I’d say whatever seems best for a casual new user, as people who are picky will change settings or grab specific cover art themselves.
I’ve been using Picard 3 betas and there are multiple cover art providers supported in the settings. Just keep the release as the first and enable the fallback to the release group. If there is release art, it is used, if not then the RG. Everybody will be satisfied.
In my opinion, if the cover art is something strange/unexpected for the user, they likely have a wrong release.
Then there is the post processing stuff that could be used to get the correct size.
But if you really want to cater to people who do not care about the correctness of the data, then you probably want to have some dialog to allow that kind of nonsense.
That’s how we have it right now. The proposal is to switch this around and use RG first.
The reason for this is that we seem to get quite some casual users being dissatisfied with the cover image results. It’s often users that don’t care much about the existing release, but they want nice cover art for the album. If they get some odd looking scan with washed out colors they blame the software and database, even if this is exactly how this specific release looks like.
If users are unhappy with the artwork, they’ll look for a different release. In most cases, they won’t upload new images.
Unless I’m aiming for a specific release, I would change to a release with the same tracklist that has a more pleasant cover. In fact, I used to do that before I started editing MB.
But I’m also okay with RG image as default. I just think it’s difficult for beginners, regardless of the default values.
This wouldn’t directly fix anything, unless we start to set the RG cover art to some digital release (that those people expect to get). This would of course require someone to add a digital release before having the RG image set to that. These cover images may have different versions as well, so the “most popular” version would always likely be the common streaming sites’ one, as they always force crop to square. Then again, there are possibly no versions of releases released with a square cover art at all (digipak, cassette, etc), and the streaming sites force crop the original.
I would rather set an option/feature in the config to prefer a digital release for a cover art if RG has one.
I guess a plugin that would fetch the image straight from any of the forced square art streaming sites would be the correct way to please that crowd.
Nobody is claiming that the data will always be perfect, but on more popular releases the RG cover is usually as expected (the ‘cleanest’ canonical cover).
Which of these should be the release group cover? Each edition and format has different front
This will also not work well with singles where almost each one has a different cover
I think one of the consequences of such a decision could be that those very same users start creating new release groups for the sake of “specific” cover art or changing the release group cover back and forth instead of adjusting their settings.
We have seen such behavior often enough for other aspects such as feat. artists in titles.
People need to learn to RTFM.
I think making the release group image the default would be a good change. Leaving it as the release art as it is right now either leads to people switching out the specific release they are tagging their files with to get different art (which may or may not be a problem for them, but it’s certainly not following the spirit of the metadata identifiers), or they conclude that MB has bad covers and the leave dissatisfied.
Making the release group cover more visible may also have the neat side benefit of making people more interested in actually setting a good release group cover.
Changing the cover art provider to the exact release one is easy enough for the knowledgeable power users who are familiar with Musicbrainz concepts.
I’m very picky about my cover art and will go download directly from an ideal source (I usually get mine from bugs.co.kr) to make sure mine isn’t from a service like spotify/deezer/etc where it’s been resized or re-encoded.