feat(tide-table): weight sample evidence by 1/df — PLN's ears found two tracks my reporting hid
PLN, on hearing a rose_rouge sample inside a seam I had labelled quand_on_decolle:
"where is our samples mathcing? gosh, i should not do so excruciating details
myself. you have all the data bro." He was right. I had 86 offset-consistent
detections and printed 4, because `locate` reported each bank's single BEST window
and threw away temporal extent — which is the informative part.
What was hiding in data I already had:
rose -> rose_rouge 22:35-24:00 (max cons 0.81), and on to 31:30
movie_paris -> something_about_drums 6:15 (0.62), 10:30 (0.49)
take5 -> take_5_drops 32:10-35:30
love_parade -> livecode_parade 55:20-56:10
So rose_rouge is continuously present 22:35-31:45 — a stretch I had split into
quand_on_decolle, blue_gold and UNRESOLVED. And something_about_drums sits in the
5:04-11:33 hole I reported as unclaimed, exactly where PLN said he played it
("im sure i played something about drums between bombe and do it right").
Then his second point, which is the principled fix: "its almost tfidf we should do
here. when we know rose sample is around a time slot, its a tell. when we see e.g.
_jungle_BreakS_, it's way less idf relevant."
Implemented as `fuse`: evidence for track T at time t is the sum, over detected
banks that T uses, of offset-consistency divided by that bank's df. A bank in one
track hands over all its evidence; a bank in eighty splits it eighty ways.
One refinement, from measuring rather than assuming: plain log-IDF is too flat for
this. jungle_breaks (df=80) carries 0.50x the weight of rose (df=2) — a 2x penalty
for being 40x more common, which would still let it dominate since it fires
constantly. 1/df gives 0.0125 vs 0.50.
Two normalisations that are not decoration. Per track, divide by the total 1/df its
banks could contribute, or a track referencing many rare banks beats a track with
one perfect tell — the reference-size bias in a third costume. And close gaps
before deciding: a rare sample fires intermittently INSIDE the track that owns it,
so `rose` at 22:35, 25:15, 28:15, 30:00, 31:10 is one track, not five appearances.
A NEGATIVE result worth recording. Weighting let MAX_DF rise from 6 to 40, taking
fingerprint coverage from 15/23 to 23/23 candidate tracks — and it added no
evidence at all: every new bank scored consistency 0.02-0.21 against a 0.30
threshold. I guessed reference duration was the binding constraint and that was
WRONG: correlation with best consistency is -0.144, and the three longest
references are among the worst detectors. Then the confound surfaced — suns_keys
belongs to blue_gold, which PLN did not play, so its low score is a TRUE NEGATIVE.
Failures and true negatives are indistinguishable without the setlist, so the
reason remains unestablished rather than explained away.
Also fixes two things that wasted PLN's time. The Boundary Lab query key is `set`,
not `gig` — bounds.tsx does get('set') ?? 'opal-festival-2026', so a wrong key
silently loads the DEFAULT document, and he auditioned OPAL's Sunset Forest seams
believing they were CosmicFest. The variable there is named `gig`, which is exactly
how I made the mistake: grepping found the word, not the key. And the generator
offered "bombe_dj -> bombe_dj" as cut #1, a seam between a track and itself,
because it read the un-merged segment file.
Showing
This source diff could not be displayed because it is too large.
You can
view the blob
instead.
Please
register
or
sign in
to comment