Hi,
I manually gave all tracks of a release the MB Release ID. Other than that, the only information the tracks have, is the track number. I use “Update Tags from existing Music Brainz Id”. For some tracks this works, but for some other tracks of the same release I get: Unable to find a track for release … that matches.
When I manually check musicbrainz.org, all track information is there for my Release ID.
Any idea why the match will work only for some tracks, but not for others of the same release?
To the best I can tell, I adjusted the match preferences to only consider the track number score.
The scoring has no effect when trying to match a track based only on the release id. To match each track to track in the release , and allowing for that the fact that you might not have all the tracks Jaikoz uses the following:
Track No
Track Length
Title
To get a match, you either need a Title match OR a track No and Track Length match, so I expect that your tracks that don’t match are not achieving this.
Thanks for explaining! My tracks are recorded from an analog source, so I don’t have track titles and the duration will definitely be off in some cases.
What about the settings on Preferences -> MusicBrainz -> Match (rather than Match Score). Are they also not considered for this type of match? I unchecked “Possible matches must be within track duration”. Will it still require a duration match if I don’t have the title?
If yes, is there a reason this needs to be this way or would you consider changing the behavior in a future release to respect this setting?
If your tracks only have a track no and a Release Id I don’t think this is enough info for Jaikoz to confidently match up the tracks within the release. Your situation with the track length being quite different is not that common.
Perhaps if I deal with the tracks as a group rather than indivudually as I do now I can relax this criteria in the future.
I’m moving away from this way of doing things, many people find Jaikoz too daunting as it is, so I’d rather do things cleverly behind the scenes and not add additional options unless they are readily understandable and really useful.
I hear you on the complexity of too many user options. I didn’t really mean to suggest additional options. Just maybe applying the existing MusicBrainz ones to the “Update Tags from existing Music Brainz Id” action.
Also, in the mean time I found that some MusicBrainz release entries have the Format “Vinyl” and tracks do not have any duration information. For those cases Jaikoz could automatically decide to drop duration as a criterion. It will never match anyway.
[quote=loeli]I hear you on the complexity of too many user options. I didn’t really mean to suggest additional options. Just maybe applying the existing MusicBrainz ones to the “Update Tags from existing Music Brainz Id” action.
[/quote]
Yeah, doesn’t really make sense in Correct Tags you are trying to find anymatches, in Update … you’d already identified the release you are just trying to work out which track goes with which
[quote=loeli]Also, in the mean time I found that some MusicBrainz release entries have the Format “Vinyl” and tracks do not have any duration information. For those cases Jaikoz could automatically decide to drop duration as a criterion. It will never match anyway.
[/quote]
Vinyl releases can still have a duration entered, it just has to be entered manually.
[quote=paultaylor]There is a reason it works this way:
Perhaps if I deal with the tracks as a group rather than individually as I do now I can relax this criteria in the future.
[/quote]
I was surprised to read that you don’t handle tracks as a group when attempting to match. It seems like the obvious thing to do. If you don’t, then you throw away a large amount of the matchable data. You will also end up splitting tracks that were previously together in the same Album into a multitude of separate Albums. After saving, this will then irrevocably (unless you have a backup) mess up all the tag data and album art.
There is a very common use case that is being ignored here, namely a user who has ripped a large collection of CD’s to disk using a common program like Windows Media Player. The tracks will generally be in a uniform directory structure (Artist/Album/Track) with a reasonable set of tags already set. Sure, these tags might not match exactly with those in the MB database, but the data quality will already be quite high since the data came from the CD itself rather than MB users who typed in their best guesses. Perhaps album art might be missing and maybe the file naming convention may be a bit off, the track numbers will probably not be zero padded. The way Jaikoz (and Picard) seem to work at the moment is they seem to sometime ignore some of this useful meta data when they could be making use of it.
Surely the algorithm should be something like this:
Get all the files in the current directory
Group them in a HashMap where the key is the Album name
For each group of tracks, attempt to find the best-match release in Music Brainz where additional points are added to the MB score if:
a) The number of tracks in MB is >= Number of tracks in this key of the HashMap (don’t allow a match with a MB release where num tracks in MB < number of tracks in this group)
b) Track Numbers (if this tags is present) match exactly with those in MB
c) Duration (if this tag is present) is within 1%
d) Track name (if this tag is present) is a close match (after converting to lower case, converting ‘&’ to ‘and’, etc, removing whitespace and non-alphabetical characters
Assign all the tracks in this group to the best-match release found in step 3.
[quote=mjw][quote=paultaylor]There is a reason it works this way:
Perhaps if I deal with the tracks as a group rather than individually as I do now I can relax this criteria in the future.
[/quote]
I was surprised to read that you don’t handle tracks as a group when attempting to match. It seems like the obvious thing to do.
[/quote]
I was only talking about ‘Update Tags from existing Music Brainz Id’ not ‘Autocorrect Tag from Musicbrainz’ . Jaikoz does consider tracks as a group, however a user may elect to only fix some tracks from a group, or may have reordered the songs so they are no longer grouped by release - so it doesnt consider tracks as a group as tightly as you might wish.
The ‘Cluster Albums’ task is intended to bring back tracks that have been inadvertently split.
Alot of people do store their files like this, BUT alot of people do not - it is much safer to parse metadata fields than data used in folder or filenames, but you can configure this yourself (at least for the filename part) by running ‘File and Folder Correct/Correct Tags from Filenames’ before autocorrecting (or you can add it to the list of tasks run in autocorrecter ). Because filenames can take many forms you should set Preferences/File and Folder Correct/Correct Tags from Filename
The algorithm is very much like this, but the user specifies exaclty what files and in what order they are fixed which make this a bit more difficult.