fix(foundry): the probe was looking in the wrong place, with the wrong lens
Three separate errors, each of which quietly threw away good material. **Where it looked.** Evenly-spaced probe windows sample the gaps. A stem is not stationary — measured on ANGIE, even windows read HIHATS at -60.9 dBFS / 1.4% active where the full file says -48.8 / 9.7%, and missed PAD STUFF's material entirely (0.0% vs 6.9%) because that stem only plays in two sections. Windows are now ranked by energy and chosen where the stem is actually playing. **What it measured.** Usability was gated on overall RMS, which on a sparse stem measures how much silence it contains, not whether it has material in it. ANGIE's HIHATS stem is -48.8 dBFS RMS and a perfectly good hi-hat stem peaking at -14.7. Level and activity now come from the whole file (it is only a frame-RMS pass) and the gate is peak plus activity relative to the stem's own peak. Three ANGIE stems and two MAREA stems come back from the dead. **What it concluded.** "Mostly low energy, low centroid ⇒ bass" fires on a drum bus, because a modern kick carries most of a drum mix's energy: ALL DRUMS reads lf 0.86, centroid 216 Hz, indistinguishable from BASS on those features. So ALL DRUMS was being filed into the bass kit AND mono-summed, and KICK with it. Onset density is asked first now (ALL DRUMS 5.5/s vs BASS 1.1/s), and a `hits` claim survives a bass measurement, because a kick IS low and slow and only the label says it is one hit. And the authority question underneath all of it. The house rule is that a sound's role is never INFERRED from its name; it is not that a producer's label about their own stem is worthless. Those have very different evidential weight. Presence and bass are decided by measurement — a stem under -40 dBFS peak has nothing in it, and "all energy under 150 Hz, nothing above 2 kHz" is unambiguous. Everything else keeps the label, because onset density cannot separate a rhythmic rhodes from a drum bus: MAREA's KEYS2 reads 5.1 onsets/s and its sparse CLAP reads 1.0, so measurement alone files both in the wrong kit, silently. Disagreements are reported, not resolved. Also: register_fred_rights.py records a freshly cut third-party kit in the rights ledger as third_party WITH its provenance, at the moment of cutting. Left alone it would land as `unknown` at the next --init, which blocks correctly but blocks with no reason attached.
Showing
armada/tide-table/register_fred_rights.py
0 → 100644
Please
register
or
sign in
to comment