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

re: the three streams of a voice cue are decoded CONCURRENTLY, not alternatives

Browse Source 
Refutes a framing of mine that two documents and the port s exporter were built
on, so it is a new page rather than an edit.

voice-region-leading-chunk.md read a long cue s three streams as three
presentations of one take, and from that came the instruction "take one stream,
do not sum", which the port implemented. The open question was which
presentation the game plays.

It has no answer. Booted with --xma_param_probe=true, the cvar whose own comment
says it is keyed to reveal which sub-wave of a movie s .slb the game actually
decodes. The guest opens three XMA contexts and decodes all three concurrently:

  ctx=0  packets=632  byte_size=1294336  ch=2  48000   ADV stream 1
  ctx=1  packets=546  byte_size=1118208  ch=2  48000   ADV stream 2
  ctx=2  packets=572  byte_size=1171456  ch=2  48000   ADV stream 3

Byte-exact against the three streams payloads taken independently off the disc
(RIFF size minus 60). Only these three contexts appear in the run.

So a consumer that picks one discards two thirds of what the game mixes. Both
"three presentations of one take" and "take one stream" are withdrawn -- and the
previous behaviour is not thereby right either, because an equal-gain 1/n sum of
channel pairs is not a downmix and the port s measured 6.02 dB loss was real.
Neither rule is established; a consumer is authoring.

Three concurrent stereo streams is six channels and N stereo streams is how XMA
carries multichannel on the 360, which would also explain the 1-or-3-never-2
span census. Recorded as a hypothesis, not a result: all three fmt chunks
declare ChannelMask 0x0002 identically, which is not what distinct channel roles
should look like.

Everything byte-level survives: the leading chunk being stream 1 clipped by our
own guard, the 70 + 8 + 17 decomposition, the bank-header discriminator.

Reach: one cue, one boot. That 28 cues are 3-stream is decoded; that all three
decode concurrently is measured on ADV alone.

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 15:48:35 +00:00
parent a98a66190e
commit 062e17bf34
2 changed files with 102 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

98
docs/re/structures/voice-three-streams-are-concurrent.md Normal file
View File

@@ -0,0 +1,98 @@
# 🔴 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.
## 🟡 The obvious reading is 5.1, and it is NOT established
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.