From a4c05bb96bff31346aa23bc4738687e05674db88 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 16:10:28 +0000 Subject: [PATCH] re: the capture recipe that passes, and a five-stream observation it turned up Take 2 of the ADV audio capture verified with the port s independent tools/port/check-capture -- six distinct channel MD5s, PASS -- run before sharing and deliberately using their tool rather than the hand that made the file. Records the recipe: sink channel_map set equal to Canary s own stream map and the same map passed to parec, so PulseAudio does no remapping; both of run-canary s mutes off; recorder started before the emulator so WAV t=0 precedes process launch; and a screenshot every ~11 s keyed to the recording s own clock. That last pair is what makes it self-checking, and both were the port s asks. Classified against the committed references, this run reads movie/other for t=10..251 and then title_noplate at t=262 (r=+0.998) and title_plate at 277/289 -- so the 253 s of audio sits wholly inside the movie with the title arriving just after. A miss is now diagnosable instead of ambiguous, which is the whole difference from take 1. Still the full mix: movie WMA bed plus voice, nothing at this boundary separates them. Also records something unexplained that the run turned up: the probe logged FIVE distinct XMA byte_size values, not three -- ADV s 1294336 / 1118208 / 1171456 plus 1150976 and 1269760. The extra pair belongs to some other cue, is not BGM_103 s two waves, and a pair is the shape bgm-two-stems documents for music banks. Untested. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/audio-capture-channel-map-trap.md | 40 +++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/docs/re/audio-capture-channel-map-trap.md b/docs/re/audio-capture-channel-map-trap.md index e66342b0..89ba5178 100644 --- a/docs/re/audio-capture-channel-map-trap.md +++ b/docs/re/audio-capture-channel-map-trap.md @@ -109,3 +109,43 @@ the capture chain and check that it comes back.** It was not run, an artefact wa published, and the person who found the defect was the one who could not see the instrument. ⚠️ **A capture is an instrument, not just an output** — the same scrutiny a parser or an estimator gets. + +--- + +## ✅ The capture that passes — recipe, and how it proves itself + +Take 2, 2026-08-29. Verified with the port's independent +`tools/port/check-capture` (six distinct channel MD5s → PASS) **before** being +shared, deliberately using their tool rather than the hand that made the file. + +```bash +MAP=front-left,front-right,front-center,lfe,rear-left,rear-right # Canary's own +pactl load-module module-null-sink sink_name=cap channels=6 channel_map=$MAP +parec -d cap.monitor --channels=6 --rate=48000 --format=s16le \ + --channel-map=$MAP --file-format=wav out.wav & # recorder FIRST +PULSE_SINK=cap SDL_AUDIODRIVER=pulseaudio \ + run-canary --mute=false … # both mutes off +``` + +Two properties make it self-checking, and both were the port's asks: + +* **The recorder starts before the emulator**, so WAV `t=0` precedes process + launch and the movie cannot fall outside the window by accident. +* **A screenshot every ~11 s, keyed to the recording's own clock.** Classified + against the committed references afterwards, this run reads `movie/other` for + **t = 10 … 251** and then `title_noplate` at **t = 262** (r = +0.998), + `title_plate` at 277/289. So the 253 s of audio sits wholly inside the movie, + with the title arriving just after it ends. **A miss would now be diagnosable + instead of ambiguous** — which is the whole difference from take 1. + +⚠️ It is still the **full mix** — the movie's own WMA bed plus the voice streams. +Nothing at this boundary separates them. + +## ❔ New, unexplained: this run decoded FIVE XMA streams, not three + +`--xma_param_probe` on the take-2 boot logs five distinct `byte_size` values: +`ADV`'s three (**1 294 336 / 1 118 208 / 1 171 456**) plus **1 150 976** and +**1 269 760**. The extra pair belongs to some other cue and is unidentified — +they are not `BGM_103`'s two waves (3 876 864 / 3 930 112). A *pair* is the shape +[`bgm-two-stems`](structures/bgm-two-stems.md) documents for music banks, so a +second bank is the first guess and it is untested.