Maybe it would be nice that it also use the image comments too.
When I upload booklet images, I usually set the comments to page x and y of z.
Booklet (1) page x and y of z.jpg
2 Likes
I keep meaning to look at better naming. For example - skip Booklet.jpg and go start at Booklet(1).jpg first when there are multiple pages so it alpha sorts in the directory better.
Like you I also name the pages in comments, but I also add other description on other images so it would be hard to set a fixed rule.
Bonus - that would make “other” make more sense.
It would make something like this automatic! https://musicbrainz.org/release/e2d8bb4d-2fad-4350-ac75-708f1495d6ae/cover-art (warning - don’t click on that… 344 images for one boxset!)
1 Like
I download them straight from the MB web site…not Picard. Need to start on that I guess.
It would be nice.
1 Like
Picard can be a big time saver. It will name everything using the first “type” it sees. Just select it to download all artwork in the Options.
If you don’t want it tagging, you can cheat. Paste the URL of the relevant release in the top right corner. You now have the album art downloading. Just drag in a random “sacrificial FLAC”. Some old junk file you just keep renaming. Then Picard will drop the art into that folder to put with your files.
Even easier, just untick the options to tag\rename the music files…
Picard is now an Art Download Tool.
1 Like
Yes, very powerful.
An observation is that Picard seems to be adding a lot of things to the experience of using MusicBrainz, that perhaps MusicBrainz should be providing…
Or look at it another way round. Picard is mining this music database and pulling out all kinds of clever combinations.
The database is the knowledge store. There is no reason it should be offering downloads of the artwork when the applications do a better job.
Don’t clutter the database interface with “art download options” when the apps can always do a better job. 
1 Like
perhaps, but Musicbrainz stores the order of tracks a release and Picard does not have to discern them. If we’re going to serious about artwork or at least booklets, then MusicBrainz should at least store the order of the pages in a booklet and the data model for images should support a few more things than it currently does. It’s very good, but there’s some room for improvement IMHO.
That’s good, but I wish that MB would store the order of the images in the booklet using a tag in the file or in the name.
1 Like
4 Likes
If MusicBrainz wants to become a resource for cover art it will need to add a new front image type specific for images edited to look good for display on screen in higher resolutions. Currently the Front image type is intended to exactly match the cover for the specific release as an archive representation of what the cover for that release looks like with warts and all.
That’s not compatible with people uploading images edited for looking good on screen when displayed in a media player program.
A way around that would be to have a new front image type that is intended for images edited to look good on screen. Call the new type “Front Beautified” or “Front Display Edited” or whatever. But make it a separate front image category than the current front image that is intended to always exactly match the specific release no matter how low in image quality that image is.
With the current guidelines I can spend hours scanning and editing a front cover image to make it look good on screen at higher resolutions. Only to have someone come along later and delete that image and replace it with an image they found on Discogs in a low resolution but arguably a more pure image of the original cover. And the possibility of that happening to a front cover image I spent hours scanning and editing causes me to question whether I should take that time to edit images to post here.
If this idea for MusicBrainz being a source for cover art it will need two separate categories for front covers.
One front image type for covers as true as possible to the original with warts and blemishes and all.
A second front image type for covers edited to look good on screen at higher resolutions.
The MB ‘release group cover’ should be set to the highest-res clean cover (usually the cover from a digital release). People can change their tagging settings to prefer the release group cover over the release cover, which should give good results for most release groups.
I know that’s not exactly what you want (e.g. a place to store cleaned up physical scans). Personally, I wouldn’t bet on MB ever becoming a home for user-edited images.
Currently the best home for those edits are https://fanart.tv/ (careful, they don’t allow editing out text etc either), and albumartexchange, imo. You can also link fanart.tv entities/covers to musicbrainz release groups, and set your cover art preferences to take those first, as another option.
6 Likes
How are these different from fixing normal scans of artwork?
I think this refers to the difference between something like fixing a scratch on a scan vs. cropping the scan to a square (so that it fits better in a digital library grid view) or applying filters that remove the halftone pattern (so you get more even colors, with the goal of looking better on a digital screen).
2 Likes
I agree that this is needed. Until it is added, you could use ‘other’ as a type and comment “display optimised”
As it currently stands, no, you cannot add customized images.
1 Like
Is this because they are considered to not be representative / accurate of the original? If so, doesn’t it depend on how much things like colour correction has been done?
I was trying to be careful using the word ‘customized images’. Because making it look more like the in-hand copy is of course fine. Cleaning up scanning colour errors, straightening, removing a bit of dust (if you have to).
Edits to make it look ‘better’ than the actual in-hand release looks, no place for them at all in MB currently.
We could add more flags and stuff to show an ‘edited’ status, but I assume (?) the idea would be to move these to the front of the image order so they are automatically pulled as the cover, which I don’t think many MB editors will agree to. I think that’s the part that’s less likely to go through.
tbh this discussion usually confuses me because most of these edits, that I see, are duplicating the digital cover to all releases in the group. Editors doing this have never explained to me what they’re trying to achieve - it seems they could tweak some Picard settings instead 
4 Likes
Thats the big discrepancy between “MB editors” and “MB users”, IMHO.
“MB editors” achieve to get the most accurate cover for a specific release, even if it is a crinkled outwashed one.
“MB users” are looking for the “best” or “biggest” or “highest quality” cover, even if it is square or customized.
2 Likes
I am often in that camp! If there’s a weird ‘true’ cover I wont necessarily use it for my files.
But then I use the ‘release group’ cover, which imo is a much better solution than changing rules to duplicate the digital image everywhere, which is what it usually boils down to. There’s a few niche cases where that’s not a solution (e.g. no good cover version exists in the group), but I can’t even remember the last time I saw that.
P.S. I’ve always thought that putting ‘release group cover’ first in the default order, in Picard, would help (ticket here)