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