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

port: the plate's period is 120, decoded -- and 105 was falsified with my own ring number

Browse Source 
The Decoder found it in the format: a nested record is itself a RATC bundle and
its header's +0x08 is the LOOP LENGTH. A record's keyframes need not fill it and
the slack is a hold at the final pose, so ptbtn00f is 105 units of ramp inside a
120-unit cycle -- the glow rests dark for 15 units. The five ptbtn0Nf records
fill their 120 exactly, which shows the slack belongs to that record and not to
the format. Disc-wide over 1781 timed nested records: 92.3% declare exactly their
last keyframe time, 7.7% more, 0 LESS -- the falsifier never fires.

THE DECISIVE TEST USED THIS PORT'S NUMBER. Both candidates need the same emulator
pacing factor, and the ring measures it independently: declared 120 -> 2.177 s ->
1.0885. 105 units needs 1.211-1.337 to reach the measured 2.12-2.34 s, which
EXCLUDES it; 120 units needs 1.060-1.170, which CONTAINS it. Two different
elements in different bundles, separate runs, tied only by both declaring 120.

My three readings in order are the useful record: 129 (105 + the since-deleted
exit_ramp_units) fitted the measurement for a reason that evaporated; 105 (the
group length) I shipped knowing it was 17% short; 120 is decoded. And the
123-vs-129 pair I once called unseparable STRADDLED the right answer without
containing it -- the sharpest argument I have seen against treating "two
candidates, nothing separates them" as if the truth must be one of the two.

Verified bit-identical 120 units apart (mean 0), 0.061 at a quarter, 0.888 at
half. Still authored because the pinned tag does not expose +0x08; delete the
entry the day a tag does.

THEIR rest() FLAG, CHECKED RATHER THAN ASSUMED: they warned a focus record is the
kind of element rest() mishandles. Censused -- 34 focus-record elements, only 2
with a varying alpha, both ptbtn00f, whose rest.alpha of 80 IS their peak,
exactly the pathology described. The port does not hit it because the plate draws
through the loop path, and the other 32 are constant-alpha so rest() is safe.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-29 19:42:28 +00:00
parent d57366a35f
commit 4031a9c58d
2 changed files with 83 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
docs/port/DECISIONS.md
View File

@@ -4371,3 +4371,53 @@ reason that has evaporated.
Verified: the plate is bit-identical 105 units apart (mean diff **0**) and differs
at 30 units (0.83). ❔ What would resolve the disagreement: whether the group
loops from its start at all, or holds at alpha 0 between cycles. Asked.
## The plate's period is 120, decoded — and it was falsified with my own ring number
The Decoder found it in the format: **a nested record is itself a RATC bundle,
and its header's `+0x08` is the loop length** — the same field
`ui_header_time_disc` already tests at the top level. A record's keyframes need
not fill it, and the slack is a hold at the final pose. **`ptbtn00f` is 105 units
of ramp inside a 120-unit cycle**, so the glow rests dark for 15 units. The five
`ptbtn0Nf` records fill their 120 exactly, which is what shows the slack belongs
to *that record* rather than to the format.
Disc-wide over 1 781 timed nested records: 92.3 % declare exactly their last
keyframe time, 7.7 % declare more, **0 declare less**. That last row is the
falsifier — a cycle cannot restart before its own last pose — and it never fires.
### The decisive test used this port's number, not theirs
Both candidates need the same emulator pacing factor, and **the ring measures it
independently**: declared 120 units → 2.177 s → **1.0885**.
| plate period | nominal | factor needed for the measured 2.12–2.34 s | |
|---|---|---|---|
| 105 units | 1.750 s | 1.211 … 1.337 | 🔴 excludes 1.0885 |
| **120 units** | 2.000 s | 1.060 … 1.170 | ✅ **contains it** |
**105 cannot reach the measured range under any pacing the ring also satisfies.**
Two different elements in different bundles, measured in separate runs, tied only
by both declaring 120.
⚠️ **My three readings of this number, in order, are the useful record:** 129
(`105 + exit_ramp_units`) fitted the measurement for a reason that later
evaporated; 105 (the group length) I shipped *knowing* it was 17 % short; 120 is
decoded. And the 123-vs-129 pair I once called unseparable **straddled the right
answer without containing it** — which is the sharpest argument I have seen
against treating "two candidates, nothing separates them" as if the truth must be
one of the two.
Verified: bit-identical **120 units** apart (mean diff 0), 0.061 at a quarter and
0.888 at half. Still authored, because the pinned tag does not expose `+0x08`
yet — **delete the entry the day a tag does.**
### Their `rest()` flag, checked rather than assumed
They warned that a focus record is exactly the kind of element `rest()`
mishandles, since a pulse's last hold is not its resting state. Censused: **34
focus-record elements in the export, and only 2 have a varying alpha** — both
`ptbtn00f`, EN and JP. Their `rest.alpha` is **80, identical to their peak**,
which is precisely the pathology described. The port does not hit it because the
plate is drawn through the loop path, and the other **32 are constant-alpha, so
`rest()` is safe for them**. Bounded, not hoped.