From 12952a87de58652cdfcd1ff6650dd91a730b869d Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 17:20:59 +0000 Subject: [PATCH] handoff: one units-per-second cannot be right, the splash timeline is confirmed, and H5 refuted 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. --- docs/port/HANDOFF.md | 107 ++++++++++++++++++ docs/re/data/title-pair-bundles-identical.txt | 35 ++++++ 2 files changed, 142 insertions(+) create mode 100644 docs/re/data/title-pair-bundles-identical.txt diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 2cc1dddb..129a9c13 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -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 diff --git a/docs/re/data/title-pair-bundles-identical.txt b/docs/re/data/title-pair-bundles-identical.txt new file mode 100644 index 00000000..a2f65f3f --- /dev/null +++ b/docs/re/data/title-pair-bundles-identical.txt @@ -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.