fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: take 2 is also unusable -- the sink is starved, 39.3 percent digital silence

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 16:19:46 +00:00
parent c479d59f52
commit 68b8f8db7f
1 changed files with 73 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
docs/re/audio-capture-channel-map-trap.md
View File

@@ -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.