Commit 5885da5f by PLN (Algolia)

docs(log 038): the results — two masters, 14 tracks, and a clean negative on the global pass

Everything landed. Two full masters differing only in air shelf, both at -14.0 LUFS
/ -0.9 dBTP / LRA 7.5-7.6 / 44100 Hz 24-bit, and 14 split tracks verifying ALL OK.
Duration is 3779.317551 s against a source of 3779.317550 — the load-bearing number,
because it means every one of PLN's playhead calls stays valid and the split lands
exactly where he put the cuts rather than approximately there.

Q1: the missing air is CYMBALS. Drums hold 0.367% of their own energy above 8 kHz
against 0.084% for the runner-up, a 4.4x concentration where evenly-spread energy
would have meant codec hiss. So opening the shelf is licensed by measurement, and
how far is not — hence an A/B rather than a number I liked. The framing that
matters: both candidates are still BELOW typical brightness for electronic masters
(8-16 kHz at 0.40% and 0.63% against a 1-3% norm), so the choice is "quite dark vs
slightly less dark", not "safe vs aggressive". The A/B is also confound-free:
identical loudness, identical true peak, range within 0.1 LU, only the tilt differs.

Q2: the floor is worse here than OPAL. Kick active time averages 44.8% against the
59% project_floor_problem measured for OPAL-26 from real orbit stems, worst at
#2 22.8%, #3 33.4%, #8 36.9%. A stage mic in a room explains it on its own, so this
is a lead rather than a verdict — but it is the first time this gig's floor has been
measurable at all.

Q3, PLN's own question, and the answer is a clean negative: the global pass was not
worth running. Correlations 0.943-0.977 against the per-section stems with level
deltas of at most 0.21 dB. The two separations are the same stems. The prediction
held exactly — htdemucs' 7.8 s receptive field means a global pass cannot give the
model more musical context, so only normalisation differs, and it barely moved. It
cost ~2.5 h of CPU competing with the master render to establish a quarter of a dB.
Sections only next time; the question was worth asking once, not twice.

Side finding: bass is the least stably separated of the four sources (0.9432,
lowest), consistent with the same run putting PunkAChien's bass into `other` — bass
stem at -81.0 dBFS while `other` was the loudest stem in the set.

The log also records three self-inflicted errors that share one shape: checks whose
failure mode was indistinguishable from success. A dropped rtk grep plus a
block-buffered logfile that made a working job look dead, so two renders raced on
the same paths for forty minutes. A speed claim built on counting directories that
appear when writers open. And a scripted edit that silently no-op'd while printing
success unconditionally. Plus the 192 kHz master, which was not a new bug at all —
topic_postprod_mastering has carried that trap since tidal-ears hit it, and I wrote
a new mastering chain without re-reading the omnibus that exists to prevent it.
parent 0a123d3b
...@@ -274,3 +274,102 @@ Branch `claude/release-board`. ...@@ -274,3 +274,102 @@ Branch `claude/release-board`.
- Whether `Outro: La Dub Sirène` (103 s) is an album track or mix-only. - Whether `Outro: La Dub Sirène` (103 s) is an album track or mix-only.
- Whether the club target is worth chasing below the LRA floor on this source. - Whether the club target is worth chasing below the LRA floor on this source.
- The unreviewed merge `2f947c2`, still standing on master. - The unreviewed merge `2f947c2`, still standing on master.
---
## The results — 2026-09-02, ~02:00
### Delivered
| | |
|---|---|
| **Master A** `Cosmic26_v1_streaming.flac` | air shelf **+5 dB** · 661 MB |
| **Master B** `ab_air8/streaming.flac` | air shelf **+8 dB** · 673 MB |
| both | **−14.0 LUFS · −0.9 dBTP · LRA 7.5 / 7.6 · 44100 Hz / 24-bit** |
| duration | **3779.317551 s** against a source of 3779.317550 s |
| **album split** | `tracks_v1_streaming/` — 14 FLACs, verify **ALL OK**, format 44100/24 |
| demucs | 14 sections + a full 3779 s global pass |
Both of PLN's forms are therefore on disk: nothing was cut from this set, so the
continuous mix simply *is* the master file, and the split sits beside it.
The duration matching the source to within a microsecond is the load-bearing
number. It means every one of his playhead calls stays valid against the master,
so the split lands exactly where he put the cuts rather than approximately there.
### Q1 — the missing air is CYMBALS
Mean share of each stem's **own** energy above 8 kHz: drums **0.367%**, vocals
0.084%, other 0.033%, bass 0.000%. A **4.4× concentration in drums**, where evenly
spread energy would have meant codec hiss and a shelf that must stay shut.
So the deficit is real drum content the room ate, and opening the shelf is licensed
by measurement. How far is not, so the answer is an A/B rather than a number I
liked. The useful context for that choice: against the tape, 4–8 kHz went 1.75% →
3.14% (+5) → 3.86% (+8), and 8–16 kHz went 0.12% → 0.40% → 0.63%, against a rough
norm of 3–6% and 1–3% for electronic masters. **Both candidates are still below
typical for air.** The choice is "quite dark vs slightly less dark", not "safe vs
aggressive" — worth saying, because the framing changes the answer.
The A/B is also clean in the way that matters: identical loudness (−14.0), identical
true peak (−0.9), range within 0.1 LU. Only the tilt differs — 0.98× below 1 kHz,
1.23× at 4–8 k, 1.59× at 8–16 k. No "the louder one sounds better" confound.
### Q2 — the floor is worse here than OPAL
Kick active time, 40–120 Hz against each track's own p95: **mean 44.8%**, against
the **59%** `project_floor_problem` measured for OPAL-26 *from real orbit stems*.
Worst: **#2 There's Something About Drums 22.8%**, **#3 Am i Doing it Right 33.4%**,
**#8 Eh ouais je Funk 36.9%**. A stage mic in a room is a sufficient explanation on
its own, so this is a lead and not a verdict — but it is the first time this gig's
floor has been measurable at all.
### Q3 — the global pass was NOT worth running
PLN's own question, and the answer is a clean negative:
| stem | correlation | level delta |
|---|---|---|
| drums | 0.9765 | −0.14 dB |
| other | 0.9742 | −0.06 dB |
| vocals | 0.9543 | −0.17 dB |
| bass | **0.9432** | −0.21 dB |
**The two separations are the same stems.** The prediction held exactly: htdemucs'
7.8 s receptive field means a global pass cannot give the model more musical
context, so only the normalisation statistics differ — and they moved the level by
at most 0.21 dB. The residual 2–6% of uncorrelated energy is chunk-boundary
placement, not a different reading of the music.
It cost roughly 2.5 hours of CPU, competing with the master render, to establish a
≤0.21 dB difference. **Sections only on the next stemless gig.** The question was
worth asking once; it is not worth paying for twice. Banked in
`reference_demucs_on_xps22`.
Side finding: **bass is the least stably separated source** (0.9432, lowest of the
four), which is consistent with the same run putting PunkAChien's bass into
`other` — bass stem at −81.0 dBFS while `other` was the loudest stem in the set.
Anyone reading stem filenames as roles would have concluded that track has no bass.
### Three self-inflicted errors, same shape
All three were **checks whose failure mode was indistinguishable from success**:
1. **The nohup "death".** `rtk` silently dropped a `grep`, and Python block-buffered
a logfile to zero bytes. I concluded the job was dead and started a second copy;
two renders then wrote the same paths for ~40 minutes.
2. **The demucs speed claim.** Counted output directories, which appear when writers
*open*. Retracted from the commit, the log, and two memory files.
3. **A silent no-op edit.** A scripted replacement whose search string carried
escaped line-continuations that did not match the file, while the script printed
"gate tightened" unconditionally. Caught by grepping the file rather than
trusting the message.
And one that was not mine to invent but was mine to prevent: the first full master
came out at **192 kHz, 1.32 GB** because ffmpeg's `loudnorm` oversamples for
true-peak detection and never resamples back. `topic_postprod_mastering` has carried
that exact trap since tidal-ears hit it. I wrote a new mastering chain without
re-reading the omnibus that exists to prevent it. The fix is structural — the
resample lives in the chain *builder*, and the in-spec gate now asserts sample rate
and channel count beside I/TP/LRA, because a loudness-only gate certified a
4.3×-oversized master as ✓.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment