This question was prompted by me discovering I have an indeterminate chunk of five-second-long mp3s in my collection that bugged out during FLAC conversion and I failed to notice during my last organization because Picard for some reason weights title matching much more heavily in its color-flagging than any other factor, even duration.
For instance if there is a long 15-minute prog song with a title like “Hoity-Toity Suite: A) Overture B) Pretension C) The Shibboleths of Eta Carinae D) …” I will shorten it to the first title and Picard will show a light green or even yellow card sometimes on that basis, even if everything else matches, and so I tended to ignore them and only check the orange/red stuff. However a version of that song with the proper full title but an absurdly short duration due to file corruption often gets a much better percentage match.
Here is an example I just tested. The version of Track 6 with the shortened title gets a yellow card. The version of Track 6 that I truncated to four seconds in Audacity to simulate corruption only gets a light green card (it’s not visible in the screenshots since I have it highlighted but the background color is even fainter than the other light green cards issued for shortened titles).
I completely understand not weighting duration very heavily when it’s a few seconds of difference, especially in the case of vinyl/tape rips. But is there any way I can get it to just automatically red-flag anything where the duration falls short by more than 30 secs?
No, you cannot currently configure the weights used for comparison.
Currently the length gets weighted at about 17% of the total matching score (see picard/file.py at master · metabrainz/picard · GitHub). Where 0 second difference gets a perfect length score, and 30 seconds or more 0 score. In between it is linearly weighted.
I guess then I would suggest having the weight itself affected by the length (possibly this should be non-linear?). Or maybe open these up in the control panel like the weights used for MB matching releases. I haven’t experimented with these and I assume you guys have but as a user it just seems like Picard expecting a five-minute file and finding a five-second one should be a show-stopper.
EDIT: I’d be tempted to adjust these myself and re-compile except I don’t know jack about Python (been a decade-plus since I even touched C++ haha) and can’t suss out where to uncap the difference from 30s.
Found this topic through searching, sorry for the bump.
I would really love some weighing options in picard for track matching inside a release. Like, in my case most of my tags are going to be in English but a lot of the releases have Japanese tracklists with kanji, so my original title and album tags are practically useless.
So in cases like these, it would be great if I could boost the track number importance, for example. The only “solution” right now is to just lower the minimal similarity for matching files to track percentage to really low, and then it works, but that seems like a bad solution tbh.
