re: the splash timing table was already reading the corrected pairing

Cargo.lock

@@ -4618,6 +4618,18 @@ dependencies = [
  "tracing-subscriber",
 ]
 
+[[package]]
+name = "sylpheed-export"
+version = "0.1.0"
+dependencies = [
+ "anyhow",
+ "clap",
+ "image",
+ "serde",
+ "serde_json",
+ "sylpheed-formats",
+]
+
 [[package]]
 name = "sylpheed-formats"
 version = "0.1.0"

docs/re/ui-keyframe-record-layout.md

@@ -176,6 +176,21 @@ the two elements' groups do not appear to start on the same frame. That offset i
 word is which. It is the same lateness `ui-keyframe-time-unit.md` records as
 "17 frames late" and leaves open.
 
+### And the corpus had already used this reading without noticing
+
+[`ui-title-build-map.md`](ui-title-build-map.md)'s splash timing table — written
+on 2026-08-28 against a 10 fps capture, and agreeing with it to ±0.1 s — reads
+`palogo_sqex.t32`'s declared `[15 30 235 239 251 255 –]` as
+
+| | the table says | the OLD reading actually gives | the corrected reading gives |
+|---|---|---|---|
+| hold at α=255 | `30 → 235` = **3.42 s** ✅ measured ≈3.5 s | `235 → 239` = **0.07 s** | `30 → 235` = **3.42 s** |
+| fade out | `235 → 255` = **0.33 s** ✅ measured ≈0.3 s | `239 → ?` — the α=0 pose is **untimed** | `235 → 255` = **0.33 s** |
+
+Its author paired each time with the pose that *reaches* it, by eye, because that
+is the only pairing that produces a sensible splash — and then checked it against
+a capture, which agreed. The record layout is what that pairing was.
+
 ## What changed in the code
 
 [`crates/sylpheed-formats/src/ui_layout.rs`](../../crates/sylpheed-formats/src/ui_layout.rs):