`locate` normalises by reference size. `crossmatch` did not, and the number said
so: correlation(reference length, seconds won) = +0.586. Ceci (524s) and Piment
(506s) won most of the set; WAP and REVOLUTION won nothing at all. The cause is
that per-track score is a MAX over that track's windows, so a 524s reference
simply gets more chances at a high max than a 154s one.
Same asymmetry, second occurrence, new location — which is the pattern in
feedback_count_what_you_bound: a bias survives a fix when the metric moves.
The correction turns "how similar is this window to track T" into "how UNUSUALLY
similar, for track T", by standardising each track's column over the whole
query. A track generically close to everything now has a high mean and wins
nothing; a track that spikes in one place wins there. It assumes each track
occupies a minority of the recording — true for 15-30 tracks over 63 minutes,
false for a 2-track set, so it is stated rather than buried, and --no-standardise
shows the raw bias.
Two more things, both from PLN's "almost the same lineup" observation:
Montreuil26's tracks_bandcamp adds 15 more renders, and six of them are tracks
OPAL never had — Jeudi Drill, PunkAChien, L'Or Bleu, Premier Septembre, Quand on
decolle, Techno Orage. That directly explains the two disagreements between the
methods: `locate` was confident about rose and love_parade, and crossmatch
mislabelled both, because rose_rouge and livecode_parade are absent from the OPAL
reference set and it can only pick the nearest thing it holds.
Six tracks now appear in BOTH gigs, so their names must merge or one track splits
its own vote and each half loses. canon_track does that with an explicit alias
table rather than fuzzy matching: a wrong explicit merge is auditable, whereas a
silent fuzzy merge of two different tracks would be invisible in the output.
Also caches the query profile keyed on mtime and window geometry, because
recomputing 63 minutes of chroma_cqt per run costs five minutes and this tool
exists to be iterated on.
