Put sound on the wire, and find three LSBs are worth 25 dB

ROADMAP P6, everything in the item except the bus half session 20 closed.
tools/encoder/adpcm.py is an MSM6258 codec, tools/encoder/extract_audio.py
takes the same seconds of the same stream the frames come from,
tools/bench/verify_adpcm.py is the gate, tools/analysis/32_audio_wire.py the
container arithmetic.

There is no reference encoder -- ffmpeg has a decoder for this format and none
the other way -- so what is gated is the decoder the encoder runs INSIDE its
own nibble search, sample-exact against ffmpeg's over 4,268 nibbles. An
encoder that agrees with its own wrong decoder is what that catches. The Singe
window: 156,250 samples -> 78,125 B at 21.97 dB, which is 7,812.5 B/s to the
byte. Normalising the disc's -13.4 dBFS level moves the SNR 21.97 -> 21.97, so
the level is not a lever.

And the two published delta formulas are not the same codec. They differ by at
most 3 in 12-bit units; encode for one and decode on the other and the SNR
goes 21.97 -> -2.88 dB, the noise louder than the signal, because ADPCM is
recursive the way the video codec is temporally recursive. Which one the chip
runs is now P6a and it is a precondition on shipping any audio.

And audio is the first thing the packed branch's simplification has cost
anything for. A record has no index BY DESIGN, so audio cannot be per-record
without making records variable; it rides a fixed cadence (F, A), the obvious
F=1 wastes 57.3% of every audio sector, and the pick is F=11 A=14 -- 0.09%
padding, 14,336 B held, wire 582.0 -> 589.6 KB/s. The codec container, which
kept its index, pays zero.

The MAME experiment did not work and 65.5 says so: :okim6258 is there at
$E92001/$E92003, read out of the machine's own program map, and feeding it
from Lua recorded silence across control 0..3 x port C 0..15. The register
semantics were not guessed at further.

FINDINGS 65. check.sh ALL GREEN before and after, with a new stage.

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

docs/ROADMAP.md

@@ -74,6 +74,28 @@ the CPU opens the window only for the measured 27.3% blit, so it is on screen
 the clock cannot tell** — 46.9% of V-DISP edges lost, zero late frames reported,
 the player believing 12 fps while the screen ran at 6.37. **The open item is now
 K4.**
+Amended end of session 33: **P6 HAS AN ENCODER AND A PRICE (FINDINGS 65).**
+`tools/encoder/adpcm.py` is an MSM6258 codec whose in-loop decoder is gated
+SAMPLE-EXACT against ffmpeg's `adpcm_ima_oki` — there is no reference encoder
+for this format, so that is the only check available and it is the one that
+catches an encoder agreeing with its own wrong decoder. The Singe window encodes
+to **78,125 B at 21.97 dB**, which is 7,812.5 B/s to the byte and 52's figure
+arriving from the other direction, and **normalising the disc's −13.4 dBFS level
+buys 0.00 dB**, so the level is not a lever. Two things came with it. **(1) The
+two published delta formulas disagree by at most 3 in 12-bit units and that is
+worth 25 dB** — encode with one and decode with the other and the SNR goes from
+21.97 dB to **−2.88 dB**, because ADPCM is recursive the way the codec is
+temporally recursive (64.1). Which one the chip runs is now **P6a** and it is a
+precondition on shipping any audio. **(2) The packed container's own best
+property is what makes audio cost.** A record has no index BY DESIGN, so audio
+cannot be per-record without making records variable; it rides a fixed cadence
+`(F, A)`, the obvious cadence F=1 wastes **57.3%** of every audio sector, and the
+pick is **F=11, A=14 — 0.09% padding, 14,336 B held, wire 582.0 → 589.6 KB/s**.
+The codec container, which already has an index and variable records, pays
+**zero** padding. That is the first cost anyone has found for the packed
+branch's simplification, and 64's risk list predicted there would be one without
+knowing what.
+
 **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
@@ -664,10 +686,46 @@ charging audio the disk's 5. Both worries above resolve:
    7.8 was decimal kB being multiplied by 1024; 2.4% high, now derived from the
    sample rate in `buscost.ADPCM_BYTES_PER_S`.
 
-**What is still open in P6 is everything except the bus:** extraction, encode,
-container interleave, and what a second stream does to `wire` — and therefore to
-`pipe - wire`, and therefore to 51.3's refill climb. That last one is the
-interaction to price next, and it is E2's question with a second consumer in it.
+~~**What is still open in P6 is everything except the bus:** extraction, encode,
+container interleave, and what a second stream does to `wire`.~~ **THREE OF THE
+FOUR ARE DONE, session 33 — FINDINGS 65.** `tools/encoder/extract_audio.py`
+takes the same seconds of the same stream the frames come from;
+`tools/encoder/adpcm.py` encodes them (**78,125 B, 21.97 dB**, gated against
+ffmpeg's decoder sample-exact by `tools/bench/verify_adpcm.py`);
+`tools/analysis/32_audio_wire.py` is the interleave and the wire. **The packed
+container's cadence is `F=11, A=14`** — 0.09% padding, 14,336 B held, 582.0 →
+**589.6 KB/s** — and the naive one-lump-per-record cadence would have wasted
+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
+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.
+
+**P6a. WHICH DELTA FORMULA DOES THE MSM6258 RUN? (new, session 33, FINDINGS
+65.2 — and it is a precondition, not a refinement.)** ffmpeg computes
+`((2*(n&7)+1) * step) >> 3`; the OKI datasheet's form truncates per term. They
+differ by **at most 3 in 12-bit units per sample** and, because ADPCM is
+recursive, **encoding for one and decoding on the other costs 25 dB — the noise
+comes out louder than the signal.** No encoder output can be committed to a
+container before this is answered.
+
+**It does not need a board.** MAME's x68000 HAS the chip: `:okim6258`, with the
+68000 reaching it at **`$E92001` and `$E92003`** — both read out of the machine's
+own program map by `tools/bench/probe_adpcm.lua`, not from folklore. What did
+NOT work is feeding it from Lua: `probe_adpcm2.lua` / `probe_adpcm3.lua` swept
+control 0..3 against PPI port C 0..15 and `-wavwrite` recorded silence
+throughout (65.5). The gap is the register semantics, and the way to close it is
+**from 68000 code with the IPL ROM's own channel-3 DMAC configuration**, which
+`21_iplrom_dmac.py` already reads out of the ROM — the one ADPCM path in this
+machine that is known-correct because Sharp wrote it. That is also the real
+design, so it is not scaffolding.
+
+**P6b. A CONTAINER WITH SOUND IN IT.** DLXP1 has no audio section. 65.3 is the
+arithmetic a DLXP2 is built from and no byte of one is written. It waits on P6a,
+because a container full of audio encoded against the wrong formula is 25 dB of
+work to redo.
 
 **E6. Container v2** — audio interleave, per-record index, scene table. Depends
 on P6's answer and on P5's index.
@@ -794,6 +852,11 @@ B2 blanking ─┬─ NOT blanked ─> K3's DMAC-DIRECT player is the one: 54.9%
                                 (64.2). Neither answer kills the branch and each
                                 picks a different player.
 B1 BURST rate (NEW, 64.2) ──> which of the two K3/K4 wins, if B2 blanks
+
+P6 audio DONE bar one (65): encoder gated, cadence F=11/A=14, 589.6 KB/s
+  └─> P6a WHICH DELTA FORMULA? ─┬─ needs no board: MAME has :okim6258
+      worth 25 dB, so it is a   │  at $E92001/$E92003 (65.5)
+      PRECONDITION not a tweak  └─> then P6b, a container with sound in it
 ```
 
 **Read that top-left branch as the project's live question.** Everything else