Cover Art Wishlist

From MusicBrainz Wiki
Revision as of 20:24, 2 June 2011 by Hawke (talk | contribs)
Jump to navigationJump to search

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:

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)
  • 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)

  • 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 Brewster

Legal questions

  1. Can we allow people to upload *any* cover art images, regardless of their source?
    1. What if someone uploads cover art from Amazon or All CD Covers?
    2. Digital downloads cannot be scanned. What do we do in this case?
    3. what if a digital download contains a PDF? Can we host that?
  2. Are there limits on what sizes we should allow? If not, what is a reasonable archive quality that we should shoot for?
  3. What if someone complains about us having their copyrighted image in the archive?
    1. Who handles this?
    2. When do we honor these requests and how do we verify their validity?
    3. In what timeframe must we honor these requests?

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?
  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?
  3. Should we store multiple sizes of images?