port: the oracle capture does not contain the intro -- a controlled negative

The Decoder took the capture I asked for and described it as the full mix, the
movie's WMA track plus the three XMA streams. It contains none of them.

Envelope cross-correlation, sliding with overhang, normalised over the overlap,
minimum 30 s of overlap so a short window cannot win on an edge. Against the ADV
bed, against each of the three voice streams, against BGM_103 and against S00A,
every pairing is a PLATEAU rather than a peak: best-to-runner-up margins of
0.001-0.016. The margin is the number that matters, not r.

Three controls, because a negative from an uncontrolled instrument is worthless:

  the instrument finds matches on this data -- bed vs bed r=1.000 margin +0.115,
    voice stream 2 vs stream 3 r=1.000 margin +0.300;
  my reference really is the movie -- the .ogv transcode against the disc's own
    ADV.wmv, r=1.000 margin +0.114, so a miss is not my transcode;
  drift is excluded -- a stretched playback would still match locally with the
    best lag climbing monotonically, and 5 s windows give 4.95, 15.30, 119.35,
    50.75, 29.35, 83.95 s, scattered across the movie.

WHAT IT IS has been handed back rather than guessed. It is 70 s of something,
all six channels carrying signal at RMS about -27 dBFS, matching nothing this
port exports. Diagnosing it is the other side of the wall.

One measurement that may help: split as 5.1, channels 3 and 6 are BYTE-IDENTICAL
-- same MD5, not merely the same peak and RMS. An exact duplicate pair inside a
six-channel surround output is consistent with the Decoder's own warning that the
6-channel frame is Xenia's hardcoded kFrameChannelsDefault rather than the
guest's request, and weakens any reading of that file as evidence of a 5.1 mix.

THE VOICE EXPORT IS UNCHANGED: still one stream of three, still marked red in the
manifest, the console line and authored/audio.json. A failed measurement should
change nothing, and what would have been wrong is treating an expensive recording
as an oracle because it was expensive.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-29 16:01:10 +00:00
parent 8fba7944d4
commit 018e879907
3 changed files with 60 additions and 1 deletions

BIN
adv-game-output-6ch.wav Normal file

Binary file not shown.

View File

@@ -114,7 +114,7 @@ HANDOFF.
| P6 BGM — the sub-wave count | **is a music bank's LEADING REGION a stem, or a decoder artefact?** | Q10 | 🔴 **HANDOFF and the decoders disagree, and P6 ships the disagreement.** `media::sound_bank_riffs("BGM_103.slb")` returns **three** sub-waves; HANDOFF Q10's census says a music bank is *"exactly two waves of identical duration (32/32 banks on the disc)"*. The third comes from `slb.rs:380` `to_xma_riffs`, whose hybrid branch emits a leading headerless packet region ahead of the `RIFF` waves — and `docs/re/REFUTED.md` already records that region as what makes `BGM_106``BGM_109` *"break the two-wave rule"*. Derived at HANDOFF `9ca1eb5`. **The exporter sums all three and writes a manifest warning**, because choosing which sub-wave to drop is a decoding question and MISSION §2 forbids this exporter answering one. So the menu currently plays a sum of three things where the census predicts two. What settles it: whether that leading region carries music. Raised with the Decoder 2026-08-29. |
| ~~P3 — the plate's ONSET~~ | ~~visible 2.13 s after settle, or group starts then?~~ | Q2 | ✅ **resolved 2026-08-29, and the answer is AUTHOR NOTHING.** The port's refutation held and produced a better answer than either option it offered. Correction at `5b0a6e6` on `auto/no-disc-and-menu-captures`: **both builds run on one clock, started together**, and the plate arrives at its own declared `t=238`. Checked against this export rather than taken on trust — build 4's visible build-in ends at `t=118` (`pteff01`, `pteff02`, `ptlogoall_eff` finish together), `ptbtn00` reaches alpha 255 at `t=238`, difference **120 units = 2.000 s**, against a measured 2.138 / 2.132 s at an emulator presenting 28.1 fps rather than 30. The 2.13 s constant is **deleted**. |
| ~~P3/P5 — `settle_time()`~~ | ~~`rest.t` is not when a screen settles, and the port's sequencer uses it~~ | — | ✅ **MEASURED 2026-08-29 and the row was HALF WRONG — mine.** The Decoder took it on a cold profile with no shader cache (`auto/no-disc-and-menu-captures` at `4bd4779`, `docs/re/boot-settle-times-measured.md`). The principle holds: the title's `rest.t` is 251 units = **4.183 s** where its art finishes at ~2 s. **But "everything the sequencer paces off that landmark is therefore late" does not.** Measured the port the way the game was measured — visible span, `--film` at 4 fps — the publisher wordmark runs **4.25 s** against the game's 4.297/4.604/4.370 and the developer logos **3.50 s** against 3.508/3.503/3.366. Dead on. My earlier reading compared the port's *arrival-to-arrival* timestamps against the game's *visible spans*, which differ by the exit ramp plus the black hold — the whole of the discrepancy I was about to chase. `rest.t` is still the wrong landmark; its blast radius is `_script_settled` waiting longer than it needs to, which is a slow test and not a wrong frame. `dwell_seconds` stays `null`, now for a measured reason. 🔴 **Do not author an Ⓐ→menu dwell**: it measures 3.763 s and contains a 1.53 s guest load stall, third independent reproduction. 🟡 Menu build-in 0.531 s and Ⓑ→title 0.482 s rest on one run and are not authored; the port is within ~0.1 s of both from the disc. |
| P4/P7 — the voice export is INCOMPLETE | **what are the three concurrent streams, and how do they combine?** | — | 🔴 **the premise of every earlier row here was refuted by the RUNNING GAME, 2026-08-29.** Canary's `--xma_param_probe` shows the game decoding **all three streams concurrently** in three XMA contexts, byte sizes matching the disc payloads exactly (1 294 336 / 1 118 208 / 1 171 456 against 1 294 396 / 1 118 268 / 1 171 516). So they are **not** three presentations of one take, there is no "which one" to answer, and the export — which ships one — is **missing two streams the game plays**. ⚠️ **The failure sounds like success**: one stream is clean audible dialogue. Stated as a top-level manifest warning per movie, on the console, and in `authored/audio.json`. **Behaviour deliberately unchanged**: an equal-gain `1/n` sum of channel pairs is not a downmix either (MISSION §6 pins an explicit matrix for exactly this reason) and summing cost `S00A` 6.02 dB when one stream was silence — swapping one guess for another is what produced this row twice. 🟡 "They are 5.1" is the Decoder's **hypothesis**: three stereo streams is six channels and N stereo streams is how XMA carries multichannel on the 360, but all three declare `ChannelMask = 0x0002` identically, which argues against distinct roles. **What settles it: a recording of the game's own output over `ADV` through the PulseAudio null sink** — candidate combinations can then be correlated against what the game played. Asked 2026-08-29, emulator was up. |
| P4/P7 — the voice export is INCOMPLETE | **what are the three concurrent streams, and how do they combine?** | — | 🔴 **the premise of every earlier row here was refuted by the RUNNING GAME, 2026-08-29.** Canary's `--xma_param_probe` shows the game decoding **all three streams concurrently** in three XMA contexts, byte sizes matching the disc payloads exactly (1 294 336 / 1 118 208 / 1 171 456 against 1 294 396 / 1 118 268 / 1 171 516). So they are **not** three presentations of one take, there is no "which one" to answer, and the export — which ships one — is **missing two streams the game plays**. ⚠️ **The failure sounds like success**: one stream is clean audible dialogue. Stated as a top-level manifest warning per movie, on the console, and in `authored/audio.json`. **Behaviour deliberately unchanged**: an equal-gain `1/n` sum of channel pairs is not a downmix either (MISSION §6 pins an explicit matrix for exactly this reason) and summing cost `S00A` 6.02 dB when one stream was silence — swapping one guess for another is what produced this row twice. 🟡 "They are 5.1" is the Decoder's **hypothesis**: three stereo streams is six channels and N stereo streams is how XMA carries multichannel on the 360, but all three declare `ChannelMask = 0x0002` identically, which argues against distinct roles. 🔴 **The first attempt at that capture FAILED and the failure is measured, not suspected.** `adv-game-output-6ch.wav` (shared `1788018994-16f9d19d90b8`, taken at `68aa192`) contains neither the movie's bed, nor any of the three voice streams, nor `BGM_103`, nor `S00A`: every pairing is a plateau with a best-to-runner-up margin of **0.0010.016**, against controls that fire at r=1.000 with margins of +0.114 to +0.300 on the same instrument and the same data. Drift is excluded — 5 s windows give best lags of 4.95 / 15.30 / 119.35 / 50.75 / 29.35 / 83.95 s, scattered rather than monotonic. What that capture *is* has been handed back to the Decoder rather than guessed. **What still settles it: a recording of the game's own output over `ADV` through the PulseAudio null sink** — candidate combinations can then be correlated against what the game played. Asked 2026-08-29, emulator was up. |
| ~~P3/P5 — the title plate~~ | ~~does the idle title show `PRESS Ⓐ`~~ | Q2 | ✅ **answered and TAKEN at this iteration.** `auto/no-disc-and-menu-captures` at `fb536df`, `docs/re/title-plate-delay-measured.md`, traces in `docs/re/data/plate-timing-run{1,2}.tsv`. It is the third case: build 4 alone, then the plate composited over it. ⚠️ The delay is timed from where build 4 **stops animating**, not from where it first appears — measured the other way the two runs differ by 0.48 s against 6 ms. `ScreenView` now draws two builds at once, as a second `ScreenView` in the same `SubViewport` rather than a subordinate screen inside one. The onset question above is what is left. |
| P3 — the plate's PULSE | **does the plate's focus record loop, and with what period?** | Q2 | ❔ **open, and the port's earlier reading of it was wrong.** The port had looked for the pulse in `ptbtn00`'s own group; `5b0a6e6` identifies it as the plate's **focus record** `ptbtn00f` — a glow ramping alpha `0x00``0x50` and back, t=6…105. Measured on the running game at 2.12 / 2.19 / 2.34 / 2.31 s, mean **2.24 s**. 🟡 **The port has not taken it.** Looping that record needs a period, and its group is 105 timed units plus the **authored** 24-unit exit ramp = 129 units = 2.15 s — composing an authored constant with a loop assumption to land on a measured number is tuning, not measuring. Separately: the port draws no focus record on `press_start` at all, because the screen has no `buttons` and nothing is focused, so *whether the game always draws it* is its own question. |

View File

@@ -3130,3 +3130,62 @@ as facts about **channels**: 0.60 × with the residual 26.8 dB down is what a
correlated channel pair at a lower level looks like, and a silent channel is an
unused one. Nothing measured here is retracted. What is retracted is every
sentence that called them *presentations*.
## 🔴 The oracle capture does not contain the intro — a controlled negative
The Decoder took the capture I asked for — `adv-game-output-6ch.wav`, 70.2 s,
6 ch, 48 kHz, shared as `1788018994-16f9d19d90b8`, taken at `68aa192` — described
as *"the FULL mix, the movie's own WMA track plus the three XMA streams"*.
**It contains none of them.** Envelope cross-correlation, sliding with overhang,
normalised over the overlap, minimum 30 s of overlap so a short window cannot win
on an edge:
| capture ch | against | best *r* | runner-up | margin | |
|---|---|---|---|---|---|
| c0 | `ADV` bed | 0.361 | 0.359 | **+0.003** | no match |
| c1 | `ADV` bed | 0.407 | 0.403 | +0.004 | no match |
| c0 | voice stream 1 / 2 / 3 | 0.42 / 0.26 / 0.27 | — | ≤ +0.006 | no match |
| c1 | voice stream 1 / 2 / 3 | 0.47 / 0.34 / 0.34 | — | ≤ +0.006 | no match |
| c0 | `BGM_103` (menu bed) | 0.271 | 0.260 | +0.011 | no match |
| c0 | `S00A` | 0.351 | 0.349 | +0.002 | no match |
**The margin is the number that matters**, not *r*. A match has a *peak*; these
have a *plateau* — best and second-best differ by 0.0010.016 across every
pairing, which is what a statistic does when no alignment exists.
### Three controls, because a negative from an uncontrolled instrument is worthless
1. **The instrument finds matches on this data.** `bed` vs `bed` → r = 1.000,
margin **+0.115**. Voice stream 2 vs stream 3 → r = 1.000, margin **+0.300**.
2. **My reference really is the movie.** The `.ogv` transcode against the disc's
own `ADV.wmv` → r = 1.000, margin **+0.114**. So a failure to match is not my
transcode.
3. **Time drift is ruled out.** A stretched playback would break a long
correlation while still matching locally, with the best lag climbing
monotonically. Five-second windows of the capture slid over the whole bed give
best lags of **4.95, 15.30, 119.35, 50.75, 29.35, 83.95 s** — scattered across
the movie, not monotonic, and every margin ≤ 0.017.
### What I can say, and what I will not
**Said:** this capture cannot answer the channel-role question, and it is not the
intro's audio. **Not said:** what it *is*. It is 70 s of something, all six
channels carrying signal at RMS ≈ 27 dBFS, matching nothing this port exports.
Diagnosing it is the Decoder's side of the wall and I have handed it back rather
than guessing.
⚠️ **One measurement on the file that may help them.** Split as 5.1, **channels 3
and 6 are byte-identical** — same MD5, not merely the same peak and RMS to six
decimals. An exact duplicate pair inside a six-channel "surround" output is
consistent with the Decoder's own warning that the 6-channel frame is Xenia's
hardcoded `kFrameChannelsDefault`, not the guest's request. It weakens, further,
any reading of that file as evidence of a 5.1 game mix.
### The voice export stays exactly as it is
Still one stream of three, still marked 🔴 in the manifest, the console line and
`authored/audio.json`. **The capture changed nothing**, which is the correct
outcome for a measurement that failed: the question is open, and it was open
before. What would have been wrong is treating a 70 s recording as an oracle
because it was expensive to obtain.