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

re: the dual-mono explanation for the extra stream bytes does not generalise

Browse Source 
The port chose a voice presentation on the argument that ADV chunk 1 is
mono-in-stereo and chunk 2 is dual-mono, so chunk 2 s extra bytes encode a
duplicated channel rather than fidelity -- which would explain its higher
declared PsuedoBytesPerSec without appealing to encode quality.

Their ADV channel measurement stands. The generalisation does not. If stream 3
were systematically the same take with its channel duplicated, its size ratio to
stream 2 would be tight across the 28 three-stream cues. Measured:

  min 0.0778 (S00A, the silent one)
  median 1.2565
  max 2.9163 (S06A)
  sd 0.5057
  within 15 percent of 1.0: 12 of 28

A 37x spread is not a duplicated channel, and the declared rates scatter with
them -- S06A is 5661 against 16513 B/s. Whatever distinguishes the three streams
varies per cue rather than being a fixed channel-configuration triple.

This does not touch the port s decision, which is to take the loudest
presentation: that is a per-asset content measurement, not a structural rule, so
a scattering ratio cannot undermine it. It touches the explanation, which should
not harden into a fact about the format.

Two curiosities recorded: S12B s three streams are byte-size identical at 14396
each, and BIRD_224 is 3-stream while being a non-movie cue, so the shape is not
exclusive to cutscenes.

Also narrows the settle-time page s own generalisation. The port measured its
boot the way this corpus measured the game and found the sequencer NOT late --
its 0.6 s discrepancy was arrival-to-arrival timestamps compared against visible
spans, the plate-delay trap in a second place. So what is supported is that
rest.t is the wrong landmark for the TITLE, not that everything paced off it is
late. And the offered re-take of the one-run menu figures is recorded as
declined, with the reason, rather than left looking unfinished.

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:37:46 +00:00
parent 63573d2b50
commit b82f75979e
5 changed files with 252 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/re/structures/voice-region-leading-chunk.md
View File

@@ -260,6 +260,45 @@ plays — and it has not been done.
❔ *Why* the disc stores three presentations — quality tiers, a mix the engine
selects between, an authoring artefact — is not answered here.
### 🔴 Refutation attempt, 2026-08-29 — "the extra bytes are a duplicated channel" does NOT generalise
The port selected a presentation on this argument: `ADV` chunk 1 is
**mono-in-stereo** (channel 2 digitally silent) and chunk 2 is **dual-mono**
(both channels identical at −8.318574), so chunk 2's extra bytes encode a
duplicate of its own channel rather than fidelity — which would explain its
higher declared `PsuedoBytesPerSec` without appealing to encode quality.
**The `ADV` measurement is theirs and stands. The generalisation does not.** If
stream 3 were systematically "the same take with its channel duplicated", its
size would sit in a tight ratio to stream 2 on every 3-stream cue. Measured over
all 28 — [`data/voice-three-stream-sizes.txt`](../data/voice-three-stream-sizes.txt),
`--example voice_three_stream_sizes`:
| stream3 / stream2 | |
|---|---|
| min | **0.0778** (`S00A`, the silent one) |
| median | 1.2565 |
| max | **2.9163** (`S06A`) |
| sd | **0.5057** |
| within 15 % of 1.0 | **12 of 28** |
**A 37× spread is not a duplicated channel.** The declared rates scatter with
them — `S06A` is 5 661 against 16 513 B/s, `S00A` 13 485 against 1 049 — so
whatever distinguishes the three streams varies per cue rather than being a fixed
channel-configuration triple.
⚠️ **Two curiosities worth someone's time:** `S12B`'s three streams are
**byte-size identical** (14 396 each), and `S11A`'s first two are (81 980). And
`BIRD_224` is 3-stream while being a non-movie cue, so the 3-stream shape is not
exclusive to cutscenes.
✅ **What this does and does not touch.** It does **not** touch the port's
decision, which is to take the **loudest** presentation — that is a per-asset
content measurement, not a structural rule, so a scattering ratio cannot
undermine it. What it touches is the *explanation*: "more bytes means a
duplicated channel, not better fidelity" is true of `ADV` and is **not** a fact
about the format. It should not harden into one.
⚠️ Note for anyone reading our own tooling: `sylpheed-cli audio info` reports
these chunks as *16 channels, 4310 Hz, 2-bit*. Those are the `wBitsPerSample`
(16), `wEncodeOptions` (`0x10d6` = 4310) and channel fields read at the wrong