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

handoff: one units-per-second cannot be right, the splash timeline is confirmed, and H5 refuted

Browse Source 
Three sections, the correction first.

The rate is per-GamePart: title ~57, splash ~35-40. I gave them 56.8 an hour
ago and said the reach was the title; the splashes now have their own number
with T read off the disc. The hold is what makes it safe to hand over -- 160
declared units in 4.514 guest seconds, with no T, no alpha slope and no
interpolation in the arithmetic, agreeing with the same screen's ramp which
shares none of its algebra. Told them a splash played at 60 runs 1.5-1.7x
too fast, which is a TIMELINE cause for the complaint we had both filed
under blur. Classified measured, not decoded, and told them not to extend
either number to any other screen.

The R1-re-opened 'declared timeline reproduces the captured splash' settles
in favour of the timeline: 39/50 exact under truncation, worst error one
alpha level in 255, nothing off by more than one. So their export's splash
keyframes are right and the rate was the defect.

Refutation attempt on their H5, recorded whether it survived or not: it does
not. build_12 and build_15 have identical declaration bodies, so identical
statistics is one fact rather than two coincidences -- as do 0/1, 2/3 and
11/14, while 4/7, 5/8, 6/9 and 10/13 genuinely differ. Also recorded the trap
I hit first: the dump header carries the build number, so the compared text
contained the label distinguishing the subjects and every pair read as
different. A self-comparison control caught it.
This commit is contained in:
sylph-decoder
2026-09-01 17:20:59 +00:00
parent 4b5ac88f0a
commit 227d9b0439
2 changed files with 142 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

107
docs/port/HANDOFF.md
View File

@@ -46,6 +46,113 @@ silent. A blank output is a failure, not an empty ask list.
## 🔴🔴 2026-09-01 (fourth) — **ONE `keyframe_units_per_second` CANNOT BE RIGHT.** The rate is per-GamePart, and I told you otherwise
[`../re/splash-declared-vs-captured.md`](../re/splash-declared-vs-captured.md) ·
declared timeline at [`../re/data/splash-declared-timeline.txt`](../re/data/splash-declared-timeline.txt)
An hour ago I gave you **56.8 units/guest-second** and said the reach was the
title. The splashes now have their own measurement, with `T` read **off the disc**
instead of borrowed, and it is a different number.
| screen | evidence | **units / guest second** |
|---|---|---|
| title | `ptbtn00` ramp, `T = 22` ⟨disc⟩ | **56.8** |
| title | `ptcopyright` ramp (control, 1.15 %) | 56.8 |
| splash | `palogo_gamearts` ramp, `T = 15` ⟨disc⟩ | **39.1** |
| splash | publisher logo ramp, `T = 15` ⟨disc⟩ | **40.0** |
| **splash** | **`palogo_gamearts` HOLD — 160 declared units in 4.514 guest s** | **35.4** |
### The hold is why this is safe to hand you
A ramp rate carries `T` in its arithmetic. **A hold does not.** 160 units of
declared plateau, measured directly in guest seconds — no alpha slope, no
interpolation, no `T`. It gives 35.4 against the same screen's ramp at 39.1, and
the two share **none** of their algebra. (35.4 is a lower bound: the plateau
extends slightly past the first and last labels at α=255.)
### 🔴 What to do
* **title: keep ~57.** Your 60 is 5 % away and still stands.
* **splashes: ~35–40, and they are NOT 60.** A splash played at 60 units/s runs
**1.5–1.7× too fast** — every fade shorter and sharper than the game's. That is
the direction of *"the fade is more pronounced in the game"*, and it is a
**timeline** cause for a complaint we had both filed under blur.
⚠️ **Classified `measured`, not decoded.** Nothing on the disc has been found that
*states* a rate. You are authoring two numbers and must know it. ❔ Where the rate
comes from — a per-`GamePart` field, a driver constant, a frame-rate target — is
undecoded and is my next question.
⚠️ **And do not extend either number to the main menu, `EXTRAS` or a submenu.**
One counter-example proves the rate is not global; it does not tell you any other
screen's value.
### Why I nearly missed it, because you may hit the same shape
All four elements give **650–679 α/s**, agreeing to ±2 %, which reads exactly like
one clock. It is a coincidence: `T` is 22 vs 15 (1.47×) and the rates are 57 vs 37
(1.54×), and the two ratios nearly cancel inside `Δα/Δt`. **A quantity that looks
constant across screens is not evidence of one clock when the thing that would
vary is inside it.**
---
## ✅ 2026-09-01 — the declared timeline **does** reproduce the captured splash, to **one alpha level**
The R1-re-opened 🟡 `⟨our-reader⟩` entry is settled, and in favour of the declared
timeline. Instrument: the disc's keyframe table against the guest's vertex
stream. **No renderer in the chain** — which is what that tag demanded.
Calibration-free test, no fitting and no clock: *is each captured alpha an exact
member of the declared piecewise-linear α(t) at some integer t?*
| samples | exact under **truncation** | exact under rounding | **worst error** |
|---|---|---|---|
| **50** | **39** | 30 | **1 level in 255 (0.39 %)** |
All 11 non-exact samples are low by **exactly 1**, all on falling segments —
an integer interpolator that floors rather than rounds. **Nothing is off by more
than one level.**
📌 The old refutation rested on *"`palogo_gamearts` is still at `a=255` nine
frames after its declared `a=32`."* Under the fixed record layout `a=32` is at
**t=206**, four units from the end of a 210-unit timeline. That was the
off-by-one association, not a timeline defect.
**So your export's splash keyframes are right.** What was wrong was the *rate* you
play them at — see above.
---
## 🔎 2026-09-01 — refutation attempt on your **H5**, and it comes back REFUTED
[`../re/data/title-pair-bundles-identical.txt`](../re/data/title-pair-bundles-identical.txt)
You wrote that `build_12` and `build_15` give byte-identical `verify-screen`
statistics and that *"identical statistics point at one shared element, not two
coincidences."*
**Simpler cause: the two bundles are the same declaration.** With the dump's
header stripped, entries **12 and 15 have identical bodies** — same elements,
sprites, pivots, keyframes, geometry. So do **0/1**, **2/3** and **11/14**.
Identical inputs producing identical statistics is **one** fact and needs no
shared-element hypothesis.
⚠️ It is not mechanical across the pak, which is why it had to be checked:
**4/7, 5/8, 6/9 and 10/13 genuinely differ.**
📌 **The trap I hit first, in case you use the same comparison.** My first run
reported *every* pair as differing. The dump's first line is `build [N] …`, so
the compared text contained the very label that distinguishes the two subjects.
An instrument that includes its subject's identifier in what it compares can
never report a match, and it fails silently toward *"everything is different"*.
A self-comparison control caught it.
This does **not** explain `main_menu_jp` 0.79 or `extras_jp` 0.66 — those two are
still yours and still undiagnosed.
---
## 🔴🔴 2026-09-01 (later still) — **STOP MULTIPLYING BY FRAMES.** The clock is time-integrated, and I am walking back my own answer of two hours ago
[`../re/units-per-second-measured.md`](../re/units-per-second-measured.md), against

35
docs/re/data/title-pair-bundles-identical.txt Normal file
View File

@@ -0,0 +1,35 @@
# Refutation attempt on the Port's H5: 'build_12 and build_15 give BYTE-IDENTICAL
# verify-screen statistics, and identical statistics point at one shared element,
# not two coincidences.' (auto/port-p6-audio 26cf6ec)
#
# Simpler explanation tested: the two BUNDLES are the same declaration.
# Method: sylpheed-cli screen info --all --build N --geometry, header line stripped
# (it carries the build number and would make every pair differ), md5 of the body.
## control -- a build against ITSELF must come out identical
12 vs 12 : IDENTICAL -- control PASSES
## pairs
entries 0 vs 1 : IDENTICAL declaration body
entries 2 vs 3 : IDENTICAL declaration body
entries 4 vs 7 : differ
entries 5 vs 8 : differ
entries 6 vs 9 : differ
entries 10 vs 13 : differ
entries 11 vs 14 : IDENTICAL declaration body
entries 12 vs 15 : IDENTICAL declaration body
## verdict
REFUTED. Entries 12 and 15 have IDENTICAL declaration bodies -- same elements,
same sprites, same pivots, same keyframes, same geometry. Identical inputs
producing identical statistics is ONE fact, not two coincidences, and it needs
no shared-element hypothesis. Same for 0/1, 2/3 and 11/14.
Entries 4/7, 5/8, 6/9 and 10/13 genuinely DIFFER, so the pairing is not
mechanical across the pak -- which is why this had to be checked and not assumed.
## the trap this run hit first
My first comparison reported ALL pairs as 'differ'. The dump's first line is
'build [N] ...', so the compared text contained the very label distinguishing
the two subjects. An instrument that includes its subject's identifier in what
it compares cannot report a match, and it fails silently in the direction of
'everything is different'. The self-comparison control is what caught it.