Cover Art Wishlist

This page has not been reviewed by our documentation team (more info).

Background information:

What do we want?

The cover art S3 bucket keys should be broken down by MBID for the release that the cover art is attached to. Given MBID 8f468f36-8c7e-4fc1-9166-50664d267127, you should find derive keys for cover art by constructing well known URLs:

Will fetch the original size front cover art for this release. Other keys that will be available:

/<mbid>.json -- JSON data for other keys that are available for this MBID. 

The supported types would be: front, back, inner, booklet, sleeve, medium, obi, spine, box, other. All the original cover art images would have no size code extension, but the following sizes would be available: 150, 300, 500. For example, to get the 300 pixel size front cover image you would fetch:
What about left-spine (or main-spine) and right-spine (secondary-spine) ? They often differ (in japanese market). Jesus2099 12:41, 17 October 2011 (UTC)
I think we would allow the users to upload more than one "spine"-typed image. At the moment I doubt we would allow to explicitly say whether this is the left or right spine though... is that really necessary for people editing Japanese? --Reosarevok 08:15, 18 October 2011 (UTC)

Note: The exact available sizes are still to be decided. Suggested size categories to look at are thumbnails, images embedded in web pages, and images embedded in music file tags.

To fetch the 150 pixels sized image of page 2 of the booklet:

Note: Use HTTP HEAD to get sizes of images.

Older discussion

  • Rob wants something easy to fetch, like<mb release id>.jpg,<mb release id>-1.jpg,<mb release id>-2.jpg so you can go through the pages of cover art.
  • Other people might want something where they can specify which cover they want, like<mb release id>/front.jpg
    • I'm not set on the scheme, but I want something that an idiot can fetch its so simple. The service should either say: 404 or give you an image. Nothing else. --RobertKaye 20:03, 10 May 2011 (UTC)
    • We also need to worry about multiple formats -- not everything is jpgs! I for one probably won't put up anything but .png, given a choice! How about Rob's initial suggestion for the actual image URLS (c.a.o/<mbid>.<ext>, c.a.o/<mbid>-1.<ext>, etc.) with redirects from: c.a.o/<mbid> -> c.a.o/<mbid>.<ext>, c.a.o/<mbid>/1 -> c.a.o/<mbid>-1.<ext> and c.a.o/<mbid>/<type> -> c.a.o/<mbid>-<relevant number>.<ext>? This means things can be looked up sequentially, without knowing extensions beforehand (Rob's needs), or by type ("Other people"s desire). Ianmcorvidae 20:38, 10 May 2011 (UTC)
    • What is the preferred image quality DPI mostly, but also final width/height. What about records? Their covers could get quite huge if scanned at say 300dpi (3600×3600 as compared to about 1500×1500 for a CD cover) —Hawke 18:29, 2 June 2011 (UTC)
    • What if any standard for reviewing/considering for replacement a given scan? Keep all scans we have or throw away the worst ones? How do we decide what’s best/good enough? —Hawke 18:30, 2 June 2011 (UTC)
  • We would need some sort of "thumbnail" version that we can use on our release pages, we don't want to be including 2000x2000 images. --Nikki 04:12, 11 May 2011 (UTC)
    • There should be two sizes of "thumbnails" a big one for one of few thumbnails per page (release or release group view) and a tiny one which will fit on a single line for release or release-group listings. --Pabouk 10:06, 17 October 2011 (UTC)
      • If I'm not mistaken, the Archive doesn't want thumbnails, just original and 500x500, which means we would have to do the resizing ourselves.--Reosarevok 08:11, 18 October 2011 (UTC)
  • We would also need release-group support ("thumbnail" version and plain version) that we can use on our release-group pages.

Maybe this can be done on the MB server side by selecting one of the release cover art (see related discussion), Murdos 09:30, 11 May 2011 (UTC)

how about a mosaic of all the different release covers? --~ 猫猫~~何? 14:02, 15 October 2011 (UTC)
  • Integrate this with collections and I would be quite happy. Imagine getting notified when somebody uploads a better version of cover art for an album you already have. -- 21:44, 11 May 2011 (UTC)
  • We would need to have a method of updating the stored image(s) when a higher quality scan comes along. When we update, what do we do with the old image(s)? Do we delete then or archive them?
  • Since each release is a unique commercial release, is there a need to store multiple versions of images? e.g. Discogs often has multiple sets of (slightly different) liners listed under one release.

What should we do?

  • Store lots of cover art! :P
    • Store lots of packaging scans, more like! Ianmcorvidae 20:39, 10 May 2011 (UTC)
      • "Scans" is not the ideal word, given that you can't scan a digital release which probably includes covers anyway. reosarevok

How should we do it?

  • With relationships? "has {type} cover art at" where {type} can be front, back, tray, obi, booklet, ..., other, then upload the image to with the right URL?
    • This is too heavy in my opinion. I'd rather have a deeper integration in MB, something like what Discogs is doing: you manage all images from MB, but you're in fact doing AJAX requests to Murdos 09:23, 11 May 2011 (UTC)
  • Secondly, I think should be initialized with all cover arts we already have (in table release_coverart). Murdos 09:23, 11 May 2011 (UTC)

How do we deal with copyright violation notices?

  • Send them to the guy?
    • No, we must manage all aspects of this archive. We will likely need to send complaints to copyright@mb and have more people on that email alias. --RobertKaye 20:02, 10 May 2011 (UTC)
      • Then what do we do if someone complains? Do we take it down (leads to a pretty worthless database), try to negotiate rights (hairy legal bullshit), say "deal with it" (invites lawsuits), what? Rob's paraphrase of seemed to say "deal with it," but if we're managing all aspects of this what do we want? Ianmcorvidae 20:43, 10 May 2011 (UTC)
  • Wouldn't answer to copyright violation notices always be the same? "Fair use"? Because we could potentially get copyright violation notices for 99% of hosted cover art... Murdos 09:33, 11 May 2011 (UTC)
  • These are all valid questions for which I will need to work out the answers with Brewster. For now, lets collect questions and soon I'll sit down with him to hammer all these out. --RobertKaye 19:34, 11 May 2011 (UTC)

Questions to ask of

Legal questions

  1. Can we allow people to upload *any* cover art images, regardless of their source? Yes
    1. What if someone uploads cover art from Amazon or All CD Covers? We dont care, since they do not own the copyrights.
    2. Digital downloads cannot be scanned. What do we do in this case? Upload them!
    3. what if a digital download contains a PDF? Can we host that? Yes
  2. Are there limits on what sizes we should allow? If not, what is a reasonable archive quality that we should shoot for? TBD. Archive says: Bring it on!
  3. What if someone complains about us having their copyrighted image in the archive?
    1. Who handles this? The archive does with their normal take down process.

Technical Resource Questions

  1. Can we create and have someone from MB maintain it?
    1. If so, this should be hosted by the archive -- is this possible? We should attempt to avoid it, but it is possible.
  2. We would like to make it possible that knowing a release MB id, we can easily construct URLs to fetch coverart. Do you see a problem with this? No. We should use the same or a similar method to:
  3. Should we store multiple sizes of images? Yes!
  4. How do we store things in your S3 archive?
    1. like this: