# 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.