port: their stream assignment does not fit my region -- weights not applied

The assignment is settled by byte_size: ctx0 -> FL/FR, ctx1 -> FC, ctx2 -> BL/BR.
Applying it needs their contexts to be my chunks and they are not. Their three
sum to 3584000 B; my whole resolved ADV voice region is 3114352 B, 469648 B
smaller than the contexts that must fit inside it. My region yields three chunks,
one an 84.553 s / 806972 B tail matching none of their sizes, leaving two real
streams at 2307380 B -- and no pair of their contexts matches it (closest 2289664,
out by 17716).

So the weights are NOT applied: assigning positions on a byte-size match that does
not hold is worse than divide-by-count, and their own figures put a swapped
assignment at 11.76 dB wrong.

Not claiming their assignment is wrong -- theirs is a probe of the running
decoder, mine is resolve_movie_voice_region's byte range off the disc, and one of
the two spans is not what the other thinks it is. That is a decode question.

Takes the parts that stand alone: one mixer gain of 0.600 for bed and voice (not
baked in), and their two failed instruments -- envelope correlation saturating at
0.86-0.95 for every pair because the channels share dialogue timing, which is the
instrument I have leaned on all fortnight.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 08:34:16 +00:00
parent 36625d7bb3
commit 46eeecf658

View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
126 sections. Search this before re-deriving anything.
127 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -137,6 +137,7 @@ dies, which is what this file is for.
* [Their pulse floor reproduces exactly once the predicate is named — 159, to the pixel](#their-pulse-floor-reproduces-exactly-once-the-predicate-is-named--159-to-the-pixel)
* [My rendered pulse, counted in their units — and #4 refutes the voice value without fixing it](#my-rendered-pulse-counted-in-their-units--and-4-refutes-the-voice-value-without-fixing-it)
* [The voice export now carries every qualifying stream — and a unity sum was refused by our own check](#the-voice-export-now-carries-every-qualifying-stream--and-a-unity-sum-was-refused-by-our-own-check)
* [Their stream assignment does not fit my region — weights NOT applied](#their-stream-assignment-does-not-fit-my-region--weights-not-applied)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -7391,3 +7392,56 @@ assumed order gives the **identity**, so the "BR is 82 % silent" channel was rea
the census's channel labels; they are corrected here rather than left standing.
Every asserting check passes.
## Their stream assignment does not fit my region — weights NOT applied
The assignment is settled on their side by `byte_size`: ctx0 (1 294 336) → FL/FR,
ctx1 (1 118 208) → FC with LFE silent, ctx2 (1 171 456) → BL/BR, giving the port
weights 0.4142 / 0.2929 / 0.2929. Applying them needs their contexts to be my
chunks. **They are not.**
| | bytes |
|---|---|
| their three contexts, summed | **3 584 000** |
| my whole resolved voice region for `ADV` | **3 114 352** |
| difference | **+469 648** — 15 % larger than the region they must fit in |
My region yields **three** chunks, one of which is an 84.553 s / 806 972 B leading
chunk this port measured to be the **tail** of another (r=0.998, lag flush against
its end) — and 806 972 is none of their three sizes. That leaves two real streams
totalling 2 307 380 B, and **no pair of their contexts matches it**: the closest is
ctx1+ctx2 at 2 289 664, out by 17 716 B.
🔴 **So the weights are not applied.** Assigning positions on a byte-size match
that does not hold would be worse than the current divide-by-count, and their own
figures say how much worse: a swapped assignment is wrong by **11.76 dB**. The
export keeps `presentation: "all"` with the count divisor, which claims nothing
about placement.
⚠️ What I am *not* claiming: that their assignment is wrong. It is derived from a
probe of the running decoder; mine is `resolve_movie_voice_region`'s byte range off
the disc. **One of the two spans is not what the other thinks it is**, and that is
a decode question in their lane, not a mixing question in mine. The numbers above
are the whole of what I can say.
📌 This is the first time in this exchange that taking a settled result would have
been the wrong move. Every previous round ended with me adopting something —
sometimes after checking it, once after they retracted it. The discipline that
mattered here was checking whether the *identifiers* resolved before using the
*conclusion* they index, and the identifier was a byte count I happened to be able
to test.
### What I did take
**One mixer gain, not two** — the same 0.600 scales the movie bed and the voice
— is worth having independently of the assignment, and is recorded. ⚠️ Not baked
in as a constant: whether 0.600 is a fixed mix constant or a volume setting is
unknown, and the port applies no gain of its own either way.
✅ And their two failed instruments, which look like results and are not:
**envelope correlation returns 0.860.95 for every stream against every channel**,
because all six residual channels share the dialogue's activity timing — a matrix
of 0.9s reads as a strong finding and is the opposite. **Sample-level correlation
returns ≈ 0**, because the XMA decode's framing offset is unknown. I have used
envelope correlation as my main audio instrument all fortnight; that it saturates
where the content shares timing is a limit I did not know it had.