Take the climb to a real branch point, and find the cadence has a third column

FINDINGS 70, and it closes ROADMAP P6.  65.6 recorded that "the slack table is
here, but 51.3's refill climb with a second consumer through a real branch point
is not", and 67.6 repeated it verbatim two sessions later.
tools/analysis/36_branch_audio.py is that run: 51.3's surplus model, 56.3's 612
real branch points, 32's cadence arithmetic, both containers' headers and the
buffer constants of the player 68 measured, in one place.  No machine -- all
five were already numbers.

AUDIO IS 1.7% OF THE CODEC WIRE AND UP TO 3.30x OF THE CLIMB.  Slack accrues out
of pipe - wire, which is a small difference of two large numbers, so a second
consumer is not priced by its share of the wire -- which is how every budget in
this tree since FINDINGS 8 has quoted it.  At 451.4 KB/s (the container's own
zero-prefill pipe, 49.5) in a 256 KB ring the climb goes 6.70 s -> 22.11 s and
the branch points arriving under it go 482/612 (79%) -> 603/612 (99%).  At 488
it is 1.19x, at 600 it is 1.05x.  Correction to 56.4: it charged audio at
ratectl.AUDIO_KBPS = 7.8, which is 7,812.5 B/s in decimal kB; in binary KB the
figure is 7.6294, so the placeholder was 2.24% high and every column moved in
the flattering direction by less than one part in six hundred of the wire.

AND ON THE PACKED BRANCH THERE IS NO CLIMB AT ALL.  A record goes straight into
GVRAM, so the video lookahead is zero records and 56.4's alarming column is
vacuous when every frame arrives with less lookahead than the one before it.
Acceptance there is a per-frame deadline, not an average, which is why B1 has to
name a burst rate.  The only consumer on that branch with any lookahead is the
audio one: 1.833 s of sound held against 0.000 s of picture.  And at 589.6 KB/s
-- the acceptance figure this project quotes -- the sounded container's surplus
is exactly zero: it plays and never banks a byte, while the silent one climbs
its record in 6.38 s.

THE COST NOBODY HAD COUNTED.  A DLXP2 group is `lump k, then F records`, so lump
k is at a LOWER address than every record of its group but the first, and a seek
to record i finds its audio behind it.  Measured on the 409 within-container
seek targets of the arcade's own graph at the shipped F=11: mean 416.5 ms of
silence entering a branch, median 416.7, p90 750.0, worst 833.3, and only 36 of
409 land on a group boundary.  The other 203 -- the scene changes -- are free by
construction, because lump 0 sits between the header and record 0.  The
container's own start is the one branch point the cadence costs nothing at, and
it was the only one anybody had looked at.

SO THE CADENCE PICK IS REOPENED, on a third column.  32_audio_wire chose F=11 on
padding and RAM; F=1, the cadence it called the worst one, has no group to enter
off-boundary at all, and gives back 12,288 B of RAM for +4.36 KB/s of wire
(0.74% of the acceptance figure).  The alternative is a second read: lump k is
up to 503,808 B behind, so it is a separate command of 7,168 B -- 11.7 ms
against 416, 36x cheaper in time -- and src/player/packed.s starts PG_AK/PG_AKF
at lump 0 and has no audio seek path at all.  Nothing here decides it; the
deciding number is what one more SCSI command costs, and that is B1's.  The
content is not uniform mod F either: the measured mean runs 0.67x..1.23x of a
uniform assumption across the sweep, and the 1.00x at F=11 is a coincidence.

New check.sh stage, ~10 s, and it gates the STRUCTURE and deliberately not the
milliseconds: audio never shortens a climb, the shipped cadence strands most
within-container branches, F=1 strands none, and the lump read is an order of
magnitude cheaper than the silence it removes.

The one thing 70.3 and 70.4 rest on is a DESIGN ASSUMPTION and is printed in the
tool's own output: one container per SCENE (53, 55.1, 56.3).  One container per
sequence makes every seek land on frame 0 and empties both sections.

No encoder, player or container byte moved.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

docs/ROADMAP.md

@@ -172,6 +172,28 @@ through a real branch point** — and 69.4 adds two small unbuilt cases, a scene
 with no audio track (`00176`) and a scene whose audio is shorter than its video
 (`00199`).
 
+Amended end of session 38: **P6 IS CLOSED, AND THE LAST ITEM IN IT REOPENED THE
+CADENCE (FINDINGS 70).** `tools/analysis/36_branch_audio.py` runs 51.3's climb
+against 56.3's 612 real branch points with the second consumer on the wire. On
+the codec branch **audio is 1.7% of the wire and up to 3.30x of the climb** —
+6.70 s → 22.11 s at 451.4 KB/s, and 79% → 99% of the game's branch points
+arriving under it — because slack accrues out of `pipe − wire` and that is a
+small difference of two large numbers. On the packed branch **there is no climb
+at all**: a record goes straight into GVRAM, video lookahead is zero records,
+and the only consumer with any lookahead is the audio one (1.833 s of sound
+against 0.000 s of picture). **At 589.6 KB/s — the acceptance figure — the
+sounded packed container's surplus is exactly zero**, which is the sharpest
+statement yet of why B1 must name a burst rate and not only a sustained one.
+And a cost nobody had counted: a DLXP2 group is `lump k, then F records`, so a
+seek into a group finds its audio BEHIND it — **mean 416.5 ms of silence at the
+409 within-container branch points, worst 833.3 ms, 36 of 409 free**, while all
+203 scene changes are free by construction. **The fix is one extra read of
+7,168 B (11.7 ms against 416) and no player has an audio seek path**; the
+alternative is F=1, which gives back 12,288 B of RAM for +4.36 KB/s of wire.
+**The cadence pick is therefore reopened and the deciding number is B1's**: what
+one extra SCSI command costs. **What is left of P6 is nothing** — 69.4's two
+unbuilt cases and 70.3's seek path are player work, not open questions.
+
 **THE COMPLETION TARGET IS M3, THE VERTICAL SLICE** (USER DECISION): one scene
 tree — a decision point, two outcomes, a death clip — with audio, streaming from
 a real SCSI volume on a stock 2 MB machine, playable. That is the point at which
@@ -736,8 +758,10 @@ playing from disc on stock hardware.**
 **P6. Audio. P6a DONE, session 34 — FINDINGS 66.** ~~and it is the largest
 unpriced risk left in the project.~~ Three quarters of P6 closed in session 33
 and the fourth precondition — which decoder the chip runs — closed in 34, on the
-machine, through the real DMA channel. **What is left of P6 is P6b (DLXP2, a
-container with sound in it) and the refill climb with a second consumer.**
+machine, through the real DMA channel. ~~**What is left of P6 is P6b (DLXP2, a
+container with sound in it) and the refill climb with a second consumer.**~~
+**P6 IS CLOSED end of session 38** — P6b in 35, P6c in 36, the level in 37 and
+the refill climb with a second consumer in 38 (FINDINGS 70).
 
 *(original framing, kept because every figure below is still the live one:)*
 MSM6258 ADPCM, 15.6 kHz mono, **7.8 KB/s**. That figure is in `ratectl.py`'s
@@ -780,10 +804,15 @@ container's cadence is `F=11, A=14`** — 0.09% padding, 14,336 B held, 582.0
 57.3% of every audio sector. **The codec container pays zero padding**, because
 it already has the index the packed one deleted (65.4).
 
-**What is left in P6 is the fourth: the refill climb with a second consumer
+~~**What is left in P6 is the fourth: the refill climb with a second consumer
 through a real branch point** (51.3, 55.4). The slack table is in
 `32_audio_wire.py` — at 582.0 KB/s exactly, silent breaks even and sounded
-starves — but a branch point has not been run with audio on the wire.
+starves — but a branch point has not been run with audio on the wire.~~
+**DONE, session 38 — FINDINGS 70**, and it produced three things the slack table
+could not: the climb multiplier (up to **3.30x** for **1.7%** of the wire), the
+fact that the packed branch has **no accumulator to climb**, and the group-entry
+silence (**mean 416.5 ms** at 409 of the game's 612 branch points) that reopens
+the cadence pick on a third column. `tools/analysis/36_branch_audio.py`.
 
 **P6a. WHICH DELTA FORMULA DOES THE MSM6258 RUN? (new, session 33, FINDINGS
 65.2 — and it is a precondition, not a refinement.)** ffmpeg computes