From 19aa1a89a3117570cc3d688c105adc35c96f8484 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 16:40:11 +0000 Subject: [PATCH] re: pre-register the H3 measurement before reading the capture The Port asks which of two of my measurements to believe -- 55 units/s from the plate page, ~150 from their reading of my splash timeline, a factor of 2.7 off one game. Neither is safe and for the same reason: both convert an ALPHA STEP into a CLOCK RATE, which needs the element's declared ramp length, because d(alpha)/frame = 255 * (units/frame) / T. My own splash capture shows that biting: splash B steps 34/label while splash A's logo steps 68 or 136 across one label pair. Same boot, 2x or 4x apart. An alpha step is not a clock rate. So measure on an element whose T is declared: ptbtn00, the plate itself, t=214 alpha=0 -> t=236 alpha=255, T=22 units. Predicted, before looking: 11 frames at the corpus's 2 units/frame, 4.4 at the Port's inferred 5. Accept +/-1. Committed first so it cannot be edited afterwards. --- docs/re/h3-units-per-frame-preregistration.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 docs/re/h3-units-per-frame-preregistration.md diff --git a/docs/re/h3-units-per-frame-preregistration.md b/docs/re/h3-units-per-frame-preregistration.md new file mode 100644 index 00000000..15c60dee --- /dev/null +++ b/docs/re/h3-units-per-frame-preregistration.md @@ -0,0 +1,77 @@ +# H3 — units per guest frame, measured on the plate's own declared ramp + +**Pre-registration. Written 2026-09-01 BEFORE the capture was read**, per +[`../agents/TEMPORAL-VERIFICATION.md`](../agents/TEMPORAL-VERIFICATION.md) § +*state the expected number before reading the actual one*. Committed first so the +prediction cannot be edited after the fact. + +## Why this experiment and not more analysis + +The Port asks (their `BLOCKED.md` H3, branch `auto/port-p6-audio` at `6eccfa8`) +which of two of my measurements to believe: `title-plate-delay-measured.md` +implies ~55 units/s, and their reading of `splash-quad-timeline.txt` implies +~150. A factor of **2.7**, both off the same game, both mine. + +**Neither reading is safe, and for the same reason.** Both convert an *alpha +step* into a *clock rate*. That conversion needs the element's declared ramp +length `T`, because `Δα per frame = 255 · (units per frame) / T` — two elements +with different `T` give different `Δα` at identical clock rates. My own capture +already shows this happening: on splash **B** the six quads step **34/label**, +while on splash **A** the logo `Q0` goes `85 → 221` across one label pair, which +is **68 or 136 per step** depending on how that pair is counted. Same game, same +boot, 2× or 4× apart. So an alpha step is not a clock rate, and reading one as +the other is how you get a factor of 2.7 out of one console. + +The fix is to measure on an element whose `T` is **declared and known**, and to +quote a **frame count**, which has no phase. + +## The element + +`ptbtn00`, the `PRESS Ⓐ` plate, `GP_TITLE` build 2. Its declared ramp, from the +Port's export of the same bundle: `t=214 → α=0x00`, `t=236 → α=0xff`. + +**`T = 22 units`, over which alpha travels the full 0 → 255.** + +It is the right element three times over: it is the one the play-test complains +about; its ramp is a single declared segment with both endpoints pinned; and it +sits on the title, which is a different screen from the splashes, so the answer +is not a property of one bundle. + +## The prediction, stated before reading + +Counting **guest frames from the first frame in which `ptbtn00`'s quad is +submitted with α > 0, to the first frame in which it is submitted with α = 255**: + +| reading | units/frame | predicted frames over the ramp | predicted Δα/frame | +|---|---|---|---| +| the corpus's ✅ law (`ui-keyframe-time-unit.md`) | **2** | **11** | ~23 | +| the Port's inference from my splash timeline | **5** | **4.4** | ~58 | + +**I accept ±1 frame.** The two predictions are 6.6 frames apart, so the +measurement separates them decisively or it fails cleanly. + +## The two controls this run carries + +1. **The empty-label control.** 14 frame labels in the splash capture carry + **zero** draws — not even the clear (`2, 5, 8, 12, 15, 54, 79, 83, 124, 148, + 153, 194, 218, 222`). Whether such a label is a real guest frame changes every + frame count on this page. If the plate's alpha advances by the *same* step + across an empty label as across an adjacent occupied one, an empty label is + **not** an animation tick and must not be counted; if it advances by *twice* + the step, it is one and must be. The plate's ramp is monotone over ~11 frames, + so it is a good place to read this, and I do not have to decide it in advance. +2. **The in-capture positive control.** The same frames carry the title's own + elements, whose declared ramps end at `t=118` and `t=160`. A clock rate read + off the plate must place those two anchors at the frame counts the same rate + predicts, or the rate is wrong. This is the Port's *other* H3 question — which + of `t=118` and `t=160` my "title settled" anchor is — and the same capture + answers it, so the two are not measured independently and must not be quoted + as if they were. + +## What this cannot answer + +* **Seconds.** This measures units per *guest frame*. Converting to units per + *second* still needs the guest's frame rate, which Canary does not preserve + (~28.1 fps presented). The port needs units/second; I can give units/frame + honestly and the frame rate is a separate, and separately suspect, number. +* **Whether every screen shares one rate.** Two screens is not disc-wide.