Files
Sylpheed/docs/re/structures/voice-three-streams-are-concurrent.md
sylph-decoder 5fb64f3d31 re: the voice dialogue is in the CENTRE channel -- measured, not inferred
The 5.1 reading of a voice cue s three concurrent streams was recorded here as a
hypothesis with counter-evidence attached. It is now answered, by the port
fitting the disc s decoded streams against a clean capture of the game s own
6-channel output, with the instrument controlled first (known-present margin
+0.248, known-absent +0.005).

Speech-band margins put streams 2 and 3 at +0.305 and +0.307 on FC, r = 0.989,
above the known-present control, while stream 1 sits in the noise on every
channel. The low band mirrors it exactly: the movie bed at 0.76 to 0.84 on the
four corners against 0.32 on FC. Dialogue in the centre, bed in the corners.

The hypothesis was right for a reason the file could never have supplied.
ChannelMask reads 0x0002 on all three streams, so the header is not merely
unhelpful, it is actively misleading -- refusing to call it 5.1 from the header
was correct, and the oracle answered what the header could not.

Three limits recorded as the measurer stated them: streams 2 and 3 are
indistinguishable to this instrument, so no rule for choosing between them is
vindicated; the one-of-three-streams warning stands, since nothing says what
streams 1 and 3 contribute; and the reach is 59.7 s of a 137 s movie, one run,
one asset.

Also records the capture that would strengthen it most and why it is not taken:
S00A rather than a longer ADV, because its second full-length stream is digital
silence where ADV s is a 0.60x copy, so a structurally different movie would
agree. Reaching it needs a driven rendered run -- S00A starts about 4.5 s after A
on the save slot -- so it cannot use --gpu=null and will carry the additive
padding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:01:26 +00:00

7.7 KiB
Raw Blame History

🔴 A voice cue's three streams are DECODED TOGETHER — they are not alternative presentations

Classification: measured. Xenia Canary, --xma_param_probe=true, one boot into the intro movie, 2026-08-29. Log excerpt committed at data/voice-three-streams-runtime.txt.

This refutes a framing of mine that two documents and the port's exporter were built on, so it is written as its own page rather than as an edit.

What was believed

voice-region-leading-chunk.md established that a long voice cue's byte span holds three streams, and read them as three presentations of one take — a defensible reading of the evidence then available (they are the same duration, and their content correlates strongly). From it came the instruction "take one stream, do not sum", which the port implemented.

The open question was which presentation the game plays.

What the game does

The question has no answer, because the premise is wrong. Canary's xma_param_probe — a cvar whose own comment says it is keyed so as to reveal "WHICH sub-wave of a movie's .slb the game actually decodes" — shows the guest opening three XMA contexts and decoding all three concurrently:

context packets byte_size channels rate disc stream
0 632 1 294 336 2 48 000 ADV stream 1 (RIFF 1 294 396 60)
1 546 1 118 208 2 48 000 ADV stream 2 (1 118 268 60)
2 572 1 171 456 2 48 000 ADV stream 3 (1 171 516 60)

Three-way, byte-exact, against sizes taken independently off the disc. Only these three contexts appear in the run.

So the three streams are simultaneous, not alternative. A consumer that picks one is discarding two thirds of what the game mixes.

ANSWERED 2026-08-29 — the dialogue is in the CENTRE channel

Measured by the port, fitting the disc's decoded streams against a clean capture of the game's own 6-channel output (audio-capture-alsa-file-tee.md). Their instrument was controlled first: known-present margin +0.248, known-absent +0.005.

Speech-band correlation margins, by output channel:

FL FR FC LFE RL RR
stream 1 (the leading one) +.013 +.006 +.012 +.009 +.012 +.005
stream 2 +.238 +.171 +.305 +.011 +.035 +.006
stream 3 +.240 +.173 +.307 +.009 +.054 +.006

r = 0.989 on FC, above the known-present control. And the low band is the exact mirror — the movie bed at FL .763 / FR .838 / RL .805 / RR .817 on one lag, with FC .317.

Dialogue in the centre; bed in the four corners. So the streams are a multichannel decomposition, which is what the 🟡 below hypothesised — and it was right for a reason the file could never have supplied. ChannelMask reads 0x0002 on all three streams; the header is not merely unhelpful here, it is actively misleading, and refusing to call it 5.1 from the header was correct. The oracle answered what the header could not.

⚠️ Three things this does NOT establish, stated by the measurer:

  1. Streams 2 and 3 are indistinguishable to this instrument — +.305 vs +.307, exactly as expected from stream 3 being 0.60 × stream 2 with the residual 26.8 dB down. So this does not vindicate any rule for picking between them; only that whichever is picked is the dialogue.
  2. 🔴 The "1 of 3 streams" warning stands. Nothing here says what streams 1 and 3 contribute to the game's output. What changed is its character: from "one of three, contents unknown" to "the centre-channel dialogue, plus two streams whose relationship to it is measured and whose role is not".
  3. Reach: 59.7 s of a 137 s movie, one run, one asset. Stream 1 being undetectable is consistent with it being stream 2's tail and a window that starts before it — a consistent story, not evidence.

The capture that would strengthen it most is S00A, not a longer ADV. S00A's second full-length stream is digital silence where ADV's is a 0.60 × copy, so if FC still carries dialogue there, a structurally different movie agrees and the finding stops resting on one asset. ⚠️ Reaching it needs a driven, rendered run — S00A starts ~4.5 s after Ⓐ on the save slot (movie-binding.md) — so it cannot use --gpu=null, and its capture will carry the ~10 % additive padding. Not taken.

🟡 The obvious reading was 5.1 — recorded here as it stood before the measurement

Three concurrent stereo streams is six channels, and N stereo streams is exactly how XMA carries multichannel audio on the 360. It would explain a lot at once:

  • the differing declared byte rates — different channel pairs, different content, same encoder quality;
  • the port's content measurements, which become measurements of channels: ADV stream 2 is mono-in-stereo (one channel digitally silent — a centre paired with a silent LFE looks exactly like that), stream 3 is dual-mono (a centre-panned line in an L/R pair is L = R exactly), and S00A's third stream is digital silence (surrounds, on a dialogue-only cue);
  • stream 3 measuring 0.60 × stream 2 with the residual 26.8 dB down — which is what a correlated channel pair at a lower level looks like, and not only what a duplicate looks like;
  • and the census dichotomy already on record: inter-descriptor spans hold 1 stream or 3, never 2 (258 and 28). If 3-stream is 5.1 and 1-stream is mono/stereo, the missing 2 is the missing 4-channel configuration.

⚠️ Against it, and the reason this stays 🟡: all three fmt chunks declare ChannelMask = 0x0002 identically, which is not what distinct channel roles should look like. Either the mask is unset on this disc or the offset is mis-taken; it is weak evidence either way, and no channel-role assignment is claimed here.

Which stream is which channel pair is unknown. Nothing measured here assigns roles, and the port must not infer them from stream order.

🔴 What this withdraws

  • "Three presentations of one take" — withdrawn. Three concurrent streams of one take.
  • "Take one stream, do not sum" — withdrawn. It was my instruction, the port implemented it, and it discards two of three decoded streams. ⚠️ This does not make the previous behaviour right either. An equal-gain 1/n sum of channel pairs is not a downmix, and the port's measured 6.02 dB loss from summing a silent stream was real. The correct handling needs the channel roles, which are open. Neither "pick one" nor "sum at 1/n" is established; a consumer is authoring, and should say so.
  • "Which presentation does the game play?" — dissolved rather than answered.

What survives untouched: every content measurement the port made, and the byte-level structure in voice-region-leading-chunk.md — the leading chunk being stream 1 clipped by our own 1.5 MB guard, the 70 + 8 + 17 decomposition, the bank-header discriminator. Those are about bytes and they did not depend on the framing.

Reach

  • One cue, one boot. ADV only. That 28 cues on the disc are 3-stream is decoded from the bytes, but that all 28 decode concurrently is measured on one of them.
  • The probe fires on first decode per (buffer ptr, packet count), so this shows all three being started; it does not by itself prove they play to the end in lockstep. Their equal durations and the port's sample-synchronous correlation both point that way.
  • Nothing here identifies the mix the guest applies downstream of the three decoders.