Better song matching with SongKong 3.13

A new release of SongKong is now available that  fixes these two issues.

Firstly it fixes a regression introduced in 3.11

When reusing existing Discogs Releases as candidates SongKong was not checking trackcount properly. The check to see if the there are more tracks than the number of songs to match which is not allowed if you have Only allow match if all tracks on album were matched is incorrect. We tried to fix this in SongKong 3.12 but made a mistake but it is now fixed.

If MetadataMatcher fails if it needlessly does Match Recording Only again

If song matching by metadata  fails to find a match it needlessy does Match Recording Only, and there is no point because this would have already been done during the Match by Folder stage, worse than that metadata matching can be called a number of times for the same group of songs. So wasted processing that can cause timeouts if extending the length of matching for a grouping over the timelimit and use additional amounts of memory.

 

New Song Changes Report in Songkong 1.9

With SongKong 1.9 we completely overhauled the song changes report, here is an example of such a report Song Changes Report

The main aims were to increase its responsiveness for big reports, and avoiding information overload by breaking down the information into smaller segments. To achieve this pages are split down into smaller parts and Javascript is liberally sprinkled over.

But the report is still quite complex so this post we explain the different sections in a bit more detail.

Summary

 

This summarizes how many songs have been loaded and checked, how long it took and how many and what percentage have been matched to MusicBrainz, Discogs and if we could find artwork for them.

One thing to consider when matching is whether to rematch songs that have already been matched or whether to ignore songs that are already matched. By default SongKong rematches all your songs but if you disable Basic:Match all songs, even if already matched then all songs that already have a Musicbrainz Id are ignored and not considered in the following sections.

MusicBrainz Summary

 

MusicBrainz is the primary data source used by SongKong.

This section shows what MusicBrainz releases your songs have been matched to. In the left handside we group the matches by the first letter of the album artist, if the first letter is not a letter they are put into the * grouping. Expanding on one of the letter groupings, lists the artists starting with that letter in alphabetical order. Selecting an artist from the list shows how your songs have been matched to their releases on the right hand side of the report.

By default only details of the first matching releases are shown, you can open close details by clicking on the small arrow in the release header information. The header tells you the name of the release together with its MusicBrainz Id, Record Label and Catalog No if known. It all shows you how many of the total songs on the release have found corresponding matches in your collection.

The details provide a hyperlink to open the MusicBrainz page for the release. Below this we list all the songs that were matched together with the song artist, Disc No and Track No.

If you have multiple copies of a song then the same release may be listed more than once, we always match the most complete match first.

Note this section looks at the details of your songs and their mapping to MusicBrainz, if the were already matched to MusicBrainz but not matched during this run of Fix Songs they will still show in this section.

Discogs Summary

This works in the same way as MusicBrainz. Songs can be matched to Discogs either by a direct search to Discogs or by a relationship existing from a MusicBrainz Release to a Discogs release. But Discogs is a secondary data source and Discogs matching and searching can be disabled, if both options are disabled in the Match tab then this section will not be shown.

Song Changes

 

This section shows what changes have been made to your files and is a listed as a file hierarchy. Each leaf folder can be selected and then the changes for each file in the folder are shown on the right handside of the report.

It is important to realize there is not a tight correspondence between songs matched in MusicBrainz/Discogs and Song Changes for the following reasons.

1. If the song was already matched to MusicBrainz and then rematched again to the same release they may not be any change required because the song already contains the fields matched.
2. Most songs can have Acoustids created, these are stored in the files. So even if no match was made to MusicBrainz or Discogs the song may still require saving
3. If the fiename mask has changed then the file will probably need to be renamed even if no metadata added to the files themselves.
4. If Fix Songs is canceled before its has completed songs may have been matched to MusicBrainz but interrupted before the changes could actually be written to file.

The list of changes made to a file is split into

1. Fields Added
2. Fields Modified
3. Fields Deleted

Songs Not Matched

Selecting this list all the songs that are not matched to either MusicBrainz or Discogs in the right hand side using a file hierarchy view.

Songs Not Matched to MuscBrainz

Selecting this list all the songs that are not matched to MusicBrainz in the right hand side using a file hierarchy view.

Songs Not Matched to Discogs

Selecting this list all the songs that are not matched to Discogs in the right hand side using a file hierarchy view.

Better matching in Jaikoz 3.4.2

Automatic matching is difficult but I've made a number of changes to improve the matching in Jaikoz in the latest release.

Jaikoz searches for possible matches in Musicbrainz then rescores them taking additional information into account to find the best match, it does this because an original Musicbrainz score only takes into account the search terms when scoring but we need to consider more values. For example we do not specify a duration in a search because some songs do not even have a duration within Musicbrainz so would never be returned by a search, but having got some potential results we want to give a higher score to those with a duration that matches the original song. Musicbrainz uses Lucene for searching with its own custom analyzer for deciding which songs are returned by a search and this latest release of Jaikoz uses the exact same analyzer to ensure scoring is compatible. This is one advantage of working on both Musicbrainz and Jaikoz !

When searching for a track we now consider more variations of the name because songs entered into Musicbrainz are normalized , for example We Have Explosive (Pt. 5) should be entered into Musicbrainz as We Have Explosive, Part 5 but they might not have been. This normalization is detailed in the Style Guidelines and In Jaikoz we now check for the title as it appears in your metadata and also as a normalized version as far as possible.

We also make workarounds for common errors in entering data. For example Musicbrainz Issue #5538 shows that users usually enter song titles as 'No. 1' , but in a large minority of cases enter 'No.1' , Jaikoz workrounds this issue.

Cluster Albums finds albums by artists with the same name but a different Release Id and tries to move the songs so that they are all on the same Release Id, note this is different to what 'Cluster' means in Musicbrainz Picard and perhaps I should have called it something different. Previously it did this by matching title against title for each Release Id being used, and picked the Release Id which had the most matches but now this has been improved. Firstly we use fuzzy matching on the title allowing for normalization as explained earlier. Secondly if all but a couple of tracks are successfully matched to one Release Id we allow matches on Acoustic Id and song length to shoehorn the remaining tracks into a potential release. This is really useful when the same song exists on two albums but is radically renamed between the two.