Difference between revisions of "Cover Art Wishlist"

From MusicBrainz Wiki
(How should we do it?)
(What do we want?: release-group need)
Line 9: Line 9:
  
 
* 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. --[[User:Nikki|Nikki]] 04:12, 11 May 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. --[[User:Nikki|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 [http://codereview.musicbrainz.org/r/286/#review538 related discussion],  [[User:Murdos|Murdos]] 09:30, 11 May 2011 (UTC)
  
 
== What should we do? ==
 
== What should we do? ==

Revision as of 09:30, 11 May 2011

Background information: http://chatlogs.musicbrainz.org/musicbrainz-devel/2011/2011-05/2011-05-10.html#T19-08-22-201182

What do we want?

  • Rob wants something easy to fetch, like coverart.archive.org/<mb release id>.jpg, coverart.archive.org/<mb release id>-1.jpg, coverart.archive.org/<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 coverart.archive.org/<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)
  • 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)

What should we do?

  • Store lots of cover art! :P
    • Store lots of packaging scans, more like! Ianmcorvidae 20:39, 10 May 2011 (UTC)

How should we do it?

  • With relationships? "has {type} cover art at ...archive.org..." where {type} can be front, back, tray, obi, booklet, ..., other, then upload the image to archive.org 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 coverart.archive.org. Murdos 09:23, 11 May 2011 (UTC)
  • Secondly, I think coverart.archive.org should be initialized with all cover arts we already have (in release_coverart). Murdos 09:23, 11 May 2011 (UTC)

How do we deal with copyright violation notices?

  • Send them to the archive.org 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 archive.org-guy 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)