e88ac3a002
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
42 lines
2.6 KiB
Plaintext
42 lines
2.6 KiB
Plaintext
# 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.
|