diff --git a/authored/timing.json b/authored/timing.json index a4383393..1a96504c 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -168,57 +168,53 @@ ], "black_hold_units": 9, "black_hold_why": [ - "MEASURED IN THE DRAW STREAM, 9 units. Not on the disc for these screens, so", - "it is authored with a why.", + "MEASURED IN THE DRAW STREAM, 9 units — and 🟡 SOFTER THAN IT LOOKS. Read the", + "audit below before quoting it. The VALUE IS UNCHANGED because changing it", + "would be my arithmetic on somebody else's instrument; the change is what may", + "be claimed for it.", "", - "The Decoder counted submitted quads rather than luminance, which is the better", - "instrument here: luminance cannot separate the outgoing fade's tail from true", - "black, and the draw stream can. Frames 21-125 submit `palogo_sqex` fading to", - "alpha 7; frames 126-129 submit NO SPRITE QUAD AT ALL; frames 130-153 fade the", - "developer splash in from alpha 34. Four presented frames, the only such run in", - "the sequence.", + "AUDIT 2026-08-29, prompted by the Decoder disclosing that `ARM=early` silently", + "loses its trigger ~40 % of the time, so their draw-stream runs are n = 1 each.", + "Three things this constant rests on have moved since it was authored:", "", - "Converted with the disc as its own clock, because that run's frame rate is", - "useless (13.1 fps against 28 elsewhere): `palogo_sqex` declares alpha >= 1 for", - "239.8 units and is drawn in 105 frames -> 2.284 units/frame, corroborated", - "independently at 2.231 by the title capture. Four frames = 9.1 units = 0.152 s,", - "with a +/-1 frame range of 6.9-11.4 units.", + "1. 🔴 THE CONVERSION USED A FRAME COUNT THEY HAVE SINCE CORRECTED. 9 came from", + " 2.284 units/frame = `palogo_sqex`'s declared span over 105 drawn frames.", + " Their batched-draw truncation fix revised that span to frames 6…119 = 114,", + " which gives 2.096 — the same declared 239 units over 9 more frames.", + "2. 🔴 ITS SECOND CORROBORATION WAS WITHDRAWN. '2.231 from the title capture'", + " is the figure behind their retracted 114-unit plate period: it was", + " regressed over the build-in, where the top-level clock advances, and does", + " not describe the transition.", + "3. 🔴 NO SINGLE UNITS-PER-FRAME FIGURE DESCRIBES A RUN. The presented rate", + " rises 33 % across one boot (1.765 → 2.357). A run-average conversion is", + " the wrong shape for a 3-4 frame event; the LOCAL rate is what applies.", "", - "⚠️ IT DISAGREES WITH THE LUMINANCE FIGURE AND THE DISAGREEMENT IS THE POINT.", - "HANDOFF Q7's pure-black plateau was measured at 0.17-0.23 s and I authored 12", - "units (0.200 s) from it. The draw-stream range is 0.114-0.190 s, overlapping", - "only at the top. And the true black is SHORTER than 9 even so: both boundary", - "frames still carry picture, at alpha 7 and 34, and are counted as black.", + "Redone with their corrected segments (publisher-late 2.165, developer-early", + "2.308 bracket the gap):", "", - "12 was also supported by the menus' transition quad declaring black for 12", - "units -- but that is a different screen's quad on a different path, and the", - "boot splashes carry no such quad at all (`palogo_eff0` is one static", - "keyframe). A number that fits by analogy loses to one measured in place.", + " 4-frame gap (their 1st run) -> 8.66 - 9.23 units (mid 8.95)", + " 3-frame gap (their 2nd run) -> 6.50 - 6.92 units (mid 6.71)", "", - "🔴 It had never been implemented at ALL until 2026-08-29 -- see the entry", - "below, kept because the way it stayed hidden matters more than the value.", + "⚠️ Those two runs were reconciled as 'the 3-frame gap replicates the 4-frame", + "one within the ±1 both are quantised to, so ~9 stands'. OVERLAPPING ERROR BARS", + "ARE NOT AGREEING CENTRAL VALUES: one frame is a third of this quantity, and", + "the midpoints are 8.95 and 6.71. The honest range is ~6.5-9.2 units and the", + "port sits at the TOP of it.", "", - "PREVIOUS ENTRY, kept:", - "MEASURED, not on the disc for these screens, so it is authored with a why.", + "What is NOT in doubt, and is why 9 is still better than what preceded it: the", + "hold is REAL and was missing entirely until 2026-08-29. Filmed at 0.05 s the", + "port had NO BLACK FRAME AT ALL where the oracle measures a plateau. A value", + "at the top of a plausible range beats a fifth of a second of missing black.", "", - "HANDOFF Q7: a screen transition is a fade THROUGH BLACK, and the pure-black", - "plateau between one screen leaving and the next arriving was measured at", - "0.17-0.23 s. The transition quad on the menus declares black for 12 units, and", - "12/60 = 0.200 s sits in the middle of that range -- so 12 units is the number,", - "and it is the disc's own where a screen carries such a quad.", + "Both boundary frames still carry picture — alpha 7 and 34 — and are counted as", + "black, so the true hold is shorter than whatever number this lands on.", "", - "THE BOOT SPLASHES DO NOT CARRY ONE. `publisher_logo` and `developer_logos`", - "each hold a single `palogo_eff0`, a 1280x720 primitive with ONE keyframe at", - "t=0 -- static, not a transition ramp. So on the boot path the hold is", - "sequencer behaviour and there is nothing to read it from.", - "", - "🔴 IT HAD NEVER BEEN IMPLEMENTED, and this is what the publisher_logo residual", - "was. Filmed at 0.05 s, the port fades the publisher out to a mean of 0.317 at", - "t=4.20 s and the developer logos are already at 5.65 by t=4.25 -- NO BLACK", - "FRAME AT ALL. The oracle measures a 0.17-0.23 s plateau there. I had recorded", - "the miss as '0.03 s, probably an artefact of the bound I composed', and the", - "Decoder agreed; we were both wrong. The bound was fine and the port was", - "missing a fifth of a second of black.", + "PRIOR REASONING, kept: the draw stream beats luminance here because luminance", + "cannot separate the outgoing fade's tail from true black. It disagrees with", + "HANDOFF Q7's 0.17-0.23 s plateau (12 units), which is a different screen's", + "transition quad on a different path -- the boot splashes carry none, since", + "`palogo_eff0` is one static keyframe. A number that fits by analogy loses to", + "one measured in place, and that reasoning survives this audit intact.", "", "Delete this the day a screen's own transition quad supplies it on the boot", "path too." diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 45295c10..d4e3d7b5 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -449,3 +449,40 @@ recorded there rather than only struck here. The Decoder's own container timed these same dwells 15–20 % long, so a seconds figure records one emulator's pacing. Anything that ever goes in `authored/flow.json` `dwell` is in **units**. + +--- + +## `black_hold_units = 9` rests on numbers that have since moved + +*Derived from HANDOFF `9ca1eb5`. Raised 2026-08-29 by the port, after the Decoder +disclosed that `ARM=early` silently loses its trigger ~40 % of the time.* + +That disclosure means every draw-stream run is **n = 1**, so I audited what the +port authors from one. Exactly one constant does: the black hold between the two +boot splashes. It is **not wrong**, but three of its supports have moved: + +* its conversion used **105 drawn frames**, revised by their own truncation fix + to **114** (2.284 → 2.096 units/frame); +* its second corroboration, 2.231, is the figure behind their **retracted** + 114-unit plate period; +* a run-average rate is the wrong shape for a 3–4 frame event now that the + presented rate is known to rise 33 % across a boot. + +Redone on their corrected segments the two runs give **8.95** and **6.71** units. +⚠️ They were reconciled as agreeing within ±1 — but one frame is a **third** of +this quantity, and overlapping error bars are not agreeing central values. The +range is ~6.5–9.2 and the port sits at the top. + +**The value is unchanged and I am not changing it**: that would be my arithmetic +on their instrument, and the port does not author a number the corpus has not +given. It is proposed, not adopted. + +What would settle it: **one more draw-stream run of the boot**, with the arm +confirmed, counting frames with no sprite quad between the splashes. A third +sample turns a 3-vs-4 disagreement into a measurement. It needs no button press, +so it should sit the safe side of the Ⓐ blocker. + +✅ Not in doubt: the hold is real. Until 2026-08-29 the port had **no black frame +at all** where the oracle measures a plateau, and both boundary frames still +carry picture (alpha 7 and 34), so the true hold is shorter than whatever this +lands on. diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 39114e14..d49ef11a 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -5312,3 +5312,52 @@ grounds to revisit the port's `60`. It is not. 60 is the **game's logical unit rate** (HANDOFF Q1, measured), the port renders at its own frame rate and converts through it, and guest pacing cannot reach it. `authored/timing.json` now says so at the constant itself, where someone about to change it will read it. + +## The n=1 disclosure, and the one port constant that rests on a single run + +The Decoder disclosed that their `ARM=early` capture silently loses its trigger +**~40 % of the time** — two of five runs logged `ARMED EARLY` and produced no +draw log at all, indistinguishable in the session log from a run that armed. So +every draw-stream figure of theirs is **n = 1**. + +That is worth more than the number it was attached to, because the port authors +constants from those runs. Auditing which: exactly one, +`black_hold_units = 9`. Everything else comes from the disc (the declared dwells +255/210, the settle window, the plate period), from the exporter, or from +multi-sample measurements (Q1's unit rate over seven frames, Q5's navigation). + +**9 is not wrong, and three of its supports have moved.** Its conversion used a +105-frame count their own truncation fix has revised to 114; its second +corroboration (2.231) is the figure behind their retracted plate period; and a +run-average units-per-frame is the wrong shape for a 3–4 frame event now that the +rate is known to rise 33 % across a boot. Redone on their corrected local +segments, their two runs give **8.95** and **6.71** units. + +⚠️ Those two were reconciled as replicating "within the ±1 both are quantised +to". **Overlapping error bars are not agreeing central values** — one frame is a +third of this quantity. The range is ~6.5–9.2 and the port sits at the top of it. + +The value stays. Changing it would be my arithmetic on their instrument, and this +port does not author a number the corpus has not given; it is filed as a proposal +in `BLOCKED.md` with the one run that would settle it. ✅ And what is not in doubt +is that the hold is **real**: until this was implemented the port had no black +frame at all where the oracle measures a plateau. + +### Their statistics, checked + +Their per-boot excesses reproduce exactly: **+0.89 %, +8.24 %, +6.79 %**, spread +7.35 pp, wider than the 5.30 pp gap under test — so boot 1 alone essentially *is* +the declared ratio. Their concession is right and my 2.4× cannot carry the weight +I gave it. + +One refinement, which cuts **against** their concession rather than for it: their +2.3 σ uses the *population* SD (3.178). At n = 3 the sample SD (3.892) is the +right estimator, giving **1.89 σ** — their run is *less* of an outlier than they +credited themselves with. Testing the other question, whether the corpus mean +differs from their prediction, gives t = 3.27 on 2 df, p ≈ 0.08. **Neither +framing reaches significance**, which is where both of us landed anyway. + +📌 Their sharpening of the instrument point is the keeper: a truncated log and a +`--screen=NAME` render at t=0 both return a **complete, well-formed answer to a +different question**. That is why neither looks like an error — nothing inside +either view can tell you it is not the view you asked for.