Good cover art sources?

I was thinking of scraping their pages instead, because they're pretty easy to parse and they don't require login (and I'm guessing a lot of MB users don't have Discogs accounts but would still like to get artwork from there). But either way would work fine for me.

OK, the next thing I want is to be able to store multiple images (with the appropriate "art types", at least for ID3 and MP4 and other formats that understand them, and corresponding filenames for the local files), and for clicking the image to open a thumbnail window of all images downloaded by all plugin sources (plus existing metadata) so I can select/rearrange/re-type them instead of going straight to Amazon. And maybe even throw in file conversion (downsize to 500x500, convert to PNG if not PNG or JPG, etc.). How much time do you have? :)

It looks pretty nice (and I love that someone is using Boo as a scripting language), but it appears to be a .NET app with a Windows-specific GUI, so I don't think it'll do me much good. But thanks anyway.

Actually: which of the zillion or so scripts for that program do you use as sources? That in itself might be useful info for me.

Looks good; I'll play with it tomorrow.

One thing: You're grabbing the first image off the viewimages page. That does seem to at least usually be the front cover, but is that guaranteed, or do we have to actually look at the release page and see which one matches the thumbnail found there?

Well, I've used the "Search at Discogs" plugin quite a bit, hacked up to put quotes around the artist and album, and it's not bad.

Obviously, nothing's going to fix the problem where variations of a release have different covers and you get the wrong variation. (Well, nothing short of some AI that scans all the releases and tries to match up track titles through guess-case and so on.) And likewise, when Discogs and MB disagree on what's an artist name variation/alias/different artist you're not going to get a match. But beyond that, since the last site upgrade, I get a lot fewer false positives than at any other site I search on, and not many more misses.

If you do an artist search followed by a within-artist release search, there are even fewer false positives (but you do get more false negatives--that search seems to be less tolerant of minor spelling variations than the global search).

Good point. The only time I've ever added a Discogs AR, other than when I'm adding new releases or verifying questionable info, is when I go there to hunt down cover art. So, it would at least discourage me.

It might be cool to pop up a messagebox that helps add the AR. Something like this:

* The icon is the thumbnail.
* The text is the search result text.
* The title is the release name.
* Button 1 is "Match". It pops open a browser window to add a Discogs AR to the release, with the link pre-filled-in and ready for me to click "Save", and also saves the image to the metadata.
* Button 2 (default) is "Maybe". It pops open a browser window showing the Discogs page, then loops back to fire the mbox again.
* Button 3 (cancel) is "No Match". It pops open a browser window showing the Discogs search, then tosses the image.

That's a horribly hacky UI that any of my designer friends would shoot me over, but it would work for me, and be pretty easy to code up....

I can't say it's guaranteed, but it's the same as the thumbnail in all of the cases I've ever seen. Anyway, I updated the pastebin URL to a new version that simply pulls the larger size of the thumbnail (I didn't notice the URLs were the same, except for the prefix, at first). So, it no longer touches the viewimages page. That also allows it to work with the master pages.

This'll improve once NGS allows us to match Discogs pages with the specific release variation on MB. There will probably have to be a lot of manual cleanup before its a perfect mapping; I imagine the NGS migration script has no idea what Discogs AR belongs to what release event.

That would be helpful, but might require some manual intervention: the Discogs page could have the correct cover but not the same tracklist as the MB release. (Unless it's an obscure release where there's only one version…then it could save a lot of time.)

Nice to know it works on someone else's machine. I said this above too, but I uploaded a (slightly) modified version with different regex that fixes a few things.

That's pretty awesome. Kudos for putting logic in like that. This kind of stuff could save hundreds of thousands of edits and many thousands of man-hours!

I use all of them at the same time, so I'm not sure which ones give me most sources.

Good catch. I wouldn't have run into that, because I don't think I have any releases without any ARs (I've MusicBrainz'd most of them already!)

The naming confused me at first, and it's also kind of hard to follow python's text representation of the data structure. release.relation_list seems to be a list of dictionaries for each target_type (artist, release, url, etc.). Inside those there are a bunch of sub-dicts and sub-sub-dicts that have the attributes for each individual AR. I mainly just trusted the other cover art plugin's way of traversing it.

I've always gone here http://www.allcdcovers.com/

I submitted some album art there too :D