Similar track with score:100 will not Match

MusicBrainz Picard
, , , , ,
1

I can have a track that has a 100 match score within the “Search for similar tracks” dialogue (using the default search query), but the “Match” functionality says that there’s no match above the threshold. If I load the matching track from the “Search for similar tracks dialogue”, the only modified tag is Genre, which goes from null to having a value.

The default query was
track:(Lune) artist:(Tim Green) release:(Eastbound Silhouette) tnum:(4) tracks:(0) qdur:(283)

I tried playing around with the “Tags to ignore for comparison” setting, ignoring everything except for track title and artist name, but this made no difference. The only way that I was able to get the track to match with the first 100 match score item listed in the “Search for similar tracks” dialogue was to reduce the threshold setting from 70% to 60%.

Perhaps the “Tags to ignore for comparison” setting is broken?

FWIW I have an example track that had the following fields matching exactly:

  • Title (“Name” in the similar tracks dialogue)
  • Length
  • Artist
  • Album (“Release” in the similar tracks dialogue)

Perhaps there is a mapping issue between Title>Name or Album>Release?

The only potential mismatch is the following field:

  • Date (2022 in original tags, but 2022-10-28 in the similar tracks dialog)

Perhaps there is a match % issue with the date value?

The other tags that already existed on my track (that do not appear as columns in the “Search for similar tracks” dialogue) were:

  • Track Number (set)
  • AcousticID Fingerprint (set)
  • Disc Number (set)
  • Total Discs (set)
  • Total Tracks (set)

Perhaps there is an issue whereby additional original fields reduce the match %?

The columns that appear in the similar tracks dialogue that weren’t already tags on my track were:

  • Country (set)
  • Type (null)

Perhaps there is an issue with null values, or Preferred Release Types/Countries/Formats? Or perhaps there are mismatching fields that are not displayed within the similar tracks dialogue? Does Picard score tag matches prioritising certain tags, eg. title, artist, before other tags? It would be nice to be able to customise this. Do the Preferred Release Type settings lower the match % (esp. if the database returns a null value for that tag)? They shouldn’t.

FWIW the following missing tags that appear in the similar tracks dialogue do not get added as new values:

  • Date (2022-10-28, maintains original value of 2022)
  • Country (XW)
  • Type (null)

This issue has left me perplexed - please help! I cannot afford the time to manually select results from the similar tracks dialogue as I have a lot of single tracks in my collection that are from albums.

2

For a file lookup Picard compares the existing metadata against the value from the database for the following fields:

  • title
  • artist
  • album
  • track length
  • date
  • totaltracks

It also checks the loaded releasetype, releasecountry and format against the preferred release settings. Furthermore if the recording in the DB is set as “video” and the local file is not considered a video file there is a small penalty to the matching score as well.

The search score from the database search (or the AcoustID lookup in case of “scan”) is also part of the final matching score.

The different checked fields have various weights, see picard/picard/file.py at release-2.10 · metabrainz/picard · GitHub

For cluster lookups (release search) slightly different comparison rules apply (picard/picard/cluster.py at release-2.10 · metabrainz/picard · GitHub).

Actually the setting is not used in searches and the idea behind the setting is something different. It is part of the settings above (“Ignore the following parts when determining if a release is complete”) and is applied only in these checks. Tags listed here have no influence in the check whether a release is considered complete and unchanged or not. So e.g. if you add the barcode here because your files have existing barcode tags, but having those different from the new barcode written by Picard you don’t consider a relevant change, then Picard will show the release as unchanged and complete even if the barcode differs.

We could consider whether we also apply this setting when evaluating search results. Need to think about this if it would have any side effects.

Yes, it does. And it should, that’s the exact purpose of those settings, they influence the matching rate. We could consider to treat unset values in the DB with a lower penalty then wrong value, though.

How are those settings set for you and what type does the release you are looking for have?

Maybe you can give a concrete example by showing the existing values for the relevant tags, the track you want to match again and maybe screenshot of the preferred releases options. Otherwise it’s only guesswork and you need to figure out which part matches badly yourself.

I missed the details in the search query. That actually already contains most of the tags, and you gave the rest of the info later. Preferred releases settings would be interesting. But I’ll check the results for your metadata.

2 Likes
3

I could identify two issues that affect the matching negatively here:

  1. The check for the video flag is checked incorrectly if it is not set, so each none-video file / track gets downrated. It’s not much, but enough in your case to move it just below the 70% rate.

  2. More significantly the check for the release types fails if no release types are set for a release in the database. It then applies a match of 0 with high weight, lowering the score significantly. It rather should probably apply the “Other” score used for unknown release types.

I’ll get this fixed. For your case lowering the threshold is probably the best workaround for now.

See PICARD-2780 and PICARD-2781

4 Likes
4

You’re a star - thanks so much for your thorough and rapid response =)

1 Like