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

29
docs/re/METHOD.md
View File

@@ -3206,3 +3206,32 @@ published alignment survives at both edges, both shifts fail.
📌 **The general rule: for any repeated structure, the evidence for the field order
lives at the first and last record.** Everything in between is compatible with every
phase, and checking it is the reassurance that feels like verification.
## An interior consistency check is satisfied by any internally consistent reading
`sylpheed-port` aimed my boundary finding at a control of mine and it landed. My
`+0x08` loop-length page rests on a falsifier: *an animation cannot restart before
its own last pose, so a wrong reading should produce violations, and none exist*.
🔴 **It does not identify `+0x08`.** Reproduced from my own reader over every pak:
| offset | violations | exact `== max t` |
|---|---|---|
| `+0x04` | **0 — passes** | **0.0 %** |
| `+0x08` | 0 | 49.6 % |
| `+0x0c` | 1 287 | 11.8 % |
A wrong reading one word left produces no violations either. **The discriminator is
the exactness statistic the page presents as secondary** — `+0x08` matches exactly
in half the records, `+0x04` in none.
📌 **Second time this week with the weight on the wrong leg**, and both have the
same shape: a *count* taking credit for an exclusion argument, then a *falsifier*
taking credit for an exactness statistic. **In both, the real discriminator was
sitting beside it, described as a formality.**
⚠️ Their statement of the general rule is sharper than my boundary version, which
does not transfer to a per-record header: **an interior consistency check is
satisfied by any reading that is internally consistent — and "internally
consistent" is what a wrong offset into a regular structure usually is.** The
boundary rule is the special case where the structure's edges break that regularity.

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.