re: the frame-vs-audio clock run is void -- four instrument faults, control caught it

The estimator had to recover the plate's known 2.53 s period and returned 0.599 s,
its own search floor, meaning no peak was found. plate-pulse-measured.md already
records that this fast-rise/slow-decay waveform defeats sinusoid fitting;
autocorrelation fails for the same reason, so the trap was written down and I
walked into it.

I also reimplemented the title gate without its twelve-sample hold, so the window
straddled the build-in -- the signal ranges 0..5433 where the plate never goes
below 159. And no Looped Data lines were captured at all: Apu logging was on, but
those lines appear only on a wrap, and BGM_103's first wrap is ~96 s after the
music starts against a 90 s window.

The audio-clock result from committed data stands and is unaffected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/data/frame-vs-audio-clock-void.txt

@@ -0,0 +1,41 @@
+# Does the FRAME clock run at the same rate as the AUDIO clock in this container?
+# 2026-08-30. ❔ NOT MEASURED. The run is VOID -- three instrument faults.
+#
+# The question: ui-keyframe-time-unit.md's "27.6 fps" and the 8.5 % splash excess
+# are frame-clock numbers from wall-clock windows on one container. The audio
+# clock is already bounded at 0.985 +- 0.015 of real time
+# (container-audio-clock.txt), which refutes a UNIFORM slowdown -- but audio can
+# hold real time on a timer while rendering lags, so the frame clock is untested.
+#
+# 🔴 FAULT 1 -- THE CONTROL FAILED, AND CORRECTLY VOIDED THE RUN.
+# The estimator had to recover the title plate's known period (2.530 / 2.540 s by
+# mid-crossings). It returned 0.599 s -- which is the SEARCH LOWER BOUND, i.e. the
+# autocorrelation found no peak at all and was pinned at its floor. The menu phase
+# returned 0.598 s, the same floor. Neither number means anything.
+#
+# 🔴 FAULT 2 -- I USED AN ESTIMATOR THE CORPUS HAD ALREADY RULED OUT.
+# plate-pulse-measured.md records that this waveform is FAST-RISE/SLOW-DECAY, that
+# mid-crossings replicate to 0.4 %, and that a single-sinusoid fit does NOT
+# (2.553 vs 2.413, r^2 0.468/0.228). Autocorrelation has the same weakness for the
+# same reason. The trap was written down and I walked into it anyway.
+#
+# 🔴 FAULT 3 -- I RE-IMPLEMENTED THE TITLE GATE WITHOUT ITS HOLD.
+# wait_plate_pulse.py requires the glyph count to sit in [500,2500] for TWELVE
+# consecutive samples. I started sampling on the FIRST frame in that band, so the
+# window straddles the build-in: the captured signal ranges 0..5433 with only TWO
+# mid-crossings in 60 s, and glyph 0 is not a titled screen at all (the plate's
+# absent floor is 159 and its pulse bottoms at 714 -- it never goes off).
+# ⚠️ A gate reimplemented from memory of what it does is not that gate.
+#
+# 🔴 FAULT 4 -- NO AUDIO REFERENCE WAS CAPTURED. Zero "Looped Data" lines in the
+# whole run, so there is no read_offset trajectory to compare against. Apu logging
+# WAS on (142 905 XmaContext lines, --log_mask=13 --log_level=3): the lines appear
+# only once a stream LOOPS, and BGM_103's first wrap is ~96 s after the music
+# starts. The menu window was 90 s. The window was shorter than the event.
+#
+# ❔ WHAT A THIRD ATTEMPT NEEDS:
+#   * the settled-title gate CALLED, not reimplemented;
+#   * mid-crossings, not autocorrelation, on any plate-like waveform;
+#   * a menu window longer than ~100 s so at least two wraps land in it;
+#   * and the menu-focus signal read from a region established to contain the
+#     glow, rather than a band around the ring row chosen in advance.