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

re: the +0x08 falsifier does not identify +0x08 -- the value is right, my argument was wrong

Browse Source 
sylpheed-port aimed my own boundary finding at my loop-length control. Reproduced
from my reader over every pak: +0x04 has 0 violations too, so the falsifier rejects
+0x0c and accepts +0x04 and never discriminated. What identifies +0x08 is the
exactness statistic the page presents as secondary -- exact match in half the
records against 0 % for +0x04.

Population differs from theirs, 3311 records against 1781, because this scan takes
every pak and requires a timed keyframe, so the percentage moves but the
discrimination does not.

Second time this week with the weight on the wrong leg: a count taking credit for an
exclusion argument, now a falsifier taking credit for an exactness statistic, and
both times the real discriminator sat beside it described as a formality.

Their general form is sharper than my boundary rule: an interior consistency check
is satisfied by any internally consistent reading, and that is what a wrong offset
into a regular structure usually is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 03:52:09 +00:00
parent 91c808d4e5
commit 1adb4e2ee7
3 changed files with 118 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/re/structures/ui-record-loop-length.md
View File

@@ -1,7 +1,31 @@
# A nested record's `+0x08` is its loop length — and the plate holds dark for 15 units
**Classification: decoded.** The field is read from the disc and checked
disc-wide (1 781 records, 0 violations). The consequence for the `PRESS Ⓐ` plate
disc-wide (1 781 records, 0 violations).
> 🔴 **CORRECTED 2026-08-31 — the value is right and this argument for it was
> wrong.** "0 violations" was published as the load-bearing evidence: an animation
> cannot restart before its own last pose, so a wrong reading should produce
> violations. `sylpheed-port` re-ran it at the neighbouring offsets and **it does
> not discriminate.** Reproduced from my own reader over every pak:
>
> | offset | violations (word < max t) | exact (word == max t) |
> |---|---|---|
> | `+0x04` | **0 — passes the falsifier** | **0.0 %** |
> | `+0x08` | 0 | **49.6 %** |
> | `+0x0c` | 1 287 (38.9 %) | 11.8 % |
>
> **A wrong reading one word left produces no violations either.** The falsifier
> rejects `+0x0c` and accepts `+0x04`, so it never identified `+0x08`.
>
> ✅ **What does identify it is the exactness row below, which this page presents as
> a secondary statistic**: `+0x08` equals the largest keyframe time *exactly* in
> half the records and `+0x04` in **none**. No unrelated word reproduces that.
>
> ⚠️ My population differs from theirs — 3 311 records against 1 781, because this
> scan takes every pak and requires a timed keyframe — so the exact percentage
> moves (49.6 % vs 92.3 %). **The discrimination does not**: 0 % for `+0x04` under
> both counts. The consequence for the `PRESS Ⓐ` plate
is then tested against the corpus's existing measurements of the running game,
which it passes and the previous reading fails.