02a99bc3e9
Two corrections to my own recent work, both prompted by the port checking it. First, the settle-time page argued the plate delay discrepancy was an instrument artefact on two legs, and one of them is withdrawn. It said the plate pulse period acts as an internal clock for presentation rate and measured 2.369 s against the corpus s 2.3. That estimate rests on ONE interval between two distinct troughs at a 125 ms sample interval -- uncertainty 0.177 s or 6.7 percent -- and trough-picking on a noisy plateau is fragile enough that re-running it gives 2.628 s, because an adjacent local minimum had been counted as a separate trough. Against the corpus s 2.24 that is +17.3 percent, about two sigma. So the pulse period does not show the run at normal speed; it is too weak to show anything, and cannot resolve a real-time factor below about 7 percent. The conclusion survives on the other leg, which is the sound one: the content-measured 2.247 s agrees with three independent prior readings (2.13 / 2.132 / 2.138), and both its landmarks are sharp content transitions rather than a trough on a plateau. A 17 percent slowdown would have put it at 2.49 s. What that leaves open matters because the port authors from these numbers: the run carries an unmeasured real-time factor under about 7 percent. The plate delay is anchored by agreement with prior runs; the menu build-in and B-to-title are anchored by nothing, so that is a second reason to treat them as provisional. Second, the shared capture is worse than truncated: parec writes the WAV header with zero sizes and patches them on clean exit, so the mid-write copy has RIFF size 8 and data size 0 against 183 MB of actual bytes. Python s wave module refuses to open it; ffmpeg and ffprobe recover by scanning and report a plausible duration, which is exactly why it went unnoticed -- the lenient reader hid it. Also corrects the attribution of the starvation numbers: 39.3 percent and 16680453 frames were measured on the finished local recording, not on the shared artefact. The port measured the shared copy and got 35.6 percent and 15289876 frames, with burst and gap medians agreeing to 0.1 ms. The diagnosis is unaffected but a number must say which artefact it came from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
9.4 KiB
✅ settle_time() — when each boot screen actually arrives, measured
Classification: measured. None of this is on the disc as a settle time. The disc declares keyframes; when a screen visibly arrives is a property of the running game, and the port authors these numbers from this page.
Answers the port's standing ask: its boot sequencer paces every screen off
rest.t, which is the last hold keyframe and not when a screen arrives — it
holds the title for 4.350 s where the build-in is over at about 2 s.
Run: one cold boot, 2026-08-29. Container had no Xenia storage root at
all, so this is a fresh profile (--create_profile_if_none) with no shader
cache — the slowest case, deliberately.
Frame log committed at data/boot-settle-run1.tsv;
analysis tools/re-capture/settle_analyse.py.
The instrument was controlled first, and then caught being wrong
title_timing_probe.py --control passed 9/9 on the content classifier —
including the movie-frame and difficulty-screen negatives — and 4/4 on the
plate detector, before the run. The run itself sampled 2 107 frames in 263.7 s
= 7.99 fps against a requested 8, with an independent one-shot grab every 20 s
agreeing with the stream to under 1 grey level. So this is not the backlog
failure mode that cost this corpus four withdrawn durations.
🔴 And the probe's own title_static mark is still biased early — do not use
it for a duration. It fires when the classifier first labels a frame
title_* and motion is low, which happens during the crossfade out of the
attract movie, before the wordmark has drawn. In this run it fired at
t=242.655 while the green-glyph count was still 0; the title art does not
reach its steady state until 243.595. Any title_static → plate figure from
this probe is therefore inflated by about a second.
The landmarks, taken from content rather than from the probe's marks
The robust landmark is the glyph plateau: the title art alone scores a steady
glyph = 154 (the corpus's live-title-build4-no-plate.png scores 159), and the
plate takes it past 700.
| landmark | t (s) | how |
|---|---|---|
| attract movie ends, first title ink | 243.362 | glyph leaves 0 |
| title art fully drawn | 243.595 | glyph reaches its steady 154 |
PRESS Ⓐ plate on |
245.842 | glyph crosses 400 → 771 |
| Ⓐ pressed | 250.983 | |
| ⚠️ guest load stall | 251.601 – 253.135 | 13 byte-identical frames |
| main menu arrives | 254.707 | classifier |
| main menu settled | 255.238 | motion below a run-calibrated floor |
| Ⓑ pressed | 262.864 | |
| title back | 263.346 |
What the port should author
| measured | ⚠️ | |
|---|---|---|
| title build-in (first ink → fully drawn) | 0.23 s | from first ink; 1.63 s from the first frame the classifier calls title_*, which is where the crossfade starts |
| title settled → plate on | 2.247 s | matches the disc's declared 120 units |
| plate pulse period | ≈2.37 s | trough-to-trough, 248.098 → 250.467 |
| main menu build-in | 0.531 s | |
| Ⓑ → title | 0.482 s | |
| Ⓐ → menu | 3.763 s | 🔴 do not author — contains a 1.53 s emulator load stall, below |
🔴 rest.t is confirmed to be the wrong landmark. The title's rest.t is 251
units = 4.183 s; its art is finished at ~2 s and the plate is on at 2.25 s. A
sequencer pacing off rest.t holds the title roughly twice as long as the game
does.
🟢 A refutation attempt that FAILED — the corpus's 2.13 s plate delay survives
The probe's own marks gave a plate delay of 3.203 s (title_static 242.655 →
plate 245.858), against the corpus's two committed runs at 2.138 / 2.132 s
and a declared 120 units ≈ 2.0 s. A 50 % disagreement, from a cold-cache boot, is
exactly where you would expect the corpus to be wrong.
It is not. The instrument was — but 🔴 one of the two arguments I gave for that is withdrawn (2026-08-29).
- 🔴 WITHDRAWN — "the presentation rate is not depressed in this run". This said the plate pulse period acts as an internal clock and measured 2.369 s against the corpus's ≈2.3 s. Re-examined, that estimate rests on one interval between two distinct troughs, at a 125 ms sample interval, so its uncertainty is ±0.177 s (±6.7 %) — and trough-picking on a noisy plateau is fragile enough that re-running it gave 2.628 s rather than 2.369, because an adjacent local minimum had been taken as a separate trough. Against the corpus's ≈2.24 s that is +17.3 %, about 2σ. So the pulse period does not show the run running at normal speed; it is simply too weak to show anything, and it cannot resolve a real-time factor below ~7 % at all. It should never have carried the argument.
- ✅ The conclusion survives on the other leg, which is the sound one.
Re-measured from content rather than from the probe's mark, steady title art
(
243.595) → plate on (245.842) is 2.247 s, and that agrees with the corpus's three independent readings — 2.13 / 2.132 / 2.138 — to within the ±0.125 s sample interval. Both of its landmarks are sharp content transitions (a glyph plateau, and a glyph crossing), unlike a trough on a noisy plateau. A 17 % slowdown would have put this at 2.49 s; it did not.
⚠️ What that leaves open, and the port authors from these numbers: this run carries an unmeasured real-time factor somewhere under ~7 %, because nothing in it was precise enough to pin one. The plate delay is anchored by agreement with three prior runs; the menu build-in (0.531 s) and Ⓑ→title (0.482 s) are not anchored by anything, and a few per cent of emulator slowdown sits inside them undetected. They were already flagged as one-run figures; this is the second reason to treat them as provisional.
✅ So the 2.13 s stands, the 120-unit reading stands, and the 3.203 s is
title_static firing during a crossfade. Recorded because a failed refutation is
worth as much as a successful one, and because the next person to read the
probe's title_static will otherwise repeat it.
🟢 And the load stall reproduces — third independent run, cold cache
title-plate-delay-measured.md records a frozen
frame on the Ⓐ path in two runs: 14 frames (1.53 s) and 12 frames
(1.39 s), both at surface mean 26.626, and concludes any Ⓐ→menu figure from
this harness is an emulator load time rather than a game constant.
This run is a third: 13 frames, 251.601 – 253.135 = 1.53 s, surface mean
26.631, labelled title_plate throughout.
✅ The claim survives, and is now stronger in a way the earlier runs could not show: this boot had no shader cache at all, so the stall is not a warm-cache artefact. ⚠️ One honest qualification — the earlier note says its two runs agreed "to six decimals"; mine agrees only to three (26.631 vs 26.626), so the mean is reproducible but not byte-identical across all three.
Reach
- One run. The durations above are one cold boot. The two that are cross-checked against independent evidence — the plate delay, against the corpus's two runs and the disc's 120 units; the load stall, against two prior runs — are the ones to lean on. The menu build-in (0.531 s) and Ⓑ→title (0.482 s) rest on this run alone. 🟢 The re-take was offered and declined, 2026-08-29: the port authors neither number, is already within ~0.1 s of both from the disc's own keyframes, and asked that no emulator time be spent on its account. Authoring a one-run measurement over a decoded value would gain nothing measurable. Left provisional deliberately rather than for want of a run.
- Sampling is 8 fps, so every landmark carries ±0.125 s, and the guest's own presentation rate cannot be measured from it — 8 fps is far below the ~28 fps the game presents at, so every sample is a distinct guest frame and repeats only appear when the guest itself stalls.
- The splash dwells are not re-measured here; they are already in
boot-order-and-splash-dwell.md.
🟢 The consumer's own red flag was larger than this measurement supports
Recorded because it is the outcome of the measurement and it went the other way from what the port expected.
The port's standing 🔴 read: "rest.t is the wrong landmark, therefore
everything the sequencer paces off it is late." The premise is confirmed here
and the consequence is not. Measuring the port the same way this page measures
the game — visible span, per-frame greyscale mean — its publisher wordmark runs
4.25 s against three cold boots at 4.297 / 4.604 / 4.370, and its developer logos
3.50 s against 3.508 / 3.503 / 3.366.
⚠️ The discrepancy it was about to chase was the plate-delay trap in a second place. It had been comparing arrival-to-arrival transition timestamps against visible spans; those differ by the exit ramp plus the black hold, about 0.6 s, which was the whole of it — the same shape as timing the title from where it stops animating rather than from where it first appears.
✅ So the generalisation this page supports is narrower than "the sequencer is
late": rest.t is the wrong landmark for the title specifically, where it
overstates by 4.183 s against ~2 s. Whether any other screen is mis-paced does
not follow from it and was not measured here.