If that file is sent to different printers then the outcomes could be different - they might be using different machines, different inks, different thicknesses of ink, different halftone screens and have different reactions between their inks and paper.
If we are trying to capture releases that are different because of differences in their CA then using that “pre-print original cover file”, (or for pre-digital that “original copy ready artwork”) is working against that.
Two avenues for error are added.
If differences between the digital file and the physical CA of 2 releases are missed then we catalogue only 1 release.
An editor finds a difference between the digital file that has been incorrectly used for a release and some physical CA in hand and creates another release. We get a duplicate release.
U2Joshua - “are you seeing that I’m in violation of this somewhere?”
The iTunes CA is not the art (CA) of the physical “The Best of 1980 - 1990” as far as I can tell. From what you say the outside border colours are significantly different. This makes the CA significantly different.
If MB was just a tagging database then there would be little problem with good looking but different CA being used.
But MB has raised the bar way up to “encyclopedia of recorded music”. And wants CA data made from the specific release in ways that attempt to capture as much info about that physical CA as practicable…
(General Observation: The word “representative” does not do the job needed around CA. Reductio ad absurdum: Dancer does a performance that is representative of that U2 cover art - is video of that dance what an encyclopedia of recorded music needs? )
… and if two different scanners scan the exact same thing, the outcomes could be different as well. Sometimes quite different. Or if you take two different digital photos of the same thing, even with the same camera and lens, under different lighting conditions. (And even more so if two different cameras). All of these are real-world unavoidable issues of a crowd-sourced cover art archive.
I suspect most printing differences from the same print-ready file will be smaller. I think anyone wanting to add the print-ready art from the publisher should of course compare it to the actual release (or a scan of it) to make sure nothing terrible happened (oops, mounted the magenta plate very misaligned, but they wanted cheap…).
Also: most people contributing to CAA, I’m pretty sure, do not have a fully color-calibrated setup. So most stuff uploaded to CAA is from an uncalibrated scanner, adjusted to look sort-of-like the original when viewed on some random uncalibrated monitor, no doubt with the original illuminated by something far short of a CIE standard illuminant.
I don’t think any ordinary editor has a scanner good enough to capture differences from using different printing machines, inks and thickness of ink, etc. So using scanned covers wouldn’t identify releases from different printing facilities anyway (unless of course someone gets a professional calibrated scanner with reference palettes and uploads to CAA). This is why we have “manufactured in {area}”, “manufactured by {label}” and “printed in {area}” relationships to help us separate releases made by different manufacturers/printers. Perhaps we can create a “printed by {label}” in the future if this information is readily available.
As to the two avenues for error, I think editors should be more careful and always document why a certain release is created in the annotation or disambiguation, whichever is more suitable. I will never recommend to anyone who tries to identify a release or differences between multiple releases only by relying on the CA uploaded. Always rely on relationships and check the edit history to see whether that relationship is from a reliable source.
ooh, as @rdswift knows, I have strong opinions on this (missing your excellent full packaging scans by the way…)
Firstly, welcome @U2joshua!! I can’t express how much I appreciate the time it takes to scan and upload images, and how important it is to musicbrainz
Anyway… in a tagging sense using a nice high res digital cover is indeed the way to go. If we could only store one release/cover per album I would absolutely say to go for it.
However, we have support for multiple releases, and a useful ‘set cover art for release group’. It’s a piece of cake to add the digital release as well, that has the artwork you want, if you feel very strongly about that aspect. Frankly, apart from ‘can’t be bothered’, I can think of no excuse not to do so.
I’m not sure if Picard has an option to tag with the release group cover yet (?) but imo it’s a step backwards to put the ‘best’ (according to the editor) art onto all the releases before that happens… why even have covers for individual releases in that case.
The itunes cover is based on a scan of a physical cover art. Like the MB image, it has visible print moiré (although not as bad as the MB image).
They may have used a better scanner to get the background color to look so even. Some higher priced models have a wide light source that makes up for the unevenness of the scanned object (like kinks and paper texture) by lighting it from both sides of the sensor.
You can simulate the process by making an additional scan with the cover turned around 180°, so the light comes from the other side. Line the scans up in photoshop (it has a feature to do this automatically) and set the top layer’s opacity to 50% to make the kinks disappear.
Different scanner technologies “see” highly reflective surfaces very differently, yes. And calibrating can make a big difference, but I don’t think that’s the main issue. Scan software settings may change the look significantly by automatically adjusting to the image. They tend to be very inaccurate by default and are a lot better with auto adjustments turned off.
Joshua do you see the iTunes hi-res artwork as being a fairly accurate rendering of the physical CA?
Like ZincRider I think the iTunes is based on the physical. But I suspect that the outer border colour has been lightened deliberately and significantly.
One such place could be the release group, and sometimes it is. But since release group images are currently restricted to choosing one of the covers from one of the releases in that group there might be no CA really being a clean version of that cover.
As you said yourself fanart.tv has this different focus of providing visually appealing versions of releases. I think this is a very good distribution of responsibilities: MusicBrainz and the CAA provide as an archive of actual data the cover art is it is for a certain release, with all its ugliness that might have happened. Other service such as fanart.tv can provide beautiful artwork. You can still choose which approach you prefer for tagging your own collection.
I have the physical release and I scanned my cover. I find it to be darker than iTunes, but lighter than the pre-existing scan. It turned out pretty darned close to what I see of the physical release, so you can pair it against the iTunes one and see the differences.
Which is exactly why I have Picard configured to use cover images from fanart.tv if they are available, and why I submit missing cover art there rather than to the CAA. I also still submit scans to CAA to support my edits. That way, I’m supporting the primary purposes of each.
Not necessarily. Gold is rather reflective and may look very different when scanned with different technologies.
As neither image is color managed, discussing color differences is probably pointless…
gives something that looks quite a bit like a washed-out version of the iTunes image here. So it’d seem iTunes has a much better scan, but they processed it for a different display gamma than your monitor is using (I’m not sure—do Macs still use a different gamma than Windows by default?) If that’s what it is, then that’s just a symptom of a lack of a color-managed workflow.
Their specifications for album cover art are: JPEG image, 1000 x 1000 pixels, file size < 1 MB. They are also very particular about the quality of the artwork accepted, rejecting images with moire or compression artifacts and much more.
And I was thinking the ~1500px we wind up with was getting a little small…
(I have no idea what people’s obsession with square images is. Many of the originals are not square. Hardly any displays are square. And yet no doubt next time I go through all the art I’ve uploaded to CAA, I’ll find some replaced with square crops…)
![[Untitled]](https://community.metabrainz.org/uploads/default/original/2X/9/971ff84cde82574e662788c852439c26db045327.jpg)
