Difference between revisions of "Cover Art Wishlist"

From MusicBrainz Wiki
(What do we want?)
(What should we do?)
Line 23: Line 23:
 
* Store lots of cover art! :P
 
* Store lots of cover art! :P
 
** Store lots of packaging scans, more like! [[User:Ianmcorvidae|Ianmcorvidae]] 20:39, 10 May 2011 (UTC)
 
** Store lots of packaging scans, more like! [[User:Ianmcorvidae|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. [[User:Reosarevok|reosarevok]]
  
 
== How should we do it? ==
 
== How should we do it? ==

Revision as of 18:25, 2 June 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)

  • 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. --70.90.189.53 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 ...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 table 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)
  • 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)
https://wiki.musicbrainz.org/index.php?title=Cover_Art_Wishlist&diff=prev&oldid=45797
wiki.musicbrainz.org
crawl=CC-MAIN-2021-17
25211
application/http; msgtype=response
sha1:CFBETYCT6EYSREJYKUELHLZOJDC7GNDM
<urn:uuid:8deaf081-4abd-470d-9ecc-6692c6eb9247>
2021-04-23T04:40:11Z
104.155.129.123
text/html
sha1:YGW4JJ2JSYJV45YG23YKCNAX3ZEZEV5X
<urn:uuid:997ba3cb-eb28-4443-9a21-0eca87b2d95b>
https://wiki.musicbrainz.org/index.php?title=Cover_Art_Wishlist&diff=prev&oldid=45797
response
<urn:uuid:598eda77-ea77-4fa7-9889-8ce3c54b73ca>
isPartOf: CC-MAIN-2021-17
publisher: Common Crawl
description: Wide crawl of the web for April 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-190.ec2.internal
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/