PLN asked for "a master split per track loaded time, cleanup parts obviously
'practice or plugging in' that are scarce VS intro/outro (can we detect this? did we
record play metadata as the ardour records?)".

Three datasets existed and had never been joined:
  - Ardour names sources `Take<N>_Tidal <orbit>-<seq>%<L|R>.wav`, so the take number
    plus the frame count plus the mtime give an exact wall-clock window with no
    session-XML parsing at all.
  - gig-log has coalesced MIDI CC at 1 Hz: 29862 events over this take, on 46
    distinct controllers. Hands-idle is the clearest signature of "plugging in".
  - per-orbit RMS/peak says what the SOUND did.

The third one is not optional, and that is the design insight. Idle hands ALONE is
ambiguous: you can play a part for three minutes without touching a knob. So a
candidate is classified by what the audio was doing underneath it — `dead` (nothing
above -60 dBFS: safe to cut), `loop` (a couple of orbits droning, hands off:
probably plugging in), `playing` (most orbits going: a real part, KEEP). On take 94
that distinction earned its keep immediately: of three hands-idle runs, two were
real parts at 8 and 4 orbits average, and only the 75s tail was actually dead.

FINDINGS ON TAKE 94 (21.1 min, 20:08:33 -> 20:29:41, 12 orbits)
  - 8 of 12 orbits peak OVER 0 dBFS, worst d4 at +9.63 dB. The files are 32-bit
    FLOAT, so this is headroom and not damage — a gain cut recovers it exactly, and
    it only becomes real clipping on integer export or at the master bus. Labelling
    it "CLIPPING" would have been a false alarm sending him to re-record material
    that is completely intact, so the tool now reads the subtype and says which it
    is. A uniform -16 dB on the record bus lands the hottest orbit on the -6 dBFS
    source target.
  - d12 silent for the whole take (-78 dBFS).
  - no track timeline: nothing published the loaded track while it recorded. The
    tool says so plainly instead of guessing, because a confident wrong boundary is
    worse than none — the existing Bandcamp splits carry crossfade bleed for exactly
    that reason. Takes from d5baca32 onward split exactly.

A MEASUREMENT TRAP, RECORDED IN THE CODE
The first pass estimated duration as size/(sr*3), assuming 24-bit. These files are
32-bit float. That put take 94 at 28.2 min starting 20:01:30 instead of 21.1 min
starting 20:08:33 — and manufactured a "6m15s dead intro" that never existed, purely
from a 7-minute window shift. The fallback now assumes 4 bytes and, more
importantly, exact lengths come from the frame count and estimated ones are labelled
"do not cut from it".

Also: logs_covering() checks EVERY log's [first,last] range rather than assuming the
newest one holds the window, because a take can straddle a recorder restart — which
is exactly what happened today.

It proposes, it does not cut: output is a report plus an EDL JSON for
armada/tide-table/edl_render.py. Trims are a taste call and the ear is the gate.