what’s the process and place that I can suggest changes to the documentation?
2 Likes
Some of the booklets can be pretty important for getting correct credits. I at least try and get the couple of pages from the back that lists the engineers, etc.
Nothing worse than trying to peer at a 600pixel wide discogs booklet trying to work out someone’s name. 
As to the help pages - there could be a more distinct bit making it clear “Accuracy first, tagging second”. And a linky to the fanart.tv\albumartexchange\TheAudioDB options that the taggers are really looking for. I get bored of having arguments with people uploading pretty squares.
5 Likes
I do love a good booklet! 
and I like to be able to browse through a booklet in order. The artwork section allows them to be ordered, but when I download them they are saved as their mbid.jpg or .png. Is there a way of keeping or discerning the order?
3 Likes
Are you going to CAA to download? In that case, I can’t answer. Don’t know how their maths work. (You also don’t get to see when an image is disabled on that page)
I use Picard and it picks them up in order. So Booklet.jpg, Booklet(1).jpg, etc.
2 Likes
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”