fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: audit what rests on a single draw-stream run; black_hold_units=9 sits at the top of its range

Browse Source 
Their ARM=early disclosure (~40% silent trigger loss) makes every draw-stream
figure n=1. Exactly one port constant depends on one: the black hold. Three of
its supports have moved -- the 105-frame count they revised to 114, the 2.231
corroboration they retracted, and a run-average rate now known to drift 33%.

Redone on their corrected segments the two runs give 8.95 and 6.71 units, not
one number: overlapping +/-1 error bars are not agreeing central values when one
frame is a third of the quantity. Range ~6.5-9.2, port at the top.

Value UNCHANGED and proposed rather than adopted -- it would be my arithmetic on
their instrument. Filed with the single run that would settle it.

Also checks their statistics: per-boot excesses reproduce exactly, and their
2.3 sigma uses population SD where sample SD gives 1.89 -- cutting against their
own concession. Neither framing reaches significance.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-29 21:43:02 +00:00
parent cb111e0642
commit 733e376366
3 changed files with 125 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
authored/timing.json
View File

@@ -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."

37
docs/port/BLOCKED.md
View File

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

49
docs/port/DECISIONS.md
View File

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