Skip to content

T
Tidal
Commit 71516e25 by PLN (Algolia)
Options

docs(log): land three captain's logs that were written and never committed 

Written 2026-08-14, uncommitted for three weeks: the -inf fader forensics on
Tidal Live.ardour, the corpus triage that found '51 broken tracks are actually
22 — the harness was the biggest bug', and the 192 kHz master-format audit
('probe, never assume'). All three are marked shareable: true, which is the
whole point — these logs are the source material for the posts and videos,
and they were sitting one bad rm away from not existing.

The rule in armada/tasks/README.md is 'write the entry when the task lands,
while it's fresh'. It worked: the writing happened same-day. It was the
committing that didn't, because git status had become unreadable (see a5a5b37).
Documentation discipline is not one habit, it is two, and the second one is
the one that survives a hard drive.

Left for PLN, one line: all three carry 'log: 025' in their frontmatter, which
025-fifteen-intros-are-not-a-set.md already owns. They also use dated filenames
like 2026-08-03-j5-audio-dropout.md rather than the README's NNN-slug.md.
Renumbering is a call about his own archive's spine, not mine — and the dates
are 2026-08-14, which lands them BEFORE 039, so the next free numbers would
read out of order.

    the log was kept. the log was not carried.
    a ship's record that never leaves the desk
    is a memory, not a record.
parent 039ff575
Showing with 459 additions and 0 deletions
armada/tasks/2026-08-14-ardour-inf-forensics.md 0 → 100644
---
log: 2026-08-14
title: "The -inf faders: read-only forensics on Tidal Live.ardour, mid-gig"
date: 2026-08-14
task: "n/a (forensics request, no board task)"
tags: [ardour, mixing, forensics, tooling]
shareable: true
---
## Cap (what & why)
Four times now, several `Tidal NN` faders in `~/Work/Sound/Ardour/Tidal Live/Tidal
Live.ardour` have shown up at -inf dB (6/12 today, 9/12 the three prior times), always
"fixed" by manually re-raising and saving. Nobody had checked whether this is a real bug
(automation override, active corruption) or just a faithful save of faders that happened
to be down. Read-only investigation, done live during a set — no writes to the session,
no process touched.
## Manœuvre (how)
Reused `tools/check-mix.py`'s XML paths (`Route > Processor[name=Amp,type=amp] >
Controllable[name=gaincontrol]` for the linear gain; `Automation/AutomationList` for
automation state; `MuteMaster`, `IO`/`Connection` for mute/routing). No git repo under
`~/Work/Sound/Ardour/` — history had to come from Ardour's own `.bak` rotation and the
`.history`/`.history.bak` undo log. Compared three real snapshots of the 12 `Tidal NN`
gain values: `Tidal Live.ardour.premap-20260729` (2026-07-29, oldest artifact on disk),
`Tidal Live.ardour.bak` (the save immediately before the current one), and `Tidal
Live.ardour` (current, saved live at 21:18:43 while this investigation ran).
## Prise (findings / artifacts)
**1. Automation override — ruled out.** Every `Tidal NN` route's gain
`AutomationList` reads `state="Off"` with **zero automation events** (`n_events=0` on
all 12). Ardour's automation states are `Off / Write / Touch / Play / Latch`; none are
`Play`. There is no automation lane that could push a value on transport roll — the
`gaincontrol` `value=` attribute is the only thing driving the fader. Example (Tidal
02): `<AutomationList automation-id="gain" ... state="Off" />`,
`<Controllable name="gaincontrol" ... value="0" />`.
**2. No shared control path.** `<VCAManager>` and `<RouteGroups>` are both empty; every
`Tidal NN` route has `route-group=None`. Each track's gain is fully independent — there
is no group/VCA master that could zero several tracks in one action, which rules out a
single-event mechanism behind "many faders down at once."
**3. -inf is exactly `0.0`, nothing anomalous.** All -inf tracks store `value="0"` on
`gaincontrol` (linear), never `NaN`/negative/denormal. This is what a fader pulled fully
down produces — not a parse artifact or corrupted float.
**4. The dead-track SET moved during tonight's own set, mid-investigation.** PLN's
report for tonight was dead = {02,03,05,07,08,12}, alive = {01,04,06,09,10,11}. Reading
the session live just now (saved 2026-08-14 21:18:43, literally while this forensics ran)
shows dead = {01,02,03,04,06,07,08,12} (8/12), alive = {05,09,10,11}. Three tracks
reported alive (01, 04, 06) had since gone to -inf; one reported dead (05) had come up to
-18.5 dB. The composition changed **within the same gig**, between the report and this
read.
**5. Save-to-save diff confirms independent, non-uniform drift.** `Tidal
Live.ardour.bak` and `Tidal Live.ardour` are Ardour's own before/after pair from the
current save (mtimes 21:18:43.117 vs .137, i.e. same save operation); `Tidal
Live.history.bak` mtime is 21:18:21 — ~22s before the save that produced the current
pair, giving a real inter-save timestamp. In that ~22s window, 4 of 12 tracks moved
independently, in both directions, to non-round values:
| track | .bak (prior save) | .ardour (now) |
|---|---|---|
| Tidal 05 | -inf | **-18.5 dB** (came up) |
| Tidal 08 | -12.3 dB | **-inf** (went down) |
| Tidal 10 | -23.4 dB | **-10.5 dB** (came up) |
| Tidal 11 | -inf | **-16.1 dB** (came up) |
The other 8 tracks were unchanged across that same window. This is the fingerprint of a
human riding faders (LCXL, MIDI-learned per `check-mix.py`'s own docstring) live, not a
bug rewriting values on save or load — a corruption mechanism would be expected to act
uniformly or on a fixed trigger, not drift a random subset by arbitrary non-round
amounts every ~20 seconds.
**6. No structural correlate for "dead" vs "alive."** Checked mute (`MuteMaster
muted="0"` on all 12, always), routing (`reaches_master() == True` on all 12), route
`active="1"` on all 12, and record-enable (`None`/not set on all 12) — no difference
between the dead and alive groups on any of these axes, in any of the three snapshots.
Route `id=` attributes are identical across `.ardour`/`.ardour.bak` (170, 240, 380, 450,
520, 590, 660, 730, 800, 870, 940, 17945) — same 12 routes throughout, none recreated.
**7. `.history` has no gain entries at all.** 12 `<UndoTransaction>`s total, spanning
2026-05-22 through 2026-08-10 (`capture` and `move marker` only) — Ardour does not push
control-surface parameter changes through undo history, so this file can't date
individual fader moves. It does confirm nothing GUI-edited the gain since 08-10; all
movement since is consistent with control-surface (physical fader) input, which bypasses
undo by design.
## Sel (the shareable learning)
**Verdict: faithful restore of a save taken mid-motion — not automation override, not
active corruption.** The strongest single fact: the *set* of silent tracks changed
twice within one evening (once between PLN's report and this read, and again between the
`.bak` and current save 22 seconds apart), with different tracks moving by different,
non-round amounts in different directions. A code bug that zeroes faders would not
produce that texture — it would hit the same tracks, or all of them, or move them to a
uniform poisoned value. What's on disk is exactly what physical faders sitting at
whatever position they were in at the instant of `Session::save_state()` would produce.
Point 1 (automation state, the task's highest-priority check) is a clean, unambiguous
negative: `state="Off"`, `n_events=0`, on every route, every snapshot.
## Hameçon (hook)
"We've fixed the -inf bug four times" and there was never a bug — there's a session file
that photographs whatever the hands were doing at save-time, and four times the photo
landed mid-dip. Ardour is a faithful narrator; the story it's telling just isn't the one
being assumed.
## Sillage (what it unlocks)
Not a code fix. If this verdict holds up, the actionable surface is *when/what gets
saved and reloaded*, not the session format — e.g. never boot a set from a save taken
mid-performance, and/or have `check-mix.py` gate the *specific file about to be loaded*
before a set starts (it already exists and already does exactly this check; the gap is
procedural, not tooling). Not proposing that gate here since it wasn't evidenced by this
investigation, only flagging that the evidence points away from needing new code.
armada/tasks/2026-08-14-corpus-triage.md 0 → 100644
---
log: 025
title: "51 broken tracks are actually 22 — the harness was the biggest bug"
date: 2026-08-14
task: "#112"
tags: [tooling, triage, silent-eval, corpus, livecoding]
shareable: true
---
## Cap (what & why)
#112 measured `live/`: **51 tracks BROKEN (don't compile), 21 CRASH (compile, throw
when queried)**, of 694. Nobody had split those 51 into root causes, so nobody knew
if it was one bug fifty times or fifty separate bugs. Read-only triage, done while
PLN performs — no `.tidal` file touched, no rig, no MIDI.
## Manœuvre (how)
The exact 51+21 dataset already existed: `docs/2026-07-31-corpus-compile-failures.md`,
produced by `tools/silent-eval.py $(git ls-files '*.tidal')`. Cross-checked it's still
current — `git log --since=2026-07-31 -- live/` touched 19 files, none of them in the
51+21 list (the touched files are all setlist tracks, which score 0/0). Grouped every
`live/` entry by the shape of its GHC error, then for each shape read the actual
`.tidal` source and `BootTidal.hs` to find out *why*, instead of trusting the verdict
label.
## Prise (findings / artifacts)
| class | count | fix kind | example |
|---|---|---|---|
| **A — dup `let`, harness-only** | 24 (47% of 51) | mechanical (fix the tool) | `live/ambient/weird.tidal` |
| **B — bare binding, harness-only** | 3 (6%) | mechanical (fix the tool) | `live/hip/bocal.tidal` |
| **C — helper past the anchor, harness-only** | 2 (4%) | mechanical (fix the tool) | `live/collab/louis/d_accord.tidal` |
| **D — syntax typo (BROKEN)** | 7 (14%) | mechanical (1-token edit) | `live/hip/instru/envahisseur_celtique.tidal` |
| **E — undefined reference** | 9 (18%) | judgement / archive (#47) | `live/mood/sad/bass_vibes.tidal` |
| **F — type mismatch** | 6 (12%) | judgement | `live/midi/nova/instruments/8box.tidal` |
| **G — CRASH: bad mini-notation string** | 21 (separate denominator) | mechanical (1-token edit) | `live/FOSDEM/after.tidal` |
**A+B+C = 29 of the 51 (57%) are not track bugs at all.** They are the harness
misreading code that plays fine live. Real BROKEN count: **22**. Real total needing a
human: 22 + 21 CRASH = 43, not 72.
### A — dup `let` across blocks (24 files, the headline)
`silent-eval`'s `track_lets()` scrapes every line starting with `let ` and dumps them
all as top-level Haskell bindings. PLN's actual workflow re-evaluates a helper as a
track evolves — `let g = (# djf …)` then later `let g = (# djf 0.355) -- FIXME
MANUAL` — which GHCi accepts fine (later binding shadows earlier, no error). A
Haskell **module** cannot declare the same name twice, so the harness reports:
```
<track>:365:1: error:
Multiple declarations of ‘g’
Declared at: <track>:364:1
<track>:365:1
```
Verified by grepping every one of the 24 files for `^let NAME`: all 24 have the exact
same shape — two or more `let SAME_NAME = …` lines in one file (`weird.tidal`,
`epilog.tidal`, `nano_rain.tidal`, `zelda.tidal` even redefine with different arity).
`live/boeuf/algorythm/first_jam.tidal` and
`live/boeuf/algorythm/fdlm2022/intro_parvagues.tidal` each redefine `g` **four times**
— this is PLN's normal iteration history, not damage.
Fix: `track_lets()` should keep only the **last** occurrence per name (mirrors GHCi's
own shadow-latest-wins semantics), same discipline the tool already applies to
BootTidal-vs-track collisions — just not to track-vs-track ones.
### B — bare top-level binding, no `let` (3 files)
GHCi accepts `name = expr` at the prompt as an implicit `let` — no keyword required.
`track_lets()` only matches lines starting literally with `"let "`, so it silently
drops these:
```
live/hip/bocal.tidal:3: scaleBocal = (scale "aeolian" (slow 4 $ "<0 <2 3>>"))
live/boeuf/samedi_confine_extra.tidal:3,39: prog = "<0 0 0 0 2 2 4 4>"
live/midi/nova/once_upon_a_loop.tidal:4: lname = pS "lname"
```
Verdict was `Variable not in scope: scaleBocal` / `prog` / `lname` — the definition
is right there in the file, one keyword away from being seen.
### C — helper defined after the extraction anchor (2 files)
`helper_block()` dedents *one* `let` block from `BootTidal.hs`, bounded by the anchor
`let -- DPV specific parameters` (line 244) to its first `:}` (line 579). `jchord` and
`jroot` are real, working, top-level `BootTidal.hs` functions — at **lines 612 and
613**, past the extraction window:
```
live/collab/louis/d_accord.tidal:42: Variable not in scope: jchord :: t0 -> Pattern ValueMap
live/collab/cookie/maudite_soit_la_guerre.tidal:368: Variable not in scope: jchord :: t1 -> Pattern a
```
Both tracks use `jchord` correctly; it works live. Fix: extend `helper_block()` (or
add a second anchor) to also import BootTidal.hs top-level defs past line 579.
### D — syntax typo, real bug (7 files)
Single stray character or misplaced token, exactly pinpointed by GHC — no ambiguity,
no musical judgement needed:
```
live/hip/instru/envahisseur_celtique.tidal:36 # gain 1.3S -- stray "S"
live/midi/nova/party/electro_blues.tidal:72 # room 0.4² -- stray "²"
live/midi/nova/grunge/le_bruit_des_bots.tidal:41 gqin é -- GHC suggests "gain"
live/midi/nova/lounge/invoque_ete.tidal:107 d9 $ f1 $ m -- GHC suggests fb/fm1
live/chip/game_on.tidal:386 orb5_21 = idcp $ "bass\n -- unterminated string
live/midi/nova/breaks/break_90s.tidal:22 . (<| "k k k …") -- parse error on '.'
live/dnb/video_live.tidal:163 operator '.' needs lower precedence than '$'
```
### E — undefined reference, needs PLN (9 files)
References a name that exists **nowhere** in the file (checked with `grep`, not just
GHC's verdict) and isn't a current `BootTidal.hs` helper either. Two shapes: bare
single-letter filter/mute helpers (`g`, `gF`, `gM`) from before the numbered-helper
convention (`gF1`…`gF7`, `gM1`…`gM12` — see `BootTidal.hs:429` comment on the
rename), or a musical pattern (`chords`, `melody`, `prog`) that's referenced but never
bound anywhere in the file:
```
live/mood/sad/bass_vibes.tidal -- g (pre-numbering helper)
live/collab/raph/partir.tidal -- g
live/midi/nova/breaks/solar.tidal -- g
live/midi/nova/breaks/its_about_time.tidal -- gM
live/boeuf/canard_breake.tidal -- gF
live/midi/nova/dnb/BreakBass.tidal -- chords
live/midi/nova/feu.tidal -- chords
live/midi/nova/party/phunk.tidal -- prog
live/midi/nova/computer_riddub.tidal -- melody
```
Can't fix mechanically — need PLN to say which numbered helper he meant, or that the
missing pattern is exactly that: missing, and the track should go to task #47
(archive dead tracks).
### F — type mismatch, real bug (6 files)
Function-arity or type errors — `cF`/`whenmod`/`slice` applied to too few arguments,
`Double` where `Note` was expected. Genuine logic bugs in the track's own composition;
fixing the missing argument's *value* needs musical intent:
```
live/midi/nova/instruments/8box.tidal
live/chill/atm/break_blue.tidal
live/midi/nova/dubstep/break_my_new_synths.tidal
live/midi/looper/god_money.tidal
live/midi/hello_world.tidal
live/hardcore/jambon.tidal
```
### G — CRASH: bad mini-notation inside a string (21 files, separate denominator)
All 21 are the same species as class D, just caught later: valid Haskell string
literal, invalid when Tidal's *own* mini-notation parser reads it at query time —
which is why GHC waves it through and it only throws when queried:
```
live/FOSDEM/after.tidal "[d d] <d d d*2 d*4>]" unexpected ']'
live/bogdan.tidal "reverbkick(<2 <4 8>>,4):1" unexpected ':'
live/snake.tidal "0 [7|1]>" unexpected '>'
live/chill/dim_blue.tidal "c4'major'<c4 f4 b3 c4>'six"
live/techno/feeling_electric.tidal "<0,0.05 .. 0.3 0.3,0.05 .. 0>" unexpected ' '
```
(16 more, same shape — stray bracket/colon/comma or a `..` range with a mismatched
comma-then-space, one per file.)
## Sel (the shareable learning)
**57% of "the corpus doesn't compile" was the *checker* not compiling, not the
corpus.** The tool that exists to separate signal from noise (`silent-eval.py`) had
three of its own blind spots, each shaped exactly like the three traps this task was
briefed with: a local `let` can shadow a boot definition (true — but the tool never
considered a local `let` shadowing *another local let in the same file*, which is
PLN's actual editing pattern); a reported line belongs to the stream group, not
necessarily the guilty block (true here too — "line 364 vs 365" is the *harness's*
generated boilerplate seam, not the track's structure); and an error being real
doesn't mean the fix is the file. Read every error before believing it — the doc this
session started from said exactly that, in its own previous round, and it was still
worth re-deriving by hand rather than trusting the label.
## Hameçon (hook)
Twenty-four tracks accused of "does not compile," and the crime scene in every one
is PLN doing completely normal livecoding — redefining a filter macro mid-session,
the way anyone iterates on a knob. The bug wasn't in the music. It was in a checker
that had never seen its own author work.
## Sillage (what it unlocks)
- Fixing A+B+C in `tools/silent-eval.py` retires 29/51 BROKEN entries with **zero
`.tidal` edits, zero risk** — pure tooling, safe to do mid-set or any time.
- After that, class D (7) + class G (21) = 28 files are still mechanical, one-token
fixes with the exact character already pinpointed — a good batch for a calm
session with `git diff` review per file, still no musical judgement required.
- Classes E (9) and F (6) are the real backlog: 15 files that need PLN's ear or a
ticket into #47 (archive dead tracks). That's the honest number to plan around,
not 51.
## Recommended order of attack
1. **Fix the harness first** (`tools/silent-eval.py`: dedupe `track_lets()` by name
keeping the last occurrence; also scrape bare `NAME = …` top-level lines; extend
`helper_block()` past line 579 for `jchord`/`jroot`). One tooling change, retires
29 files, touches no track, provably safe to ship anytime — including mid-gig.
2. Batch the class-D + class-G one-token fixes (28 files) — mechanical, low-risk,
good background/downtime work.
3. Bring classes E and F (15 files) to PLN as a judgement list, likely resolved
mostly by archiving into #47 rather than repair — several reference a helper
naming convention (`g`/`gF`/`gM`) that's been retired for a while.
armada/tasks/2026-08-14-master-format-audit.md 0 → 100644
---
log: 025
title: "Probe, never assume — the 192 kHz audit"
date: 2026-08-14
task: "#144 (192 kHz loudnorm defect audit)"
tags: [mastering, tooling, salvage, opal2026, montreuil26]
shareable: true
---
## Cap (what & why)
Task #144 established two silent format bugs in our mastering tool: `loudnorm`
leaves the render at 192 kHz unless `-ar` is forced, and `flac -c copy` keeps the
*source* file's STREAMINFO (so a header can claim the wrong duration/rate). Log
020 (2026-08-12) caught both on OPAL-26 the same afternoon. This pass audits
every released/candidate master under `Prod/` plus the live SoundCloud catalog
to see how far the 192 kHz defect actually spread, and whether anything already
public is affected. Done cold — `ffprobe` only, no re-encoding, no rig contact,
because PLN was performing live during the audit.
## Manœuvre (how)
`ffprobe -show_entries stream=sample_rate,bits_per_raw_sample,channels` (+ format
duration) across every FLAC/WAV/MP3 under the Opal26 and Montreuil26 master
trees, the Take95 Bandcamp candidate, and — critically — `sc_catalog/audio/`,
which holds masters *recovered from live SoundCloud* (numeric SC track-ID
filename prefixes = confirmed public). Cross-checked local pre-upload masters
against their SC-recovered counterparts to see whether the bug travelled.
Also diffed per-track durations against plausible track length to re-test the
log-020 "FLAC header claims the whole set" bug specifically.
## Prise (findings / artifacts)
**Verdict table**
| release | files | sample rate(s) | bit depth | verdict |
|---|---|---|---|---|
| Take95 (`Tidal/output/Take95/`, master + 11 tracks + 11 mp3) | 23 | 48000 Hz, uniform | 24-bit (flac) | **clean** — `master.log` explicitly confirms "2 ch @ 48000 Hz" |
| Opal26_master `tracks/`, `tracks_v3/`, `tracks_v4_club/`, `tracks_v4_streaming/` | 60 | 48000 Hz, uniform | 24-bit | **clean** — current candidates |
| Opal26_master top-level, current (`archive_24bit.wav`, `SunsetForest_club.flac`, `SunsetForest_streaming_48k.flac`, `SunsetForest_v4_club.flac`, `SunsetForest_v4_streaming.flac`) | 5 | 48000 Hz | 24-bit | **clean** |
| Opal26_master top-level, superseded (`premaster_14.flac`, `SunsetForest_streaming.flac`) | 2 | **192000 Hz** | 24-bit | **defective, but superseded** — both have a corrected sibling on disk with a later mtime; risk is only "grabbed by mistake later" |
| Montreuil26_master top-level (`club`, `streaming`, `streaming_filled`, `streaming_final`) | 4 | **192000 Hz, uniform** | 24-bit | **defective — the only version on disk**, no fixed sibling exists |
| Montreuil26_master `tracks_bandcamp/` (15 per-track splits, Bandcamp-ready) | 15 | **192000 Hz, uniform** | 24-bit | **defective — Bandcamp release candidate**, needs re-render before shipping |
| `sc_catalog/audio` — Live39c3 House of Tea Party (SC id 2238245696) | 1 | **192000 Hz** | 24-bit | **defective — CONFIRMED PUBLIC on SoundCloud right now** |
| `sc_catalog/audio` — LiveMontreuil Algorave III (SC id 2326200872) | 1 | **192000 Hz** | 24-bit | **defective — CONFIRMED PUBLIC on SoundCloud right now** |
| `sc_catalog/audio` — remaining 33 flac/mp3 files | 33 | 44100 or 48000 Hz, each internally consistent | 16- or 24-bit (era-dependent) | **clean** |
| Prod top-level local masters (`39c3_HoT_master.flac`, `..._master_crowd.flac`, `39c3_TOILETRAVE_master.flac`) | 3 | **192000 Hz** | 24-bit | **defective — the local source of the confirmed-public bug** |
**Root-cause confirmation**: `39c3_HoT_master.flac` (local, 192 kHz) matches the
publicly-live `2238245696_Live39c3_House_of_Tea_Party.flac` (also 192 kHz) exactly
— the bug was baked in locally and shipped as-is. The `39c3_TOILETRAVE_master.flac`
local render is also 192 kHz, but its SC upload happened to go out as MP3
(2240961797, 44100 Hz) — MP3 structurally can't carry 192 kHz, so that one track
escaped by accident of format, not by the pipeline being fixed.
**Within-release consistency**: no mixed-rate album found. Montreuil26 is
uniformly 192 kHz (masters + all 15 tracks) — wrong everywhere, but not a
partial/mixed defect. Opal26's *current* candidates are uniformly 48 kHz; the
192 kHz files there are dead-but-not-deleted intermediates from the Aug 12
incident, sitting next to their fixed replacements.
**Header-lie cross-check (the `flac -c copy` half of #144)**: re-tested by
diffing per-track durations against plausible track length instead of trusting
a single global read. Opal26 tracks (e.g. "01" at 524–530s vs "15" at
225–252s across all four track dirs) and Montreuil26 tracks (362s vs 424s)
each report a distinct, plausible per-track duration — none show the "whole
set" duration log 020 caught. **That half of the bug looks fixed in every file
checked this pass**; only the sample-rate half is still live.
**Bit depth / channel sanity**: no mono-should-be-stereo, no 8-bit, nothing
truncated. The 16-vs-24-bit split in `sc_catalog` tracks by era (older
SoundCloud uploads are 16-bit, current pipeline outputs 24-bit) — not a defect.
**Hard-clipping (OPAL-26 precedent)**: not re-tested this pass — confirming
clip state needs a decode-based peak scan, which is more CPU than a STREAMINFO
read and was explicitly out of scope while PLN is performing. No new evidence
either way; flagged as a follow-up, not a finding.
## Sel (the shareable learning)
The 192 kHz bug wasn't a one-off — it's the tool's *default* behavior any time
`-ar` isn't threaded through, and it reproduced on at least three separate
render runs after the one log 020 already caught and "fixed." Two of those
renders are sitting live on SoundCloud today. The fix that matters isn't
re-rendering the two known files — it's making `-ar 48000` (or whatever the
target is) impossible to omit in the shared render path, because every
standalone `ffmpeg`/`sox` invocation that bypasses it will reintroduce the same
bug with zero error output.
## Prioritised action list
1. **Re-render and re-upload** (already public, confirmed defective):
- Live39c3 House of Tea Party (SC 2238245696) — local source is
`Prod/39c3_HoT_master.flac`
- LiveMontreuil Algorave III (SC 2326200872) — local source not yet
identified precisely in this pass (see gaps below)
2. **Re-render before shipping** (not yet public, but the only copy on disk is
defective): Montreuil26_master's 4 top-level masters + all 15
`tracks_bandcamp/` files — this is the active Bandcamp release candidate.
3. **No action needed**: Opal26_master's current tracks (`tracks_v4_*`) and
top-level masters are already clean; the 192 kHz siblings there
(`premaster_14.flac`, `SunsetForest_streaming.flac`) are dead weight —
worth deleting so nobody grabs the wrong one later, but not a release risk
as-is. Take95 is clean end to end.
## Gaps — what this pass could NOT confirm
- Did not locate the exact local render that produced the public
`LiveMontreuil_Algorave_III` (SC 2326200872) upload — `sc_catalog` only holds
the recovered-from-SC copy, and it doesn't obviously correspond 1:1 to the
in-progress `Montreuil26_master/` Bandcamp package (different pipeline, README
there describes work still in the mastering-tooling build-out per task #009,
not a shipped release). Whether that SC upload predates the current
`Montreuil26_master/` rebuild, or was made from it, is unconfirmed.
- Did not check `content/lives/2026/` for either OPAL or Montreuil — the
directory is empty, so neither gig has a canonical published-metadata entry
yet on the site; treating both as pre-release for the *website* even though
the SC-recovered file proves at least one Montreuil recording is public
*somewhere*.
- Did not probe the `*_data/eff/*` per-orbit stem renders under `Prod/`
(dozens of directories, not final masters) or the remaining ~25 `sc_catalog`
mp3 files individually beyond the one spot-check — mp3's rate ceiling makes
this defect structurally impossible there, so risk is low, but it is
unverified, not verified-clean.
- Did not re-run the FLAC frame-level clipping/peak check from log 020 on any
file in this pass — decode-based, deliberately skipped given the live-rig
constraint.
- Could not confirm whether Take95 was ever actually pushed to Bandcamp (found
no upload log); it exists as a clean local candidate either way.
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