[quote=“rdswift, post:17, topic:260843”]
I do, but I also upload scans of the full digipak covers so it’s all there for the archive. My reason is that, unless you specify in Picard to use the original image size rather than 500 x 500 px (for example), MB / CAA / Picard will take the largest dimension of the file and resize it to the specified size, and then fill in the smaller dimension with a blank background to create a square image. I would rather have a nicely cropped square image than one with blank filler bars on the top and bottom.[/quote]
Please don’t upload images edited to personal preferences.
Maybe it would be a good idea to open a ticket that crops non square images instead of letterboxing them? It really is something that can eventually be automated rather than misrepresenting releases in the database.
I don’t understand why you’re so against people uploading cover art images that have been cropped to a square so that they are properly served to Picard for tagging. Would you mind elaborating?
Tagging music is the most common use for cover art but it is not the only use for cover art.
We want the database to be as accurate as possible and show an accurate representation of the cover and not be someone’s preference.
For example if someone wanted to write an academic paper on how cover art has changed over time we want it to be accurate for them.
Just because your music player only supports square images does not mean all software will be limited in this way.
As aerozol suggests this is a feature that could potentially be written in picard to make all images square by cropping the top and bottom or the sides. This would change how you tag you music and not change it for those who want the original dimensions.
Which is EXACTLY why I also upload scans of the full digipak covers. For some reason people seem to have missed (or ignored) that comment in my earlier post. That way the archival information is preserved AND there is a proper square cover image for the taggers.
I’m sorry, but I still don’t understand why @aerozolONLY wants the archival images uploaded and NOT the tagging images (which, as you say, is the most common use for the cover art).
My point is that arbitrarily cropping to match the smallest dimension can be just as bad as arbitrarily padding to match the largest dimension. Sometimes a proper square cover image requires a combination of cropping and padding with a specific color (or pattern) to match the original image. If someone has already gone to the trouble of doing that for tagging purposes, it would sure be nice if it was available so as to save the next person from having to recreate it.
[quote=“rdswift, post:25, topic:260843”]
I’m sorry, but I still don’t understand why @aerozol ONLY wants the archival images uploaded and NOT the tagging images (which, as you say, is the most common use for the cover art).[/quote]
Please don’t refer to this as just my opinion/problem - it’s Musicbrainz policy not to store fan art. Even if your edits make perfect sense for YOUR needs.
I use album art exchange if I need an artificial ‘clean’ image, but there’s others out there as well. Perhaps some way of integrating these into the database/tagger would be a good idea, I think it’s been mentioned in the past.
When I fetch cover art for my own personal tagging, I prefer it to have the original dimensions, not an arbitrary cropping. Your prefer something different, and that’s fine, but it’s still your preference. Uploading images edited to your personal preference to CAA also imposes your preference on others.
Cover Art Archive is first and foremost an archive, not a music tagging cover art resource. While you can (probably) never escape subjective bias (e.g., in the scanning process or white-balancing etc. pre-upload), actively adding it does seem somewhat counter-intuitive to me.
I would suggest looking into uploading originals to CAA and then uploading modified cover art images to https://fanart.tv/ (there’s a Picard plug-in for fetching from fanart.tv already, and FanArt.tv speaks MBIDs, so you’re sure the releases etc. match 1:1).
All that said, I personally don’t really care too much, as long as you also upload the original, non-squared images and make it clear (e.g., in edit notes) what’s what.
The scanning process, white balancing and other edits can be quite destructive when done wrong. The guidelines recommend scanning at 300dpi, which may cause moire patterns that don’t exist in the original image, but descreening will remove the screen pattern that is actually printed on the cover. You can’t go right here. You can only pick the lesser of two evils.
Level and white balance adjustments often cause loss of detail in the shadows and highlights. I think this should be avoided.
Colors are usually off to some degree. Getting objectively good color is achievable, but it’s a matter of budget. One would have to invest in a color managed workflow. A calibrated scanner and/or screen sure would be nice to have…
Then there is the condition of the covers. Even if they’re new they’re not necessarily pristine. Wear and tear is not supposed to be on there. Small fixes are easy to do and will make the scan look closer to what the cover was supposed to look like, but there’s always the risk of getting it wrong. Detail will often look like wear or dirt, so great care is necessary when touching up. So what would be preferred? Compromised quality by wear or compromised quality by touch ups?
I totally agree that digipack covers should not be cropped to square; they’re quite a bit wider; it would be nice if there was a standardized ratio to crop them to.
CD booklets are pretty close to square and you rarely lose much by cropping them.
Tagging music may not be the only use of cover art here, but it’s probably the most important one. If you’re not cropping out text or other important parts of the image, I’d say the benefits of cropping to square outweigh the disadvantages, but that’s just my personal opinion.
If we really want to show as much of the cover as possible, we’d have to leave the edges intact - but noone would want to use an image like that for tagging.
It would be nice if there were proper guide lines for preparing cover art to refer to.
Thank you for the guidance, and for providing a straight, clear and courteous response. In spite of what some people would have you believe, I have always understood that MB was first and foremost an archival service. Apparently my mistake was in thinking that it was also a service to provide cover art for file tagging, mainly because of using Picard and having it natively use MB as its source for cover art.
It is clear to me that I need to carefully re-think how much effort I put into scanning and uploading information to MB when I, and most others, are guaranteed no benefit from it. Even though you did say that you “personally don’t care too much”, it does disappoint me that I am discouraged from uploading information that will benefit the greatest number of people. It seems that my efforts might be better spent uploading information to fanart.tv instead.
It is “also a service to provide cover art for file tagging”. Just as MusicBrainz is also a source of information for tagging. See e.g., the discussion we had a little while ago:
But being an archive first means that priorities are slightly different from sites dedicated to music tagging cover art (such as fanart.tv).
Also, just for clarity: when you upload files to the CAA, you are not uploading anything to MusicBrainz. Any files you upload to the Cover Art Archive go directly to the Internet Archive’s servers and never touch any infrastructure managed by MetaBrainz.
I think FanArt.tv is a great project, exactly because it gives a venue for putting out polished, standardised versions of cover art. But it is not a place to put original, non-touched up scans/images. So when cover art tagging requirements change (e.g., 500×500 used to be plenty, but these days even 1000×1000 are not enough in many cases), you will either have to dig up and rescan the original release… or find a source—and archive, if you will—that has this untouched original image, that can then be polished up again for the new standards. (Also, CAA is great for hosting scans of booklets etc., which are often the best direct source of information about MusicBrainz releases.)
What I’m trying to say is that I would rather have you upload squared front cover images to CAA along with all the original scans as well, rather than you not uploading anything at all. (In fact, maybe it is time for a discussion such as the one I linked but centered around CAA?)
I don’t have much of a problem with them being uploaded either, but if they’re being upped for tagging they’re probably being set as the primary cover, which does end up misrepresenting the release in the database.[quote=“rdswift, post:10, topic:265031”]
courteous response
[/quote]
I feel like this is aimed at me - have you read my first reply? Maybe I should have elaborated more?
I think everybody here is entirely sympathetic to your needs and good intentions and I’m also VERY grateful to any time spent scanning images for the database.
But I think it’s also important to appreciate the many hours that editors have put in to make sure the database is as accurate as possible - including showing square releases as square releases and not square releases as not square.
Also it’s pretty great that people have put time into the fanart plugin, and release group cover setting and tagging (have you tried using this rd? Most release groups have a square cover release you can add and tag with) for exactly this reason, so there’s really been a lot of effort put in to facilitate your needs as well.
Anyway, hang in there, Musicbrainz is very community led, which means this won’t be the last time you get frustrated with guidelines!! I think every long time editor will agree with me there!
I think in this case though it would only be worth rage quitting if I went through and removed your edited images, which I really can’t be bothered doing, so don’t worry about it
Thanks for this. I’ve only been on MetaBrainz for about a month, and I hadn’t seen that discussion (yet).
I couldn’t agree more.
Obviously poorly worded on my part. I know that it’s all done on CAA, but the upload “interface” that I use is on MB, thus it feels like I’m uploading to MB (which is actually a tribute to how seamless the interface is – kudos to the developers). Sorry for the confusion.
Thanks. I didn’t mean for my comment to sound like a threat or an ultimatum, and in re-reading it I can see how it could be interpreted that way. For that I apologize.
Having said that, I really do mean that I need to think seriously about what I’m doing with respect to scanning and uploading (i.e.: how much, what quality, and where to place the images). I’m slowly working my way through my collection of 1,400+ CDs as I tag and organize them on my NAS, and scanning everything (and cleaning up the images) for each one is a LOT of work. The work (and time commitment) increases exponentially when stitching together scanned images is involved. I know there are people out there that do much more in this regard than I do, and I sincerely applaud their efforts. Perhaps the compromise (for me) is to simply upload the raw scanned image files in a lossless format (PNG?) and leave the cleanup and stitching for others if and when it is required. Would that meet the archival needs that is MB’s primary function? I could then spend my “clean up” efforts on producing covers for Fanart.tv if they are not already there.
I agree completely. There are a few that I follow and vote on daily, and it never ceases to impress me their commitment to the work. By following their edits, I have learned so much about improving the quality and completeness of my own edits.
Thanks for this. I hadn’t tried that yet but will. Like anything, it’s not perfect because sometimes different releases have different covers, but it’s another option.
One thing that is still an obstacle here is the fact that Picard only seems to be capable of pulling cover art from one source at a time. It’s great that you can choose which source now, but there’s no way to say “use CAA if dimensions are at least X, else check Fanart” or “replace local art if new art is bigger”, “use Amazon only if nothing else is available”, things like that. There’s not even a manual way to compare and select between local, CAA, Fanart, etc
As long as the cleanup and stitching is with the aim of staying true to the release, print errors, ‘parental advisory’ marks (this one is a common
example ‘fix’ people like to do) and annoying formats included, nobody has any problem with that at all
Please keep it up!
Just so you know, I tried the Release Group Cover thing, and it automatically takes the first image of type “front” from whichever release is specified to provide the image. In other words, the square image will never be selected unless it is the first “front” image in the list (which it won’t be). I guess that’s not a valid alternative after all.
Hmm, if I understand your process correctly that’s expected behaviour.
What I meant is that you add another release, eg the one with the cleanest square cover you can find (often a digital release these days), and set that one too the release group cover. Them you can tag using that image, across the whole release group.
I don’t know if that’s what you’re after?
I agree that would work, but only if there was another release (e.g.: digital) available that used a square front cover image. I suspect that’s not something that can be counted upon (especially for older albums), and thus likely not a reliable alternative. For the older stuff, I suppose it might work if there were a vinyl release with a square cover image.
In practice it is something that can pretty much be counted on, and manually assigning one square image every 100 or so isn’t the end of the world. It’s very unlikely that something that has a Digipak release doesn’t have some other format as well. And then there’s the FanartTV plugin as backup.
If that doesn’t quite cut it for you, suggestions (and tickets) are always welcome!
Edit: A bit disappointing to see that you have only been uploading square cropped front-only images even after this discussion…
