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
168 lines
9.4 KiB
Markdown
168 lines
9.4 KiB
Markdown
# ✅ `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`](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`](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`](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. |