Improved Discogs Artwork Coverage with SongKong 3.9

Better Discogs Artwork Coverage

 Discogs has a concept of primary artwork and secondary artwork, primary artwork contains the front cover art and secondary artwork was used for other images such as the back cover or sleeve inserts. It used to be that an editor could specify whether an image was primary or secondary. But now when editing the first image is always considered the primary image and all other images are secondary images, this order can be modified by dragging and dropping the images in Discogs to make a different image the primary image.

However the Discogs data dumps contain many releases that only contain secondary images and no primary images. The precise reason for this is still unclear but whereas SongKong previously ignored secondary images meaning no Discogs images was found for these releases SongKong 3.9 now makes use of the secondary image if a release contains no primary image but does contain secondary images.

For you this means even better image coverage

Improved Matching

We deal with some more difficult matching problems in this release the key ones being:

For multi disc releases grouped one folder per disc SongKong could incorrectly match just one of the folders to a MusicBrainz release and not the others if MusicBrainz only contained a single disc version, even if  the complete release was available in Discogs. Now when matching multi-folder groupings if it fails to match the folders to MusicBrainz SongKong attempts Discogs match before breaking into subfolders and matching each folder to MusicBrainz only if no Discogs match is found.

If you have iTunes configured to make a copy of all songs added to it (the default) then any songs with no metadata are added to the Unknown Artist/Unknown Album folder. SongKong now realizes that this folder does not represent an actual album and therefore should be treated as one.

A silly assumption crept in somewhere that if all songs are by different artists then it must be a Various Artists compilation but this is often not true such as in this album - and this prevented SongKong matching albums when it should have. 

 

Various Fixes

 We also have a host of bug fixes across  various parts of SongKong, full details at the Issue Tracker

Finding more artwork by looking for similar releases

Hot on the heels of SongKong 2.1 we have SongKong 2.1.1 and this includes an important fix to the artwork finder.

Some Background

Within MusicBrainz different versions of the same release can all be grouped together under a Release Group. For example a CD version and an LP version of the same release would be part of the same release group. Artwork is added at the release level but usually the artwork for all releases within a release group is the same or very similar. Because of this if no artwork can be found for the release that SongKong matched to then SongKong will check releases that are part of the release group and if any artwork found use that instead.

Discogs

Discogs has a similar concept to Release Groups called Masters.  Masters also nominate one release as the Main Release which is often the chronologically earliest. But currently most releases in Dicogs are not linked to Masters so it isn't terribly useful to SongKong at the moment.

Instead we search for simply search for releases with the same artist and release name as our matched release and check the artwork of these releases. At least that is what it was meant do to but it wasn't working, now fixed in SongKong 2.1.1 so the artwork count should continue to rise.

A new Discogs Image Archive

New Discogs Image Archive with SongKong 1.25

SongKong and Jaikoz both use the Cover Art Archive as their primary resource for artwork but a very important secondary resource has always been the cover art provided by Discogs.
 
In March 2014 Discogs changed their terms and conditions so that from now any user of  a third party application could access a maximum of 100 images in a 24 hour period, and was required to authenticate their access using OAuth. The reasoning behind this was to prevent websites hot limiting to Discogs images, I can certainly understand that issue but think that giving 3rd party applications access via an application key would have been a more sensible option. Forcing users to explicitly authorize their access was onerous but I went along with it and released SongKong 1.23 with the required authentication.

It then became apparent the 1000 images limit was also per application. So any application, regardless of how many users it has, can only access 1000 images per day. This made it pointless for each customer to individually authenticate their access so I released SongKong 1.24 and this removed the requirement for customer authentication. But we still had a significant problem - a limitation of 1000 images per users was not too bad, but a limitation over the complete customer base of SongKong made use of Discogs cover art unsustainable. And of course the problems are even worse for Jaikoz with its larger customer base.

The solution was to cache the images provided by Discogs so any image only has to be looked up once from Discogs, then additional customers requesting the same image can use the cached image. Of course this requires the cached images to be available from a central server and I considered setting up my own Discogs Image Archive but this takes some effort and some time to build up the size of the archive. Luckily such a service has just been launched courtesy of the One Music Api, this archive doesn't yet contain all the images provided by Discogs but is growing every day and already provides good coverage. 

Today I release SongKong 1.25 with support for the One Music Api Image Endpoint. Within a week I expect to have a new release of Jaikoz with the same support