Improvements to Match to Recording Only section of the report in SongKong 1.26

SongKong 1.26

Today we release SongKong 1.26 this has a number of refinements to the matching process, testing has shown some very nice improvements to matching accuracy and coverage.

Full details here

Match to Recording Only

 There are also some nice improvements to Match to Recording Only section of the report, and I thought I would use this as an opportunity to explain this section further.

Songs are usually distributed as a release, be it an album, a compilation , an e.p. or a single the songs is part of a larger release. This also applies to digital downloads, although it is easy to purchase tracks they are still distributed as part of a release - even if the release is just a one song digital single.

With SongKong ideally we want to match group of songs to a release, but here are many reason why it might not be possible to do this all of the following problems could prevent a match:

• The release does not exist in MusicBrainz or Discogs
• You do not have all the songs of the release and you have Only allow match if all songs in folder match to one album enabled
• Your songs for that release are distributed over multiple folders and you have  Only allow match if all songs in folder match to one album enabled.
• The songs metadata is completely incorrect
• The songs have no metadata and are not known to AcoustId
• The songs match to multiple recordings by different artists via Acoustid
• The songs length is incorrect because it has been badly ripped.

If we cannot match the group of songs to a release we can still try to match songs one by one but it much more difficult to be sure of the correct release, especially if the existing track doesnt have any release metadata. So if Only allow match if all songs in folder match to one album or
Only allow match if all songs in folder match to one album are enabled we don't do this.

But even though we cannot identify the album this doesn't prevent SongKong matching the song. SongKong can use fingerprints to match to Acoustid, then use Acoustid to match to a suitable song (or recording in MusicBrainz parlance). When Acoustid matches to multiple recordings we take into account the existing song title (if any). Then we look at how many sources the choices have, Acoustid - Recording pairs that have been matched form multiple sources (i.e users) are more likely to be correct. Finally if we cannot make a safe decision about the name of the song we don't match to the recording. If we do make a match the only fields that are updated are:

• MusicBrainz Recording Id
• Song Title
• Song Artist

and the song is considered unmatched for the purposes of renaming songs so that if some songs in a folder are matched to a recording and some are not they do not get split up.

The Recording Only section of the report shows these matches. Originally SongKong simply listed the songs that were matched per artist in alphabetical order. But this was not very easy to decipher as a SongKong user myself I found I wanted the songs grouped by existing album name, this then helped me pinpoint problem recordings that were not matched often explaining the reason why the group of songs not matched to an album in the first place.

So here it is:

The MusicBrainz Recording shows the song titles that the songs have been matched to, clicking on a title will take you to the MusicBrainz page for that recording.

The Existing Info (Discno, TrackNo, Filename) column shows just that if they exist. Remember Match to Recording Only doesn't add release specific information like Disc No or Track No so these values are only shown if the song already contained them in its metadata. In this screenshot we see that songs did have Track No set but not Disc No set, so only track no and filename is shown.

Songs are grouped by existing release title of it exists, not the folder. So if  two songs from different folders with the same value for artist and release are matched this means they will be listed in the same section. Whereas two songs in the same folder with different values for release would be listed in different sections.

Any songs matched to recording will always have an Artist field because this is updated when matched but they may not have a release field, in this case they are just grouped by the artist name

Both these points can be seen in these screenshot:

Although both songs are in the C:\MusicUnmatched\The Tea Party\Splendor Solis folder they are split into two sections because only one has the release field set as we can see with the help of Jaikoz

MusicBrainz adds Series support

MusicBrainz have just done their bi-yearly schema update release, although MusicBrainz do releases every two weeks throughout the year they can only make changes that modify the database schema (such as adding new tables) in schema update releases.

Highlight of this release is support for Series as suggested by long time Jaikoz user Elliot Chance http://tickets.musicbrainz.org/browse/MBS-2714. A series can link together releases or release groups such as this Bravo - German Pop Hits compilation

and you can also browse all the Series added so far.


This is interesting for SongKong and Jaikoz, I feel I should be making use of this, but not clear how yet - does anyone have any good ideas ? 

Full release details can be found here ,and there are changes in  the corresponding search done by yours truly.

There should be also new MusicBrainz virtual machine released with the latest database within the next few days.

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