Talk:Cover Art Sites

From MusicBrainz Wiki
Revision as of 15:54, 19 August 2009 by LiDEL (talk | contribs) (added proposal)

CoverArtSites > Discussion

CoverArt Sites Discussion


Just some thoughts from IRC... Catgroove, Freso, warp, and I discussed ASINs which don't have coverart, and whether they ought to be added. Though most supported the practice, catgroove did raise a valid point which bears mentioning. The current use of the ASIN AR is overloaded. It's essentially a "can be purchased for mail order at" AR combined with a "has coverart at" AR, while also being a useful unique identifier that other sites using MusicBrainz data can use to match their data with MusicBrainz data. However, now that Amazon also does 3rd party sales, they increasingly have ASINs which don't pull up art, as the art is user-submitted, not Amazon-created. In these cases, we could link the ASIN for all the other benefits, but then either we then add a coverart AR to get the art from a different source, or we have an ugly empty box show up in the coverart area. Catgroove raised the point that we may be implying a MusicBrainz endorsement of the 3rd party Amazon seller by linking to the Amazon listing for this sort of ASIN, and thus, might be responsible if the purchaser linked from MusicBrainz to the 3rd party via Amazon is unhappy with his/her purchase. --BrianFreud [5/20/2007]

  • hey brian, you may want to add a link to the point in the chatlog when we started talking it, so people can read for themselves :) DeleteWhenCooked -- mo 23:23, 20 May 2007 (UTC) I would, but just like the "DateTime" string in wiki, I have no idea how to pull off the fancy-IRC-linkage-thingers :P DeleteWhenCooked --BrianFreud

Subpages permissions

Regarding Ruoak's comment above, as I quoted, perhaps we ought to have a subpage for Artist/Label permissions and links? Stumbled onto Sub Pop's blanket permission page, in their FAQ. Could be a useful to list all the permissions together "Can I use images/sound clips/whatever from the Sub-Pop site?" "You are hereby granted official Sub-Pop permission to use unaltered Sub-Pop owned material from the Sub Pop web emporium." --BrianFreud

The Use Of's 'wayback' machine for coverarts

  • Personally I think this is pretty underhand and not very professional of us to do. If we can't get proper permission we use wayback and wait for the image owners to issue a C&D? So basically we are saying the only reason we don't steal images from the point of origin is because they could replace them with a 'Stop Stealing Images' jpg, or something less pleasant (and frankly, we would deserve it). Where's the morals, and indeed respect for other discography sites? --Gecks
    • I cannot agree more :/ - what good can we expect from links like: [[Image:m16507uneac.jpg]] or ? This IMHO is just plain bad (eg: using archive as to bypass the need for an authorization) and only calling for trouble... Please consider rethinking this. Please DeleteWhenCooked if you think I'm overstating the importance of this. -- dmppanda 12:21, 22 May 2007 (UTC)
      • Gecks and dmppanda, please note, by linking to art at, we are *not* linking to the art at the site - so in the two above examples, we are not "stealing" art from allmusic or discogs. The file that is loading is stored on an server, and we have permission from to use their art. retroactively respects the robots.txt file, as can be seen in their FAQ. Were a site to feel we were misappropriating their art, that site would need to issue a C&D, nor would they need to replace the art (indeed, since we are loading the art from's archived copy of the art, the site changing the art on that site's server would have no effect.) The site would simply need to adjust their robots.txt configuration, and the very next time attempted to scan that site, every single cover from that site we link to in the archives would immediately become a bad link. Additionally, I am not a lawyer, but ruoak says the MusicBrainz lawyers have given us a clean bill of health on this. Indeed, from my (limited) understanding, 17 U.S.C. §107 (US law) seems to be a pretty strong legal protecton. For an even better idea of this, however, take a look at discussion of the Google case decided on 5/16/07, where this protection was clarified. -- -- BrianSchweitzer 02:32, 23 May 2007 (UTC) DeleteWhenCooked
        • I don't think the lack of a robots.txt should imply permission to be archived by Plus we are 'stealing' - the ownership of copyright of a photo or scan of a record sleeve lies with the person doing the photograph/scanning (though of course he/she is possibly in breach of copyright from the original image creator). Just because we aren't using their bandwidth, doesn't mean we aren't taking someones images for our own gain against their wishes. Lets not forget that that most of the sites that seems to be coming up in these discussions are also community built (digital nirvana, discogs, etc). It's biting the hand that feeds and totally wrong. No different to creating a script to convert, say, a discogs page to a new MBz release, and run it on an snapshot (which would be dead easy). --Gecks
          • Well, in the case of Digital Nirvana, the site no longer exists. It changed control and became Live Nirvana. All the covers there, however, were contributed, to make it a repository. The users gave them expecting they would be used elsewhere, hence why Live Nirvana stopped watermarking, even though Digital Nirvana previously had done so. (Digital Nirvana only had watermarked because people *were* stealing bandwidth by linking directly to the pictured on the DN server. As for the lack of a robots.txt, it's a indutsry standard - not just, but google and the others obey it as well, depending on your selected settings. The lack of a robots.txt actually does, by my understanding of current US law, imply permission to archive a site. -- BrianSchweitzer 13:16, 23 May 2007 (UTC)
            •*/ - "We're sorry, access to has been blocked by the site owner via robots.txt." - So I guess that, by your understanding of current US law, implies that livenirvana (and now consequently, digitalnirvana) have express wishes for their site NOT to be archived? Regardless of this I still think that there's no good reason to circumvent asking the webmasters permission. If we were that confident that they had no problems with us using to show their images, where's the harm in asking? --Gecks
              • Because no matter where we are sourcing the files from, the copyright remains with the original copyright owner - not any one site. The site can choose to block our using their images, but they have no ability to grant permission for us to use any image - their own use of the image is also infringing on the same copyright, if indeed any infringement is occurring. As mentioned, Digital Nirvana turned its resources over to Live Nirvana - they are not the same site; rather, one is a no-longer existent site, and the other is a site which has received many resources from the former site. DN chose to not use a robots.txt, and to use watermarks - in effect, allowing images to be directly linked to, but retaining a visible sign of provenance. LN chose to use a robots.txt, and not to use watermarks - in effect, not allowing images to be directly linked to, but allowing them to be reused elsewhere, so long as LN doesn't have to foot the bill for such hosting. -- BrianSchweitzer 13:54, 23 May 2007 (UTC)
                • So basically you don't even care about this business - as far your concerned, as long as we host the image ourselves, and aren't leeching bandwidth it's fair game to use anything from anywhere? IMO this is reprehensible regardless of the legalities, especially when it's from user-built sites, but I'll leave it at that. --Gecks
                  • No, I'm saying you're arguing different things at the same time without making clear what your issue is. Is your concern a possible copyright infringement? If so , the lawyers and recent court cases have cleared us there, hence why ruoak changed the policy. Is your concern the unauthorized use of images from a particular site? If so, a) we are not using images from that site, so no incurred bandwidth or other costs to that site, b) the site is also using the images under the same protections we have (see first possible If), b2) that 3rd party site is in no position to then authorize any use anyhow, as they are not a copyright or licensing rights holder for the art in the image, and c) that site can always choose to prevent our (and anyone else) using the images, regardless of where they are stored, by changing their robots.txt settings. Ownership of the art does not rest with the person who scans it; it rests with the original creator of the art, and we are making a fair use under US law of that art; where it originally was posted on the internet really has no bearing on the legality or "properness" of subsequent use of the image file. I really don't understand what the concern is here. -- BrianSchweitzer 15:42, 23 May 2007 (UTC)
                    • I have spoken to about this and they have expressed no objections to us deep linking. They still haven't put up a permission page because they do not feel that such a thing is necessary. But, there is nothing underhand going on here. I've spoken with Gordon Mohr from who has taken the issue up with Brewster himself and there are no issues. If I felt that something was underhanded, we would not be doing it! -- RobertKaye
                      • As I said, it's not the permission granted by that's the issue, it's the fact we're not even trying to ask permission of these other sites, we're just using instead. -- Gecks
                        • I think one point being missed here is that 99.999% of the sites on the net, be they fan, bootleg, "wiki", whatever, have no permission themselves to be displaying the artwork. It's not that we're stealing anything from them - just because you scan something, you receive no ownership over the art you've scanned. I've had a long time now to consider this, and my take is that, essentially, is contributing storage space and bandwidth - others too can benefit, but we also are a beneficiary of their willingness. Given that there is a very clear and stated policy for MusicBrainz's willingness to remove any images for which the proper rightsholders send a removal request, then I see absolutely no issue here. Would you also have an issue with the local paper which uses a cover image in a CD review, or a sales catalogue which uses artwork in a circular? Of course not. They are making a fair use of the image, just as we are. Even when using artwork from a label's site itself, via, we're doing it in such a way as to make the very smallest possible footprint - is issuing a single request, caching that image, then feeding us that image from their permanent cache. I've truely tried to see your point here, over several weeks and months of thought Gecks, but it all just comes back to fair use rights and the right of the rightsholder to request removal. The site that happens to originally have the scan has no rights. We're making fair use rights use, as permitted and as is protected by many different statues and court decisions. We're even going the further step of allowing the proper rightsholder carte blanche request removal - though they would, I assume, have to prove that they are in fact the proper rightsholder. -- BrianSchweitzer 02:33, 01 August 2007 (UTC)
                          • Honestly, for the last time: nothing to with the legalities! They don't 'own' that data any more than we own ours. However they have collated and built that data just as we have here. The exchange of discographic data between these resources should be transparent, and involve both parties. Not only is this what is right, it also would build relations between facilities that are essentially working to the same end. (this and indeed all but the first few responses to the initial point should probably be DeleteWhenCooked as I don't think it's been productive!) -- Gecks

In edit#7523511 I was asked by mo to "please hold of adding archive links for a bit, as the legal issues are getting fussy," which I have done. In nothing of the above or at kuno/CoverArtLegalIssues is it very clear what the problem is however, so could someone spell it out clearly for the benefit of all. The most of the above seems to more about giving credit where credit is due than actual law, and the stuff on the other wiki page isn't elaborated on very much. --foolip

Just a tip on They try to do a pass on the entire web every 6 to 12 months, but it can take a long time for files to actually be added to the archive. However, if a particular document is currently available on the web, there is a very easy way to "force"'s bot to add that document to the archive for immediate use - and the url remains valid forevermore thereafter. Simply take a non-robots address -, for example, and pre-fix it with (as long as the date string is correctly formatted, any valid such date string will work). When then loads the page, you'll get Remove the middle [http:// http://] (to remove a unneeded redirect), and you have a perfectly working url to the document. This works for any http-accessible document, as well as most https documents. Thus, if metal-archives, or another site, has a coverscan you need, and it's not already in, you can easily have it added, and the resulting url will continue to work so long as itself continues to exist. -- BrianSchweitzer 02:40, 01 August 2007 (UTC)

  • This works very well, thanks for the tip! However, when I tried leaving the [http:// http://] it did not cause a HTTP redirect as you said, so I just leave it in the URL. -- foolip

I've written to a couple of days ago about their affiliate program, a couple of minutes ago I've received an answer. I seems I'm not allowed to open an appropriate affiliate account for MusicBrainz, as I need to be the owner of the website or something like that, however, they were pleased to see such a project and promised to contact MB administration and propose some kind of partnership which would include affiliating. I guess they might be also interested in using MusicBrainz for more, like datafeeding their shop, but that's just pure guessing and wishful thinking on my side. In short: we might be seeing covers for russian releases on MusicBrainz in the near future. -- NikolaiProkoschenko

  • Nikolai, my understanding was that MB now is signed up as a affiliate. Any idea where things stand on this, re affiliate and covers? -- BrianSchweitzer 17:03, 16 October 2007 (UTC)
    • Yes, that's right, current server release includes basic support for Cover image and product link should be added separately -- NikolaiProkoschenko.

Does have an English page? -- BrianSchweitzer 08:13, 19 October 2007 (UTC)

Just because foolip added I noticed something: allows the loading of the cover art only if you have loaded the release page before, which sets a cookie with the permission. If you try to load the cover art directly you get an error "Referral Denied". This is surely to pevent others of using the cover art. I guess it'll be hard to get their permission since it would require them to drop this cover art protection. -- OutsideContext

  • do have affiliate programs where you get a part of the sales profit, and it would be reasonable to think that you can use the cover art in such cases. Can anyone contact anyone on behalf on MusicBrainz and inquire about these things? I doubt that, so how should it be done? --foolip
    • Sounds like one for rob to me; does he have an interest in the CoverArt initiative, perhaps? --voiceinsideyou
      • Totally off topic, but as you seem to know YesAsia better than I... I used to use them for tracklists in scripts I cannot type/read. They recently switched to using images instead of unicode tracklistings, which has made finding many tracklists in original scripts difficult. Is there a way you know of to still get unicode, instead of image, tracklists at -- BrianSchweitzer 06:38, 27 September 2007 (UTC)
        • Yes, if you switch the display language to the language of the release you get the track listing in test instead. If it's a Chinese release, make sure to try both simplified and traditional. I've encountered a few releases where this doesn't work because there are some mixed scripts, but it usually does the trick. --foolip
          • Thanks for the tip, though I've not been able to get it to work. I've tried switching to the different language versions (via the links at the bottom center of their pages), but still only get image-tracklists. Am I missing something? -- BrianSchweitzer 17:00, 16 October 2007 (UTC)

Recently, started including their watermark into coverart images, I guess this makes them unsuitable for MusicBrainz. I can still ask them nicely :) -- NikolaiProkoschenko is also a nice russian shop, which appears to offer complete catalogues of different labels. Unfortunately, it also includes their URL in the image. Is it acceptable at all for MusicBrainz to use such coverart or is this a case of "use until better one is found"? -- NikolaiProkoschenko

  • This came up back when ruoak first asked me to throw out some wayback art ARs. Some of the ones I added had watermarks, which would seem similar to what you're describing. The concensus on the watermarks was to not use art that has visible ones, so I'd say the answer to your question is no, if they have the url added to the image, we wouldn't want to use those. -- BrianSchweitzer 21:38, 17 October 2007 (UTC)

I often find that has a more accurate tracklisting (including cat number) than I'm not sure if HMV operates an affiliate program, but if links to images could be used in return for clicks, it would be a great alternative. Did anyone ever formulate a "standard letter" asking for permission to use such links? --ArtySmokes

What about instances where music--and the corresponding cover art--is only available on For example, [[[Image:3411670-1225303037.jpg]] 3411670-1225303037.jpg] corresponds to (and --cparker15

I would think that, assuming were contacted and permission from them obtained, in these cases, were the artist to also then give permission, only then would it be yes, on a case by case basis. --BrianFreud

Wikimedia Commons

Now I see that Wikipedia does not give permission (I'm assuming due to the fact that nearly all their articles on albums are fair use on Wikipedia only), but what about those albums whose artwork is under a free license on a site that does NOT allow --free-- FAIR use, that being Wikimedia Commons? That should be compatible with MusicBrainz, with GPL and Creative Commons licenses, etc. --Geopgeop 14:21, 16 December 2007 (UTC)

  • Well, the problem is still where to get the image from - bandwidth, etc. --Gecks

Actually, Commons may be open, but since MusicBrainz uses CC-BY-NC-SA for parts of its site, there might be incompatibilities with the licenses. --Geopgeop 19:53, 17 December 2007 (UTC)


Would deep links for be permissible?

They would need to be contacted for permission. Once permission had been obtained, only then, yes. --BrianFreud

Rate Your Music

Do we really need a specific permission, if the website allows (and even provides the links) to deep link the featured cover images? I'll take as an example the Counting Crows (RYM) album August and Everything After (RYM): their cover detail page is actually titled in the browser header link to this images. They provide links using HTML and BBcode. Just wondering... --JM Beaubourg

  • Most sites don't provide express permission. However, for ones like RYM that do, I can't see any reason why that would be an issue, so long as the appropriate applicable permission details/info is provided on the CoverArt page for that site. -- BrianSchweitzer 07:26, 03 May 2008 (UTC)
  • They probably provide permission assuming it's for users to link to the artwork in forums, etc. Not for a site with this sort of traffic, especially one that is essentially 'competition'. I think it's always best to ask - it's just rude not to! I mean, why not ask? --Gecks

How about FreeCovers → Music CD ? They have high quality cover scans for logged Gold users, but direct no-login-required ones like this one are fine I think. -- liDEL 15:54, 19 August 2009 (UTC)