In a server update last April we quietly said that “we’ve also improved cover art support slightly.” What we actually did was release the first version of the Cover Art Archive, a cooperation between MusicBrainz and the Internet Archive. First, a little background:
Cover art (the images associated with music products) adds a great amount of value to the digital music experience. Many projects and apps on the net use these images to add color and depth to their music tools. However, there isn’t a cleanly organized, publicly available resource where everyone can access these images. You can use Amazon product images, but your project needs to be able to abide by their Terms of Service, which doesn’t work for everyone. Many projects use Google Images to source their cover art, but that is an inexact science since they may not always find the right image.
The Cover Art Archive aims to solve these problems by making these images available to the public. But since we are not lawyers, we can not say what can and can not be done with these. So use them at your own risk! That said, everyone on the internet is using these images anyway and the common understanding is that if you’re selling music you’re pretty safe. We suggest that when you try to figure out what to do, make sure that you respect the artists and their labels and make the music world a better place.
All images in the Cover Art Archive are indexed by the release’s MBID, and all metadata can be parsed by a JSON document. For instance, to fetch the front cover for any given release, construct this URL:
http://coverartarchive.org/release/76df3287-6cda-33eb-8e9a-044b5e15ffdd/front
Once you GET this resource, you will be redirected to the proper Internet Archive URL that yields either an image file or a 404 error if we do not have this image. For lots more details on how to use the Cover Art Archive, please take a look at our API documentation. So far, there are Java, C and Perl bindings to the API.
For some stunning examples of what people have already done with the Cover Art Archive, please take a look at these links:
- Jerry Lee Lewis: The Ultimate: The Sun Years. 109 images that carefully document a large box set.
- Star Trek box set
- ベスト☆きらり A Japanese release with lots of fun and colorful images.
So far, we’ve collected nearly 100,000 images that are attached to 54,000 releases for a 5% coverage in MusicBrainz. The largest file we have clocks in at 23MB and the largest image is 16,000 x 7842 (125 megapixels!). For all of the juicy stats on this project, check out our cover art statistics page.
We’ve just gotten started and we need your help! Won’t you please consider uploading some images to this archive? To get started, log in with your MusicBrainz account (or create a new one) find your favorite release and then click on the cover art tab to view the existing pieces of art and/or upload new ones. For more details, see our How to add cover art guide.
Thank you to everyone who has worked hard to make this project a reality! And thank you to Brewster Kahle and the Internet Archive for fostering this project!
MetaBrainz Blog 
Excellent idea. I love MB even more now! 🙂
Congratulations on the release! One of the exciting aspects of the cover art uploaded so far is its quality… it generally appears to be of a higher resolution than that available via Amazon et al.
Why don’t you just use last.fm’s album.getinfo for initial data? I would love to switch over to musicbrainz as my cover resource.
Also, quality is important as I think we need to think about retina displays.
@Tjorriemorrie – MusicBrainz itself isn’t doing any data collection, which is fairly standard practice – we don’t guess data, we let the community contribute it all. I think we’re going to be good with the quality stuff, because people are going through great lengths to upload fantastic scans and high quality images. Again, that’s also fairly standard MusicBrainz behaviour!
I think it can be negative for the survival of records, for them going on being released, that people upload hi-res scans.
Why are the Perl bindings in the Net:: namespace? Net:: is for network protocols.
@jesus2099: You could say the same about all metadata really…
I notice that the URL specifies a “release”. Does this mean that in the future we can hope to see images for other types of MBID, such as artists?
mavit: it seems so now, given the talks in our summit! 🙂
We’ve already got a patch in the pipeline for release-group cover art (which is just a pointer to a release whose front cover should be used, but nevertheless), and at the summit we also discussed adding other entities in the vague future sometime, as reosarevok mentions 🙂
While it is certainly great to be able to upload large scan images, these images can get quite big. I’m using Picard to tag my mp3s and I love to be able to get cover embeded in them as well. Only problem is, Picard will download the cover in original size (could be 2000x2000px, 500-700kB) for every file. Do any of you know if there is a plugin for Picard to get these covers resized to smaller size? Or any other solution?
While I haven’t tried it, if you’re using the cover art plugin you should be able to do that by editing it as indicated in http://tickets.musicbrainz.org/browse/PICARD-237?focusedCommentId=22406&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_22406 – I am not sure if the built-in cover art stuff has been released but if it has I can’t really help with that one 😦
I note that in the latest MusicBrainz server VM schema release musicbrainz-server-2013-10-14.ova, there is no cover_art table, but there do appear to be TYPEs cover_art_presence and cover_art_url. Is there any updated documentation on how cover art is treated in the 2013-10-14 schema? Thanks!
Stewart: Have you looked in the cover_art_archive schema?
OK, is it possible to load mbdump-cover-art-archive.tar.bz2 in the musicbrainz-server-2013-10-14.ova VM with 49.831 gigabytes available on the root partition? I previously attempted to upgrade the VM from schema version 18 to 19 and it failed due to a PostGres tmp file filling the root partition. Thanks.