Measure the level off the whole disc, and find the headroom is not worth buying

FINDINGS 69, ROADMAP P6 -- the item 66.3 reopened in session 34 and sessions 35
and 36 both deferred.  The chip clamps its accumulator at 10 bits INSIDE the
recursion, and the ten seconds every audio figure in this tree is quoted on peak
at 435 of 511: it fits, and it fits by accident, because that window is a
-13.4 dBFS passage.  Nothing knew what the loudest passage of the game was.

tools/analysis/35_audio_level.py reads every stream of the unique scene footage
(00000-00201) through extract_audio.py's own chain -- 1,291.6 s, 201 of 202
streams -- and encodes windows of it with adpcm.CHIP.  The disc peaks at 946 of
2048 = -6.71 dBFS (00200 @ 2.11 s), which is 5.35 dB over the clamp, and the
census behind that peak is 687 samples of 20,182,000 (0.0034%) in 402 events,
44.0 ms, longest 0.90 ms.

THE HEADLINE IS A NEGATIVE: THE LEVEL DOES NOT CHANGE.  Forty 2 s windows drawn
over the game's timeline at six gains -- the disc's own level (gain 1.0) has the
best mean SNR (22.03 dB) and the best median, and loses the worst-window column
to -3 dB by 0.04 dB.  The gain that guarantees zero clamping disc-wide (0.5402)
costs 0.85 dB of mean SNR across the whole game to buy back 1.90 dB on the
2.11 s that clamp, because the OKI step table's floor is a constant 16 and does
not scale with the signal.

AND 66.3's MECHANISM DOES NOT SURVIVE A CONTROL.  Error after a clamp run is
elevated ~5x -- and so is the same window at a gain that never clamps, read at
the same indices, because those samples are simply loud.  Worst ratio 1.28 over
64 offsets, and the clamped encode's whole-window mean |error| is the LOWER of
the two (4.71 vs 5.05).  adpcm.encode runs the chip's clamp inside its own
sixteen-way search, so it never loses the chip's state.  The worry was right
about the mechanism and aimed one layer too late: an encoder clamping at 12 bits
while the chip clamps at 10 is exactly that divergence, and 66 closed it.

pack.py gains --audio-gain (default 1.0) so the level is a named parameter with
a measurement behind it instead of a shift buried in a list comprehension, and
prints the encoded window's peak against the clamp.  tmp/packed_singe.dlxp
rebuilds byte-identical, all 6,039,040 B.  New check.sh stage, ~18 s.

Three rig facts in 69.4, because a shipping encoder meets all three: 00176 has
no audio track at all; 00199 is 61.31 s of video with 1.25 s of audio; and 18
stream pairs share duration, peak and RMS, 7 of them byte-identical.

The 10-bit clamp is a DRIVER SETTING, not a chip constant -- x68k.cpp:1089 sets
OUTPUT_10BITS -- so it is MAME's reading of the board, and hardware item 5 is
what settles it.

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

tools/bench/check.sh

@@ -828,4 +828,22 @@ python3 tools/analysis/34_packed_audio.py tmp/packed_singe.dlxp \
 grep -aE "^  (OK|FAIL) |^    (order|variant|bits|init) |min of play ->" \
   tmp/packed_audio.log
 
+echo "--- session 37: THE AUDIO LEVEL, measured off the whole disc (FINDINGS 69) ---"
+# ROADMAP P6, the item 66.3 reopened and two sessions deferred. The chip clamps
+# its accumulator at 10 bits INSIDE the recursion, and the ten seconds every
+# audio figure in this tree is quoted on peak at 435 of 511 -- which fits, and
+# fits BY ACCIDENT, because that window is a -13.4 dBFS passage.
+#
+# So the level is measured against the loudest thing the game can play, which
+# means every stream of the unique scene footage (00000-00201, FINDINGS 32.1)
+# through extract_audio.py's own chain. The gate asserts the disc's peak and
+# the census behind it; a different pressing is a legitimate reason for it to
+# go red, a different ffmpeg downmix is not.
+#
+# ~18 s, and it needs the Blu-ray mounted like every other stage here.
+python3 tools/analysis/35_audio_level.py --gate > tmp/audio_level.log 2>&1 \
+  || { cat tmp/audio_level.log; exit 1; }
+grep -aE "DISC PEAK|LOUDEST PASSAGE|THE CLAMP|LEVEL GATE|NO AUDIO TRACK|^  1\.0000|^  0\.5" \
+  tmp/audio_level.log
+
 echo "ALL GREEN"