# 🔴 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`](../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`](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`](../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`](../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`](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.