From 68b8f8db7f0916ebb2585773a93de39de3159d6f Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 16:19:46 +0000 Subject: [PATCH] re: take 2 is also unusable -- the sink is starved, 39.3 percent digital silence The port could not find the movie bed or the cutscene voice in take 2 either, this time with a correlator they had rebuilt and calibrated in both directions after retracting the first one. Their negative stands. They named two readings: the capture path is still losing the guest s mix, or the guest is not emitting these sources -- and flagged the second as landing on them hard, because if the game never plays the .wmv s WMA track the port s intro audio has been wrong since P4. It is the first, and take 2 says so on its face: digital silence on all six channels 6557892 / 16680453 = 39.3 percent non-silent runs 10595, median 13.60 ms, longest 1.19 s silent runs 10596, median 3.94 ms burst+gap period about 17.5 ms, 57 Hz, duty cycle 60.7 percent The recording is chopped into 13 ms fragments separated by 4 ms holes, ten thousand times over -- a starved sink, PulseAudio filling underruns with silence. That destroys envelope correlation by construction, since the envelope is dominated by a 57 Hz chop unrelated to the content. The file s strongest periodicity is 5.2 s rather than BGM_102 s 37.487 s loop; the estimator was controlled first, recovering a synthetic 37.487 s loop as 37.480 and scoring non-repeating noise at 0.019. So the port s alarming hypothesis is NOT supported. Nothing here says the game fails to play the movie s audio; it says this capture cannot answer either way. A monitor sink cannot fix it: parec reads a monitor that advances at wall clock and substitutes silence, so every moment the emulator runs below real time is a hole and the timebase is warped non-uniformly. The route that would work is an internal tap at SDLAudioDriver::SubmitFrame, which sees every frame the guest produces in guest order with no wall clock -- same shape as xma_param_probe, additive and default-off. Not attempted this iteration. Also corrects a provenance number I got wrong: I told the port take 2 was 253.3 s when the shared file is 318.5 and the full recording 349. I read ffprobe while the recorder was still writing and copied the file before it finished, so the shared artefact is itself a truncation. Corrected provenance: movie 10-251, title 262-318, back to movie at 329 -- meaning the file includes the title screen, contrary to what I told them. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/audio-capture-channel-map-trap.md | 73 +++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/docs/re/audio-capture-channel-map-trap.md b/docs/re/audio-capture-channel-map-trap.md index 89ba5178..ed4309f0 100644 --- a/docs/re/audio-capture-channel-map-trap.md +++ b/docs/re/audio-capture-channel-map-trap.md @@ -149,3 +149,76 @@ Nothing at this boundary separates them. 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. + +--- + +## 🔴 TAKE 2 IS ALSO UNUSABLE — the sink is being STARVED, 39.3 % digital silence + +Take 2 passed the duplicate-channel check and carried a verified screen log, and +the port still could not find either the movie's WMA bed or the cutscene voice in +it — this time with a **calibrated** correlator (they had retracted their first +one: it scored 0.415 hunting a bed inside a synthetic mix that certainly +contained it, so it could not have found the target even when present). Their +rebuilt instrument passes both directions, and their negative on take 2 stands. + +They named the two readings: *the capture path is still losing the guest's mix*, +or *the guest is not emitting these sources*. ⚠️ They flagged the second as +landing on them hard — if the game never plays the `.wmv`'s WMA track, the port's +intro audio has been wrong since P4. + +**It is the first, and the capture says so on its face.** Take 2, measured +directly: + +| | | +|---|---| +| frames that are digital silence on **all six** channels | **6 557 892 / 16 680 453 = 39.3 %** | +| non-silent runs | **10 595**, median **13.60 ms**, longest 1.19 s | +| silent runs | **10 596**, median **3.94 ms** | +| burst + gap period | **≈17.5 ms → 57 Hz**, duty cycle **60.7 %** | + +The recording is chopped into ~13 ms fragments separated by ~4 ms holes, ten +thousand times over. That is a **starved sink** — PulseAudio filling underruns +with silence because the guest is not keeping the driver fed — and it destroys +envelope correlation *by construction*: the envelope is dominated by a 57 Hz chop +that has nothing to do with the content. + +✅ **So the port's alarming hypothesis is NOT supported by this capture.** Nothing +here says the game fails to play the movie's audio track. What it says is that +**this capture cannot answer the question either way**, and the earlier +autocorrelation hint pointed the same way — the file's strongest periodicity is +at **5.2 s** (r = 0.449), not at `BGM_102`'s 37.487 s loop, and 5.2 s is a beat of +the dropout schedule rather than anything musical. (Estimator controlled: it +recovers a synthetic 37.487 s loop as **37.480 s**, and scores non-repeating noise +at r = 0.019.) + +### Why the monitor-sink route cannot fix this + +`parec` reads a sink **monitor**, which advances at wall-clock rate and +substitutes silence whenever nothing is written. So any moment the emulator runs +below real time becomes a hole in the file, and the timebase is warped +non-uniformly — deleting the silences does not repair it, it just compresses time +unevenly. + +❔ **The route that would work is an internal tap**, and it does not exist yet: +`SDLAudioDriver::SubmitFrame` sees every frame the guest actually produces, in +guest order, with no wall clock involved. A cvar-gated WAV writer there would be +the same shape as `xma_param_probe` — additive, default-off, read-only — and +`/canary` is writable with `build-canary` available. **Not attempted this +iteration.** + +## 🔴 And a provenance number I got wrong + +I told the port take 2 was **253.3 s**. The file is **318.5 s**, and the full +recording on disk is 349 s. I read `ffprobe` *while the recorder was still +writing*, quoted the partial length, and copied the file before it finished — so +the shared artefact is itself a truncation of the run. + +The corrected provenance, from the same screen log: movie/other **t = 10 … 251**, +`title_noplate` at **262**, `title_plate` **277 … 318**, back to movie/other at +**329** (the documented title idle timeout). ⚠️ So the shared file **includes the +title screen**, which contradicts what I told them — I had said it sat wholly +inside the movie window. + +**A length in a provenance claim must be read from the finished artefact.** +Measuring a file that is still being written is the same class of error as +reading a level table that cannot see the defect. \ No newline at end of file