Ask the chip which decoder it is, and find four wrong axes where one was expected

ROADMAP P6a, on the machine. 68000 code programs HD63450 channel 3 with the
IPL ROM's own ADPCM bytes -- dual address, 8-bit port, cycle steal, external
request -- and feeds the MSM6258 a designed 1,678-nibble stream at the chip's
own pace: 839 B in 0.1074 s = 7,811.4 B/s against the format's 7,812.5, CER=$00.
That transport is P6b's, not scaffolding.

Sixteen candidate decoder models, three capture decimations and a searched
prologue are fitted to MAME's capture. Exactly one reproduces it sample-exact
over all 1,678 samples, and every axis carries a negative control: flip it
alone and the closest survivor disagrees on 826, 1,504, 156 and 1,522 samples.

The chip runs 'terms', takes the LOW nibble of a byte first, clamps the
accumulator at 10 bits and starts it at -2. tools/encoder/adpcm.py defaulted to
the opposite of all four, and 65.2 named the wrong axis as the risk: the delta
formula is worth -2.88 dB and the NIBBLE ORDER is worth -25.74 dB. 65.1's "high
first, measured" was a measurement of ffmpeg, i.e. of the VOX file convention,
which is a different question from what a chip does with a byte in its data
register.

The 10-bit clamp is free on the Singe window and only because that window peaks
at 435 of 511 -- 1.4 dB of headroom on a -13.4 dBFS passage, 12.1 dB below where
the encoder was clamping, and inside the recursion. So the audio level is an
open choice again, downward, and the loudest passage on the disc is unmeasured.

Session 33's silence had two ordinary causes: the PPI's port C is an input until
control word $92 says otherwise, and $01 is COMMAND_STOP. And a rig fact worth
the space: the 8 MHz ADPCM clock is CT1 in the YM2151's $1B, delivered on the
sound system's schedule rather than at the store, so a transfer started in the
same breath as the setup plays its first ~17 ms at the old clock and no model
fits a stream that changed rate part way through.

Name the layer: this is MAME 0.277's okim6258 device model measured end to end
through the machine's real transport. It settles the rig and not the silicon.
Also struck: 64.4's "no MAME source tree is on this machine" -- there is none on
disk, but the machine has network and the upstream tag fetches.

check.sh ALL GREEN before (tmp/check_s34_start.log) and after
(tmp/check_s34_end.log), with one new stage.

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

tools/bench/verify_adpcm.py

@@ -2,6 +2,14 @@
 """Gate tools/encoder/adpcm.py against the only independent decoder on this
 machine: ffmpeg's `adpcm_ima_oki`.
 
+THIS FILE IS NOT ABOUT THE X68000's CHIP and after session 34 that distinction
+is load-bearing. It checks this implementation against an independent one, so
+its parameters stay ffmpeg's -- variant 'shift', high nibble first, a 12-bit
+clamp, accumulator from 0. What the MACHINE's MSM6258 does is measured by
+tools/bench/adpcm_run.sh and it is a different set of four values on all four
+axes (adpcm.CHIP, FINDINGS 66). Do not "fix" the defaults here to match it: a
+reference check whose reference has been adjusted to agree is not a check.
+
 There is no ffmpeg ENCODER for this format -- `adpcm_ima_oki` is decode-only --
 so the encoder here cannot be checked against a reference implementation. What
 CAN be checked, and is, is that the decoder our encoder runs in its own loop is
@@ -70,14 +78,22 @@ ck(ff == ours, f"variant 'shift' is SAMPLE-EXACT vs ffmpeg over {len(nibs)} nibb
 lowfirst = [adpcm.unpack(data, len(nibs))[i ^ 1] for i in range(len(nibs))]
 bad = [v * 16 for v in adpcm.decode(lowfirst, "shift")]
 ndiff = sum(1 for a, b in zip(ff, bad) if a != b)
-ck(ndiff > 0, f"low-nibble-first DISAGREES on {ndiff}/{len(ff)} -- so the order is measured, not assumed")
+ck(ndiff > 0, f"low-nibble-first DISAGREES on {ndiff}/{len(ff)} -- so what ffmpeg reads is measured, not assumed")
+# AND IT IS A FACT ABOUT A FILE FORMAT, NOT ABOUT A CHIP. Session 33 recorded
+# this line as "nibble order: HIGH FIRST, measured", which it is -- of the VOX
+# convention ffmpeg implements. Session 34 asked the machine's own MSM6258 the
+# same question through HD63450 channel 3 and got the OTHER answer: the chip
+# takes the LOW nibble of a delivered byte first (FINDINGS 66), and encoding
+# for the wrong one of the two costs -25.7 dB on the Singe window. The two
+# claims do not conflict; they are about different things, and only one of them
+# is about the machine this is being ported to.
 
 print("--- and the second variant is not the same decoder ---")
 terms = [v * 16 for v in adpcm.decode(adpcm.unpack(data, len(nibs)), "terms")]
 d = [abs(a - b) // 16 for a, b in zip(ff, terms)]
 nd = sum(1 for x in d if x)
 ck(nd > 0, f"variant 'terms' differs on {nd}/{len(d)} samples, max {max(d)} in 12-bit units"
-           " -- OPEN: which one the MSM6258 runs is unmeasured")
+           " -- and 'terms' is the one the machine runs (adpcm_run.sh, FINDINGS 66)")
 
 print("--- and getting the variant wrong is NOT a rounding error ---")
 # THE MEASUREMENT THAT CHANGED THIS FROM A FOOTNOTE INTO AN OPEN ITEM. The two