Second attempt at locating crossfaded track boundaries without PLN's ears, with
the three faults of v1 fixed: references taken ADJACENT to the boundary instead
of from a track midpoint (a livecoded track is not stationary), a MEDIAN over
every separating orbit instead of a weighted mean over 1-5 (one liar cannot move
a median), and a CUSUM change-point instead of a threshold plus a 6s sustained-
crossing rule that could not resolve a 4-cycle crossfade (~7.7s at 124 BPM).
It got better: median error 24.0s -> 16.6s, voters 1-5 -> 4-8. It is still not
good enough to ship, and I did not ship it.
The useful part is the SHAPE of the failure. Every single error is negative, and
the accurate boundaries are exactly the ones PLN described as short:
#3 -21.0 #4 -15.2 #5 -18.0 #6 -18.5 #7 -41.2 (his: 'still the drops')
#8 -4.4 #9 -2.0 #10 -2.4 (his: 'perfect starts perfect')
The lens finds where the incoming track FIRST APPEARS; the ear marks where it
TAKES OVER. They differ by the length of the crossfade, which is precisely the
quantity that varies. So the lens is measuring a real thing, just not the one we
asked for — a much better position than 'it is noisy'.
Two ways forward are written into the file, plus an explicit warning not to
paper over it with a constant offset fitted to these eight points: the errors
span 2.0-41.2s, so a fitted constant would be memorisation, not a method.
Prior art checked at PLN's suggestion and worth recording: the OPAL gig log is
useless here (2 track events in 87 minutes — the gig-log 'track' field only
started recording properly in 97b22c0b, AFTER the gig), but
Prod/Montreuil26_master/boundaries_ground_truth.json holds 14 user-confirmed
boundaries from a RELEASED split. That is a second, independent labelled set the
next attempt should validate against before touching OPAL.
