Sylpheed/docs/re/boot-order-and-splash-dwell.md

The boot's first ten seconds: publisher, then developer — and the movie has a logo card too

Status: ✅ CONFIRMED. The order is measured in three independent cold boots and confirmed by eye, not only by a correlation. The dwells are decoded — they are on the disc, and the running game reproduces them to within the emulator's own frame pacing.

Raised by the port agent against data/boot-timeline-2026-08-29.tsv, whose label column runs splash_dev before splash_pub — the opposite of what authored/flow.json carries. If that ordering were real it would be a boot-order bug in the port. It is not real, and this page says why.

The order: publisher first

Brightened ×6 — these frames have a surface mean of ≈5/255. Top-left and top-right are the two splashes; the bottom row is what comes next and is NOT a splash.

run	SQUARE ENIX (publisher)	GAME ARTS/SETA/studio anima (developer)
1	3.046 → 7.343 s	7.683 → 11.191 s
2	1.180 → 5.784 s	6.051 → 9.554 s
3	1.192 → 5.562 s	5.929 → 9.295 s

Three cold boots, t = 0 at process launch, a ~0.2–0.3 s black hold between them. Publisher first, every time, and the top row of the contact sheet is what the two segments actually show. docs/game/navigation.md §1 and ui-title-build-map.md stand.

Why the committed TSV says otherwise — the probe attached late

data/boot-timeline-2026-08-29.tsv opens at t = 0.692 with twelve byte-identical rows: mean 5.642, splash_dev +0.8707, splash_pub +0.0294, to four decimals. Twelve identical samples over 1.27 s are one observation of a held screen, not twelve.

Those exact numbers appear in my run 1 at 8.42 – 10.94 s — same mean, same two correlations, same four decimals. So that capture's t = 0 is roughly 7.7 s into the guest's boot: the publisher splash had already been and gone before the stream opened, and the developer splash was simply the first thing the probe ever saw.

The label column is right about what each frame is. It is wrong about what came before the file starts. Nothing in the TSV is retracted; its reach is.

The trap that makes this worse: ADV.wmv opens with a SQUARE ENIX card

After the developer splash there is a black hold and then a screen that scores 0.59 – 0.75 against live-splash-publisher.png — above the classifier's threshold, so it is labelled splash_pub a second time. In all three runs:

run	second "splash_pub"
1	17.793 → 20.301 s
2	16.930 → 20.664 s
3	14.669 → 17.308 s

The bottom row of the contact sheet is that screen. It is a blurred, bloomed SQUARE ENIX wordmark, lower in the frame — the intro movie's own opening title card, i.e. ADV.wmv (movie-binding.md) already playing. The real splash's wordmark is sharp and centred; the movie's is soft and sits below centre.

⚠️ So splash_pub is not a safe label once the movie has started. A boot classifier keyed on live-splash-publisher.png will fire twice per boot. The discriminators that do work: the real splash holds perfectly still (identical frame statistics to four decimals for seconds at a time) and scores 0.93–0.94; the movie card drifts continuously and never exceeds 0.76.

The dwells are on the disc — do not author them

Both splash bundles declare their whole life. Read with the corrected keyframe record layout (ui-keyframe-record-layout.md) and Q1's 1 unit = 1/60 s:

	declared	visible span	measured (run 1 / 2 / 3)
publisher, palogo_sqex.t32	α 0@15 → 255@30 → 255@235 → 232@239 → 32@251 → 0@255	15 → 255 = 240 u = 4.000 s	4.297 / 4.604 / 4.370 s
developer, palogo_gamearts.t32 (seta, anima identical)	α 0@15 → 255@30 → 255@190 → 232@194 → 32@206 → 0@210	15 → 210 = 195 u = 3.250 s	3.508 / 3.503 / 3.366 s

Measured ÷ declared, over all six spans: 1.074, 1.151, 1.093, 1.079, 1.078, 1.036 — mean 1.085. A 30 Hz timeline stretched by 8.5 % is the game presenting at 27.6 fps, which is the rate this corpus has measured independently three times (27.6 on the boot splash, 28.3 and 28.8 on the idle title — ui-keyframe-time-unit.md).

✅ Classified decoded. The port reads 240 units for the publisher and 195 units for the developer and authors nothing.

🔴 WITHDRAWN — "the game runs them ~8.5 % long". I measured one element's span and called it the screen's.

Retracted the same day. sylpheed-port said the port plays the full group — 255 and 210 units — not my 240/195, and they are right for a reason sharper than either of us first had. The _eff elements ramp α 0 → 255 over t=0..15, while the main logo is still fully transparent there:

palogo_sqex.t32      0:a=0   15:a=0    30:a=255  235:a=255 239:a=232 251:a=32 255:a=0
palogo_sqex_eff.t32  0:a=0   15:a=255  30:a=212   45:a=0

So the screen is visible from within t=0..15, and its visible span is 0→255 and 0→210 — the full group. My "240 units visible" was one element's visible span, computed while another element of the same build was already on screen.

Recomputed against the screen:

	ratios
publisher (255 u = 4.250 s)	1.011, 1.083, 1.028
developer (210 u = 3.500 s)	1.002, 1.001, 0.962	one below unity
mean	1.0145	against 1.085 before

A 1.5 % mean with a measurement below unity is not a clock running at 54 u/s. The systematic is gone and Q1 stands unqualified.

⚠️ And the consequence I drew was wrong too. "A port playing 240 units at 60 shows the publisher splash 0.42 s less" — it plays 255, so the gap is 0.174 s, and on the developer splash the port runs longer than my mean. There is no direction to correct in, and nothing here supports moving keyframe_units_per_second.

🟡 What survives, weakly: against the full group the publisher still runs long in all three boots (1.011, 1.083, 1.028) while the developer sits at unity. Three boots per screen is thin and it is not a systematic.

✅ And the splash builds carry their own OPAQUE BLACK backdrop — verified

sylpheed-port found the fifth family member on their own side while confirming the above: their "visible" test counted any element with alpha > 0, which includes palogo_eff0.prm. Checked against the disc (tools/re-capture/fade_quads.py e10 e11):

entry 10   [0] palogo_eff0.prm  1 kf   t=0  fade=0xff000000 (alpha 255)  scale=100x100  pos=(0,0)
entry 11   [0] palogo_eff0.prm  1 kf   t=0  fade=0xff000000 (alpha 255)  scale=100x100  pos=(0,0)

Alpha 255 over RGB 000000: full-screen opaque black, drawn from t=0 and showing nothing. So "any element drawn" reports these screens visible from t=0 while the frame is black — "visible" read as "drawn", the fifth member.

📌 Worth having on its own: this verifies, from the disc, the premise behind screen render --black — "what the game composites over on a screen carrying its own background, and so what a framebuffer capture must be compared against". On the splash builds that background is declared, not assumed.

📌 This is the fourth instance of one family — pivot anchor read as drawn extent, centre track as bounding box, cycle length as motion duration, and now one element's visible span read as the screen's. Every one is a number used as though it described the thing beside it.

sylpheed-port reported their verify-dwell at 4.28 s / 3.58 s and called it agreement with these boots. Checking the arithmetic rather than the impression:

	declared	at Q1's 60 u/s	measured (3 cold boots)	ratio
publisher	240 u	4.000 s	4.297 / 4.604 / 4.370, mean 4.424	1.106
developer	195 u	3.250 s	3.508 / 3.503 / 3.366, mean 3.459	1.064

All six ratios exceed 1 — 1.074, 1.151, 1.093, 1.079, 1.078, 1.036 — mean 1.085. The implied unit rate is 54.3 and 56.4 units/s, and the port's own two numbers imply 56.1 and 54.5. Four estimates, none at 60.

⚠️ The obvious explanation does not work. A detector triggering early and late would lengthen the interval — but the declared span is 15 → 255, and outside it the alpha is 0, so there is nothing on screen to trigger on. An 8.5 % overshoot is 20 units, ten rendered frames, which a threshold cannot manufacture from a blank screen.

🟡 So this is a real systematic and its cause is not established. Either the title's timeline advances at ~55 units/s rather than Q1's 60, or the boot inserts something between the declared span and what a capture sees. ⚠️ It is not the same discrepancy as the sweep leaf's (which runs ~50 % slow, not 8.5 %), and I am recording it as an open qualification on Q1 rather than a correction to it — three boots per screen is thin, and Q1 was measured on a different quantity.

📌 For the port: these dwells are still decoded and still should not be authored — but a port that plays 240 units at exactly 60 u/s will show the publisher splash for 0.42 s less than the game does.

⚠️ Reach of the ±: a correlation crossing a threshold during a fade is not a sharp edge, so an individual span is good to roughly ±0.2 s. The developer's first two runs agree to 5 ms, which is the instrument at its best; run 2's publisher span (4.604 s) is the outlier and its onset at 1.180 s is early enough to be a stream still filling. The order does not depend on any of this.

Method

tools/re-capture/boot_timeline_probe.py, whose --control was run first and passed 11/11 on the content classifier and 4/4 on the plate detector, including live-splash-publisher.png → splash_pub and live-splash-developer.png → splash_dev with each rejecting the other at 0.035. So a 0.87 reading against the developer reference is a real match and not an artefact of two dark images: the two references are both dark and they do not correlate with each other.

Both splash references are themselves committed captures whose identity is independent of any correlation — live-splash-publisher.png was matched to GP_TITLE entry 10, whose elements are literally named palogo_sqex, and live-splash-developer.png to entry 11, palogo_gamearts / palogo_seta / palogo_anima.

Boots were cold: /dev/shm/xenia_* cleared, no pad input at any point.

What this does not say

• Nothing here is about the movie's length or the attract loop; the runs were cut at 26–45 s. That half is in data/boot-timeline-2026-08-29.tsv, whose intervals are unaffected by the attach offset even though its absolute t is.
• The 0.2–0.3 s black hold between the two splashes was not separately timed against the declared palogo_eff0.prm backdrop; it is consistent with the 0.14–0.30 s black hold already measured between screens (title-plate-delay-measured.md) but that is a consistency note, not a measurement of this particular gap.