Compare commits

...

615 Commits

Author SHA1 Message Date
46ee0d7f78 chore(agents): restore evidence sharing after the asset purge
Some checks failed
CI / Native — linux (pull_request) Failing after 5m14s
CI / WASM — Web (pull_request) Successful in 36m12s
CI / Formatting (pull_request) Successful in 1m40s
Issue #49 removed game assets from git. It also, silently, removed the only
transport agents had for showing each other evidence: each agent works in its
OWN clone, so "commit the screenshot, the other one pulls it" was the mechanism,
and PROTOCOL.md's file table said so in as many words -- "evidence cited by a
finding -> git". That row sat directly above "🔴 Never commit game content",
which is how 76 MB accumulated: the two contradicted each other and the table
won, because it was the one that told you what to do.

WHAT REPLACES IT

  * one host directory, `Sylpheed/docs/re/captures/`, bind-mounted read-write
    into BOTH agents at /work/docs/re/captures. All three -- host, decoder,
    port -- see the same files live, every citation resolves, and nothing can
    reach git history. Read-write on purpose: showing each other a screenshot
    is the point.
  * PROTOCOL.md's table rewritten. Cited evidence -> present but never
    committed; derived measurements (csv/tsv/txt/log/json) -> still git, they
    are our numbers not game content; evidence that must cross MACHINES ->
    attached to the issue or PR, because a bare clone has no captures.

Verified, not assumed: container A wrote a .png there, a SEPARATE container B
read it back, the host saw it, `git status` reported 0 changes, and
`git check-ignore` named the rule.

THE CHECKER WAS RED ON EVERY CLEAN CHECKOUT

A fresh clone/worktree/CI has no captures, so it called all 134 citations
dangling and exited 1. A gate that is red before anyone changes anything is one
people learn to ignore -- the exact failure this file already carries a comment
about. It now distinguishes "no captures here" (expected, explains itself,
exit 0) from "these are missing" (real, exit 1, unchanged when assets ARE
present). Both paths tested.

ALSO
  * `sylph-decoder` no longer mounts `xenia-rs` -- retired repo, gone from disk,
    the mount pointed at nothing.
  * CONSOLIDATION.md closed: it still described captures as committed and the
    history fork as undecided. Both are settled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-20 13:12:26 +02:00
c0a5840ce8 Merge pull request 'fix: re-lock the self-referencing git dep after the history rewrite' (#60) from fix/relock-after-history-rewrite into main
Some checks failed
CI / Native — linux (push) Failing after 3h1m17s
CI / WASM — Web (push) Successful in 35m42s
CI / Formatting (push) Successful in 2m7s
Reviewed-on: #60
2026-09-20 11:01:57 +00:00
4156cb6bd1 fix: re-lock the self-referencing git dep after the history rewrite
Some checks failed
CI / Native — linux (pull_request) Failing after 2h42m36s
CI / WASM — Web (pull_request) Successful in 33m28s
CI / Formatting (pull_request) Successful in 2m29s
`crates/sylpheed-export` depends on THIS repository by tag:

    sylpheed-formats = { git = "…/Sylpheed.git", tag = "formats-pin-2026-09-01" }

and `Cargo.lock` pinned it to commit `#1cd5b8b1`. The issue-#49 history rewrite
replaced every commit, so `1cd5b8b1` no longer exists on the remote and the tag
now dereferences to `e2630413`.

⚠️ The failure is invisible here: `~/.cargo/git` still has the old object, so
builds on the machine that did the rewrite keep working. A clean checkout --
CI, or the other desktop -- cannot resolve the locked rev at all. That is the
worst shape for a breakage, which is why this was measured from an empty
CARGO_HOME rather than trusted to a local build.

`CONSOLIDATION.md` called this dependency out as the hard blocker for the
rewrite. It was not re-checked before the push; this is the fix.

The dependency's SOURCE is unchanged -- `crates/sylpheed-formats` has tree
`55461e46` at both the old and the new commit, so the rewrite never touched it
and the build result is identical.

Verified:
  * remote tag peels to e2630413, matching the new lock
  * `cargo fetch --locked` from an EMPTY CARGO_HOME -> exit 0
  * `cargo check -p sylpheed-export --locked` -> exit 0

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-19 23:11:06 +02:00
e16556dc29 Merge pull request 'chore(re): stop committing game assets; captures stay local' (#59) from chore/captures-local-only into main
Some checks failed
CI / Native — linux (push) Failing after 6m55s
CI / WASM — Web (push) Failing after 6m24s
CI / Formatting (push) Successful in 1m8s
Reviewed-on: #59
2026-09-19 19:16:47 +00:00
d96b225e47 chore(re): stop committing game assets; captures stay local
Issue #49: the repos carry code, tooling and docs only.

Untracks 143 screenshots, 3 savegame blobs and `tools/re-capture/ob_digits.png`
(a digit-template sheet cut from game frames) -- 146 files, 76.4 MB. They stay
in the working tree and are gitignored, so the pages' relative links still
resolve where the captures exist and nothing ships.

Derived measurements (csv/tsv/txt/log/json/jsonl/npy) are our own numbers, not
game content, and stay tracked -- they are what most claims rest on.

`check-capture-citations` had its contract inverted, and it is the half worth
reading:

  * presence now comes from the WORKING TREE, not `git ls-files`. The assets are
    deliberately untracked, so asking the index would report every screenshot as
    missing and fail all 203 citations.
  * a NEW failure: a game asset that IS tracked. A screenshot that sneaks back
    in is invisible in review -- a binary shows as "Bin 0 -> 1234567 bytes" --
    and is permanent once merged, since removing it later needs a history
    rewrite. So that half has to be loud.

Verified:
  * selftest 8/8, including the new rule
  * scan: 212 present, 212 cited, 0 dangling, 0 tracked  -> exit 0
  * force-add one PNG -> "game assets TRACKED: 1", exit 1, selftest red

⚠️ This does NOT remove the blobs from history; a clone still fetches them.
That needs a filter-repo rewrite and a force-push, which is a separate,
human-run step.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-19 21:03:46 +02:00
4c1e15b818 Merge pull request 'fix(test): open sound.pak once, not once per call' (#58) from fix/slb-suite-one-archive into main
Reviewed-on: #58
2026-09-19 18:48:28 +00:00
9a8746d380 Merge pull request 'fix(ci): run the container as the invoking user, not root' (#57) from fix/ci-run-file-ownership into main
Reviewed-on: #57
2026-09-19 18:48:21 +00:00
1cbbfd90cb Merge pull request 'docs(re): adopt the homeless disc-contents page, re-measured' (#56) from docs/adopt-disc-contents into main
Reviewed-on: #56
2026-09-19 18:48:14 +00:00
e82d7bff6f Merge pull request 'chore: hand the workspace over — the gated launchers, and the state of play' (#55) from chore/handoff-2026-09-18 into main
Reviewed-on: #55
2026-09-19 18:48:08 +00:00
00585952a9 Merge pull request 'ci: pin the toolchain to 1.98.1 in all three jobs' (#54) from fix/ci-pin-toolchain into main
Reviewed-on: #54
2026-09-19 18:48:00 +00:00
cd3c1a2f73 Merge pull request 'test: one disc resolver, no machine-specific defaults, and all three corpora in the CI container' (#53) from fix/corpus-mounts-and-paths into main
Reviewed-on: #53
2026-09-19 18:47:53 +00:00
2f39c8826e fix(test): open sound.pak once, not once per call
`slb_leading_segment_disc` was SIGKILLed by the OOM killer in `docker/ci/run`
at its 7 GB cap, so the documented 45/377 baseline did not reproduce on a 15 GB
box.

`PakArchive` holds the whole concatenated payload in memory and `sound.pak` is
1.01 GB (sound.p00-.p04). `bank()` and `bank_named()` opened it on every call --
inside loops -- and five tests opened their own besides, ~26 opens in all. With
cargo's default thread count that is ~6.1 GB of archive in flight against a
7 GB cap with `--memory-swap` equal to `--memory`, so there is no swap to
absorb it.

The archive is immutable once open and every accessor takes `&self`, so one
`OnceLock` instance is equivalent to N private ones at 1/N the memory.

⚠️ The failure mode is worth knowing: a SIGKILLed suite prints no
`test result:` line at all, so it disappears from a scraped tally instead of
failing visibly. The run still reported "0 failed" -- true, and useless. Check
cargo's exit code (101), not the tally.

Measured in the capped container, 7 GB, default threads:
  * before: SIGKILL (signal 9), 0 of 10 tests reported
  * after : 10 passed in 3.17s
  * (single-threaded before the fix: 10 passed in 22.64s -- the fix is also
     ~7x faster, because it no longer re-reads 1 GB from disc 26 times)
  * cargo fmt --check clean; cargo clippy --tests -D warnings clean

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-19 16:59:10 +02:00
4a8f1221b2 fix(ci): run the container as the invoking user, not root
Docker on the dev boxes is rootful, so without `--user` every byte the build
writes into the bind-mounted repo is owned by root and the user needs `sudo` to
delete their own artifacts. This is not hypothetical: `export/` in a working
tree held 227 root-owned paths (149 MB) from earlier runs, and the `sylpheed.db`
regen in the workspace CLAUDE.md writes straight into /work, so it lands
root-owned every time.

The catch is that the daemon creates a named volume root-owned, so a `--user`
container cannot write /cargo or /target at all. So take ownership of both
volumes first -- once, and only when it is actually wrong, since a recursive
chown across a ~36 GB target volume is not something to repeat per invocation.
Both are sampled, not just one, because an older run can leave them drifted.

Volume names become overridable (SYLPH_CI_CARGO_VOL / SYLPH_CI_TARGET_VOL),
which is what let the chown path be tested without touching the real caches.

Placed above the corpus-mount block so it does not collide with #53.

Measured, not assumed:
  * fresh root-owned volumes  -> chowns once, then writes as uid 1000
  * second run                -> no chown, correctly cached
  * `cargo check -p sylpheed-ppc` through the runner -> passes, exit 0
  * a file touched in /work   -> owned fabi:fabi, removable without sudo

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 21:30:29 +02:00
06601c2a48 docs(re): adopt the homeless disc-contents page, re-measured
`GAME_CONTENTS.md` sat in the workspace root through the whole consolidation,
adopted by neither repo -- the corpus documents formats in depth but never said
what files the disc holds or where they sit.

Re-measured rather than transcribed, and that caught a real error: the source
placed `resource3d/`, `DefTables` and `MiscBin` under `dat/`. All three are in
`hidden/` -- which is why `SYLPHEED_RES3D` points at `hidden/resource3d`.
Counts, the language table and `media_id` (0x2D2E2EEB, from the XEX header)
re-verified against the retail extract.

Half the source was pre-RE speculation phrased as status -- `dat/*.pak` marked
"Unknown, magic bytes TBD" when the container is decoded disc-wide, plus a table
guessing each archive's contents from its name. Carrying that forward would put
claims into the corpus the corpus has already refuted, so it is dropped and the
page says what was dropped and why. INDEX.md stays the single authority on
format status.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 21:07:03 +02:00
sim
e45a56ad83 chore: hand the workspace over — the gated launchers, and the state of play
Resuming happens on the other machine, so anything that lived only in this
workspace either comes into the repo or gets named as something to carry.

**The launchers come in.** `run-canary-safe.sh` (Wine) and
`run-canary-native-safe.sh` (native) are the ONLY sanctioned way to start Canary
from the editor — they force software Vulkan and refuse to launch while a
hardware Vulkan device is visible, because Canary on the AMD GPU takes VS Code
with it. They sat in the workspace root, outside git, hardcoding one machine's
absolute paths, which is exactly why they could not be checked in. They now
derive the workspace from their own location and honour `$SYLPHEED_ISO` and
`$CANARY_BIN`, so the layout is a default rather than a requirement. Same for
`run-canary-native.sh` (interactive, hardware Vulkan — not from the IDE),
`diagnose-freeze.sh`, `live-guest-state.sh`, `heaptrack-wrap.sh` and the
`asound-null.conf` the native launcher needs beside it.

Both safe launchers were run from `tools/` before this commit: the native one
reached content in 20 s (`VERDICT: HEALTHY`, title + 25,398 XMA lines, no
faults), the Wine one ran 25 s and logged 4 `ADV.wmv` hits.

**`docs/agents/HANDOFF-2026-09-18.md`** records what changed since 2026-09-16,
what is on the server, what cannot travel through git, and the traps this machine
paid for — chiefly that the guest-PC branch probe exists only on the fork's
snapshot branch, so a rebuild from `sylpheed-re` silently loses it.

**`HANDOFF-2026-09-06.md`** gets a correction note rather than an edit: a plain
clone works again now that the 545 MB branch is gone, and its baselines are two
baselines old.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 07:17:36 +02:00
sim
c88391b68c ci: pin the toolchain to 1.98.1 in all three jobs
All three jobs used `dtolnay/rust-toolchain@stable`, so the gate resolved to
whatever stable was on the day it ran. A floating lint gate is not a gate: the
same tree goes green or red by date, and that already produced a disagreement
between two people reading the same commit — `collapsible_else_if` is `warn` on
1.92.0 and `allow`-by-default pedantic on 1.98.1, so both readings were correct.

1.98.1 is what run 206 resolved and what `docker/ci/Dockerfile` already pins, so
`docker/ci/run cargo clippy …` on a desktop becomes a true stand-in for this
workflow instead of an approximation. The header says how to bump: the three
refs here and the Dockerfile's `FROM` in one commit, in a PR of its own, where
the lints the new version turns on are the diff.

Also: the corpus-report step's comment quoted `207/0/14`, a tally two baselines
old. It now describes the shape of the problem without pinning a number that
decays.

Closes #15.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 22:21:27 +02:00
sim
cc9392bde4 test: one disc resolver, no machine-specific defaults, all three corpora in the container
Finishes #16 in the three places its earlier remedies missed.

`tests/`: the last four local `disc_root()` copies now use `tests/common`, and
with them goes the one real hardcoded fallback — `ui_keyframe_record_disc.rs`
fell back to an absolute path on one machine, which made `unset SYLPHEED_DISC`
a no-op there. Control: with the corpus absent that suite now finishes in 0.00s
instead of 57.55s, so it skips rather than finding a disc of its own.

`examples/`: seventeen examples defaulted to `/disc`, the mount point inside the
CI container. Redundant there — `docker/ci/run` sets `SYLPHEED_DISC=/disc` — and
wrong everywhere else, where a missing corpus turned into a file-not-found
against a path that has never existed on the host. They now name the variable to
set, like the other hundred examples already did.

`docker/ci/run`: mount `$SYLPHEED_RES3D` and `$SYLPHEED_ISO` alongside the disc.
Only the disc was mounted, so an in-container run sat out the res3d and iso
suites while looking like a full one — the defect this issue is about, in the
runner itself.

Measured in the container on this desktop with all three corpora present:
45 suites / 377 passed / 0 failed / 14 ignored, and `sylpheed-corpus-report.txt`
now reports PRESENT for all three rather than for the disc alone.

Refs #16.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 22:18:59 +02:00
4efd9f5936 Merge pull request 'fix(ppc-manual): 543 dead links, from two generator bugs and wrong relative paths' (#48) from fix/ppc-manual-dead-links into main
Reviewed-on: #48
2026-09-17 05:11:45 +00:00
080cae410d Merge pull request 'chore: retire the last dead paths and names from the consolidation' (#47) from chore/retire-leftover-names into main
Reviewed-on: #47
2026-09-17 05:11:31 +00:00
5f01fc9cf8 Merge pull request 'docs(reference): adopt the last reference files from the project root' (#46) from docs/adopt-root-reference into main
Reviewed-on: #46
2026-09-17 05:11:09 +00:00
sim
09b2a4871d docs(consolidation): record that the devkit and XEX1 keys are not needed
Project Sylpheed ships as a retail XEX2 (human decision, 2026-09-16), so
Phase 2's key harvest is closed rather than left looking unfinished.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 22:38:06 +02:00
sim
9bfe96e44d fix(ppc-manual): 543 dead links, from two generator bugs and wrong relative paths
- Category pages linked each family as `<slug>.md`, relative to categories/,
  where no family page lives. They now link `../<category>/<slug>.md`.
- Form pages linked a member into its *own* category directory, so every
  VMX128 sibling (`vsldoi128`) pointed at vmx128/ although its family page is
  under vmx/. They now link into the family's directory.
- Hand-written "Related" and sibling mentions linked other categories' pages
  as if they were in the same directory. 109 are retargeted through the page
  index; 29 that pointed a family page at itself (`vrefp128` on vrefp.md) and
  6 naming instructions the manual has no page for are plain text now.

Regenerated at the existing Canary pin (f21ebd49e): upstream has moved on, and
re-pinning belongs in its own change. The generator reports 0 family pages
changed and is idempotent; the only dead links left are TEMPLATE.md's
placeholders.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 22:37:12 +02:00
sim
cf7e02c51d docs(consolidation): close the plan — phases 5 and 7 are done
Record the end state at the top of the page: four repositories archived, their
clones gone from this machine, the Phase 7 drops done or never present here, and
Canary's default branch moved off `xenia-rs`. The retention question and the
history rewrite stay open for the human.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 22:35:03 +02:00
sim
e909c7c133 chore: retire the last dead paths and names from the consolidation
Nothing here changes what a tool computes; it changes where tools look.

- tools/re-capture: 33 censuses globbed /work/sylph_extract, a path that has
  existed nowhere since /work became a clone, so they matched nothing and
  printed empty results. They now resolve the disc through a new disc.py
  from $SYLPHEED_DISC and exit loudly without it (the #44 fix, generalised).
  Nine scripts that imported siblings from the retired Reborn checkout or an
  old session scratchpad now import from their own directory. unitgroup.py
  only needs the variable when --pak is not given.
- sylpheed-xex: the loader only ever uses the XEX2 retail key. The dead
  devkit key and a doc comment claiming a devkit fallback that does not
  exist are gone; Project Sylpheed is a retail XEX2, so no XEX1 key either.
- sylpheed-viewer: real_font_rasterizes looked for /tmp/sylph_extract and so
  always skipped. It reads $SYLPHEED_DISC now, and passes against the disc.
- Comments and docs that named xenia-rs, the Reborn repository or /work/*.pe
  as places to look now name sylpheed.db, Canary's ppc_context.h and the
  flat .pe; docs/re/README.md no longer says the native Canary build does not
  run.

Historical records keep their original paths: findings that were measured
against /work/xenia-rs/sylpheed.db still say so.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 22:30:28 +02:00
sim
6dcdea1cf1 docs(reference): adopt the last reference files from the project root
Three untracked files in the project root had no home in either repository:

- the Xbox 360 technical reference report (a research compilation) becomes
  docs/reference/xbox360-re-technical-reference.md, unchanged;
- XBOX360_ARCHITECTURE.md becomes docs/reference/xbox360-architecture.md,
  trimmed to its platform facts. Its format "status" sections (PAK unknown,
  mesh unknown, audio TODO) and the `just sniff` workflow predate every
  decoder in this repo and were wrong;
- generate_export_docs.py becomes tools/generate_export_docs.py, the path the
  committed xbox360-exports.* already name as their generator. It lived
  inside a Canary checkout, so it now takes --canary and --out and fails
  loudly on a tree that is not Canary.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 22:19:54 +02:00
591527439d Merge pull request 'docs(ppc-manual): check every xenia-rs claim against Canary's source' (#45) from docs/ppc-manual-canary-claims into main
Reviewed-on: #45
2026-09-16 20:03:03 +00:00
49d1b861fa Merge pull request 'fix(re-capture): name_block_bases reads the disc from $SYLPHEED_DISC, loudly' (#44) from fix/name-block-bases-disc into main
Reviewed-on: #44
2026-09-16 20:02:52 +00:00
sim
f3c512f2ab docs(ppc-manual): check every xenia-rs claim against Canary's source
The hand-written parts of the manual still described how the retired
xenia-rs interpreter behaved: its snapshots, Rust casts and helpers. Each of
those 490 statements is now either restated as what Canary's emitters and
x64 backend actually do (at the pinned canary_experimental commit), or
dropped where it only made sense for xenia-rs.

Checking them turned up claims that were wrong, not just outdated:

- VSCR[SAT] is never modelled in Canary (DID_SATURATE is a stub and mfvscr
  cannot see it); the pages said saturating ops set it stickily.
- Canary does not implement lswi/lswx/stswi/stswx, dcbi, mtfsb0/mtfsb1,
  vmsum*, vmhaddshs, vupkhpx/vupklpx, and most SPRs; pages described them
  as working.
- Traps evaluate TO in Canary; stvebx/stvehx/stvewx store one element, not
  16 bytes; mtmsrd writes only EE; fres/frsqrte/vrsqrtefp precision claims
  and the stfs "rounds under RN / sets FPSCR" claim contradicted the spec.
- Reservations are a 64 KiB block bitmap plus a value compare, not
  per-address tracking.

Claims that neither Canary's source nor a public spec settles are marked
unverified (NI at boot, vmaddcfp128 operand order, estimate bit-exactness).

Generated regions are untouched; re-running the generator changes nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 21:52:38 +02:00
sim
8b7d9f9d71 fix(re-capture): name_block_bases reads the disc from $SYLPHEED_DISC, loudly
Its data-table section globbed `/work/sylph_extract/**/*.pak`, a path that has
existed nowhere since `/work` became a clone. The glob matched nothing, so the
section reported "0 disc names" and an empty table with no error — while the
committed `docs/re/data/name-block-bases.txt`, generated back when the path
existed, records 13 450. The disc is required for that section, so a missing or
non-disc `$SYLPHEED_DISC` is now an error (exit 1), not an empty result.

Verified: without the disc, exit 1 with the message; with
`SYLPHEED_DISC=…/sylph_extract` (the original /work/sylph_extract), the section
reproduces the committed figures exactly — 13 450 distinct disc names,
50 / 261 data-table rows, `sub_82341A20 r30 0x82088F94 217 names 89% disc`.

⚠️ The artefact itself is deliberately NOT regenerated. Rebuilt from the current
database it changes findings — solved bases move, three 15/15 rows vanish, −280
lines — and the cause is the database, not this script: the string extractor's
Shift-JIS path requires kana, so kanji-only Japanese (e.g. the allocator's
`32B  未開放 %4d : 最大…使用量 %4d / %4d` debug lines) is not in `strings`, and
the bases those names pinned no longer resolve (sub_8285F2C8 r5 @ 0x820AE7AC:
15/15 before, 7 now). Regenerating would bake that regression into a cited
research artefact (`docs/re/structures/player-tuning-tables.md`).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 21:08:55 +02:00
781da7047a Merge pull request 'docs: stop telling people to use the retired xenia-rs' (#43) from docs/retire-xenia-rs-instructions into main
Reviewed-on: #43
2026-09-16 18:55:48 +00:00
328c122ce4 Merge pull request 'docs(ppc-manual): quote Canary and our own decoder, not the retired xenia-rs' (#42) from docs/ppc-manual-canary into main
Reviewed-on: #42
2026-09-16 18:55:41 +00:00
41133c9d2d Merge pull request 'fix(tools): every sylpheed.db reader honours $SYLPHEED_DB, and none needs a retired checkout' (#41) from fix/sylpheed-db-contract into main
Reviewed-on: #41
2026-09-16 18:55:32 +00:00
sim
2f838040ca docs: stop telling people to use the retired xenia-rs
Instructions and generated text that still sent readers to `xenia-rs`, which is
archived and deleted locally. Provenance and dated research records are left as
they are — "lifted from xenia-rs", or a finding stating what database it was
measured against, is still true, and rewriting it would falsify the record.

Changed, because each one tells someone what to do today or writes stale text:

  docs/re/README.md          the RE toolchain guide queried `xenia-rs/sylpheed.db`
                             with `xenia-rs/zq.py`, and its "Dynamic" bullet said
                             to prefer xenia-rs's probe suite OVER Canary. Now:
                             `sylpheed.db` at the repo root (how to build it and
                             re-stamp names), `tools/zq.py`, dynamic = Canary, and
                             `.rdata` reads from the `.pe` (offset = VA - 0x82000000)
                             in place of `--dump-addr`.
  challenge-mission-gate.md, structures/achievements.md
                             reproduction commands `python3 xenia-rs/zq.py dis …`
  crates/sylpheed-xexdb/SCHEMA.md
                             titled after the retired `xenia-analysis` crate,
                             citing `xenia-rs dis`, pointing at a `xenia-analysis`
                             source path
  sylpheed-xexdb/src/formatter.rs
                             WROTE "generated by xenia-rs" into every disassembly
                             it produced (no test pins the banner)
  sylph-xexdb.rs, db.rs      "SQLite" / "DuckDB writer for xenia-rs"
  sylpheed-formats/src/hash.rs
                             pointed at `xenia-rs/RE_SYMBOLS.md`, now at
                             `docs/re/RE_SYMBOLS.md`

Verified: every rewritten reproduction command was extracted from the doc and
run as written against the regenerated database — all 5 exit 0 and return the
disassembly they describe. The README's function count (25 676) is the database's
own. `cargo fmt --all -- --check` clean.

Not changed, deliberately: the README's Oracle bullet says Canary's native Linux
ELF "crashes / does not run". That is about Canary, not xenia-rs, and it conflicts
with a July note that the native build works — unverified either way here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 20:37:08 +02:00
sim
dedcf37867 docs(ppc-manual): quote Canary and our own decoder, not the retired xenia-rs
The generator had not been able to run correctly since the manual moved into
`tools/ppc-manual/`: it computed the repository root as `HERE.parent.parent`,
which now names `tools/`, so the XML, Canary's emitters and xenia-rs all stopped
resolving — silently, because both scrapers skipped what they could not find.
Every page's references had been pointing at paths that exist nowhere.

What each source contributed, measured on the 350 pages before this change:

  Operation (pseudocode)  251 pages: fixed boilerplate "derives from the xenia-rs
                          interpreter"; 99 carry real hand-written seeds
  C translation           337 pages: the same kind of boilerplate
  xenia-rs snapshot       336 pages: the interpreter arm, pasted in — the only
                          per-instruction semantics on unseeded pages
  links                   xenia-rs opcode/decoder/interpreter + Canary emitter

Now:

  * semantics come from **Xenia Canary**, the reference emulator, read through
    `git show` at a pinned upstream commit (`origin/canary_experimental`,
    f21ebd49e9). Not our checkout: it carries instrumentation and lacked
    upstream's `mcrf` fix, so it would have published probes and a wrong `mcrf`.
    Each page embeds the emitter (`InstrEmit_<mnem>`), and for the 128 pure
    one-line delegations also the helper that holds the semantics.
  * decode references point at `crates/sylpheed-ppc` — the decoder that
    produces `sylpheed.db` — as in-repo relative links.
  * the boilerplate now says what is true, and the C translation guide maps
    Canary's actual HIR calls, checked against `ppc_hir_builder.h` (including
    that `UpdateCR(n, v)` truncates to 32 bits).
  * `rust_scraper.py` -> `decoder_scraper.py` (interpreter half dropped);
    missing sources are now errors, not empty results.

Verified:

  consistency checks        455 XML entries, 350 families, 598 index keys
  hand-written tails        386/386 byte-identical after regeneration
  xenia-rs in generated     0
  pages with a snapshot     349/350 (was 336) — `dcbi` has no Canary emitter at all
  in-repo decoder links     910/910 resolve to a line holding the identifier
  emitter boundaries        brace counter == column-0 `}` rule on 521/521;
                            preprocessor model unit-tested (#if 0/#else/#elif)
  idempotency               re-run: 0 pages updated, 0 working-tree changes

Hand-written notes (outside the generated regions) are not rewritten here:

  * 110 links into `../../xenia-rs/...` were dead; they now point at the file in
    the archived repository (git.mc02.dev/fabi/xenia-rs @ 8401d4d). Line anchors
    were dropped because the notes predate that commit — 0 of 441 old line
    ranges match it — and a precise-looking wrong anchor is worse than none. The
    link text, which carries the author's line numbers, is unchanged.
  * 140 prose claims about xenia-rs's behaviour remain. 23 are verified to hold
    for Canary too (the 32-bit CR0 truncation, OE left unimplemented); the other
    114 need checking one by one, and some invert — e.g. `divdx` notes a correct
    64-bit CR0 update in xenia-rs where Canary's `UpdateCR` truncates. Left for
    a deliberate pass rather than a blind substitution.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 20:34:34 +02:00
sim
120621daca fix(tools): every sylpheed.db reader honours $SYLPHEED_DB, and none needs a retired checkout
`SYLPHEED_DB` is the documented contract for the static-analysis database —
`docker/decoder/sylph-decoder` sets it, and `docs/agents/CONTAINER-NOTES.md` and
`decoder-loop.md` list it — but no reader honoured it:

  isl_cmdtab.py, name_block_bases.py   hardcoded `/work/xenia-rs/sylpheed.db`, a
                                        path that has not existed anywhere since
                                        `/work` became a clone. Both failed on
                                        every machine, before and after the
                                        database moved.
  zq.py                                 used `$SYLPH_XEXDB`, a name invented in
                                        #39 without grepping for the existing one.

All three now resolve `$SYLPHEED_DB`, then `$SYLPH_XEXDB` (kept as an alias so
nothing already written against it breaks), then `<repo root>/sylpheed.db`, and
refuse with exit 1 naming both variables and the build command otherwise.

`grab_tutorial.sh` hardcoded its helpers into the retired `sylpheed-reborn`
checkout. That copy's `skip_intro.sh` still calls the removed `vgamepad` and
exits 0 having pressed nothing — the failure this repository's own copy was
rewritten to make loud. So the script was already running a silently broken
helper; it now resolves its helpers from its own directory. Nothing exists only
in reborn's `tools/re-capture` (checked: 0 reborn-only files).

Verified against the same database, output compared byte for byte with the
ORIGINAL scripts (path-substituted copies, sibling imports resolvable):

  resolution path    isl_cmdtab   name_block_bases
  default (root)     identical    identical
  $SYLPHEED_DB       identical    identical
  $SYLPH_XEXDB       identical    identical
  bad path           exit 1       exit 1          (zq.py: exit 1 too)

and `isl_cmdtab`'s output is byte-identical to the body of the committed
`docs/re/data/isl-command-table.txt`.

⚠️ `name_block_bases`'s output does NOT reproduce the committed
`docs/re/data/name-block-bases.txt` (2,609 lines differ, `strings in the image:
7366` vs `7140`). That is the database, not this change: the artefact was
generated from the agent box's older 586 MB database, and this machine's is the
current generator's. Two databases are in circulation. Not regenerated here.

⚠️ Also not fixed, because it is a different bug: `name_block_bases.py` globs
`/work/sylph_extract/**/*.pak`, another path that exists nowhere now; that part
of its report is silently empty. It should read `$SYLPHEED_DISC`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 20:07:19 +02:00
ad30352384 Merge pull request 'test(formats): invert the primitives tripwire to pin the fix (#38, option A)' (#40) from fix/38-invert-primitives-tripwire into main
Reviewed-on: #40
2026-09-16 17:02:31 +00:00
sim
26c3d304e9 test(formats): invert the primitives tripwire to pin the fix (#38, option A)
`the_derived_order_puts_primitives_last_and_that_wipes_screens` asserted that
switching primitives on still flattened at least one screen (`wiped_on > 0`),
and said to turn `include_primitives` on by default the day it stopped.
`cfcda55` made that day arrive — a keyless primitive that would hide the screen
is now forced to paint first — and the wire had been red since 2026-08-29,
invisible to CI because the runner has no corpus and the suite self-skips.

#38 chose option A: keep the default off, and pin the fix instead. The flatness
proxy stood in for "paint order is solved", and the fix's own record says that
is only partly true — "This does **not** make `include_primitives` safe by
default" (docs/re/structures/ui-prm-primitives.md). So:

  * renamed to `no_build_is_wiped_with_primitives_on` — the old name asserted
    the bug; it survives in the doc comment for anyone searching from #38;
  * `wiped_on > 0`  ->  `assert_eq!(wiped_on, 0)`, with a message saying what a
    failure now means (`forced_backdrop` regressed) and that it must not be
    "fixed" by turning primitives off in the test;
  * `include_primitives` stays `false`; no library code changes.

It is the only end-to-end check of the rule: the four tests in
`ui_forced_backdrop_disc.rs` pin its mechanics, and none composes with
primitives on.

Verified with the corpus present, including that it can fail:

  fix                        3 passed   125 builds draw a primitive, 0 wiped
  forced_backdrop disabled   FAILED     36 of 125 wiped — the new message fired
  restored                   3 passed   125 builds, 0 wiped

The control's 36 is exactly the "36 builds ... wiped by our own sort" that
`cfcda55` and `ui-forced-backdrop.md` report — the guard independently
reproduces the fix's own number, so it measures precisely what was repaired.
The control was a one-line `return false;` in a scratch copy; the working tree
was restored and `git diff` showed only this test file before committing.

Closes #38

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 19:01:13 +02:00
cb731f2e96 Merge pull request 'feat(xexdb): re-land #35 onto main — import-thunk naming, FKs, zq.py fixes, RE symbols' (#39) from feat/xexdb-import-naming into main
Reviewed-on: #39
2026-09-16 05:09:15 +00:00
f33a2ff646 Merge pull request 'feat(port): adopt the measured held-direction repeat rate (F1)' (#27) from feat/f1-held-repeat into main
Reviewed-on: #27
2026-09-15 19:47:28 +00:00
523a2aa94b Merge pull request 'chore(tools): adopt the PPC manual and a canary launcher that works anywhere' (#34) from chore/adopt-orphan-assets into main
Reviewed-on: #34
2026-09-15 19:46:48 +00:00
cea680b24d Merge pull request 'docs(agents): the gate that cannot see a working tree, and the Phase 5/7 checks re-run' (#36) from docs/consolidation-dirty-tree-finding into main
Reviewed-on: #36
2026-09-15 19:46:37 +00:00
d3011ea8e2 Merge pull request 'docs(agents): the plan to consolidate six repositories into two' (#29) from plan/consolidation into main
Reviewed-on: #29
2026-09-15 19:46:19 +00:00
bc9f6bd49b Merge pull request 'fix(re): the capture checker counted its own selftest fixture as a citation' (#37) from fix/capture-citations-selfscan into main
Reviewed-on: #37
2026-09-15 19:46:02 +00:00
840d4b8bac Merge pull request 'docs(re): give docs/re/ the citation check docs/port/ has always had, and prune' (#33) from fix/capture-citations into main
Reviewed-on: #33
2026-09-15 19:44:48 +00:00
04e8d6244c Merge pull request 'feat(xexdb): lift the DuckDB generator and disassembler out of the retired emulator' (#32) from feat/xexdb-tool into main
Reviewed-on: #32
2026-09-15 19:15:22 +00:00
5a77229bbb Merge pull request 'docs(agents): how the containers and agents are actually set up' (#31) from docs/containers-setup into main
Reviewed-on: #31
2026-09-15 19:15:12 +00:00
9d41971646 Merge pull request 'docs(reference): adopt the four homeless reference files, and a LICENSE' (#30) from harvest/xex2tractor-assets into main
Reviewed-on: #30
2026-09-15 19:15:02 +00:00
sim
0679abb9f9 harvest: RE_SYMBOLS.md and apply_re_symbols.sql, which Phase 3 left behind
Phase 3 lifted the DuckDB tool out of `xenia-rs` but not the two files that go
with it, and this branch's own code already depends on one of them: the FK rule
in `db.rs` and `db_schema_golden.rs` exists *because* `apply_re_symbols.sql`
re-stamps reverse-engineered names onto `functions` after every regeneration.
Sylpheed referenced that file three times and contained it nowhere — on no
branch. CONSOLIDATION.md's end state is "Sylpheed holds everything", and the
`xenia-rs` clone is scheduled for deletion.

  docs/re/RE_SYMBOLS.md       byte-identical to xenia-rs/RE_SYMBOLS.md (cmp)
  tools/apply_re_symbols.sql  every statement identical; the two comment lines
                              that name paths now name this repo's paths

Verified against the real 336 MB database, which carries all 16 foreign keys,
inside a transaction that was rolled back (the database is unchanged):
every statement runs, and 208 functions carry reverse-engineered names. Run
from both the old location and this one.

Not harvested: `xenia-rs/zq_dis.py`, an untracked six-line subset of
`zq.py dis` with a hardcoded path — superseded, nothing to keep.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-15 19:23:07 +02:00
sim
dce085277a chore: ignore /sylpheed.db — zq.py now defaults to it
The previous commit on this branch made `tools/zq.py` look for its database at
`<repo root>/sylpheed.db`, and its refusal message tells people to put one there.
Nothing ignored that path. The database is a build artefact of several hundred
MB, so a single `git add -A` would have committed it into a public repository's
history — the class of blob CONSOLIDATION.md's history-rewrite fork exists to
argue about.

Anchored (`/sylpheed.db`, plus DuckDB's `.wal`) so it covers only the default
location, not any file of that name elsewhere. Verified by creating the files:
both ignored, `git status` silent, and a `sylpheed.db` in a subdirectory is not
swallowed by the rule.

Found while writing the Phase 7 steps: moving the 336 MB database out of
`xenia-rs` before that clone is deleted is exactly how someone would put it here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-15 19:20:38 +02:00
fdf498c684 docs(agents): the #32 workspace test count is in — 367 passed, and the one failure is main's
Closes the page's one explicitly outstanding result. Run in sylph-ci:local
(rustc 1.98.1, byte-identical to the runner) with the disc present and
--no-fail-fast: 45 suites, 367 passed, 1 failed, 14 ignored. The +9 against the
disc-less #35 run (377) is exactly #35's nine imports.rs unit tests.

The single failure is ui_prm_primitives_disc, red on main since #23 and
bisected there, not introduced by #32.

Records the three things that stopped the number being obtained, as rules:
--no-fail-fast (an earlier run silently covered half the workspace), a memory
cap sized to the host (the default 7 GB OOM-kills slb_leading_segment_disc on
this machine with the disc mounted), and a ~36 GB disk budget for a cold target
volume.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 08:13:02 +02:00
108378fe21 docs(agents): the formats-pin tag count is 7, and the disk figures have moved
Re-checked against the server rather than the page. `Sylpheed` has 7 tags and
all 7 are `formats-pin-*`. The eighth this page counts, `formats-pin-2026-08-29`
without a letter suffix, is in `Syplheed-Reborn` — a repo a Sylpheed rewrite
would not touch, and one Phase 5 archives read-only regardless.

The pin itself is exactly as claimed: `formats-pin-2026-09-01` resolves to
`e2630413`, and the in-container build fetches that git dependency over the
network for real, so the blocker is live rather than theoretical.

Also updates the disk figures the "don't rewrite" recommendation rests on: 90%
used and 96 GB free, not 83% and 154 GB, with `target/` at 34 GB. The
recommendation is unchanged and the argument is now stronger — reclaiming
118 MB by rewriting history while 34 GB of rebuildable output sits beside it is
the wrong lever.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 21:25:53 +02:00
d9ba2c73b1 fix(re): the capture checker counted its own selftest fixture as a citation
`check-capture-citations` exits 1 on a clean checkout of this branch, and would
have kept doing so for ever:

    🔴 cited but NOT committed: 1
        docs/re/captures/no-such-file-anywhere.png

`SEARCH` includes `tools`, so the scan reads this file -- and `selftest()`'s
planted fixture is a literal capture path. The checker cited its own test data,
to a file that will never exist by construction. A gate that is red before
anyone changes anything teaches people to ignore it, which is the opposite of
what Phase 4 built it for.

Excluding only this one file (`SELF`) keeps every other tool in scope. A real
citation belongs in a page, or in a tool that opens the capture -- never in the
checker itself.

Added a selftest case for it, because this is exactly the class of bug the rest
of this file already documents surviving: the ERE that matched nothing while
five ticks stayed green. Verified the guard can fail, rather than assuming it:

    exclusion neutralised -> "own fixtures not counted 🔴 FAILED",
                             selftest rc=2, real check rc=1 reproducing the bug
    exclusion restored    -> selftest ok (7 cases), check rc=0

After the fix, on this branch:

    captures committed          : 212
      cited by a page or a tool : 212
      cited by nothing          : 0
      🔴 cited but NOT committed: 0        rc=0

which is also the first independent confirmation of Phase 4's "212 captures,
all cited" -- the checker now agrees with the page.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 21:18:55 +02:00
d0f3885fb5 docs(agents): re-run the Phase 5 and Phase 7 checks, and record what they say
This page says not to trust its own ledger on arrival, so the checks were run
again rather than read. Nothing was archived and nothing was deleted — both are
the human's, and both phases stay open.

The substantive finding is that Phase 5's containment check is the wrong test
for half the list it names. `xenia-rs` and `xex2tractor` were never absorbed;
their disposition is harvest-then-archive. Run the check literally against
`xenia-rs` and it returns 42 of 42 refs "not present in Sylpheed" — every line
true, every line unactionable, which is the failure this page already names
once about Phase 0's first gate. For those two the invariant is that the
harvested artefacts are in Sylpheed and the repository is archived rather than
deleted; that is now checked separately, and it shows the harvest is real but
lives only on the unmerged PR branches, so Phase 5 should follow them rather
than precede them.

Containment itself holds for the two repos it does apply to: 21/21 and 2/2.

Also answers Phase 7's one open question — nothing cites `texcompare/`, and all
four `ship_render` citations name the example program, not the output
directory — and records that most of Phase 7's list does not exist on this
machine, that `has_wiki: true` is a flag rather than content (all six wikis
return 404, never initialised), and that the disk is at 90%, not the 83% the
page records.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 21:00:40 +02:00
589c403c62 docs(agents): the zq.py database path is fixed, not outstanding
This page recorded it as "not changed here, because the right replacement is a
decision". The decision was taken: PR #35 `38cc170` resolves `$SYLPH_XEXDB`,
then `<repo root>/sylpheed.db`, then refuses with both named — no third
fallback, because the database is an untracked build artefact and a default
that silently resolves to the wrong one is worse than no default.

Leaving the page saying otherwise would be the defect this section is about.

`SCHEMA.md`'s retired-repo heading is still outstanding and stays listed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 20:50:44 +02:00
5f623bf110 fix(zq): stop defaulting the database path into the repo being deleted
`zq.py` hardcoded one absolute path, and it pointed inside `xenia-rs` --
a repository CONSOLIDATION.md archives in Phase 5 and drops in Phase 7. It
resolved on exactly one machine, and on that machine it was days from becoming
a `duckdb` exception about a missing file, with nothing saying why.

Resolution order is now `$SYLPH_XEXDB`, else `<repo root>/sylpheed.db`, else a
refusal that names both. The repo-root path is taken relative to this script,
not the caller's cwd, because zq.py is run from wherever the investigation is.

No fallback beyond that, on purpose. The database is a build artefact of a few
hundred MB and is not tracked, so there is nothing to fall back *to*; a default
that silently resolves to the wrong database is worse than no default. That is
issue #16's lesson, which was about exactly this shape in the test suite.

Both failure paths say what to do and exit 1:

  $ zq.py fn 82000000            # nothing set, nothing at the repo root
  no database found.
    looked for: /…/Sylpheed/sylpheed.db
    set $SYLPH_XEXDB to an existing one, or build it with:
      sylph-xexdb dis <xex|iso> --db sylpheed.db --analyze sql

  $ SYLPH_XEXDB=/nope/missing.db zq.py fn 82000000
  $SYLPH_XEXDB is set but is not a file:
    /nope/missing.db

Also fixes the regeneration hint, which still named `xenia-rs dis` -- the
retired binary. It is `sylph-xexdb dis`.

Connecting is skipped when there is no subcommand, so `zq.py` still prints its
usage on a machine that has no database yet.

Verified: usage with no db (rc 0); missing db (rc 1); `$SYLPH_XEXDB` set to a
non-file (rc 1); and `$SYLPH_XEXDB` pointed at a real 336 MB database, where
`imp Rtl` returns its 1,280 `RtlLeaveCriticalSection` call sites. That database
turns out to have been generated from the uncommitted tree this branch ports:
it carries `import_address`, `import_role` and all 16 foreign keys -- an
independent confirmation of the schema the golden test now locks.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 20:49:49 +02:00
b2f089e7d3 docs(agents): the Phase 0 gate cannot see a working tree — it missed 468 lines
Found 2026-09-14 while pulling the repos on the other machine: `xenia-rs` had
468 uncommitted lines plus an untracked 338-line `imports.rs` in the very crate
Phase 3 lifted, written 2026-09-10 and sitting there for four days. Verified
absent from `iterate-4A` and from the lifted crate in PR #32 — it existed in
exactly one place, and that place was not git.

Phase 0 is titled "Secure the single-copy work" and its gate passed anyway,
because the gate iterates `refs/heads` and a dirty working tree has no ref.
Canary's two dirty files were secured only because a human already knew about
them; nothing found them. Phase 1 then declared the archive honest while this
sat beside the branches it pushed. Phase 5 ends with "delete the local clone"
and Phase 7 drops the emulator, so a deletion was scheduled against it.

Records: the finding and the `git status --porcelain` half the gate was
missing (run across all four repos — only Canary is dirty, and both entries are
already on Phase 7's drop list); that it is secured on `harvest/import-thunk-
naming` and ported in `feat/xexdb-import-naming`; a fifth entry in the
wrong-claims list; and a `0b` row in the status table.

Also records three pieces of Phase 3 residue found while porting, the sharpest
being that `tools/zq.py` still defaults its database path to a location inside
`xenia-rs` — the repository Phase 5 archives and Phase 7 drops. Left unchanged:
the right replacement is a decision, not a guess.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 20:44:48 +02:00
13c895abff feat(xexdb): port import-thunk naming + schema-wide foreign keys
Carries `xenia-rs` `harvest/import-thunk-naming` (b4f19f1) across into the
lifted crate. That work was found UNCOMMITTED in the retired repo's working
tree on 2026-09-14 and exists nowhere else: absent from `iterate-4A`, absent
from this crate as lifted. CONSOLIDATION.md Phase 5 ends with "delete the local
clone" and Phase 7 drops the emulator, so it had a deletion scheduled against
it.

Not a cherry-pick. The lift's base is exactly the harvest's parent (8401d4d),
so each file was merged three-way -- lifted vs base vs harvest -- which is what
made the port reviewable: 10 conflicts, 9 of them pure rustfmt reflow from the
lift's formatting pass, and 1 semantic.

The semantic one is insertion ORDER. `xdbf_achievements.image_id` is now a
foreign key onto `xdbf_images(id)`, so the image rows must be inserted before
the achievement rows. The merge moved that block; the conflict was the stale
copy left at the old position.

What arrives:

* **Import-thunk recognition** (`imports.rs`, 338 lines). An XEX import is not
  a PLT jump: the linker emits a four-word thunk whose first two words are
  import RECORDS that the loader rewrites at module load. On disc they are
  still records, so a PowerPC-only decoder prints two meaningless `.long`s in
  front of an indirect branch. This maps every word of every thunk, and every
  direct branch into one, back to its `imports` row. Shape-validated rather
  than trusted: an entry is indexed only when the four words it points at
  actually have the thunk shape.

  Adds `instructions.import_address` (FK onto `imports.address`) and
  `import_role` (`'record'` | `'thunk'` | `'call'`, NULL iff import_address is
  NULL), plus an index. `tools/zq.py` gains `imp` and `impcalls`, and `dis`
  now names imports instead of printing `.long 0x01010194`.

* **Sixteen schema-wide foreign keys**, declared wherever a column is derived
  from another table. CREATE TABLE and insertion order become load-bearing.

  `functions` is deliberately NOT an FK parent and the golden test now asserts
  zero inbound FKs onto it: DuckDB implements UPDATE as delete+insert, so one
  inbound FK would make `functions.name` un-updatable and break
  `apply_re_symbols.sql`, which re-applies RE symbol names after every
  regeneration.

The database path needed no change in the binary: `DbWriter` builds its own
index inside `ingest_instructions` from `info.import_libraries`. Only the two
output paths (`enrich_section` for JSONL, `write_asm`) take it as an argument.

Verified: `cargo test -p sylpheed-xexdb` = 10 passed / 0 failed, including
`db_schema_golden` (41s, builds a real DuckDB) which locks the 16-FK set and
the no-FK-onto-functions rule. `cargo clippy -p sylpheed-xexdb --all-targets
-- -D warnings` clean; `cargo fmt --all --check` clean.

Stacked on #32 -- it ports into a crate that only exists there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 20:43:16 +02:00
MechaCat02
34d3bbc8fd docs(agents): record the progress, and correct four claims this page got wrong
Paused at six of eight phases, all committed and pushed, nothing left in a
working tree. The page now carries a STATUS section the other machine can
finish from: what is done, which PR each phase is in, what to run next, and
what is deliberately left for the human.

🔴 FOUR THINGS THIS PAGE ASSERTED WERE WRONG, and each is corrected in place
rather than quietly amended:

  * "10 dangling citations" was ONE. Eight were DIRECTORY references, which
    resolve and are absent only from `git ls-tree`; one was a path ending a
    sentence, with the full stop pulled into the match. I reported that 10 to
    the human twice.
  * `extract -r` is not how the .pe was made and nothing depends on it. The
    plain extract is, and the tool Phase 3 keeps reproduces it byte-for-byte.
  * The Phase 0 gate compared branches by SHA and called seven safe branches
    unpushed -- a branch that is an ancestor of a pushed one is preserved.
  * There is no DirectXShaderCompiler drift; the ' m' is nested submodule dirt.

The pattern is worth more than the corrections: every claim that was REASONED
turned out wrong, and every one that was RUN held. Phase 2's gate refuted its
own premise, Phase 3's proved two alarming row deltas were an improvement, and
Phase 4's check caught a deletion I had just made. The page now says to re-run
the gates rather than trust the results recorded in it.

Phase 5 (archive) and Phase 7 (drops) are open and marked NOT STARTED, with
the reason each needs the human: archiving is reversible and deleting a
repository is not, and the drops are on the human's disk.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 21:22:47 +02:00
MechaCat02
10dc260f0c chore(tools): adopt the PPC manual and a canary launcher that works anywhere
CONSOLIDATION.md Phase 6. Both lived untracked in the project root -- on one
disk, backed up by nothing.

  tools/ppc-manual/   393 files, 3.7 MB. 455 instructions, 350 family pages,
                      598 mnemonics resolvable through index.json, plus the
                      generator that produced them.
  tools/run-canary.sh the oracle launcher.

🔴 THE LAUNCHER WAS BROKEN IN TWO WAYS AND IS REWRITTEN, not copied:

  * it pointed at `xenia-rs/sylpheed.iso`, a SYMLINK. Wine cannot resolve one
    and says "path invalid", which reads as a corrupt image rather than a path
    problem -- it has cost a session before. It now points at the real file and
    warns if handed a symlink.
  * it hardcoded one machine's absolute paths, and named `xenia-rs`, which this
    consolidation retires. Now derived from the script's own location, with
    SYLPH_CANARY_BIN / SYLPH_ISO overrides and a check that each exists.

The standing constraints are in its header where someone will read them: one
emulator at a time, Canary runs MUTED, and never judge a crash or a hang from
a Bash-launched run -- a SIGKILL that looked like the binary was the editor's
process supervisor.

⚠️ The manual's GENERATOR reads the xenia-rs source tree, which is going away.
Its decoder now lives here as crates/sylpheed-ppc, so the generator must be
repointed before it is run again. Recorded in the README rather than left for
someone to discover; the manual's content is checked in and regenerates from
nothing implicitly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 21:18:00 +02:00
MechaCat02
6d4fe37110 docs(re): give docs/re/ the citation check docs/port/ has always had, and prune
CONSOLIDATION.md Phase 4. `tools/port/check-citations` has checked
`docs/port/*.md` since it was written; `docs/re/` never had one, and
`docs/re/captures/` is the largest thing in the repository -- the one place a
file can be added, never cited, and never noticed.

  captures committed          : 212
    cited by a page or a tool : 212
    cited but NOT committed   : 0

🔴 THE PREMISE I STARTED FROM WAS WRONG FOUR TIMES, AND EACH CORRECTION IS IN
THE TOOL RATHER THAN JUST IN MY HEAD:

  * "10 dangling citations" -- the real number was ONE. Eight were DIRECTORY
    references, which resolve and are simply absent from `git ls-tree`; one was
    a path at the end of a sentence with the full stop pulled into the match.
    A checker that cries wolf nine times in ten teaches you to ignore it.
  * The one real dangler, `live-submenu-unidentified.png`, was COMMITTED and
    then deleted on 2026-08-30 while the page kept citing it and kept making
    the claim it backs. Restored from 77e54e95 rather than dropping the link:
    deleting evidence while keeping the conclusion is the thing this corpus
    exists to prevent.
  * Two "orphans" are opened BY FILENAME from `screen_match.py`, which builds
    the directory separately. A path-only scan called them unreferenced and
    deleting them would have broken the tool. The check now counts any
    basename named anywhere.
  * Pruning then EMPTIED two directories that pages cite as directories, and
    the check went red on the very citations that made them evidence. It
    caught its own damage. A file inside a cited directory is cited.

The selftest covers all of it, including the failure that actually happened:
an earlier version passed five green ticks while the scan silently returned
NOTHING, because `git grep -E` is POSIX ERE and cannot compile `(?:`. A
selftest that cannot see the failure that occurred is decoration.

46 orphaned captures dropped, 30.7 MB from the checkout. ⚠️ That reclaims no
repository space -- the blobs stay in history -- and it is not meant to. It
means every capture here is now evidence some page or tool actually uses.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 21:14:52 +02:00
MechaCat02
a9291149bd test(ppc): identity_op off in the golden generator, with the reason
The shifts clippy objects to are the point. These are instruction ENCODERS:
every field is written at its ISA position, so `(((vb >> 5) & 0x3) << 0)`
sits in a column with << 11, << 16, << 21 and reads straight against the
manual's field table, and a trailing `| 0` says 'the low field is zero
here', which is information.

Reduced to what clippy wants, the encodings stop being checkable by eye
against the ISA -- and eye-checkability is all a golden GENERATOR has. There
is nothing else to verify it against.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 21:08:41 +02:00
MechaCat02
d8ce791852 docs(agents): how the containers and agents are actually set up
Written for the other machine, which asked. Everything in it was read off the
running host rather than remembered.

Also adds docker/ci/ -- the CI image recipe and a capped runner -- because the
image existed on exactly one host and its Dockerfile was in a scratch directory
under /tmp, which was swept. That is the same shape as every other thing this
consolidation has turned up: something correct that exists in one place.

  docker/ci/Dockerfile          rust 1.98.1 + the apt list copied from ci.yml
  docker/ci/Dockerfile.ffmpeg   + ffmpeg, which sylpheed-export shells out to
  docker/ci/run                 6 CPUs / 7 GB / NO SWAP, named cargo volumes

The rule the runner exists to enforce: every heavy command goes in the capped
container. CARGO_BUILD_JOBS caps codegen units, not rustc's threads, not the
linker, not the test harness -- a bare host build is unbounded and has frozen
this box repeatedly.

The document also records the two agent defects the other machine will meet:
a brief change does not reach a RESUMED session, and nothing brought an agent
back to its own red PR (fixed in #24, which is itself subject to the first).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 20:43:55 +02:00
MechaCat02
1de202d88d test(ppc): bring the disassembler's golden fixtures across
Three tests failed on the extracted tree for a reason that was not a port
defect: disasm_goldens.rs resolves its fixtures through a relative path to
xenia-cpu/tests/golden/, and I had copied the test without the data.

The fixtures (base + extended mnemonics, VMX128 registers) and the generator
test now live in sylpheed-ppc, and the shim test in sylpheed-xexdb points at
them. serde/serde_json become dev-dependencies of sylpheed-ppc, which the
fixtures need and the library does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 20:43:48 +02:00
MechaCat02
b596f1fc71 docs(agents): how the containers and agents are actually set up
Written for the other machine, which asked. Everything in it was read off the
running host rather than remembered.

Also adds docker/ci/ -- the CI image recipe and a capped runner -- because the
image existed on exactly one host and its Dockerfile was in a scratch directory
under /tmp, which was swept. That is the same shape as every other thing this
consolidation has turned up: something correct that exists in one place.

  docker/ci/Dockerfile          rust 1.98.1 + the apt list copied from ci.yml
  docker/ci/Dockerfile.ffmpeg   + ffmpeg, which sylpheed-export shells out to
  docker/ci/run                 6 CPUs / 7 GB / NO SWAP, named cargo volumes

The rule the runner exists to enforce: every heavy command goes in the capped
container. CARGO_BUILD_JOBS caps codegen units, not rustc's threads, not the
linker, not the test harness -- a bare host build is unbounded and has frozen
this box repeatedly.

The document also records the two agent defects the other machine will meet:
a brief change does not reach a RESUMED session, and nothing brought an agent
back to its own red PR (fixed in #24, which is itself subject to the first).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 20:42:56 +02:00
MechaCat02
c9dd2cb705 fix(xexdb): clear the lint gate on the imported crates
rustfmt, then clippy -D warnings across the three new crates. Mechanical,
except three decisions that are stated rather than silently allowed:

  * lzx.rs gets file-scoped needless_range_loop/explicit_counter_loop allows.
    Index arithmetic IS the algorithm -- LZX is defined over symbol indices,
    Huffman slots and window positions, and a decompressor that is merely
    idiomatic is worth nothing if it is not bit-exact.
  * sylpheed-xexdb gets crate-scoped allows for needless_range_loop (nine
    sites index reg[r] where r is the PowerPC register number -- the index is
    the meaning), too_many_arguments and type_complexity. This code arrived
    whole from a retired repository; a refactor here would be an unreviewed
    edit dressed as a lint fix.
  * Everything else clippy asked for is FIXED, including all 14 doc-indent
    sites, the let-else, and a Prepared type alias in the binary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 20:25:44 +02:00
MechaCat02
62b0f79590 wip: tool README, DuckDB wording, zq.py escape hatch 2026-09-13 19:42:26 +02:00
MechaCat02
8738e36374 Merge branch 'harvest/xex2tractor-assets' into feat/xexdb-tool 2026-09-13 19:31:49 +02:00
MechaCat02
86da451bfe wip: extract the xexdb tool closure 2026-09-13 19:31:49 +02:00
MechaCat02
444776ae1a docs(reference): adopt the four homeless reference files, and a LICENSE
CONSOLIDATION.md Phase 2. Each of these existed only in a repository about to
be retired, or as an untracked file on one disk -- which, for anything that
has to survive a machine, is the same as not existing.

  xex2-format.md            39 KB   the XEX2 container format
  xbox360-exports.{json,md} 1.1 MB  2,913 exports: xboxkrnl, xam, xbdm
  ppc-instructions.{json,md} 340 KB the PowerPC instruction reference
  LICENSE                            MIT -- this repo had none

The first two are byte-identical to xex2tractor's copies, verified with cmp,
and byte-identical again to the loose untracked copies in the project root:
three copies, zero of them tracked.

docs/reference/ is deliberately its own directory with a README that says
what it is NOT: nothing here is a finding, and no docs/re/ page should cite it
as evidence. Reference material filed beside measurements is how a borrowed
table starts getting read as a result.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 19:20:30 +02:00
MechaCat02
524fb3684d docs(agents): phases 0-1 done, and the Phase 2 gate corrects the page
PHASE 0 -- the single-copy work is secured. Canary 8e63a9542 commits the
--pad_file_repeat instrument that had been uncommitted while the numbers it
produced were already shipping in the port; sylpheed-re and
audit-handle-lifecycle-probes pushed; all 14 local branches reachable.

Two corrections found by running it:

  * There is no DirectXShaderCompiler gitlink drift. `git submodule status`
    shows no '+'. The ' m' is NESTED submodule dirt (DXC's own SPIRV-Headers
    and SPIRV-Tools), which is upstream's business.
  * The gate itself was wrong. It compared branches to remotes BY SHA and
    called seven safe branches unpushed -- a branch that is an ANCESTOR of a
    pushed branch is already preserved. It now tests reachability, which is
    what it meant. A check that goes red for something unactionable is the
    failure this repo keeps naming, and this page shipped one.

PHASE 1 -- the four retiring xenia-rs branches pushed (32/52/56/59 commits).
The loop is clean everywhere except pi/clippy, pi/clippy-clean and pi/reauth3,
unreachable by ancestry and redundant by patch-id: the one case where the
answer lives outside the gate.

PHASE 2 GATE -- run, and it corrected this page in two directions.

  extract      (xex2tractor, no -r)    IDENTICAL to the project .pe
  extract -r   (xex2tractor)           differs -- 1,903 bytes over 273 runs
  extract      (xenia-rs, iterate-4A)  IDENTICAL, and .xex.json too

Right: the .pe is an xex2tractor extract. Wrong: it was made WITHOUT -r. So
the dependency this gate existed to protect does not exist -- the tool Phase 3
keeps already reproduces the file. -r drops from 'must port' to optional, with
a warning that it must never become the .pe, since it writes into the image
and would invalidate every byte-offset citation in docs/re/.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 19:18:54 +02:00
MechaCat02
c7a4378d37 docs(agents): the plan to consolidate six repositories into two
The end state the human set: Sylpheed holds the port, the corpus and every
tool; the Canary fork holds the emulator and oracle. Four repos retire.

Eight phases, each with a gate. What matters more than the sequence is the
ledger: every absorption claim here was RUN, not reasoned.

  Reborn's 21 remote + 8 local branch tips  -> all ancestors of Sylpheed/main
  Sylpheed-Godot's 2 tips + the root graft  -> all ancestors
  agent-backups/, 23 refs across 4 bundles  -> all present in Sylpheed
  3 unpushed pi/* branches, by patch-id     -> all 4 patches already on main
  issues / PRs / releases / wikis, 6 repos  -> zero outside Sylpheed

Three things the check found that a plan built on the obvious reading would
have destroyed:

1. The F1 instrument -- Canary's --pad_file_repeat patch, the one behind the
   repeat rate now shipped in the port -- is UNCOMMITTED, alongside 4 unpushed
   commits and a branch contained in no remote. Phase 0 exists for this.
2. xenia-rs has 4 unpushed branches of JIT/multicore/native-threads work.
   Dropping the emulator is a decision; dropping work that was never pushed is
   a different act, done by accident.
3. The DuckDB tool is not on master, which last moved 2026-06-15. It is on
   iterate-4A/apu-xma-stage1, +22 commits, 2026-09-10.

On the captures question the measurement contradicted the premise: 193 of 257
files are cited by a page or opened by a tool, and two are fixtures that
cargo test opens. 64 are orphans. Phase 4 builds docs/re/ the citation check
docs/port/ has had all along -- it already finds 10 dangling citations -- and
fixes those BEFORE deleting orphans, so the deletion cannot ratify them.

Deleting reclaims nothing anyway: the 118 MB is in history, and the build
depends on this repo by tag (formats-pin-2026-09-01, pinned in Cargo.lock).
That is Phase 5's explicit fork rather than a default.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 19:02:27 +02:00
MechaCat02
b6e206f1bc fix(port): held_direction() polls the stick instead of reconstructing it
Reported by a human on a real controller: hold the left stick down, the
cursor moves one item and stops. The repeat never runs.

`held_direction()`'s own comment says "Polled at the DEVICE, never through
Input.is_action_pressed". It was not. The d-pad and keyboard branches polled;
the STICK branch read `_latched`, which is a reconstruction of the stick's
position from the event history.

That reconstruction is only as good as the last event seen. A stick held
still sends nothing, and one event reading below RELEASE -- a spring
settling, a deadzone-shaped value, a driver emitting a zero on focus change
-- clears it with no event afterwards to set it back. The port then believes
the stick is centred while the player is holding it, which is precisely the
symptom reported.

Now polls `Input.get_joy_axis()` against the game's own 0.61, which is what
the comment always meant. The latch stays as a fallback for INJECTED events,
so the script harness and verify-input keep testing something.

🔴 Every instrument here missed this because every instrument SUPPLIES the
input it measures: verify-input ticks repeat_due() directly, --script sends
InputEventAction which bypasses the input map, and the new --script=hold:
injects its own axis event. All three agreed with each other and none read a
device. Same shape as the 2026-09-01 report that opened gamepad.gd, one
level deeper, with the lesson already written at the top of that file.

So this adds the two things that would have caught it:

  --script=hold:down:2.0   hold one real axis deflection and log every move
  --input-probe            print what the devices report, on change

⚠️ The fix itself is NOT verified. It matches the symptom exactly and was
found by reading, but only a human holding a stick can confirm it, and the
probe exists so the answer is measured either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 14:27:09 +02:00
MechaCat02
a88e273c40 feat(port): adopt the measured held-direction repeat rate (F1)
REPEAT_DELAY = 0.402, REPEAT_INTERVAL = 0.134, from
docs/re/f1-repeat-measured-via-driver-patch.md -- 12 and 4 frames at the
run's achieved 29.87 fps guest rate, converted to seconds because this port
does not run at the guest's rate and it is the cadence that was measured.

The mechanism has been here since 2026-09-02 and inert on purpose. The
instruction it was waiting on is now vindicated in the most awkward way: the
draft it refused to ship had 0.40 / 0.20, so the guessed delay was nearly
right and the guessed interval was off by 50 %. The half that was wrong
would have been protected by the half that was right.

The delay and the interval are NOT equally well evidenced, and the code says
so at the constants. No physical controller exists in the Decoder's
container, so the measurement fed Canary's file driver the SDL driver's own
400/100 ms constants: the 402 ms that came back is the constant that went
in, and confirms the instrument. The 133 ms interval against a fed-in 100 ms
is the new fact -- the game paces repeats to its own frame consumption. One
run; the two-run minimum is not met and the finding says so itself.

Also: the prediction that this would turn verify-input's "a held stick is
ONE step, not six" red was wrong. It stayed green, because steps() never
advances a clock and so had never called repeat_due() at all -- the rate was
about to ship into a harness with no coverage of the feature, with a green
line that would have been read as coverage.

So verify-input gains a `repeat` subject: nothing before the delay, the
first repeat on the delay, the steady interval, cadence independent of frame
rate (the code claims this in a comment, so it is now asserted), and a
direction change restarting the delay. Each asserts THESE numbers, not the
shape -- a shape-only check would have passed on 0.40 / 0.20. The control
removes the premise, a held direction, and every controllable row inverts.

The first-repeat row measures from the arming tick, not from t=0: that tick
is the frame the press is handled, which is the origin the finding measures
its 12 frames from. Measured from zero it read 0.433 vs 0.402 and the
tolerance would have had to be widened to hide a units mismatch.

Closes #2

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 13:34:14 +02:00
5aeca0a55a Merge pull request 're: land the F5/F6 title-clock corpus (docs/re, reference data, sylpheed-formats)' (#23) from auto/frame-blend-draw-path into main
Reviewed-on: #23
2026-09-13 11:16:17 +00:00
MechaCat02
66f38adaa4 fix(lint): PathBuf is unused once the merge takes #22's shared disc_root
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 16:45:05 +02:00
MechaCat02
fd39038652 Merge origin/main into auto/frame-blend-draw-path
`mesh_consistency_disc.rs` had the only conflict: this branch added a
`Sightings` type alias where #22 replaced the file's private `disc_root()`
with the shared `common::disc_root`. Both kept — they are unrelated edits
that happened to land in the same lines.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 16:44:36 +02:00
MechaCat02
ccd49ac31f fix(lint): clear the clippy gate across examples and tests
80 findings, not the 14 the first run showed -- clippy stops at the first
failing compilation unit, so `--keep-going` is what makes the list complete.

60 were machine-applicable (`cargo clippy --fix`). The rest by hand:

* five descending `sort_by` -> `sort_by_key(Reverse(..))`
* `chunks_exact(4)` on both sides of four zips, so the compared items stay
  `[u8; 4]` rather than one array against one slice
* three `type` aliases for the census maps and the captured-quad tuple
* `&PathBuf` -> `&Path` in two disc tests
* two range loops; one of them keeps `#[allow(needless_range_loop)]` with the
  reason -- the index is into a map's value, which changes each iteration
* the module doc list in `invert_capture` re-indented to markdown's rules
* `blit`'s eight arguments get `#[allow(too_many_arguments)]`, not a struct

One dead `let off = b.len();` in a `ratc` test is dropped rather than renamed.
The sibling test at :162 is the one that asserts an offset; if this one was
meant to as well, that is a test change and not a lint fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 16:42:41 +02:00
MechaCat02
c6f7a18e30 fix(lint): the hand-judged clippy sites in library code
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 16:36:43 +02:00
MechaCat02
62376dd4a1 style: rustfmt sweep — 107 files the lint gate never saw
This branch predates CI on `main`. `cargo fmt --all` only; no behaviour.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 16:34:40 +02:00
5b84b3fb5d Merge pull request 'test: make $SYLPHEED_DISC an actual control, not a decoration (#16 remedy 3)' (#22) from fix/corpus-control into main
Reviewed-on: #22
2026-09-12 14:30:22 +00:00
b7e59a6245 Merge pull request 'feat: propose-work — push, open the PR, and move the issue, in one command' (#21) from feat/propose-work into main
Reviewed-on: #21
2026-09-12 14:30:05 +00:00
5952013a91 Merge pull request 'docs(agents): a red PR is the next unit of work, and check the workspace' (#24) from fix/loop-verify-own-pr into main
Reviewed-on: #24
2026-09-12 14:27:07 +00:00
sylph-decoder
4d1d5a1f2e re: fix two stale rows -- NEW GAME's destination, and my own repeat claim
No emulator-requiring state/approved item was open this iteration (issues
#1, #3, #5 all landed and moved to state/needs-human; #25 still awaits
approval). Used the gap for corpus consistency instead of idling, per the
same "a correction that never reaches the row someone reads" failure this
project keeps naming.

1. menu-navigation-semantics.md's own Q4 table still said NEW GAME was
   "not tested" and its own prose said it was "deliberately not pressed"
   and hangs the emulator -- both refuted BY THIS SAME PAGE on 2026-08-28,
   34 lines further down ("NEW GAME -- measured ... it is not a hang. It
   opens DIFFICULTY then SELECT DATA"). The correction never propagated
   backward into the table or the status line above it, so a reader
   stopping at either would come away with the wrong (and already-refuted)
   answer. Fixed in place, struck rather than deleted, with the actual
   destination and an honest note that DIFFICULTY has no id-table name
   match (already refuted separately) while SELECT DATA plausibly matches
   GP_SELECT_STORAGE as a fresh, low-confidence guess.

2. Found the identical failure mode in my own recent work: HANDOFF.md's
   original Q1-Q10 summary table (near the top of a 6600+ line file) still
   quoted the 2026-08-30 "no auto-repeat" finding as current, three commits
   after this same session measured 12 frames delay / 4 frames interval
   through a repeat-capable driver and explained why the earlier negative
   was a driver limitation, not a game fact. A reader who only sees the
   summary table -- which is exactly what a long file trains a reader to
   rely on -- would get the withdrawn answer. Fixed with an explicit note
   pointing at the current entries rather than silently editing the number
   in place, so the correction itself stays visible.

Refutation-shaped either way: two claims ("NEW GAME untested", "no
auto-repeat") checked against this corpus's own newer evidence and found
not to survive, recorded rather than left to be rediscovered.
2026-09-12 13:24:27 +00:00
sylph-decoder
34fb1ddf1e re: F3 sting half closed -- no sting, measured with a working positive control
Continues the static lead from two iterations ago
(f3-title-sting-mechanism-found-not-value.md) with the dynamic half it
named as the next step. Booted with --xma_param_probe=true (the same
census menu-audio-cues.md used for the menu's SE cues), no pad input,
recording continuously from window-open: a glyph time series (not a
threshold trigger) and every newly-seen XMA-PARAM stream, stamped on
arrival since Xenia's own log carries no timestamps.

Positive control, and a real one: the probe caught the title's two BGM
stems starting at t=147.6s, matching f3-title-plays-bgm-102-and-103.md's
already-established finding exactly -- the instrument finds a real stream
before being asked to find nothing.

From the plate's first visible activity through 68 seconds of build-in
plus fully-settled pulsing (killed at t=220.1s), zero new XMA streams
appeared beyond the two BGM stems and three unidentified early ones (boot
splash, not this question). No SE-range stream, no second BGM, nothing --
measured, not the prior static reach limit.

Refutation attempt this iteration, recorded either way: my first read of
the fine-grained glyph series said BGM and the plate's build-in start at
"essentially the same moment". Checking the raw per-sample data instead of
a coarse table refutes that -- first non-zero glyph reading is ~0.67s after
BGM onset, and immediately noisy rather than a clean climb. Corrected in
the doc rather than left as an overclaim for someone chasing frame-accurate
sync later.

Reference data: docs/re/data/f3-sting-{glyph-timeseries,xma-param-arrivals}.tsv
-- derived numeric/log-line data, not a capture of rendered game content.
2026-09-12 12:40:34 +00:00
sylph-decoder
ed9a7d702d re: F1 answered -- 12 frames initial delay, 4 frames interval, by patching in the repeat the driver lacked
Direct follow-through on this session's own named next step. The prior
result (f1-held-down-measured-no-repeat-via-file-driver.md) concluded the
file driver cannot show menu repeat because its GetKeystroke() never emits
a REPEAT-flagged event, and that the menu's repeat is very likely driven by
that flag rather than raw polled state. Testable, so tested: patched
/canary/src/xenia/hid/file/file_input_driver.h to add opt-in repeat behind
a new --pad_file_repeat cvar (off by default, every other scripted script
unaffected), using the SDL driver's own constants verbatim
(HID_SDL_REPEAT_DELAY/_RATE = 400/100, guest-time ms via
Clock::QueryGuestUptimeMillis) rather than re-deriving them. Incremental
rebuild, ~1 minute (only xenia_main.cc needed recompiling).

Control: the driver's own log confirms repeated keystroke events fire as
designed, zero crashes.

Result: re-ran the identical held-DOWN capture. The cursor that moved once
and stopped in the null result now cycles continuously through the whole
5-item menu, wrapping, for as long as the button is held -- the null result
was real for that driver path, and giving the driver the one thing it
lacked reverses it completely.

Measured at this run's achieved 29.87 fps guest rate: 12 frames (~402ms)
initial delay from the press-triggered step to the first repeat step; 4
frames (~133ms) steady-state interval for 13 of 15 gaps, 3 frames (~100ms)
for the other 2 -- slower than the raw 100ms constant driving it, which
this page flags but does not trace further (most likely the game batches
drained keystrokes per its own frame tick rather than reacting to each one
instantly). The 4-frame figure is what matters for the port: it's what the
cursor visibly does.

Honestly scoped: this measures what the game does when FED repeat events
shaped like the SDL driver's, not a capture through an actual physical
controller (none exists in this container) -- classified measured, not
decoded, for exactly that reason. One run only; the corpus's two-run
minimum isn't met, flagged rather than overclaimed.

f1_hold_capture.py gains an optional `repeat` argument. The Canary source
patch itself lives in /canary, outside this repo (Canary source, not
sylpheed-formats) -- fully described inline in the finding doc so it can be
reapplied if that tree doesn't persist across a container reset.

Reference data: docs/re/data/f1-repeat-cursor-transitions.tsv -- every
transition's frame, guest tick and Y position, not the raw draw log.
2026-09-12 12:31:05 +00:00
sylph-decoder
db830a1e75 re: F1 measured -- held DOWN moves the cursor once and no more, via the file driver
Fifth boot attempt this session, first clean one, using the harness debugged
last iteration (env-safe input, wide capture window, signed-in profile,
blanked X root). Reached the menu, held DOWN 2.5s wall-clock, armed the F10
draw capture, released, killed -- zero crashes.

Achieved vs requested: 433 of 600 requested frames, spanning 14.43s of GUEST
time against ~4.5s wall-clock for the hold+tail window -- this run went at
~3.2x real time (a cheap static menu, nothing pacing it to a display
refresh). The 2.5s wall-clock hold covers roughly 8s of that guest time.

Method: track one quad shape's position per frame via read_draws.py, not a
screen diff -- the approach f1-menu-repeat-harness-built-not-answered.md
already named as correct. Exactly one shape-group moves at all: one jump of
~0.21-0.225 NDC units (matching the known one-menu-item pitch), complete
within 4 frames / 133ms guest time of arming, then flat (a ~0.0125 pulse
wobble only) for the remaining 427 frames / 14.3s of guest time. Broadening
the match threshold finds no other moving element.

This is a STRONGER negative than the 2026-08-30 result it agrees with (that
one sampled a screen diff at ~4-5fps for 2.0s; this reads every quad every
frame for ~8s of guest-time held) -- it survives, rather than confirms, last
iteration's "coarse sampling hid a fast repeat" alternative, which does not
survive a per-frame instrument over a much longer window. Refutation
attempt against my own prior lean, recorded: it does not survive.

Reconciled, not left in conflict: the human's play-test and pad.py's
"auto-repeats" warning almost certainly went through a REAL controller
(Canary's SDL driver), which auto-repeats keystrokes at a documented
upstream 400ms/100ms (guest time) via the REPEAT keystroke flag. The file
driver deliberately never emits that flag, by design -- so it cannot show
repeat regardless of how carefully or how long it's held, which is exactly
the negative measured here. Still no F1 number; now a specific, well-
evidenced reason the file driver alone will never produce one, and a named
next step (add opt-in REPEAT-flag support to the file driver, matching the
SDL driver's constants, then re-run this exact capture) -- not attempted
this iteration, a second unit on an already-complete one.

Reference data: docs/re/data/f1-cursor-quad-y-per-frame.tsv -- the derived
per-frame Y position and guest tick, not the raw draw log itself (a capture
artifact, kept uncommitted per the corpus's game-content rule).
2026-09-12 12:13:41 +00:00
sylph-decoder
6f08999859 re: F1 dynamic attempt -- harness debugged through four bugs, still no number
Tried to close out issue #1 with an actual draw-log measurement this
iteration: built f1_hold_capture.py to boot to the settled main menu via the
proven glyph-gated route, arm the F10 UI-draw capture, hold a direction, and
read cursor position per frame -- the instrument f1-menu-repeat-harness-
built-not-answered.md already validated but never got to run against a
reachable menu.

Four bugs found across four boot attempts:

1. tap() shelled out to pad.py without this script's own env, so the press
   went to /tmp/xenia_pad.txt while Canary watched OUT/pad.txt -- an
   unobserved press indistinguishable from a dead pad. Fixed with an
   in-process tap() using the same pad() the hold uses; confirmed working
   the next run (title 154.5s, menu 163.0s).

2. ui_draw_capture_frames/max were persisted at 3/20000 from a prior
   session in xenia-canary.config.toml -- log_ui_draws is now a documented
   no-op (F10 arms unconditionally) and these two cvars didn't visibly
   respond to command-line overrides. Bumped to 600/400000 directly in the
   config.

3. The real blocker: this container has no signed-in profile (no content/
   directory at all -- a fresh container after a restart, which every
   container is right after one). Without a profile the title's sign-in
   dialog sets IsUIActive() true, which reproduces
   structures/title-a-press-fault.md's already-diagnosed unbounded-
   keystroke-queue crash -- verified byte-for-byte against that page's own
   addresses (PC 0x868 past sub_82457038, 0x828F3xxx registers, identical
   host/guest address arithmetic), looping continuously from before F10 was
   ever pressed. Fixed by creating a profile (--create_profile_if_none) and
   signing in (--logged_profile_slot_0_xuid), matching boot_menu.sh, which
   already did this and so never hit it. Confirmed: zero crashes with the
   fix, dozens per run without it.

4. Found but not re-verified: no xsetroot blank before launch, so a stale
   X-root frame from a killed prior run gave a false "TITLE" read at 2.6s,
   before any real window existed -- skip_intro.sh already blanks the root
   for exactly this reason. Fixed in the script.

Ran out of budget before a clean end-to-end run landed. Still no number for
issue #1 -- the Port keeps -1.0. Flagged prominently (HANDOFF, REFUTED.md)
because bug 3 will hit any bare run-canary invocation in any fresh
container, not just this script.
2026-09-12 12:02:53 +00:00
sylph-decoder
cefa90855b re: F1 -- traced C_PAD_RINGBUF; the queue naming inference was wrong
Continuing the F1 investigation rather than starting a fresh one. Last
iteration left two competing hypotheses open (Keystroke-queue-driven vs
polled-state-driven repeat) and flagged C_PAD_RINGBUF's producer as the
cheapest thing to trace next -- named but not traced.

Traced it this time: C_PAD_DECODER's own constructor (sub_8220B610)
allocates C_PAD_RINGBUF (52-byte control struct, 1024-byte backing buffer,
confirmed against its own Shift-JIS trace strings -- "C_PAD_RINGBUF
initialization" and its allocation-error message). Its update function
(sub_8220B8C0) takes the input-manager singleton as a parameter and reads
the ring at offsets 12, 36, 40, 44 and 48 -- not just the one button word.

Offsets 36-48 are four consecutive fields read together through the same
int-to-double conversion an analog axis would use. XamInputGetKeystrokeEx
has no field for a stick position, so a structure carrying four axis-shaped
fields cannot be a keystroke queue -- it reads as a periodically-refreshed
polled-state snapshot. My own prior reading of the "ring buffer" name as
implying a queue was the wrong inference; refuted by tracing it, recorded
either way per adversarial duty.

This shifts the balance toward the second, previously-uncertain hypothesis:
the file driver's GetState() was always capable of showing real repeat (no
modification needed), and nav_repeat_and_b.py's null result is more likely
a sampling artifact of its ~4-5 fps screen-diff detector than a structural
driver limit. Revises "what would close it" accordingly -- re-run the
existing draw-log position-tracking instrument, gated on the menu properly,
before reaching for a driver change.

Not found: the actual producer that writes into C_PAD_RINGBUF each frame --
narrowed to "reachable from the input-manager singleton fetch in
sub_821A9DC8," not traced to completion. Still no number for issue #1;
this narrows the path to one, further than last iteration but not there.
2026-09-12 11:05:22 +00:00
sylph-decoder
531c2d0ca4 re: F1 -- the "no auto-repeat" finding was measuring our own driver
Issue #1's premise (the human's play-test: a held direction repeats) directly
contradicted menu-navigation-semantics.md's 2026-08-30 "no auto-repeat"
row. Read the instrument before trusting either: nav_repeat_and_b.py drove
input through Canary's --hid=file driver, and that driver's GetKeystroke()
is explicitly, deliberately built to deliver exactly one event per held
press ("scripted input wants precisely one event per press, and repeat is
what makes menu steps overshoot" -- file_input_driver.h's own comment).
input-pad-read-path.md already established the game reads menu input via
this same Keystroke API. A driver engineered to prevent repeat cannot be
evidence the game lacks it -- the counter's control (a tap gives 1 spike)
proved the counter works, not that the driver could show more than one.

Not a clean reversal, and said so: the same driver's GetState() holds a
button continuously with no edge suppression, and pad.py's own docstring --
written by an earlier session driving this exact tool -- warns that a longer
dpad hold "auto-repeats and overshoots," describing an observed effect
through this same driver. The two pieces of evidence disagree and this page
does not resolve which wins.

Also read from Canary's source: the SDL input driver (what a real controller
goes through) auto-repeats keystrokes at 400 ms initial delay then 100 ms
interval, guest time (HID_SDL_REPEAT_DELAY/RATE, upstream Xenia, not a
project change) -- a concrete, testable prediction for what the real number
could be if the menu treats repeat-flagged keystrokes as nav steps, matching
the human's "medium pace" description. Not yet measured.

Refutation attempt this iteration, recorded per adversarial duty: targeted
the 2026-08-30 "no auto-repeat,  measured" claim. Survives only partially --
demoted to unsettled, not flipped to a confident opposite. New REFUTED.md
section (Menu navigation and input) and the row in
menu-navigation-semantics.md both corrected in place, old text kept per
convention.

What would close it: trace C_PAD_RINGBUF's producer (keystroke ring vs
polled state) statically, or add an opt-in repeat mode to the file driver
and read cursor position off the draw log per frame. Neither run this
iteration -- this is the static half, and reversing a standing claim is
enough for one unit without stacking a build-and-boot run on top of it
unverified.
2026-09-12 10:57:46 +00:00
sylph-decoder
f91ac9aad3 re: F3's sting half -- the mechanism is decoded, the value isn't (issue #5)
f3-title-plays-bgm-102-and-103.md's BGM census resolved a literal
`addi r5,r0,<imm>` before every call to the play primitive, which is blind by
construction to a cue id supplied any other way. Two of the primitive's 34
callers ARE supplied another way -- one is a register passthrough inside a
generic 6-caller wrapper `sub_821CCCB0(obj, cueId)` with a -1 "don't play"
sentinel. One of its six callers chains back to slot 1 of GamePart_Title's
OWN dispatch table at 0x820a3dec, identified by its adjacent
RegisterToFactory<0, class silph::GamePart_Title> string -- the same
convention already used disc-wide for the other 28 GameParts, not a
neighbourhood guess this time.

Traced as far as static analysis goes: the field that would carry the cue id
traces to a 19-caller shared helper's return value, too common to be
title-specific -- reads as "allocate a sound-emitter handle", not "here is
the cue". The value most likely gets set at whatever runtime moment the game
wants this emitter to speak, which a disassembly listing does not contain.
Classified undecodable-with-reach, not a fourth thing -- narrower and
better-aimed than the prior reach ("SE goes through a different call").

Every address cited was independently re-decoded from the raw .pe bytes
(file offset = VA - 0x82000000), not taken from the database's own
mnemonic/operands columns, and all agree.

Refutation attempt this iteration: checked whether the "6 callers is
exhaustive" claim for sub_821CCCB0 survives indirect dispatch (a plain
kind='call' xref scan is blind to a vtable/function-pointer-array entry).
Checked function_pointer_array_entries and kind='ind_call' xrefs for all
four functions in the chain -- none found. The claim survives.

What would close it: --xma_param_probe=true during a title boot's build-in,
watching for a newly-decoded stream when the plate reaches full alpha with
no input -- the same technique menu-audio-cues.md used for the menu's SE
census. Not run this iteration; this is the static half only.
2026-09-11 22:29:51 +00:00
sylph-decoder
b93d202f04 re: shape the F6 out-of-sample residue (issue #9) -- one open question, not three
f6-out-of-sample-RESULT.md left three failures unexplained beyond "n=2 wasn't
enough". Reviewing what's already decoded: two of the three (the ptcopyright/
parent ramp ratio, the sweep-leads-plate lead) fail in the SAME direction
(0.75x, 0.71x of predicted), and f6-unit10 already established the sweep and
plate families are gated by separately-triggered parents -- a ratio across
two independently-triggered elements has no structural guarantee of being a
constant, unlike a ratio internal to one element family (which is exactly
what the passing three checks are). The gross mislabeling that caused the
ORIGINAL 1.7x conflict was fixed two days before the prereg was written, so
that's ruled out as the cause here; whether the cross-group phase genuinely
varies boot to boot vs. an artifact in the frame-based ratio math is still
open, and needs more captures to tell apart -- filed as a follow-on, not run
here.

check_labels.py conflated two different claims under one "N LABEL(S) DRIFTED"
verdict: identity checks (which element -- clock-free, still 3-for-3 out of
sample) and timing checks (a cross-element ratio and a self-consistency curve
fit -- 0-for-2 out of sample). Split into two reported groups; only identity
gates the exit code now. Tolerances untouched -- widening them to pass f6c
would be tuning the check on the case that failed it, the same error class
already named twice in this corpus. Verified with synthetic data shaped like
the real f6c residue (3/3 identity, 0/2 timing, exit 0) and confirmed the
selftest's injected mislabel still fails an identity check (exit 1) --  no
capture exists in this fresh container to run it against real logs.

The withdrawn sweep->plate lead (0.138-0.141) stays withdrawn. Nothing here
reinstates a number.
2026-09-11 21:26:02 +00:00
sylph-decoder
1c49c92f34 fix: unbreak the merge -- ComposeOptions grew at, the Explorer's literal didn't
`cargo build -p sylpheed-cli` after resolving the merge's one real conflict
(a rustfmt-only clash) was not "the merge is resolved" -- it only checked the
crate whose conflict I'd just looked at. `cargo check --workspace --all-targets`
finds the actual break: sylpheed-viewer's `compose_screen` builds a
`ComposeOptions` struct literal, and this branch added a field
(`at: Option<u32>`, for posing a composite mid-animation) that main's Explorer
code never had to name because every prior caller used `..Default::default()`
or the field didn't exist yet. Neither side's diff touched the other's line,
so nothing in the conflict pointed at it.

`at: None` is the only correct value here -- the doc comment on the field
already says so ("`None` keeps the settled composite, which is what every
existing caller wants"), and the Explorer's screen view has no notion of
mid-animation posing to wire up. This restores its exact prior behavior; nothing
about the Explorer's data source, static-only rule, or design changes.

PR #23 is red on this. Fixes it in place rather than opening a second PR, since
it is the same unit -- a merge I performed that did not actually leave a
building tree.
2026-09-11 20:22:52 +00:00
MechaCat02
b21e9cba8d docs(agents): a red PR is the next unit of work, and check the workspace
Two gaps the first post-migration decoder iteration exposed, both in the same
place — the loop ends before it can observe its own result.

1. Step 1 read notifications but never looked at the agent's own open PRs. It
   opened #23, labelled the issue `state/needs-human`, and stopped; nothing in
   the brief would ever bring it back to a red check. Next iteration it planned
   to start a new question on top.

2. It called the merge resolved on `cargo build -p sylpheed-cli` — the crate the
   conflict was in. The break was in `sylpheed-viewer`, which neither side of
   the merge edited: one branch added a `ComposeOptions` field, the other had a
   literal construction of it. The crate you just fixed is the one place the
   breakage cannot be.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-11 22:04:57 +02:00
sylph-decoder
5b850bb565 Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path
# Conflicts:
#	crates/sylpheed-cli/src/main.rs
2026-09-11 19:23:13 +00:00
7f38c9d12e docs: strike propose-work from "Still to build" — it is built
GITEA-SETUP.md listed `propose-work` as unbuilt, and this PR builds it without
touching that list, so merging would leave the doc describing a tool as missing
that exists. Strike it the way `gitea-verify` already is: say what was built,
then say what is still missing — here, an end-to-end run, which only the agent
box can do because only it holds a token that can make the POSTs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-11 06:14:02 +02:00
15d51b30ac test(formats): make $SYLPHEED_DISC an actual control (#16 remedy 3)
Before this commit, `unset SYLPHEED_DISC` did not disable the disc-backed
suites on the machine that has the disc: every `disc_root()` fell back to a
hardcoded absolute path that exists on this box. The env var looked like a
control and was not one. Same for $SYLPHEED_RES3D and $SYLPHEED_ISO.

Replace the duplicated resolvers with one `tests/common/mod.rs`:

  - 17 local `disc_root()` definitions -> 1
  - 7 copies of the skip macro -> 1 (`skip_without_disc!` and siblings)
  - 16 hardcoded absolute paths -> 0 executable ones
    (3 of those were inline in `mesh_disc.rs`, in no resolver at all,
     and 2 were in `examples/`)
  - `corpus_report.rs` now reports on the SAME resolver the suites use,
    instead of a second copy of the logic its own comments flagged as a
    drift risk.

The 17 copies had already drifted into FIVE variants, and they were not all
the same function. `movie_manifest_disc`, `movie_subtitle_disc` and `slb_disc`
honoured $SYLPHEED_DISC and nothing else, while the other 14 fell back. So one
name already meant two things -- a third instance of the shape #16 is about.
The shared helper adopts the env-only behaviour those three already had, rather
than inventing a sixth variant.

Two module docs still described the fallback after it was deleted, which is the
same defect in prose: `texture_disc` claimed "or the default dev path exists"
and `pak_idxd_disc` said "or drop it at the default dev path below". Both now
say what the code does.

Verified both ways on the machine that HAS the corpus, which is the only place
this refactor can be falsified:

  A  env unset  -> "ABSENT -- $SYLPHEED_DISC unset; its suites self-skip"
                   suites=31 passed=209 failed=0 ignored=14, slowest 0.12s
  B  env set    -> "PRESENT via $SYLPHEED_DISC" (all three corpora)
                   suites=31 passed=209 failed=0 ignored=14,
                   slowest 1235.53s (mesh_consistency_disc)

Identical tallies, opposite corpus states, ~10000x apart in wall clock. (A) is
new behaviour -- it was previously unreachable here. (B) proves nothing broke.

`just test-disc` sources `.env` (already gitignored) for the set case. Note the
quoting trap documented there: the corpus paths contain spaces, and an unquoted
`VAR=a b c` parses as "run command `b`", failing silently into ABSENT -- which
looks exactly like a working skip.

Remedy (1) (`#[ignore]` + `--ignored`) is deliberately NOT done here: (3) already
moves the mode from the filesystem into the environment, and `#[ignore]` already
carries three meanings in this directory (corpus-absent, known-failing, bare).
Overloading it a fourth time would re-create the defect.

`cargo fmt --all --check` clean; no new compiler warnings.

Refs #16

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 20:47:23 +02:00
b924d1e9cb feat: propose-work — push, open the PR, and move the issue, in one command
GITEA-SETUP.md has listed this under "Still to build" since 2026-09-04:

  `propose-work`, superseding `push-work` -- push the branch AND open the PR
  with `Closes #N` AND set the label, in one step. Today `push-work` does the
  first third; the other two thirds being manual is how they get skipped.

PROTOCOL.md 145-149 requires all three:

  * branch `auto/<agent>/<issue#>-<topic>`, one item per branch
  * open the PR with `Closes #<issue>` in the body
  * label the issue `state/needs-human` and say, in one line, what to look at

Until now those were three things to remember, and PR #20 had to add a warning
to `port-loop.md` about the two that get forgotten. A rule enforced by memory
decays; this makes the sequence structural.

WHAT IT DOES NOT DO is reimplement push-work's refusals -- it CALLS push-work,
so `main`, shared branches and force-push stay refused in exactly one place.
Duplicating them would let the copies drift, and the copy that drifts is the
one that matters.

Three design choices worth stating:

  * THE ISSUE NUMBER IS DERIVED FROM THE BRANCH NAME, which PROTOCOL already
    specifies as `auto/<agent>/<issue#>-<topic>`. So a PR cannot cite a
    different issue than the branch was cut for -- a mismatch no reviewer would
    catch. `-i` overrides.
  * `-m` IS MANDATORY. PROTOCOL says an issue in `state/needs-human` must say
    what to look at and what pass and fail look like, "so a person can judge it
    in under a minute". Refusing without that line is cheaper than letting the
    label carry an empty promise and costing a human a round trip.
  * IT MOVES THE LABEL RATHER THAN ADDING IT -- other `state/*` labels are
    removed. Leaving `state/in-progress` attached makes the board lie about
    what is waiting on a person.

The token is read from a file and handed to curl through a `--config` document
on stdin: never an argument, never exported. Arguments are world-readable in
/proc and this token can push. Verified that the mechanism actually delivers
the header rather than silently dropping it -- with a bogus token the API
answers "invalid username, password or token", while the same URL with no
header returns the list anonymously, so the header is demonstrably being read.

Also verified: issue derived from the branch (#42 from
`auto/decoder/42-widget-census`), refusal without `-m`, refusal when the branch
carries no number, `--dry-run` sends nothing, and repo/API derivation from the
remote. `--dry-run` deliberately does NOT require a credential -- it exists so
an agent can check the command it is about to run, and demanding a token it
never sends would make the check unavailable exactly where it is cheapest.

Identical in both agents' bin/ on purpose: the agent name comes from the
branch, so there is nothing per-agent to diverge.

UNVERIFIED, and stated as such: no end-to-end run. That needs a real token and
a real issue, which this desktop does not have -- it is the second machine, and
the agent credentials live on the agent box. Everything above the network call
is exercised; the POSTs are not.

Refs #11

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 19:17:41 +02:00
1884c5d664 Merge pull request 'docs: give the Port agent an Each iteration section (it had none)' (#20) from fix/port-loop-iteration into main
Reviewed-on: #20
2026-09-10 17:09:41 +00:00
65004ffe2c docs: give the Port agent an Each iteration section (it had none)
`decoder-loop.md` has had `## Each iteration` since 2026-09-04, ending in

  7. Commit, `push-work`, open the PR, label the issue `state/needs-human`,
     and stop.

`port-loop.md` has never had that section at all. It states the rules -- "you
cannot close your own work", "you move an item to state/needs-human", work
reaches main "through pull requests" -- but nowhere gives the STEPS that carry
them out. The Port agent was told the rule and never the procedure.

Two steps were missing entirely, and both are Phase 7 check items:

  * READ YOUR NOTIFICATIONS first. They are polled and nothing pushes them, so
    an agent that skips this never receives anything addressed to it -- and the
    symptom is silence, not an error. That is GITEA-SETUP.md Phase 7 check 1.
  * OPEN THE PR AND SET THE LABEL. That is Phase 7 check 2.

The second carries a trap worth naming in the brief rather than in a runbook:
`docker/port/bin/push-work` ONLY PUSHES. Verified by reading it -- no /pulls
call, no `Closes #`, no label; its refusals (no main, no force-push) are
intact. `propose-work`, which would do all three, is still unbuilt --
GITEA-SETUP.md's own words are "the other two thirds being manual is how they
get skipped". The capability is there (`pull_request_write` and `issue_write`
are both in the pinned MCP tool set), so this is an instruction gap, not a
permissions one.

Written to mirror the Decoder's shape while using the Port's own vocabulary --
a gate is an artifact, verify against captures rather than our renderer, state
the expected number first, `authored/` entries carry a `why`, never an invented
number where a measured one is pending.

Found by the Pi agent while answering a Phase 7 readiness question. My own
check had been decoder-only, which is why the asymmetry survived it.

Refs #11

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 19:37:40 +02:00
8c4ce15c55 Merge pull request 'test: report which corpora a run actually had (#16 remedy 2)' (#19) from fix/corpus-report into main
Reviewed-on: #19
2026-09-09 16:50:52 +00:00
9b286596e9 test: build the fallback message with format!, matching the commit before it
`420e84c` claimed the report prints

  SYLPHEED_DISC   PRESENT via the HARDCODED fallback, NOT $SYLPHEED_DISC

and it did not. The string was built by `"...(not ${env})".replace("${env}",
env)` -- a placeholder substituted at runtime, which printed
`(not SYLPHEED_DISC)` and dropped the `$`. I had cleaned this up before
committing, but the edit silently no-op'd (rustfmt had already rewrapped the
line, so the pattern no longer matched) and the commit went ahead with the
message quoting output the code does not produce.

Now a plain `format!`, which is what it should have been: shorter, no
placeholder to keep in sync, and the `$` makes it read as the env var it is.
The quoted output in `420e84c` is accurate as of this commit.

Not squashed into it because force-push is denied on this remote, and a
visible correction is worth more than a rewritten history anyway.

Verified: `cargo fmt --all -- --check` clean, both tests pass, output matches
the text above exactly.

Refs #16

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 07:40:20 +02:00
420e84c90f test: report which corpora a run actually had (#16)
`cargo test --workspace` reports the same tally whether the disc corpus was
exercised or entirely absent. Measured: the disc suites RAN on a developer
desktop (1936 s, mesh_consistency_disc alone 1220 s) and SKIPPED on CI
(2.4 s total) -- and both reported 207 passed / 0 failed / 14 ignored across
30 suites.

Two mechanisms compound:

  * a skip is a PASSING test. The gated suites `eprintln!("SKIP: ...")` and
    return early from a test that still passes, so a skipped suite and a
    fully exercised one both score 1 passed. The totals are invariant.
  * the message is invisible. `cargo test` captures a passing test's output,
    so NEITHER log contains a `SKIP:` line. The absence of one proves
    nothing, which makes the obvious check useless too.

And `14 ignored` cannot help: `#[ignore]` is static, so that column is the
literal count of attributes in the source and cannot move at runtime. Ask
what this check would still report if the corpus were entirely absent, and
the answer is 207/0/14.

This is #16's remedy (2) -- the only one that touches the REPORT, which is
the defect. Remedies (1) and (3) improve the control and are left open.

Adds `tests/corpus_report.rs`: always runs, never fails, resolves all three
corpora exactly as the per-suite helpers do, and records what was available.
It writes to a FILE rather than relying on stdout, because a passing test's
stdout is captured and would be invisible in exactly the CI log that needs
it; the workflow then prints that file. It also appends to
GITHUB_STEP_SUMMARY when set.

Run here, it immediately shows the thing the issue is about -- all three
corpora resolve through the HARDCODED fallback, so SYLPHEED_DISC is not
controlling anything on this machine:

  SYLPHEED_DISC   PRESENT via the HARDCODED fallback, NOT $SYLPHEED_DISC
  SYLPHEED_RES3D  PRESENT via the HARDCODED fallback, NOT $SYLPHEED_RES3D
  SYLPHEED_ISO    PRESENT via the HARDCODED fallback, NOT $SYLPHEED_ISO

The ABSENT branch is the one CI takes and cannot be reached on a machine
that has the corpora, so `resolve_renders_every_branch` exercises it
directly rather than shipping it unrun -- along with "set but does not
resolve", which is what a typo in the env var produces and which is
deliberately reported as a DIFFERENT state from absent, since the two want
different fixes.

Verified: `cargo fmt --all -- --check` clean. Clippy is unchanged by this
(a test target; CI's `cargo clippy --workspace` does not build test cfg) --
it fails identically on unmodified main here with
`only_used_in_recursion` at vfs.rs:85, which is the rustc 1.90.0 vs the
runner's 1.98.1 divergence, i.e. #15, not this.

Refs #16

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 07:39:49 +02:00
1bae6c6bad Merge pull request 'style: rustfmt sweep — 774 hunks across 154 files → 0 (#12)' (#18) from chore/rustfmt-sweep into main
Reviewed-on: #18
2026-09-08 20:09:53 +00:00
066b34df1a Merge pull request 'WASM: compile for wasm32, and fix trunk's binary selection on aarch64' (#17) from fix/clippy-lints-wasm into main
Reviewed-on: #17
2026-09-08 20:09:43 +00:00
ed54f95d54 style: rustfmt sweep -- 774 hunks across 154 files -> 0
`cargo fmt --all -- --check` has failed on every run in this repository's
history, identically on `main` and on every branch. This is #12.

Mechanical: `cargo fmt --all`, nothing else. 154 files, all `.rs`, no other
extension touched. `cargo check --workspace` exits 0 afterwards, so nothing
changed semantically.

ON THE ORDERING, WHICH WAS THE REAL QUESTION.

HANDOFF-2026-09-06 section 7 warns this is the expensive fix: a whole-tree
reformat before #7 and #8 return "would put a conflict in every file of 861
commits and make the reviews those items exist to enable unreadable".

That is measurably too pessimistic, and it had been reasoned rather than
tested. Measured here by three-way merging a rustfmt'd `main` against both
unmerged branches, file by file:

  file/branch pairs tested   32
  merges CLEAN               28
  merges CONFLICTING          4   (8 conflict hunks total)

    sylpheed-cli/src/main.rs      1 hunk
    sylpheed-export/src/check.rs  1
    sylpheed-export/src/screen.rs 4
    sylpheed-export/src/video.rs  2

All four are against `auto/frame-blend-draw-path` only;
`auto/port-p6-audio` does not conflict anywhere. The earlier framing --
154 dirty files, 133 that cannot collide, 21 that can, the collision set
carrying 147 of 774 hunks (19%) -- reproduces exactly. What it did not say
is that most of the 21 still merge cleanly, because rustfmt's edits and the
branches' edits rarely land on the same lines.

So the cost of sweeping now is 4 files and 8 hunks for one branch, against
a check that is otherwise red forever. Deliberately NOT folded into the
WASM PR: 154 reformatted files would make that one unreviewable.

Closes #12
2026-09-08 20:07:01 +02:00
c7bdc11f22 ci(wasm): drop the artifact upload, which cannot work on Gitea
With the build fixed, `trunk build --release` succeeds and the job then
died on its last step:

  ::error:: @actions/artifact v2.0.0+, upload-artifact@v4+ and
            download-artifact@v4+ are not currently supported on GHES.

Gitea presents as GHES and the action aborts by design -- go-gitea/gitea
#31256 and #36024. Same class as the trunk-action bug this branch already
fixes: an action written for GitHub's hosted fleet, on a runner that is not
it.

Dropped rather than downgraded, because nothing consumes the artifact.
`web-dist` had exactly one reference in the repository -- the line that
produced it. There is no `download-artifact`, no deploy step, and no second
workflow. It was failing the job for no benefit.

The two ways to keep it are recorded in the file rather than here, because
choosing between them needs a fact this run does not provide (the runner's
node version) or a supply-chain decision (a third-party action).

What now runs end to end on aarch64, from scratch:

  Install Trunk             ok   (v0.5.1, the arch fix, on the real runner)
  cargo check wasm32        ok
  trunk build --release     ok   10m 56s, 3 files in dist/

Refs #11

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-08 20:03:30 +02:00
b2bc70d483 fix(wasm): select the bin target, so trunk emits a real bundle
`trunk build --release` reached the asset pipeline for the first time and
failed there:

  found more than one target artifact: ["sylpheed_viewer", "sylpheed-viewer"]

The crate declares both a [[bin]] `sylpheed-viewer` (src/main.rs) and a
[lib] `sylpheed_viewer` cdylib (src/lib.rs), and the index.html link named
neither, so trunk refused to guess.

Trunk's error offers two ways out and THEY ARE NOT EQUIVALENT. Measured,
both exiting 0:

  data-target-name="sylpheed_viewer"   1_478 bytes,        1 app symbol
  data-bin="sylpheed-viewer"          21_298_268 bytes, 2_998 app symbols

Selecting the lib "succeeds" while linking nothing, because there is no
wasm entry point in it -- no wasm-bindgen dependency, no import, no
`#[wasm_bindgen(start)]`. The linker drops the whole app and trunk emits an
empty module. That would have turned this job GREEN on a bundle that cannot
start, which is worse than the red it replaced.

`main()` is a valid wasm entry: it calls `sylpheed_viewer::run()` and its
only native-specific code is already `#[cfg(not(target_arch = "wasm32"))]`.
With the bin selected, trunk injects a real init -- `import init`, an
integrity-checked module preload, `__wbindgen_start`, and the
`TrunkApplicationStarted` event.

The lib.rs docs claimed this file was the WASM entry point "called from
`wasm_bindgen` init on the web". Nothing ever called it. That comment is
what made the lib look like the right target, so it is corrected here
rather than left to mislead the next reader.

Verified locally with trunk 0.21.7 on x86_64. The exit code does not
distinguish these two cases -- only the artifact does.

Refs #11
2026-09-08 18:55:05 +02:00
35000abacf Merge pull request 'Clear all 73 clippy lints, and make the Clippy step real' (#14) from fix/clippy-lints into main
Reviewed-on: #14
2026-09-07 19:58:07 +00:00
5e7c64945a Merge pull request 'Gitea working surface: MCP, branch protection, runbook, and two protocol rules' (#10) from agents/gitea-mcp into main
Reviewed-on: #10
2026-09-07 19:57:55 +00:00
sylph-pi
5c25d74fe1 ci(wasm): bump trunk-action v0.5.0 -> v0.5.1 for aarch64
`Install Trunk` has never run to completion here, because the two steps
before it always failed first. With those cleared it becomes reachable,
and on this runner v0.5.0 would fetch the wrong binary.

v0.5.0 switches on PLATFORM alone and never consults the architecture:

  case 'linux': arch = 'x86_64-unknown-linux-gnu'; break;

v0.5.1 reads it and maps it, failing loudly rather than wrongly:

  const arch = process.env['ARCH'] || process.arch;
  case 'x64':   targetArch = 'x86_64';  break;
  case 'arm64': targetArch = 'aarch64'; break;
  default: core.setFailed(`Unsupported architecture: ${arch}`); return;

Node reports `arm64` here, so it resolves to `aarch64`, and upstream does
publish trunk-aarch64-unknown-linux-gnu.tar.gz. There is also an `ARCH`
env override if the mapping is ever wrong.

Read out of the two bundled dist/index.js files, not the release notes.
Counts moved as predicted: `x86_64-unknown-linux-gnu` 1 -> 0, `aarch64`
0 -> 1, `os.arch()` 5 -> 5. Confirmed independently on both machines.

Two further changes the bump carries, neither of them about architecture:

  * the download host moves thedodd/trunk -> trunk-rs/trunk. Trunk moved
    repositories and v0.5.0 still points at the old one -- arguably the
    more durable half of the fix.
  * `io.mv` 1 -> 0 and `io.cp` 2 -> 3. A cross-filesystem move throws
    EXDEV; a copy does not. This is the fix for self-hosted runners whose
    /tmp is a separate filesystem, which is ours. NOTE: the string EXDEV
    appears zero times in either bundle, so this cannot be found by
    grepping for the error it prevents -- it is visible only as the
    primitive swap.

STILL UNVERIFIED: whether `trunk build --release` then succeeds. Everything
above concerns selecting and fetching the binary. The step after it has
never run in this repository's history, on any architecture, so there is no
basis to predict it. Expect to read that log fresh.

Refs #11

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 21:32:41 +02:00
sylph-pi
1405d7b8ca fix(wasm): make cargo check --target wasm32 compile
With the `mio` subtree gone (previous commit), two blockers remain. Each
was invisible until the one before it was cleared, which is why #11 was
written around only the first.

1. getrandom 0.3 refuses wasm32-unknown-unknown without being told which
   backend to use. It needs `--cfg getrandom_backend="wasm_js"` AND the
   crate's `wasm_js` feature; its own error is explicit that either alone
   is insufficient. Nothing here depends on getrandom directly -- it
   arrives through `ahash`, in `sylpheed-viewer` only -- so the feature
   half is declared there purely to switch it on.

2. error: bevy_egui uses unstable APIs to support clipboard on web.
   Needs `--cfg web_sys_unstable_apis`.

Both cfgs live in /.cargo/config.toml scoped to the wasm target, so native
builds are untouched.

Verified on aarch64 / rustc 1.98.1 -- the runner's toolchain -- from
scratch with the cache cleared: exit 0 in 163s. Independently reproduced
on x86_64 / rustc 1.90.0 as a controlled A/B against the parent, both
running the job's exact invocation:

  with this branch                        exit 0, zero errors, 38s
  same command at 34f19ae                 exit 101, the getrandom error

The control also shows `bevy_egui` is never reached when getrandom fails,
and the passing case contains no `mio` and no `tokio` in the wasm graph at
all -- so each blocker is confirmed separately rather than by the
aggregate exit code.

This does NOT make the WASM job green, and the next failure is already
identified rather than left to be discovered. `Install Trunk` uses
`jetli/trunk-action@v0.5.0`, whose bundled `dist/index.js` contains the
string `x86_64-unknown-linux-gnu` exactly once and `aarch64` not at all,
while calling `os.arch()` five times with no mapping for it. On this
aarch64 runner it will fetch an x86_64 binary. Upstream trunk does ship
`trunk-aarch64-unknown-linux-gnu.tar.gz`, so the asset exists and only the
action's selection is wrong -- but replacing the install step means
picking a version to pin and an install method, which is a decision, not a
fix. Left for #11 to decide.

Refs #11

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 21:06:41 +02:00
sylph-pi
2216f71ca9 fix(formats): drop the unused normal tokio dependency
`sylpheed-formats` declared `tokio` as a normal dependency and never used
it as one. All four references in its `src/` are inside a `mod tests` --
three runtime builders in ship.rs (539, 566, 690; `mod tests` at 498) and
one `#[tokio::test]` in xiso.rs (182; `mod tests` at 179) -- and tokio was
ALREADY present in `[dev-dependencies]`, so the tests keep compiling
unchanged.

The unused normal dependency pulled `tokio/full`, whose `net` feature
drags in `mio`, which does not build for wasm32:

  error: This wasm target is unsupported by mio.

Removing it is right on its own terms; the WASM job is merely what exposed
it. Native is unaffected -- `cargo check --workspace` exits 0 on x86_64.

This is separated from the CI configuration it was found through because
it is the one change here that touches another crate, and #11 is
`state/proposed` around the getrandom error alone. It is ordered first so
that every commit builds: the reverse order would leave an intermediate
commit still failing the wasm check on `mio`.

WARNING: this does NOT reach `sylpheed-export`, which builds
`sylpheed-formats` from the git pin `formats-pin-2026-09-01` (`e2630413`,
contained in `auto/frame-blend-draw-path` only) rather than the workspace
path crate. The dependency is not gone tree-wide until that pin resolves,
so anyone later adding `-p sylpheed-export` to the WASM job will hit `mio`
with this fix apparently already applied.

Refs #11

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 21:06:26 +02:00
34f19ae66e docs: the handoff's resume steps assume a machine this is not
§§1-9 were written on fabi-Hyrican-PC. On the other desktop the ~/.sylph-*
credentials do not exist, the Pi does not resolve, and stable is 1.90.0 rather
than the 1.98.1 §8 records -- so §8.2 (fetch the WASM bundle) and §8.4 (Phase 7)
cannot be run from here at all. Says which of the four steps can.

Measured rather than carried over: protection holds (10/10), fmt is 774 hunks
across 154 files, check-citations is 19, and the tests are 207/0/14 across 30
suites. Two of those need reading carefully:

  * clippy DIVERGES. The runner is rustc 1.98.1 -- read out of job 794's log,
    not assumed -- and is clean; here 1.90.0 exits 101 on only_used_in_recursion
    at vfs.rs:85. That is #15 ceasing to be theoretical. It is NOT evidence that
    CI's green is fake, which is the §7 lesson-5 inference in the other
    direction.
  * the test tally matches to the unit while measuring something else. 15
    *_disc.rs files resolve disc_root() through a hardcoded absolute path, so
    unsetting SYLPHEED_DISC does not skip them: the disc suites RAN here (1936 s,
    mesh_consistency_disc alone 1220 s) and skipped on CI (2.4 s total) -- and
    both report 207/0/14, because the skip path returns from a test that still
    passes. Good news for #14, since this run is the stronger evidence; and worth
    an issue, since SYLPHEED_DISC looks like a control and is not one.

I got that last one wrong first -- inferred "the counts cannot match" from "the
fallback resolves", which is §7's shape a sixth time, recorded as such.

Also: a plain `git clone` of this repo fails three ways on the pack that still
carries the 545 MB; --filter=blob:none works. And §6's tokio claim was
challenged and survived -- every use is inside a #[cfg(test)] module.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-06 22:20:30 +02:00
MechaCat02
08b589fb70 docs: handoff for resuming on another machine
Written to be read cold by a session with no context: what is established
versus what is someone's claim, which of the four actors the gate actually
binds, and what is in flight but unpushed.

The transferable part is §7 -- one failure shape recurred five times in two
days across two agents and the assistant: a property inferred from something
ADJACENT to it rather than tested directly. Protection from a settings page,
reachability from a DNS record, a label count from a grep that matched the
function definition, Gitea's host from a DNS lookup, and a clippy version from
rustfmt output parity. The last is the sharpest: rustfmt 1.8.0 and 1.9.0, nine
months apart, both emit 774 hunks here, so formatting parity carries no
information about which clippy ran -- and the conclusion drawn from it (that
CI's green was cached or ungated) was wrong in a way that would have sent
someone chasing a phantom.
2026-09-06 14:01:39 +02:00
MechaCat02
e0bcef1ec2 fix(formats): collapse the one else { if }, so both toolchains agree
`ascii_runs` in movie_manifest.rs had a nested `else { if .. }`. Clippy's
`collapsible_else_if` flags it — on some toolchains.

WHY IT WAS NEVER CAUGHT, AND WHY THAT IS THE INTERESTING PART:

  clippy::collapsible-else-if   @1.92.0 (2025-12-08)  ->  warn
  clippy::collapsible-else-if   @1.98.1 (2026-09-01)  ->  allow

CI installs `dtolnay/rust-toolchain@stable`, which floats. The runner is on
1.98.1, where this lint is allow-by-default, so the Clippy job passed. A local
run on a nine-month-old stable failed on the same bytes. Neither instrument was
broken; "clippy clean" is simply a statement about a toolchain and a date, and
nothing in the pipeline records which. That is #15, and this commit does not fix
it -- it removes one instance of its consequence.

Fixing it rather than pinning, because `else { if }` is worse code on every
version. A tree whose cleanliness is contingent on a release date is the thing
to avoid; agreeing with both toolchains is cheaper than arguing about which one
is right.

⚠️ I FIRST DIAGNOSED THIS WRONG, and the wrong version is worth recording. From
CI's rustfmt reporting 774 hunks and mine reporting 774, I concluded the
toolchains matched, therefore the clippys matched, therefore CI's green must be
a cached or ungated result -- "the frozen splash again". Every step after the
first was false. rustfmt is deliberately output-stable within a style edition;
clippy explicitly moves lints between groups. Measured here afterwards:

  rustfmt 1.8.0-stable -> 774 hunks
  rustfmt 1.9.0-stable -> 774 hunks     (nine months apart, identical)

So formatting parity carries no information about which clippy ran. It is the
same error as reading protection off a settings page or reachability off a DNS
record: a property inferred from something ADJACENT to it. The peer refuted it
by measurement -- `No cache found` in the run log, and `success()` evaluating
'true' in 207 against 'false' in 203 -- rather than by accepting the framing.

Verified on both: 1.92.0 `clippy --workspace -- -D warnings` rc=0 (was 101);
1.98.1 with the lint forced on, 0 sites. rustfmt still 774, so no debt added to
#12. Tests 207 passed / 0 failed / 14 ignored, unchanged.
2026-09-06 10:17:55 +02:00
sylph-pi
658a93de9e fix: stop the lint pass adding rustfmt debt to #12
The lint work added 8 rustfmt hunks. Run 206's Formatting job reports 782
where run 204 reported 774, and the difference is mine — debt added to the
one issue the lint pass argued should not be disturbed. Measured against a
`4ac5c9f` worktree under the same rustfmt, the tree is back to 774: equal
to baseline, not merely close to it.

Two causes, both interactions rather than mistakes of judgement:

`cargo clippy --fix` writes its replacement on one line. Where the call
sat inside a multi-line method chain that produced

    .as_chunks::<2>().0.iter()

which rustfmt wants split across three lines. Seven sites, in
`formats/{audio,vfs,game_data}.rs` and `cli/main.rs`. An eighth was a
`for` header pushed past the width limit; it reads better as two bindings
than as a six-line chain, so that is what it became.

The last one is subtler and was the only file left over after the other
seven were fixed. `ship_capture.rs` had

    let mut flush = |base: u32,
                     size: u32,

and clippy correctly removed the `mut`. That shortens the line by four
characters, so the closure's six continuation parameters were then
aligned four columns too far right — a formatting change caused by a
change on a different line, in a file whose own hunk count is what
exposed it.

Worth recording because it generalises: `--fix` output is not rustfmt
output, and on a tree that is not rustfmt-clean the difference is
invisible in the diff and only shows up as a hunk count moving. The check
that catches it is a count against a same-toolchain baseline, not an
inspection of the patch.

Re-verified after the reformat, since these edits changed real lines:

    cargo clippy --workspace -- -D warnings   exit 0
    cargo test   --workspace                  exit 0   207 passed, 0 failed
    cargo fmt    --all -- --check             774 hunks == baseline

Refs #12, #13

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
2026-09-05 22:51:18 +02:00
sylph-pi
531bb1a7f3 fix(viewer,cli,export): clear the remaining 30 clippy lints
`cargo clippy --workspace -- -D warnings` now exits 0. `cargo test
--workspace` still reports 207 passed, 0 failed, 14 ignored across 30
suites — identical to runs 203 and 204, so none of this changed behaviour.

The workspace total was 73, not the 48 run 204 reported. `-D warnings`
turns a lint into a hard compile error, so `sylpheed-formats` failing
stopped its dependents from ever being built: `sylpheed-viewer` (14) and
`sylpheed-cli` (11) had never been linted by anyone. Clearing formats in
bc79817 is what made them visible.

  formats  43 -> 0   (bc79817)
  viewer   14 -> 0
  cli      11 -> 0
  export    5 -> 0

Collision surface, measured rather than assumed. Every viewer file
carrying a lint is byte-identical on both `auto/frame-blend-draw-path`
(495 commits) and `auto/port-p6-audio` (366). All eleven cli sites fall
outside every hunk either branch touches. 68 of the 73 sites could not
collide with anything.

The five that can are all in `sylpheed-export`, and three of those are
real:

  main.rs:278   `&out` -> `out`, inside frame-blend's hunk -278,12
  main.rs:318   `&out` -> `out`, inside port-p6-audio's hunk -303,44
  audio.rs:113  an added `#[allow]` in a file frame-blend DELETES

Each is one line. Resolving the first two means taking the branch's
version and re-applying a borrow removal; the third resolves to the
deletion. Flagged here so neither branch owner meets them cold.

Judgement calls, all stated at the site rather than suppressed globally:

* Three `too_many_arguments` in the viewer are false positives.
  `draw_viewer_ui`, `poll_loader_channel` and `apply_pak` are Bevy
  systems — every parameter is a `Res`/`ResMut`/`EventWriter` the
  scheduler injects, so the count is the framework's dependency list and
  cannot be reduced without a `SystemParam` struct.
* `cmd_screen_render` (cli, 8/7) is a plain function, so that one is real
  if mild; its arguments are the subcommand's flags.
* Two `dead_code` fields in export are serde schema fields. They model
  what the on-disc JSON accepts; deleting them would quietly change that.
* `iso_loader.rs` gains a `FrameRx` alias for the ffmpeg frame channel,
  which is what "very complex type" was asking for.

A site-local `#[allow]` with a reason is a decision recorded where it
applies: one lint, one function, and any new violation elsewhere still
fails the build. That is not the shape PROTOCOL.md forbids.

Closes #13

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
2026-09-05 17:47:50 +02:00
sylph-pi
cbb6c078a6 fix(formats): clear all 43 clippy lints in sylpheed-formats
Run 204 gave this repository its first clippy measurement — 48 errors, 43
of them in `sylpheed-formats`. This clears that 43 to zero under the exact
invocation CI runs, `cargo clippy -p sylpheed-formats -- -D warnings`.

Why this crate first, and why it is safe to touch:

Every one of the 43 sites was checked against the line ranges that
`auto/frame-blend-draw-path` (495 commits) and `auto/port-p6-audio` (366)
actually modify. None of them overlap. Eleven of the fifteen affected
files are byte-identical on both branches, including `mesh.rs` and
`texture.rs`, which carry 28 of the hits between them. The three sites in
`audio.rs`, `ui_layout.rs` and `slb.rs` that live in files those branches
do change fall outside every modified hunk. The collision argument that
defers #12 does not transfer here; it was tested rather than assumed.

It also unblocks a measurement. `-D warnings` turns a lint in this crate
into a hard compile error, so its dependents never build — `sylpheed-cli`
and `sylpheed-viewer` have never been linted at all, and viewer is the
largest crate in the workspace. Both depend only on `sylpheed-formats`
(`sylpheed-export` pins it from a git tag instead), so this commit is what
makes their real counts knowable.

  38  applied by `cargo clippy --fix` — chunks_exact_to_as_chunks,
      manual_div_ceil / is_multiple_of / range_contains, unnecessary_map_or,
      needless_borrow, let_and_return, dead_code, unused_mut/variables.
      Purely local expression rewrites: 38 insertions, 39 deletions.
   2  by hand: a doc continuation that markdown was parsing as a list, and
      `d / frame` behind a `frame > 0` guard becoming `checked_div`.
   3  `#[allow(clippy::too_many_arguments)]` with a stated reason.

On those three allows: 8 parameters against a threshold of 7, in the mesh
anchor path. The real fix is a shared params struct across
`anchor_pool_mesh`, `validate_block` and `validate_block_report` — the
latter two take the same eight arguments and one delegates to the other —
which is a change to the decoder's signatures and belongs to whoever owns
that path, not to a CI-lint pass.

This is not the shape PROTOCOL.md forbids. `continue-on-error` suppresses
everything, present and future, at the job level, and cannot tell "not
yet" from "no longer". A site-local `#[allow]` with a reason is a decision
recorded where it applies: one lint, one function, and any new violation
anywhere else still fails the build.

`sylpheed-export`'s remaining 5 are deliberately untouched — three of them
sit inside hunks both long-lived branches modify, and that crate blocks
nothing. Left for #13.

Refs #13

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
2026-09-05 16:59:57 +02:00
sylph-pi
82ea4f5963 docs: record the third softening, which was authored dirty
The two instances already in "Checks that were kind once" were correct
when written and decayed. The third was wrong on its first commit, and it
arrived by a different route: the check and the tree's failure to pass it
land in the same change, so the softening writes itself.

Concretely — the Clippy step had never run (no component in the
toolchain), and the tree is not clippy-clean, so fixing the step and
turning it red are the same commit. The first draft paired the fix with
`continue-on-error: true` and a comment promising removal once the debt
was paid: an expiry date nobody set, in the shape #12's closing line had
already ruled out for rustfmt. Reverted on reading it.

Adds the distinction, a table separating decay from dirty authorship, and
an earlier tell than the mechanical test:

    If you are writing the softening in the same commit as the check,
    the thing you want is an issue, not a flag.

The mechanical test is unchanged and still correct; this only catches the
same failure sooner, at the keyboard rather than at review.

Refs #12, #13

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
2026-09-05 15:55:04 +02:00
sylph-pi
e85bb0bb05 ci: install the clippy component the Clippy step needs
`dtolnay/rust-toolchain@stable` installs a minimal profile. The `native`
job named no components, so every run that reached the Clippy step died
on

    error: 'cargo-clippy' is not installed for the toolchain
           'stable-aarch64-unknown-linux-gnu'

before clippy read a line of source. That is not a lint result; the step
had never run. The `fmt` job below always named `components: rustfmt`
correctly — this one never did.

Two lines of behaviour change. The rest is the comment explaining why the
step is left gating on `-D warnings` rather than softened: the workspace
is not clippy-clean (run 203's build alone emits ~13 rustc warnings that
`-D warnings` promotes to errors), and `continue-on-error` cannot tell
"debt not yet paid" from "debt paid". That debt is scoped in #13, the way
the rustfmt debt is in #12.

Run 203 is what made this visible. With the aarch64 fix in 64bb7da the
native job got all the way through:

    cargo check  --workspace   ok  10m01s
    cargo build  --workspace   ok  19m04s
    cargo test   --workspace   ok  16m22s   214 passed, 0 failed
    cargo clippy --workspace   toolchain error

Refs #13

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McNbzUeq1KRBWs4G6X2YVj
2026-09-05 15:39:44 +02:00
sylph-decoder
b81b1f589d Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-04 13:22:46 +00:00
sylph-decoder
89525be210 handoff: withdraw the sweep-plate separation; label check is unproven
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-04 13:20:22 +00:00
sylph-decoder
b9afe324da re: out-of-sample test FAILS 3 of 6 -- plate-relative numbers withdrawn
One fresh no-input boot against predictions registered before it. Sweep-
internal quantities pass on a run that had no hand in deriving them: leaf
period ratio 1.1753, size ratio 1.3009, pulse/sweep 0.0963. Those are now
3-for-3 across captures.

The three plate-relative quantities fail, together and in the same
direction: ptcopyright ramp ratio 0.550 vs 0.733 (0.75x) and sweep->plate
separation 0.0996 vs 0.138-0.141 (0.71x). So the separation is not a
constant -- three runs give 0.138, 0.141, 0.0996 -- and my published "2.2%
agreement" was n=2. Withdrawn. The F6 conclusion survives qualitatively;
the number does not.

Also records that check_labels.py fails its first independent test. I
validated it on the two captures that produced the labels, which is an
instrument validated on its own training data. Two of four checks fire on
f6c. I am not guessing which of labels/tolerances/run-variation is
responsible.

Caught mid-analysis that I had first run the checks against a log still
being written; re-ran on the complete log and the numbers are identical, so
the failures are not a truncation artefact.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-04 13:20:09 +00:00
sylph-decoder
bbe339d856 re: pre-register F6's numbers for an out-of-sample boot
Every F5/F6 figure comes from captures taken for other purposes and
re-analysed after the reader and three labels were corrected. None has been
tested out of sample. Six predictions registered before the capture, five of
them checkable by check_labels.py, which now takes --cap NAME=path.

Prediction 6 is the one already got wrong once (0.057 against ptcopyright
instead of 0.14 against the real plate), and is stated so a landing near
0.057 would show the correction itself was wrong.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-04 13:17:26 +00:00
sylph-decoder
98f2bdef32 handoff: withdraw linkage-batching; 0x3002 class survives refutation
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-04 13:16:07 +00:00
sylph-decoder
a4e7c69d7a re: refute my own batching hypothesis -- blend state, not linkage
Last iteration I proposed that the two sweeps share one indices=8 draw
because ptloop01 links to ptloop02, and said testing it needed a
loading-screen capture I lack. Wrong twice: a linked pair was already in
every capture, ptbtn00 -> ptbtn00f.

Measured: ptbtn00f is drawn ALONE in 899 (f6b) and 1441 (f6) draws and
batched in ZERO, while the sweeps pair up in 1092 and 1744. Linkage does not
batch. The constraint is blend state -- ptbtn00f is additive and its linked
partner alpha-over, which cannot share a draw. The sweeps batch because both
are additive on one page.

Page+blend is necessary but not sufficient: 8154/alpha-over appears as two
separate draws in a single frame, 2108 such draws in f6b. This removes a
wrong cause rather than supplying a batching rule.

Extends read_draws.py to preserve draw grouping (draw index and quad count
per draw); check_labels.py still passes unchanged as a regression control.

Refutation attempt on the port's 0x3002/0x3003 menu-item reading: survives.
958 of 970 stems contain "btn"; the 12 exceptions are psselect_slot and
psselect_slot_blank, which are menu rows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-04 13:15:57 +00:00
sylph-decoder
429ad585c2 handoff: elements can carry two records; focus_link is a misnomer
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 20:55:24 +00:00
sylph-decoder
baf285d366 re: enumerate an element's records; focus_link is a misnomer
Adds examples/element_records.rs, which lists leaf AND focus_link records
for an element, plus a disc-wide census. Built because I claimed alpha 80
was undeclared after reading one of ptbtn00's two records -- and focus_link
was already parsed, with ui_layout.rs:424 already documenting the focus
record. The format was known and I did not consult it.

Census: 1467 of 15493 elements (9.5%) across 815 builds carry a second
record whose keyframes are invisible to a by-name leaf lookup.

Refutes our own parser's description of the field. It is documented as "the
focused state of a button", but GP_TITLE has pgloading_loop1 -> loop3 ->
loop4, a chain of three loop animations, and ptloop01 -> ptloop02, the two
sweeps. Neither is a focused state. Naming defect only -- behaviour is right
where it is read -- so not renamed here.

🟡 Notes a better candidate for why the two sweeps share one indices=8 draw:
they are linked, not merely co-textured. Testable on the pgloading chain,
which needs a loading-screen capture I do not have. Named, not claimed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 20:55:12 +00:00
sylph-decoder
943d890813 re: RETRACT the alpha-80 refutation -- it is declared, in ptbtn00f.rat
I claimed ptbtn00f's peak alpha of 80 was capture-only and refuted the
port's audit with it. Verified on the disc myself: ptbtn00f.rat, loop 120,
eight keyframes 0:0 6:6 29:74 35:80 50:80 58:74 97:6 105:0. ptbtn00 carries
TWO child records -- the leaf ptbtn00.rat (flat 255, which I read and
described correctly) and the focus record ptbtn00f.rat, which holds the
pulse. My "nothing declares 80" said only that nothing reached my
enumeration. METHOD.md has five entries on exactly this class.

Resolves the 🟡 with it: the corpus line attributing the 120-unit loop to
ptbtn00f is correct as written.

Turns the retraction into a stronger check. The amplitude is declared, so
check_labels.py now verifies the SHAPE: mean |alpha| error 1.14 levels (f6)
and 0.35 (f6b) against the declared 8-key curve. The first version assumed
the onset frame was t=0 and f6b FAILED at 3.24; the fix was aligning by
content rather than loosening the tolerance, since the 6->74 segment climbs
~6 levels per frame. Best lag is ~1 frame in both runs -- the element is not
drawn while its curve sits at alpha 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 20:31:58 +00:00
sylph-decoder
9873ca19e1 tools+re: a check that reads the label, and the alpha-80 refutation
Three of my errors were the label rather than the measurement, and a
correction in one document did not reach the next page I wrote. The port
built check-authored-vs-declared for values the disc can arbitrate and named
the gap: capture-only values that name an element rest entirely on my label.
check_labels.py closes that for the cases where the identification was
itself made by matching a declared quantity -- 8 checks over two captures,
all passing, with a --selftest that points the plate label at ptcopyright
(the real error) and must fail. It does, at 82-83% against a 5% tolerance,
with the other checks still passing so the failure is localised.

Refutation of the port's "all five figures are also declared": lands for
one. ptbtn00f's peak alpha of 80 is not declared anywhere -- ptbtn00.rat's
parent peaks at 255 and its leaf is one keyframe at 255 flat, with the
120-unit loop declared but no amplitude. The period checks out; the
amplitude is capture-only and their check cannot see it.

Opens a 🟡 not mine originally: the corpus attributes the 120-unit loop to
ptbtn00f, but it belongs to ptbtn00.rat whose leaf is ptbtn00.t32. Left
uncorrected since the identification rests on the period, which holds under
either name.

Adds examples/leaf_keyframes.rs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 20:28:37 +00:00
sylph-decoder
aaac060510 re+handoff: correct F6's separation -- it was measured against ptcopyright
The F6 page measured the sweep-to-plate separation against ptcopyright and
called it the plate. I had already established, on another page, that
ptcopyright is NOT the plate -- ptbtn00f is. Against the real plate the lead
is 83 and 165 frames, i.e. 0.138 and 0.141 of a sweep loop (2.2% apart),
against the 0.057 I published and sent to the port.

The conclusion is unchanged and stronger: with no input the glow precedes
the plate by 2.4x more than reported, and with A it still collapses to
essentially zero (-1 frame). Gating the sweep on the plate is a worse fit
than I made it sound.

Third instance of a label being the error rather than the measurement, and
this one is the same label I had already corrected elsewhere -- the
correction did not propagate to a page written after it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 20:24:00 +00:00
sylph-decoder
7e9fb55a79 handoff: F5 code route attempted and not settled; no literal snap target
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:54:21 +00:00
sylph-decoder
aa54a5aeec re: F5 code route -- not settled, plus a bounded negative on literal targets
The brief asks for two routes and I had only run the capture. This runs the
code route far enough to record an honest failure: the title's phase 2 and 3
handlers dispatch through vtables on nearly every branch, so finding the
clock write statically needs indirect-call resolution this container does
not do cheaply.

What the scan does establish: over 0x821C4000-0x821CD000 there is no
`li rN,<v>` for any v in 160..250, against a control of 684 li instructions
in the same range. So the snap target is computed or data-derived, not a
literal in the title's code.

Refutation aimed at my own capture result: a literal would have NAMED the
target and refuted "unpinnable from any capture". None exists, so that claim
survives and gains a second reason.

Names the instrument that would settle it: a write-watch on the clock field
in Canary, which would also close "which function advances the clock".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:54:10 +00:00
sylph-decoder
b0a7b5c785 re: record the failed refutation, and that the batched-draw trap recurred
The refutation aimed at the port did not land -- they already run two
timelines, measured on their side (72.6/552.6 against declared 73/553 over
17748 samples), the right instrument for a question about their own
renderer. Recorded as an attempt that failed; still worth making, since they
report they would otherwise have asserted it from the code.

Also notes in METHOD.md that the batched-draw trap produced a THIRD wrong
finding with the entry already written. Two sections of that file and a
REFUTED.md line already said a draw carries more than one quad. The lesson
is not the fact but that a reader written before consulting the file
reproduces the bug the file exists to prevent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:40:00 +00:00
sylph-decoder
0530e0f2d9 handoff: two sweeps loop 720:600; the open period is closed
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:24:06 +00:00
sylph-decoder
7c01f33e0c re: confirm the two sweeps loop at 720:600, and close the open period
Pre-registered 1.2000 from the declared leaf loops before measuring.
Measured 1.1967 (0.28%) in f6b and 1.1841 (1.33%) in f6, as a ratio inside
each capture so no clock enters -- which is why runs differing 2x in frames
agree. f6b happens to pace at one frame per leaf unit: 600 frames for 600
declared units, 718 for 720.

First test pteff03a's declared timeline has ever had. It could have failed
against me: the flattering reading of unit 11's batched draw is one
traveller driving both quads, which gives equal periods. It does not.

Also closes "one wrap per capture, period not obtained", which has been open
all week -- both leaves give a complete boundary-to-boundary cycle in both
existing logs. The truncating reader saw one quad, so it could see only one
of the four cycles already on disk.

Refutation aimed at the port: running both leaves at one rate leaves the
strips locked and drifting ~118 units per cycle from the game.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:23:55 +00:00
sylph-decoder
7c007cc421 re: pre-register the two-leaf period ratio before measuring
pteff03a's declared timeline has never been checked against a capture. The
leaves declare 600 and 720 units, so the periods must differ by 1.200 within
a single capture. Equal periods is the flattering-but-wrong outcome the
batched-draw reading could have produced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:22:37 +00:00
sylph-decoder
dfe21fda1f handoff: 0x3003 is 0x3002 parented; kind bit 0 decoded disc-wide
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:19:54 +00:00
sylph-decoder
f7cc0bd283 re: decode kind bit 0 as "has a parent" -- 0x3003 IS 0x3002, parented
The port is blocked on what 0x3003 is, having only 0x3002 in its menu-item
rule. The two differ in bit 0 alone. Disc-wide over every .pak: kind&1 ==
has_parent agrees on 15493 elements with 0 counterexamples -- 192/192 for
0x3003, 778/778 for 0x3002, and the same for every other kind. The flag is
exactly redundant with the +32 parent field.

So the bit that differs carries no role information: 0x3003 is a 0x3002
button record that is parented. That replaces the port's circumstantial case
with the field, which is what they asked for rather than a widened rule.

Flags what this does NOT license: it is not a decode of "is a menu item",
and 0x73002/0x73003 (160 elements) carry an undecoded 0x70000 that any
mask-based rule silently decides about.

Adds examples/kind_bit0_census.rs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:19:44 +00:00
sylph-decoder
d4efe551e0 handoff: F6 closed -- do not gate the sweep on the plate
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:13:06 +00:00
sylph-decoder
60ccd3413d re: F6 -- the human is watching their own A press, not a declared keyframe
The brief asked which of two declared events the human sees. Neither. With no
input the sweep pair enters 34 frames (f6b) and 67 frames (f6) before
ptcopyright -- 0.057 of a sweep loop in both, agreeing to 1.2% across runs
that differ 2x in frames. With A pressed during the build-in the separation
is 2 frames.

A reveals the plate and restarts both sweep leaves at t=0 in the same frame,
so a player who presses A sees them start together and reports exactly that.
The control that makes it an explanation: in the late-press run A landed
after the sweep had already started naturally and the two are 29 frames
apart -- same input, opposite result, decided by when the press falls.

Consequence for the port: do NOT start the sweep with the plate. That fits
one boot and breaks the other. The declared gate plus the snap restarting
leaves produces both observations with nothing authored.

Refutation attempt: looked for a case where the port's current behaviour
fails against these four captures; found none.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-03 19:12:55 +00:00
sylph-decoder
1ca70b45aa Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-03 19:11:35 +00:00
sylph-decoder
3b8c62be77 handoff: F5 snap target undecidable within [160,238); the port's 236 is free
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 21:37:29 +00:00
sylph-decoder
9d28bebb58 re: F5 snap target is [160,238) and cannot be pinned from any capture
ptcopyright goes absent -> 255 in one frame at the snap, skipping its
declared 138->160 ramp, so t>=160; the sweeps are still at 255 so t<238.
Its identification is measured: in the control it first draws at t~143 and
reaches 255 at t~164 against a declared 138->160.

It stops there for a reason worth recording. Every build-4 element with a
key past t=100 holds a constant pose across [160,238) -- their intersection
is exactly that window -- so the game draws a bit-identical frame at t=160
and t=236.

Refutation attempt on the port's 236.0: not merely survives, it can never be
confirmed or refuted by capture. Every value in the window is
observationally identical, and it stays that way because the clock freezes
at settle and the exit ramp plays on leave rather than on a timer.

Classified undecodable-with-reach so nobody spends another run on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 21:37:19 +00:00
sylph-decoder
49e848f59d handoff+re: correct unit 10's quoted range; pulse ratio verified
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 21:10:45 +00:00
sylph-decoder
1f149a1863 re: re-run the two findings resting on the truncating reader
Pulse ratio HOLDS: 0.1000 (f6b, 16 clean cycles) and 0.0993 (f6). 60 leaf
units = 120 title units = ptbtn00f's declared loop. The independent leg
under leaf/title = 0.5 stands.

Unit 10's conclusion survives but MY NUMBERS WERE WRONG. I quoted
254.0-256.9 / 253.9-254.9 as the implied parent's range; those were the rows
I had printed, every 20th frame, not the series. Real first-cycle figures
are 250.9-260.5 (f6, n=1128) and 253.1-255.0 (f6b, n=560).

Post-wrap the spread widens to 237-283, but only in f6 -- the run with
dropped frames -- while f6b holds at median 254.3. That is my linear phase
model drifting, not the parent varying; a parent that varied would degrade
in both.

Same shape as an error already in my record: a printed subset doing the work
of the population.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 21:10:31 +00:00
sylph-decoder
568a2c004f handoff: F5 verified with the full-quad reader; snap restarts both leaves
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 21:07:07 +00:00
sylph-decoder
536206e89c re: F5 survives the full-quad reader, measured rather than asserted
Last iteration I asserted F5 was unaffected by the truncating-reader bug
because it compared like with like. Asserting that is the move that produced
the bug, so this measures it. The new reader sees 9.7 quads/frame vs ~7.5.

Scalar that needs no element identification: quads mid-ramp (0<a<250) per
frame goes 6,4,4,4,2,1,4,3 -> 0 at f436, while the control never reaches 0
anywhere in 48 frames of build-in. One frame with nothing part-way through a
ramp is the cut.

Bonus the old reader could not show: both sweeps enter at f436-438 at their
declared opening alphas -- pteff03 at 255, pteff03a at 1,2,3,4,6,11,17 from
its declared 0.

Refutation attempt on the port's "clock jumps to 236.0": tried and failed.
My bound is [100,238), which contains 236 -- consistent, not independent
confirmation.

Adds tools/re-capture/read_draws.py so the truncating regex is not re-rolled.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 21:06:55 +00:00
sylph-decoder
f50de2c821 handoff: pteff03a IS drawn -- keep both sweeps; units 5 and 6 refuted
Also notes that REFUTED.md L170 already recorded a draw carrying two rotated
parallelograms, so the general fact was written down before my reader
contradicted it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:39:00 +00:00
sylph-decoder
1f175dd98c re: REFUTE my own units 5 and 6 -- pteff03a IS drawn, the reader was truncating
The two sweeps are batched into ONE additive indices=8 draw, two quads, and
my parser took the first v: match per line and discarded the rest. Every
analysis saw quad A and never quad B. No new capture was needed -- the same
logs units 5 and 6 used already contained it.

Both strips measured: opposite directions matching the declared -639->1521
and 1721->-839, and a size ratio of 1.301 against the declared sy ratio
800/600 = 1.333.

Unit 5 recorded that the PORT's renderer draws pteff03a and treated that as
the port being wrong. The port was right.

Third instance of this class in the corpus (palogo_anima and the six-quad
dump are the others): a truncating reader yields a clean, complete-looking
negative. Reading one raw draw line in full would have caught it -- indices=8
was printed on every line and says two quads outright.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:38:29 +00:00
sylph-decoder
df37b7432d handoff: clock conflict resolved -- ptcopyright not the plate; rate 0.5 x3
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:20:05 +00:00
sylph-decoder
9115cf9288 re: the pulsing element IS ptbtn00f, and the 1.7x clock conflict was mine
Phase-free: the pulse is exactly 1/10 of the sweep's 600-unit loop -- f6b
gives 60.0 frames over 16 cycles with zero variance against a 600-frame
sweep. 60 leaf units x the independently measured leaf/title = 0.5 gives 120
title units, ptbtn00f's declared loop exactly. That is also a third
independent route to the 0.5 ratio, from an unrelated declared quantity.

And it resolves the conflict I have been flagging on three pages. The quad I
called "the plate" at x=-0.54 is ptcopyright: its fade-in is 21-22 title
units under both agreeing calibrations, matching ptcopyright's declared
22-unit ramp, not the plate's 12. The plate is the pulsing element. Two
elements, one label, and I checked the label -- there was never a clock
conflict. Retires the 🟡 on every title-unit figure across three pages.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:19:53 +00:00
sylph-decoder
60be20a4b8 handoff: correct F5 -- keep clock:"shared", A advances it to the settle
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:11:12 +00:00
sylph-decoder
24719d3c72 re: CORRECT F5 -- A snaps the whole title, not just the plate
The pre-registered wider test refuted my own claim. Pressing A at the
sweep's gate instead of 40 frames later leaves ~40 frames of artwork
animating: three elements mid-fade-in vanish in one frame and the settled
set appears at 255. The sweep enters at 255 with NO ramp where the control
ramps it 17->255 over ~15 frames, so the title clock jumped past t=100 --
and not past 250, since ptloop01's exit would have hidden the sweep.

So clock:"shared" is NOT refuted. I told the port the opposite and must
correct it.

Cause: the press takes 11-12 frames to take effect (f445->f456, f424->f436)
and my 5-frame artwork window sat entirely inside that gap. It matched the
control because the input had not been acted on yet. The window was not just
short, it was positioned where the effect cannot appear.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:10:59 +00:00
sylph-decoder
306b3a576f re: pre-register the widened F5 artwork test before reading the capture
F5's artwork half rests on 5 frames. This run presses A at the sweep's gate
instead of 40 frames later, giving ~40 frames of still-animating artwork,
and states the prediction for both outcomes before the log is opened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:09:04 +00:00
sylph-decoder
eb32e1277a handoff: F5 -- A cuts the plate to final; clock:"shared" refuted
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:07:53 +00:00
sylph-decoder
12d26d59c9 re: F5 -- A snaps the plate, and does NOT advance the artwork's clock
Three captures, aligned by the sweep's position rather than by frame number.
The plate's alpha goes 23,46,69,92,115,139 over ~11 frames with no input,
and 255 in a single frame when A is pressed: zero intermediate values
against eleven. A cuts, it does not accelerate -- the human's prior holds.

The control is what makes it readable. Four elements ramp out right around
the press and I could have reported that as the effect; at sweep x=-1.42 all
three runs agree quad for quad, so those exits are the ordinary build-in.

Refutes clock:"shared" on F4's own discriminator: the artwork keeps
animating across the press, frame for frame identical to the control. Reach
stated -- that half rests on a 5-frame window, since everything else on
screen is already at 255 and cannot discriminate.

Also records the first attempt's miss: blind wall-clock timing put the press
after the settle, where A is accepted instead. The probe now gates on the
sweep appearing, which is the parent's declared t=70..100 gate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:07:42 +00:00
sylph-decoder
d9a88b01e3 tools: F5 probe -- a second A during the title build-in
Presses A once to skip the attract video, then again during the build-in,
and records the press instant so a press that lands late is reported rather
than silently reinterpreted. Blind timing is the weak point: the build-in is
~5 s wide and run pacing has been seen to vary 2x.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 20:02:52 +00:00
sylph-decoder
0ce1eb875f handoff: F6 -- sweep gated at t=70/100, and reinstate rate 0.5
Gives the port the declared parent ramp and corrects my withdrawal of the
0.514 rate: the frames-based expression was the error, not the ratio.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:39:35 +00:00
sylph-decoder
36538fae87 re: F6 unit 10 -- the parent's declared alpha gates the sweep, and it multiplies
Build 4 declares ptloop01/02 alpha 0 until t=70, full at t=100, with 238..250
an EXIT ramp -- which answers the brief's "is 238..250 an entry or an exit"
for these elements. Builds 5/6 declare the same records flat 255, so the
build must be named before the question has an answer.

Control ran in the direction that could have flattered the hypothesis and
did not: the leaf's own alpha FALLS 255->128 where the capture RISES 8->255.
Decomposing against the leaf's declared curve leaves an implied parent that
pins at 255.0 +/-1.5 across hundreds of frames while the drawn alpha swings
242->132->145. Parent alpha is multiplied in; closes that standing 🟡.

Restores unit 8's 0.514: leaf/title = 0.4795 and 0.4667 across two runs that
differ 2x in frames. I over-withdrew it last iteration by discarding the
ratio along with the frames it had been quoted in.

Adds examples/ptloop_parent_keyframes.rs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:39:21 +00:00
sylph-decoder
4d84396de0 re: F6 -- correct the onset, the sweep starts MIDWAY not just before the plate
The port challenged two statements of mine as mutually inconsistent and
refused to guess which I meant. They were right to. Answering with the
clock-free quantity they proposed:

  (onset - title start) / (plate - title start) = 0.489 / 0.507  (3.7% apart)

So the onset is at the MIDPOINT. That refutes the port's implemented 0.2 and
my own summary's "shortly before the plate" (~0.85) alike.

Root cause of my error: the ratio measurement was right, but I converted it
to title units through the plate's declared 12-unit ramp and wrote the
summary from the conversion. That calibration makes title-start..plate 75
units where the data declares the plate at t=238 -- 3.2x out, not the 1.75x
this page reported. All title-unit figures withdrawn; the ratios never
needed a clock.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:32:01 +00:00
sylph-decoder
36cebf753a handoff: F6 -- start the sweep just before the plate, and drop my frames-based rates
Delivers the two numbers the port needs (lead 0.79-0.80 baselines, period
13.93 baselines, each reproduced across two captures) and withdraws unit 8's
0.514 units/frame: captured frames differ 1.947x between runs, which is the
size of the port-vs-decoder disagreement we had left standing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:21:41 +00:00
sylph-decoder
7b3c83858d re: index F6 unit 9, which closes the sweeps' unmeasured period
ui-clock-freezes-at-settle.md left the sweep period  because a validated
estimator disagreed between two dwells (515 vs 452 frames). The cause is now
measured: captured frame counts are not comparable across runs at all --
1.947x between two captures of the same animation, with the baseline moving
1.953x alongside. As a ratio the period reproduces to 0.35%.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:21:09 +00:00
sylph-decoder
15207b1c74 re: F6 unit 9 -- sweep period and onset, as ratios reproduced across two runs
Two captures of the same animation disagree on frame counts by 1.947x, so
frames are not comparable across runs. Expressed as ratios to a long
in-capture baseline, both runs agree: loop period = 13.93 baselines (0.35%
apart), and the sweep starts 0.79-0.80 baselines BEFORE the plate (0.9%).

This answers F6: the sweep does not start at t=0 as the port has it, nor
exactly with the plate -- it leads the plate by about 40 title units, under
a second, which is consistent with what the human reported seeing.

Surfaces a conflict rather than smoothing it: unit 8's title rate of 1.0
units/frame (from ptcopyright) and the plate's 0.571 units/frame are 1.75x
apart in the SAME capture. Either an element's declared ramp is misread or
the two are not on one clock -- the port's clock:"shared" premise. The
ratios stand without a clock; the title-unit conversions are 🟡 pending F4.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:20:30 +00:00
sylph-decoder
a726391ead tools: make the sweep probe confirm it is actually recording before proceeding
Applies the fix unit 9 named. Twice a probe printed "armed", carried on and
wrote no draw log -- once because the window lookup failed, once with the
window found and the key sent. Sending the keystroke is not evidence the
logger responded.

After arming, the probe now polls for xenia_re_ui_draws_*.log to exist and
be non-empty, for up to 20 s, and aborts loudly if it does not appear. A
probe that cannot confirm its own instrument is recording is a probe whose
negatives mean nothing.

Narrower fixes were tried and were not enough: making the window lookup
fatal caught the first failure and not the second.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:11:39 +00:00
sylph-decoder
7863ad3b62 re: F6 unit 9 -- wrap-to-wrap period NOT obtained, two harness failures
Unit 8's rate (0.514 units/frame) rests on one wrap, a start-to-wrap span
rather than a period. Hardening it needs a longer capture with two or more
wraps. Two attempts, both failed on the harness rather than the game.

First launch never started: the pgrep && echo || { } guard took the wrong
branch, no output directory was created and no process ran, while a stale
emulator from the previous iteration was still up. It looked like a running
capture for several minutes.

Second launch started, armed, pressed A and wrote no draw log at all --
canary.stdout stayed at 0 bytes and no xenia_re_ui_draws log appeared,
despite the script printing "armed at 8s". Likely a race with the orphaned
emulator from the first failure, not confirmed.

Unit 8's numbers are unaffected; they came from the intact f6 capture,
which is still on disk. The offset has two independent supports; the rate
still rests on a single wrap and the port should not ship on it.

The lesson, and it is the second harness failure of this shape: "armed at
8s" printed while nothing was being logged. The arming step reports success
on SENDING the keystroke, not on the logger responding -- the same silent
failure that cost the first F1 probe a run, which I "fixed" by making the
window lookup fatal. That fix was too narrow: the window was found, the key
was sent, and the log still never appeared. The check that would have
caught both is to wait for the draw log to exist and be non-empty after
arming, and abort loudly otherwise. A probe that cannot confirm its own
instrument is recording is a probe whose negatives mean nothing, and I have
now written that bug twice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:09:59 +00:00
sylph-decoder
fbc008a0ab re: F6 unit 8 -- the leaf's clock in title units: offset +40, rate ~1/2
The two numbers the port asked for, both from one capture so nothing
crosses runs.

Title rate, which unit 4 flagged as an assumption and is now measured:
ptcopyright declares alpha 0->255 across t=138..160, 22 units, and the
rising run is 22 frames. So 1.0000 title units per frame, with the step
agreeing independently (255/22 = 11.6 against a measured modal 12). That
also confirms the splash's 1 unit/present on a second screen, which it had
never been checked against.

Leaf rate, anchored on the wrap rather than the endpoint: first drawn at
frame 746, wraps at 1914, so 1168 frames for the declared 600-unit loop =
0.5137 units/frame. This SUPERSEDES unit 3's 0.463, which divided 540 units
by 1167 frames -- but the declared track is stationary from t=540 to t=600,
so that endpoint is where motion stops, not where the loop ends.

So: offset +40 title units (confirmed, and the title rate being 1.000 makes
frames and units interchangeable there), rate 0.514x the title's, within 3%
of exactly one half. leaf_t = 0.514 x (title_t - 40).

Flagging rather than smoothing, as they asked: the port runs the leaf
unscaled at 1.0x where this measures 0.514x, so their sweep should cross
twice too fast -- which a viewer ought to notice alongside the early start,
yet the human reports the animation looks correct. Either "looks correct"
is about the effect rather than its speed, or one of the two measurements
is wrong. My rate rests on a single wrap; a longer title capture giving a
wrap-to-wrap period would settle it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 19:06:11 +00:00
sylph-decoder
ffde5abd94 re: F6 unit 7 -- the title has exactly ONE moving quad; the lights are in the texture
The port raised a real caveat: my earlier scans filtered on height (>1.2
NDC) and sample count (>=20), so a population of many small lights would
have been invisible to both by construction. Dropping both filters, over
the whole title era: 59 distinct shapes, 2 moving, 57 static, and ZERO
small moving shapes. The two moving keys are the rounding-split halves of
one element, pteff03.

So there is exactly one moving quad on the title, 883x1134 px.

That answers the human's actual uncertainty -- whether the game renders one
light per line or one light covering several close lines. It is the second:
the multiple lights are painted INTO the texture of a single large sweeping
sprite, not drawn as separate moving objects. A port reproducing "several
lights" as several elements would be modelling the wrong thing.

The port's caveat was right to raise and the check excludes the population
it warned about -- third time in this exchange that asking was worth it
even when the specific worry did not apply.

What I have NOT done, and it was the literal ask: the human asked for
screenshots and I have taken none. I answered the counting question from
the draw stream because it is the stronger instrument for how-many and
how-big -- it reads the guest's vertex buffer rather than pixels and cannot
miss a faint light. But "what do the lights look like" is a question about
an image and the draw stream cannot answer it. That remains open.

Reach: one boot, one window, every quad in the stream. Static elements are
not counted as lights -- 57 exist and some may pulse in place; this unit
counts motion, not brightness.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:57:07 +00:00
sylph-decoder
d53128151f re: F6 unit 6 -- pteff03a is not submitted at any size; the collapsed-scale candidate dies
Unit 5 filtered on height, so a collapsed quad would have been invisible to
it by construction. Dropping that filter: across the whole title era,
frames >=700, every quad regardless of size --

  RIGHT->LEFT travellers (pteff03a's direction):  0
  LEFT->RIGHT travellers:                         2  (both pteff03)
  static shapes:                                 10
  degenerate/collapsed quads:                     0

Not one quad travels right-to-left in the entire title era at any size, and
nothing is submitted collapsed. So pteff03a is absent from the draw stream
-- not drawn invisibly, not drawn at zero scale. That strengthens unit 5
from "no tall quad of that size" to "no quad of that motion at all".

All three candidate mechanisms are now dead: the zero-alpha skip is weak on
its own terms (explains opening frames, not a whole run), the focus/variant
link was eliminated by the port's wider survey (linked targets chain across
unrelated element kinds -- on one menu a sweep points at a button, so the
field is a chain pointer rather than a variant selector), and collapsed
scale dies here.

Recording that as the state rather than proposing a fourth candidate.
Three have been named and three have failed, two by checks that took
minutes. A fourth guess before the human's "one streak or two" look would
be guessing against an answer about to arrive for free.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:46:22 +00:00
sylph-decoder
19757cfec6 re: F6 unit 5 -- pteff03a is never drawn; the game shows ONE sweep, not two
Every quad taller than 1.2 NDC in the whole capture, frames 1..2499:
h=3.15 travelling left-to-right over 1754 samples (pteff03), and h=2.00
static for 54 frames (not a sweep). Nothing in pteff03a's expected band
above 3.4, and only one travelling quad in the capture at all.

pteff03a declares 800% scale against pteff03's 600%, so its AABB is ~1303
px ~ 3.62 NDC, travelling right-to-left. It is absent.

Not a windowing artefact: ptloop02's leaf reaches alpha 128 at its t=150,
which at the unit-3 leaf rate is ~324 frames after its start, well inside
the 1754 frames captured.

For the port: their renderer draws pteff03a, confirmed on their side at
three instants. An extra light streak the game never shows, appearing
partway through the build-in, looks exactly like "the sweep starts too
early" -- and unlike the alpha question it does not depend on unit 2.

One capture, one boot, one window. The scan was over every tall quad in the
whole stream rather than a filtered subset, so the absence is strong, but
it is still absence in one observation. The five-second human check the
port is arranging (one streak or two) settles it faster than another
capture and should come before anyone deletes an element.

The disc declares ptloop02.rat as element 12 beside ptloop01.rat as 11,
identical pivots and keyframe times, so why one is submitted and not the
other moves to my side. Untested candidates: its leaf alpha starts at 0
where pteff03's starts at 255; or a focus/variant link means only one of
the pair is ever active.

Refutation: the port's own challenge to my by-size identification -- that
both sprites are byte-identical in size -- they withdrew themselves and
correctly. The sprites are both 399x180 but the LEAVES declare different
scales, so the drawn quads differ by a third in height. Second time in this
exchange a challenge was right to raise and wrong in its stated reason, and
both times the check still found something real. The value was in asking.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:43:18 +00:00
sylph-decoder
a30761f128 re: F6 unit 4 -- the sweep is on screen 41 frames after the title starts, not at the plate
Same capture, counts only. Title's first drawn element is frame 706; the
sweep is first submitted at 746 and first ON SCREEN at 747, so +41 frames.
For scale, the plate's declared t=236 is frame ~942 at 1 unit/present --
195 frames after the sweep is already visible geometrically.

Named rather than folded in: that comparison assumes the title's first
drawn frame is its t=0 and that its clock runs at 1 unit/present. The 41 is
a raw frame count and carries neither.

What it settles: POSITION does not gate the sweep late. So if a human sees
it start when the plate appears, the gate cannot be where the quad is -- it
has to be how opaque it is. That puts the whole of F6 on unit 2, which is
amber: does the parent's alpha multiply into the leaf? The parent ramps
0->255 across t=70..100, so if it multiplies the sweep is invisible until
~70 and dim to 100 (a real early gate); if it does not, the sweep is fully
lit from +41 frames and the human's report has no mechanism yet.

The disagreement has narrowed usefully: before this unit "starts when the
plate appears" had two candidate mechanisms, position or alpha. Position is
now excluded by measurement.

Refutes my own unit 1 framing. I wrote that a quad can be "fully opaque and
entirely off-screen" and offered the travel as the likely explanation. It
is not -- the sweep is on screen at +41 frames, nowhere near the plate. The
travel explanation is dead, and I record it because I proposed it and it
steered the port's reading of their own renderer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:37:21 +00:00
sylph-decoder
f456c87d06 re: F6 unit 3 -- the sweep's POSITION fits the declared track, origin at leaf t=0
Took the port's point and dropped the alpha line. Three exchanges had gone
on alpha -- a bound, a refutation, a downgrade -- over 14 usable samples of
1754, when the position travels 2160 px monotonically in the same capture.

pteff03's declared leaf track is linear at 4.000 px/unit: -639 at t=0, -39
at t=150, 1521 at t=540. The capture's first clean segment runs frames
746..1913 with x from -641.1 to +1522.1. Both endpoints land within ~2 px
on a 2160 px travel, 0.1%. Two independent checks rather than one fitted
parameter. A single wrap at frame 1914 confirms the declared 600-unit loop
and falls after the segment.

Answers the clock origin: the leaf's t=0 is its first drawn frame, so the
game does not carry the leaf forward from the title's clock. That CONFIRMS
the port's own correction -- they had attributed ~135 units of earliness to
the leaf starting at title t=0 and withdrew it on two relayed numbers; the
full series says the withdrawal was right.

Rate here is 540 units in 1167 presents = 0.463 units/present, flagged as
the weak half: one run, in presents, and it does NOT match the 1
unit/present the splash work established. Either the leaf runs a slower
clock or one of the two is not what I think. The origin does not depend on
it.

And the useful negative: a linear fit across all 1754 samples gives max
residual 1108 px on 1402 px of travel, 79%, because the trajectory wraps
and a straight line through a sawtooth is meaningless. A fit not checked
for residual would have reported a slope and a plausible origin from that
same data -- which is exactly why the port's tool selftest must reject a
wrong-shape series, and why I segmented before fitting.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:35:54 +00:00
sylph-decoder
796bc0420c re: CORRECT F6 unit 2 -- identification wrong, presentation misleading, claim downgraded to amber
The port challenged the by-size identification: both sweep sprites are the
same size, so size cannot separate pteff03 from pteff03a, and the two
leaves floor at 128 and 0. They were right, and it is broken a third way.

Their discriminator -- the leaves travel in opposite directions -- is in
the capture I already had. Both rows drift +2.19 and +2.18 in x, i.e. BOTH
LEFT TO RIGHT, so both are pteff03. The 0.7% size difference is per-frame
rounding splitting one element across two keys, not two elements. pteff03a
does not appear in this capture at all.

And my own presentation misled. The "alphas 8 24 33 50 58" I quoted were
sorted(set(...))[:9] -- the nine LOWEST DISTINCT values, not the series.
Read as a trajectory they look like a ramp from 8. They are a tail. The
counts: 9 of 1140 and 5 of 614 samples below 128, so 14 sub-floor samples
out of 1754.

The bound argument survives in shape and collapses in weight. A sample
below 128 is still unexplainable by a leaf flooring at 128, but 14 of 1754
is a thin tail and a tail is where a vertex-grouping slip or a partial
frame would show up. Downgraded to amber: not refuted, not established.

Settling it needs the same capture read as a SERIES rather than a set --
alpha against frame across t=70..100, where a multiplying parent must
produce a monotone ramp on nearly every frame rather than 14 stragglers.
One more read of data already on disk.

The port was right to hold the renderer. Adopting this would have changed a
rendering rule on every screen with a leaf, on 14 samples I had presented
as a trajectory.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:27:21 +00:00
sylph-decoder
bc241f5d06 re: F6 unit 2 -- the parent's alpha IS multiplied into the sweep leaf
Question, look-at and not-covered written before the work, per PROTOCOL's
units section.

One boot, one A to skip the attract video, then no input so the title
builds in undisturbed. The sweeps are the two rotated 600%-scaled strips,
identified by size: NDC 1.38x3.15 and 1.39x3.15, matching the corpus's own
independently measured AABB height of 1134 px (2*1134/720 = 3.15).

Drawn alphas run 8, 24, 33, 50, 58, 74, 83, 100, 107 and 16, 41, 67, 91,
116, 128... pteff03's LEAF alpha is bounded below by 128 (keys 0:255
150:128 540:255 600:255). 8 < 128, so the leaf cannot produce it alone.
The parent's alpha is multiplied in.

That refutes the port's screen_view.gd decode that "the leaf runs on its
OWN timeline and the parent's alpha is NOT multiplied in" -- which is
exactly what that file asked for. It flagged honestly that every
observation behind it had parent alpha 0, so "the leaf wins" and "the
parent is ignored because it draws nothing" were never separated, and named
t=100..238 as the separating interval. This capture is in that interval.

Bears on F6's original report: the parent ramps 0->255 across t=70..100, so
if it multiplies in the sweep is invisible before ~70 and dim until 100. A
human reporting it starts late is seeing a real gate -- the parent's ENTRY
ramp, not the 238 cluster, which unit 1 showed is an exit.

Reach: one boot; quads identified by size against a previously measured
AABB, not by name, since the draw stream carries no names. The bound
argument needs only that the leaf minimum is 128, which is from the disc.
It does NOT establish the combination is plain leaf x parent rather than
some other one that also dips below 128 -- only that the parent
participates.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:23:49 +00:00
sylph-decoder
df41225003 re: F6 unit 1 -- 238..250 on the sweep is an EXIT, not a start
One unit, per the new PROTOCOL section. Question, look-at, and
not-covered written before the work.

pteff03 and pteff03a -- the sweep parents behind ptloop01/ptloop02 --
declare 0:a=0 70:a=0 100:a=255 238:a=255 250:a=0. So they rise 70->100 and
fall 238->250. The brief's own warning was right: 238..250 is a fade-out,
the same shape ptcopyright uses, and ptcopyright starts nothing.

The sweep is declared visible from t=100, which is 136 units BEFORE the
plate reaches full alpha at 236, and is fading out by 238.

That contradicts the human's report that the sweep only starts when the
plate appears -- and the reason both can be true is the next unit.
ptloop01/ptloop02 are .rat leaves whose own timeline is a TRANSLATION:
ptloop01 runs x = -639 -> 1521 over a 600-unit loop, so at its own t=0 the
sweep sits off the left edge of a 1280-wide screen. The parent's alpha says
"drawn"; the leaf's position says "where". A quad can be fully opaque and
entirely off-screen.

Explicitly not actionable alone: this says 238 is not a start. It does not
say the port should show the sweep from t=100, because if the leaf is
off-screen there then both renderers can be correct on alpha and differ
entirely in what is visible.

Refutation of the brief's own lead that "236-238 is a synchronisation point
and a human reported a behaviour change there": the synchronisation is
real -- pteff02 at 236, ptlogo_back2eff and ptcopyright at 238 -- but the
reading is refuted. For the sweep it is where things END. A cluster of
keyframes marks a moment; it does not say which direction anything moves
through it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:19:21 +00:00
sylph-decoder
90b7c6ea26 re: F3 -- the title plays BGM cues 1102 and 1103, from seven sites in its GamePart
A human says something is missing on the title. Something is: it plays BGM,
and two different cues.

Method with the control built in rather than bolted on. R4 wants a negative
to show the method finding the menu's cue first; this method cannot produce
a false negative for one screen because it does not look at one screen. It
finds every call of the play function in the image and reads the cue each
passes: 34 callers, cue ids 1103 x24, 1102 x3, 1107 x2, 1108, 1106, 1104,
category 4 on every one. 1103 is the cue the corpus already attributes to
the menu, and the method finds it 24 times.

GamePart_Title's neighbourhood is 0x821C4xxx-0x821C7xxx per the registry
page, and seven play sites fall inside it: 1103 at 0x821C52D0, 0x821C5620
(inside the phase handler sub_821C5580), 0x821C6188 and 0x821C6294; 1102 at
0x821C53B0, 0x821C5BA0 and 0x821C6DE0.

So the title plays BGM_103 and BGM_102, and 1103 is the SAME cue as the
menu's -- which is why a port playing nothing on the title sounds like
something is missing rather than merely quieter.

The sting is NOT answered and the page says exactly why: this play function
carries ids in the 1102-1108 BGM range, the UI stings are SE_* cues with
ids 1-322, and not one of the 34 sites passes an id in that range. SE goes
through a different call and this method is blind to it by construction.
That is a bounded negative about the instrument, not the game, and reading
it as "no sting" would be the third time this corpus mistook a blind spot
for a fact.

Reach: exhaustive over every bl to 0x8217ACF8, so complete for that
function. The GamePart attribution is by address neighbourhood and carries
the registry page's own "by position and convention, not proven" caveat.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:16:55 +00:00
sylph-decoder
1ed07d246e Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-02 18:15:33 +00:00
sylph-decoder
e38556d976 handoff: F2 closed -- no per-cue gain on the disc, the port authors the mix knowingly
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:06:52 +00:00
sylph-decoder
1021708636 re: F2 CLOSED -- undecodable with reach, all three sites checked
Third and last site: the executable's play path. sub_821C5580's cue-1103
site is li r5,1103 / li r4,4 / lwz r3,0(r29) / bl 0x8217ACF8, i.e.
play(this, category, cue_id). No volume is passed and no float argument is
set up by the caller at all; the callee's prologue confirms r5 is the cue
id with -2 and -1 sentinels.

Honest limit stated: the callee saves f30/f31 so it uses floats internally
and could look a level up for itself. "No gain is passed" is not "no gain
exists" -- but there is nothing at this site for the port to transcribe.

So F2 closes as undecodable-with-reach with all three sites checked:
tables.pak cue records (exhaustive, passing control, and numbers carry
names there so a gain would have had one), sound.pak bank headers (all 9519
entries, no readable header), and the play path (category, not level).

The port authors the mix and now knows it is authoring, which is what this
question existed to make explicit rather than accidental. The one authored
value the game exposes is the user-facing sound options screen -- a runtime
master, not a per-cue table.

Refutation of the play-test's premise that "a cue record commonly carries a
volume beside its wave index": REFUTED for this game across all three sites
where it could live. Recorded because it was a good prior -- it is what
sent me to the right three places -- and being wrong about where a value
lives is different from being wrong to look.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 18:06:36 +00:00
sylph-decoder
654c4f1e99 re: F2 second site checked -- sound.pak carries no readable bank header either
Continued F2 at the site the previous page named as the first thing to do.

dat/sound.pak is a 114 KB index over ~1 GB of payload across sound.p00-p04.
Its 9519 entries carry no readable signature at all: the most common
first-four-bytes pattern is "...." on 3830 entries and no entry begins with
an ASCII magic. Exactly one entry is under 4 KB (#9454, 533 bytes), where a
bank header or wave index would be small and structured.

So the SE bank's metadata is not reachable as a header in sound.pak. The
entries are audio payload, high-entropy by nature, and a gain beside a wave
index is not sitting in front of them.

Stated as a negative about REACHABILITY, not existence: a per-wave gain
could live inside a container these entries are compressed into and I have
not decompressed one.

Two of three sites now checked, both negative; the executable around
sub_821C5580 remains. Classification unchanged at undecodable-with-reach,
but better bounded.

Records the shape the answer is taking: if the executable also has no
per-cue gain, the honest conclusion is that the game does not author a
per-cue mix at all and the levels come from the user-facing sound options
screen as runtime state. That makes the port's job authoring a master
balance rather than transcribing a table -- undecodable rather than
decoded, which it must know, because a mix authored in ignorance and one
authored deliberately look identical in the file and differ entirely in how
far they can be trusted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 17:36:59 +00:00
sylph-decoder
02d7f9062b re: F2 -- no gain field in tables.pak, with the two unchecked sites named
The port has no gain anywhere and confirm sits 3 dB above the music. Asked
the disc rather than choosing a number.

Five audio-bearing objects in tables.pak, zero tokens matching VOL GAIN
LEVEL DB ATTEN AMP MIX LOUD. Control passes: the same matcher finds 38
SE_UI hits, so "0 hits" is not a broken matcher.

The negative is stronger than a name search usually is, and I expected it
not to be. Dumping the schema shows the token stream is value-then-key
pairs -- "40, LINE_PITCH", "0, Y_OFFSET_ANALOG_STICK" -- so NUMBERS ARE
TOKENS AND THEY CARRY NAMES. A gain in this format would have a name, and
the name search covers exactly the space where it would live. That turns "I
did not find one" into "one is not there in this file".

Reach, and it is why this is undecodable rather than decoded: I did not
check the .slb bank headers, which is the other conventional home for a
per-wave gain beside a wave index -- and is where the play-test's own
framing points. No .slb exists as a loose file on the extracted disc, so it
costs a pak extraction I did not have budget for; it is the first thing the
next attempt should do. Nor did I check the executable, where a mix could
be immediates in the sound-play path around sub_821C5580.

So this is not "the mix is not on the disc". It is "the mix is not in the
table where a cue's fields live".

Pointer, not a finding: object #15 lists po_sound_scr.prt -> SOUND among
GP_OPTIONS' screens, so a user-facing sound options screen exists and at
least one volume is runtime state.

Port keeps authoring nothing yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 17:08:07 +00:00
sylph-decoder
8c5bd2ca0a Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-02 17:05:38 +00:00
sylph-decoder
85d2e93d05 re: F1 harness built and committed; the run did not reach the menu
The port needs an initial delay and a repeat interval and has shipped the
mechanism with -1.0 rather than invent them. This builds the instrument and
does not get the numbers.

The vertex stream is the right instrument: C_PAD_DECODER has no timer on
any direction path, so the repeat is in the layer above and cannot be read
out of that function; a cursor move is a quad changing position, and the
guest's vertex buffer carries that with no Canary processing in the path.

tools/re-capture/menu_repeat_probe.sh arms the logger, drives the boot with
pad-file presses and holds a direction. It ran its whole sequence. But the
boot did not reach the menu: in the settled era every quad shape holds a
constant y, and the shapes are near-full-screen rects rather than a button
list. No cursor, so nothing to repeat.

Two instrument errors worth more than the failed run.

The first attempt ARMED NOTHING and said nothing -- xdotool search --class
... --window %1 F10 behind a || true. The run completed normally and only
the ABSENT log revealed it. The working form looks the window up by name,
activates it, and sends F10 to the window and globally; a missing window is
now fatal rather than tolerated, because a silent arming failure is
indistinguishable from a screen that draws nothing.

My first cursor detector measured the wrong change: presents where the SET
of quads changed, which fired on 157 of 161 adjacent pairs because during a
build-in everything animates. Tracking one quad shape's POSITION instead
correctly reports no motion. That is the play-test's own lesson landing on
me -- an instrument that measures change can still measure the change of
the wrong thing.

Next run must not drive the boot blind: gate the presses on a classifier or
join with boot_menu.sh, which reaches the menu but takes screenshots rather
than draw logs. Blind was chosen because screenshots cost ~10 s each while
xenia runs; wrong trade, since a mistimed press costs the whole run.

Reach: the negative is about this run, not the game. F1 stays open and the
port should keep its -1.0 constants.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:41:55 +00:00
sylph-decoder
ad3d14ab26 re: a THIRD timed channel in the decoder -- my "only two" was wrong, and +0xC4/+0xC8 are timings not masks
Chasing F1 I examined a counter block I had skipped. this+0x10 decrements
every update and fires output bit 0x4 at zero, guarded against the HELD
word by cfg +0xA0; it is re-armed from +0xC4 = 10 and +0xC8 = 8.

So my statement that "the only two timed inputs in the whole decoder are LB
and LT" is false, and two constants I tabulated as ring-word button masks
(B|Y and Y) are counter reload values. A number that is a valid mask AND a
valid duration cannot be told apart by its value, only by its use, and I
classified those two by value.

What it does not change: F1 is still not answered. This channel is guarded
by cfg +0xA0 = ring bit 1 = B, not a direction. The D-pad and left-stick
paths still carry no counter, so "a held DIRECTION has no repeat timer in
C_PAD_DECODER" stands, and the human's observation that it repeats in the
real game is consistent with the caveat this page already carried: the
repeat is in the layer above.

Explicitly NOT offering 10 and 8 as F1's two numbers. They belong to a
channel on a button that is not a direction, and at 60 units/s they are
0.167 s and 0.133 s -- about 7 moves a second, which does not match "a
medium pace, slow enough to see which item is selected". Reporting them as
the menu repeat would be the same read-a-config-infer-a-behaviour error
this correction is about.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:35:55 +00:00
sylph-decoder
fa9f9eee52 Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-02 16:34:44 +00:00
sylph-decoder
e820121d8a re: the plate pulses via ptbtn00f on a declared 120-unit loop, not ptbtn00 at 244
The port asked whether the PRESS (A) plate pulses and with what period,
framing it as "does the timeline loop at 244 or does something else drive
it". Both halves of that disjunction are wrong about ptbtn00.

ptbtn00 ramps, holds, extinguishes at t=244 and stays out. The pulse is
ptbtn00f -- the plate's focus/glow variant, reached through focus_link and
carrying no top-level element of its own -- which declares a 120-unit loop
from the disc. A reader looking only at ptbtn00 sees a one-shot because the
looping element is the one a declaration-order walk never reaches. Same
element that needed the by-name accessor in ui_layout, for the same reason.

Cross-check that makes it more than a stopwatch reading: 120 declared units
at the rate law is 2.000 s at 60 Hz, against a measured mean of 2.24 s over
four intervals -- 12% long, the direction and roughly the size Canary's
pacing produces.

Stated plainly as what it is not: the port asked for a per-frame series and
this is not one. The four intervals come from the screenshot probe, the
weaker instrument, carrying a wall-clock duration off an emulator with
load-dependent pacing -- the class that has cost this corpus four withdrawn
timing claims. The strong instrument has never reached this screen: five
attempts, blocked by wall-clock timeout, frame cap, a self-matching pkill,
and the title sitting past the 137.7 s attract movie.

So the fact and the period are answerable now; the trajectory within a
cycle is not, and I am not inferring its shape from declared keyframes when
the whole point of the splash exercise was that only a capture confirms
shape.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:28:33 +00:00
sylph-decoder
99330c3e87 handoff: H1 -- no key-repeat in the decoder; the timers are a double-tap latch on LB/LT
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:21:06 +00:00
sylph-decoder
dcaa322146 re: the decoder's timers are a double-tap latch on LB/LT, not key repeat
Answers H1's first half with a negative, and decodes what the timing
constants are for.

C_PAD_DECODER's +0xB4/+0xB8 and +0xBC/+0xC0 (10 and 90, twice) are not a
key-repeat delay/interval pair. They are two identical channels of a
DOUBLE-TAP detector, on cfg +0x74 (LT) and +0x70 (LB), firing output bits
0x20 and 0x40.

The mechanism, from the image: both timers tick down once per update; a
press arms the short timer to 10; a RELEASE adds 1000 to it as a flag
stored inside the counter, which is why the tick watches for exactly 1000
and clears both there; a second press while the flag is set arms the long
timer to 90; and while the long timer runs the output bit is asserted on
EVERY update, with the short timer re-armed to 1010 each time.

So it is a latch, not a repeat: a double-tap opens a 90-update window and
the bit is held for its whole duration. That is a dash or barrel-roll
shape, which fits the buttons it is wired to.

H1: the directions have NO timer. The D-pad and left stick reach the output
word through bare mask tests -- the four left-stick literals at 0x8220C458,
C474, C490, C4AC, and DPAD DOWN through cfg +0xA4 -- with no counter
loaded, decremented or tested on any of those paths. On the evidence of
this layer a held direction does not repeat.

Reach: one layer. A menu could implement repeat on top of a held bit, and
this says nothing about that -- but it does establish the repeat is not in
the shared decoder, so it would have to be per-screen. "One step per
deflection" stays authored for the port; this narrows rather than settles.

Refutation of my own earlier note that a decoder "is where a game normally
puts its repeat timing, its edge detection and its button remap": remap
survives, edge detection survives, repeat timing is REFUTED. That clause
was a prior about how games are written, not a reading of this one.

Also commits tools/ppc-dis, the minimal PowerPC disassembler this corpus
has been rebuilding in scratch and losing to container restarts three times
in one session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:20:50 +00:00
sylph-decoder
cac31deccd re: sub_822380B0 is a type-tagged draw-queue walker, not the interpolator
Walked the route the bounded-negative page named -- trace down from the
quad emitter -- and got one step.

sub_822380B0 is not a geometry emitter. It fetches a vertex pointer from
sub_823C2AC0, stashes it at this+0x20, then loops over an array of item
POINTERS at this+4 bounded by this+0x0C and this+0x10, loading a type tag
from item+8 and dispatching on it. So the object is a draw QUEUE and this
function consumes it.

That is a partial answer to a different open question:
ui-quad-class-foothold.md records that no function iterating screen
elements has been found. This iterates UI items and dispatches per item.
It is a draw queue rather than a screen's declared element list, so it is
not that walk, but it is the consumer immediately downstream and the type
tag at item+8 is a concrete field to chase.

Still not the interpolator: alpha is already decided by the time an item
reaches the queue. The evaluator runs before the enqueue, so the next step
is whoever pushes items -- the writer of +0x0C/+0x10 on this object.

Recorded as an increment, not a finding: one function identified by
disassembly, no behaviour measured, identification resting on code shape
alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:17:12 +00:00
sylph-decoder
8859189938 Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-02 16:15:46 +00:00
sylph-decoder
7c47ba13be handoff: withdraw the resample caveat -- the captures are crops, pixels to pixels
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:14:41 +00:00
sylph-decoder
b32bcb97ae re: CORRECT the resample consequence -- the captures are crops, not resamples
The port pre-registered a test and ran it: against live-splash-publisher.png
a cropped render scores RMSE 558.1 (0.85%) and a scaled one 10118.8
(15.4%). Cropping is 18x better.

Confirmed here independently, from a different observable: the committed
captures are 1279x675, 1280x690 and 1252x754. VARYING heights. A fixed
presenter resample produces one size; crops of differently-sized windows
produce exactly that spread. And ui-render-tone-curve.md had already
recorded every capture aligning at dy=0 dx=0 with correlation 0.9466, which
a 0.9375 vertical scale cannot produce -- the evidence was in the corpus
before I wrote the claim.

So the captures are crops of a 1:1 surface, and every RMSE, glyph count and
surface mean against them is pixels to pixels with no filter to caveat. The
blanket "everything measured off a PNG carries the resample" is withdrawn.

Not refuted: the cvar reading. Canary does letterbox by default. What is
refuted is my inference that the corpus's capture path went through it.
Whether the presenter is bypassed, the window is 1:1, or the tool crops
before saving is open and unestablished.

The error is the one this session keeps paying for: I read a configuration
and inferred a consequence FOR THE DATA without testing it against the
data. The test costs one render and one RMSE and I had every capture needed
to run it.

Also downgrades my refutation of the corpus's oracle principle from
"survives with a qualifier" to "survives, and my qualifier was wrong",
kept rather than deleted because the failure is the instructive part.

Section 1 (gamma: VdGetCurrentDisplayGamma is kStub, the splash shader has
no pow/ramp/lookup) and the two-path distinction stand unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:14:28 +00:00
sylph-decoder
3dfedd152b handoff: Canary applies no gamma but does resample; the vertex stream is the cleaner oracle
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:11:26 +00:00
sylph-decoder
515ad205e5 re: what Canary does between the guest's draw and a captured pixel
Answers question 3 of the 2026-09-02 play-test, from Canary's own source.

Gamma: Canary applies NONE. VdGetCurrentDisplayGamma is declared kStub and
only reports kernel_display_gamma_type (default 2, TV/BT.709) to the guest
so D3D can build a ramp. And the guest does not apply one either, for the
splash: its dumped pixel shader is four ALU ops -- tfetch2D, three muls, a
max -- with no pow, no ramp, no lookup.

Geometry: yes, the presenter resamples. present_letterbox defaults true and
present_safe_area_x/y default to 100, so the guest's 1280x720 is scaled to
fit the window and letterboxed with nothing cropped. That accounts for a
number the corpus has carried without explaining: captures measure the game
surface at 1279x675, and a single-pixel oracle placed at 1280x720
coordinates read the copyright line instead.

The structural consequence is the useful part. There are two measurement
paths and only one has Canary in it:

  pixels        guest draw -> EDRAM -> resolve -> front buffer ->
                presenter (scale + letterbox) -> X11 -> screenshot -> PNG
                => carries a resample
  vertex stream guest CPU writes a vertex buffer -> the draw logger reads
                guest memory directly
                => carries nothing

The per-frame alpha series is the second path, which is why it can be
stated as the game's values rather than as pixels we measured. Everything
measured off a PNG carries the resample: every RMSE against a capture,
every glyph count, every surface mean.

Refutation attempt on this corpus's own founding principle, "the oracle is
the real game running in Canary, captured": it SURVIVES but needs a
qualifier it has never carried. A PNG capture is the oracle plus a
resample. Harmless for ordering, counts, durations and change; a filter in
the path for anything pixel-exact. The vertex stream is the stronger oracle
and should be preferred where the question can be asked of it.

Not measured: the resample's actual filter. I read the cvars saying scaling
happens, not the kernel doing it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 16:11:09 +00:00
sylph-decoder
934fbfbbbf re: the interpolator is not found, and four routes are excluded
Question 1's behavioural half is answered elsewhere and measured. This is
the other half -- which function -- and it is not found. Recorded as a
bounded negative so the next attempt does not repeat four searches.

Excluded, all by exhaustive scans of the image:

  integer lerp shape (divw with mullw and subf within 10 instructions):
    28 sites image-wide, NONE in the UI region 0x82200000-0x823FFFFF
  mulli by 40, the keyframe record stride: 31 sites, NONE in the UI region
  addi rX,rX,40 in the UI region: 43 sites; the screen/bundle ones at
    0x823CCA6C and 0x823CCA94 disassemble to a 40-byte container COPY loop
    (CTR=10, ten-word copy), a vector reallocation, not an evaluator
  fmadd-family in the UI region: 811 sites over 142 pages -- too diffuse to
    select on, so float is neither excluded nor narrowed

The first two together say the evaluator does not compute its fraction with
integer multiply-and-divide and does not index records by multiplication.
With the measured steps landing on exact integers, the likeliest remaining
shape is a float lerp with a per-segment reciprocal, converted to a byte --
stated as a hypothesis, not a finding.

Names the route I would take next and did not have budget for: trace DOWN
from the quad emitter. sub_823C2AC0 has exactly 6 callers, four of them
sibling emitters, and sub_822380B0 reads its colour from this+0x04..0x10.
Whoever writes those fields is one step from the interpolator.

Reach stated: the two opcode negatives are exhaustive over the whole image
rather than sampled, but they do not exclude the interpolator living
outside the UI region, which is an assumption inherited from
ui-quad-class-foothold.md and not independently checked.

Not blocking the port: it needs whether to lerp and how, which is answered.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 15:42:25 +00:00
sylph-decoder
e1b259925c handoff: the game lerps every frame, and your 3.2 s hold is correct
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 15:29:54 +00:00
sylph-decoder
acc6c09632 re: the game interpolates every frame, and its splash is ALSO mostly frozen
Answers question 1 of the 2026-09-02 play-test: interpolate or hold. It
interpolates, piecewise-linearly, evaluated once per present at one unit
per present.

palogo_sqex_eff gives 28 distinct alphas over 28 consecutive presents,
changing on 26 of 27 adjacent pairs. It is not one slope, and the disc says
why: that element declares 0:a=0 -> 15:a=255 -> 30:a=212 -> 45:a=0, three
segments with three gradients. Predicted -2.87 and -14.13 per unit against
measured modal steps of -3 (x6) and -14 (x9). The declared keyframes
predict the per-frame steps, which makes this a prediction rather than a
description.

So the port must lerp: hold-to-next-key would emit 3 states where the game
emits 28. And "eased" is the wrong description -- there is no easing
function, the envelope only looks eased because consecutive declared
segments have different gradients.

Alpha lives in the per-vertex k_8_8_8_8 colour, rewritten into a fresh
vertex buffer every frame. Not a PS constant (ps_c[n=0] on 1048/1048), not
a blend factor, not a texture swap.

🔴 And the game's splash is ALSO mostly frozen. Measured with the same
statistic the play-test used on the port: the game moves 21.2% and 27.8%
against the port's 16.4%, and its longest frozen run is 3.34 s against the
port's 3.20 s. The publisher declares 205 of 255 units -- 80% -- as a flat
hold at full opacity.

That refutes the play-test's second clause. "A fade does not hold one
picture for 3.20 s" -- this one does, for 3.34 s. Its first clause stands:
26 states for a 45-unit build-in is too few, the game gives 49 and 51.

The deficit is the state count, not the freeze: ~100 against 26. Acting on
the second clause would have sent the port to remove the one part of its
splash that is already right.

Not answered: which function does it. This is the behaviour; the
image-side half of question 1 is still open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 15:29:34 +00:00
sylph-decoder
8580c8738b Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-02 15:26:38 +00:00
sylph-decoder
33a6b4ea6f re: the three routes to 60 are one witness in three coats -- audit, and the capture sized
The port observed that the justification for 60 has changed three times
while the number never moved, and that three routes sharing an upstream
assumption are weaker than they look. Checked. They do share one.

Route B needs "the guest presents 60x/s", which comes from the vblank
histogram UNDER XENIA'S 60 HZ LIMITER. Route C needs "the vblank is 60 Hz",
which is that limiter's cvar directly. Route D is a wall-clock duration
that lands on 60 only because the vblank is 60 Hz and Canary roughly keeps
up. All three reduce to one fact: the display refreshes 60 times per second
on this emulator. I presented them as corroboration and that was wrong.

What is actually established, by manipulation rather than agreement:
units/second EQUALS the display refresh rate. Forcing 30 Hz gave 30.2
units/s; at 60 Hz it is 59.8/61.3. One factor changed, the output tracked
it.

It becomes "60 units/s" only via an external fact this corpus has not
measured -- that an Xbox 360 outputs 60 Hz. That is a hardware
specification and it is solid, but it belongs outside the measurement
rather than laundered into a third agreeing route.

The conditional form is more useful anyway: it says what to do on hardware
that is not 60 Hz, which is exactly why the port's time-based clock at a
fixed 60 units/s is the right construction rather than a coincidence. And
it keeps the port's `authored` classification correct -- nothing here
promotes it.

Also sizes the clock-origin capture properly. FRAMES=9000 ran to completion
still in the movie at 8999, so the cap really fired this time. Content
hashes show 3967 distinct decoded frames against ADV.wmv's declared 4131 --
96% complete -- at 1.79 presents per decoded frame, not the 2.00 I assumed,
which is why the estimate was short. Needs ~294 more presents to clear the
movie plus >=236 for the plate, so FRAMES=11000.

Free on the way past: 3967 decoded frames over 7091 presents at ~52
presents/host-s is 29.1 movie frames/s against the disc's declared 30.000,
a 3% match that ties the present rate to a disc fact rather than a clock.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 15:08:55 +00:00
sylph-decoder
befcb74780 re: the clock rate follows the VBLANK -- reconciling three pages that disagreed
h3 says 2 units per guest frame, units-per-second-measured says
time-integrated at 56.8 units/s, and my own page says 1 unit per present.
All three rest on real data and one mechanism explains all of them: the
clock advances one unit per VBLANK, and presents can be dropped without the
clock caring.

That accounts for the corpus's steps of +17/+34/+51 (1, 2, 3 vblanks
between two logged presents), for the same animation spanning 21 labels in
one capture and 33 in another -- which a strict per-present clock cannot
produce -- for h3's three plate steps of 23, and for my own 14 consecutive
steps of 17 in a run that dropped almost nothing.

My "1 unit per present" was nearly right and named the wrong clock. At
--framerate_limit=30 Xenia vblanks at 30 Hz and the guest presents ~30/s,
so presents and vblanks coincide and the test could not tell them apart. It
correctly refuted time-integration; it could not locate the tick.

Solid: the RATE follows the vblank rate. 255 declared units take 4.26/4.16 s
at a 60 Hz vblank and 8.45 s at 30 Hz -- 59.8/61.3 against 30.2 units/s. A
time-integrated clock predicts 4.25 s in both. So a console at 60 Hz gives
60 units/s, and the port's value stands on a third independent route.

Not solid: per-vblank vs per-present. My step samples are ~12 per run,
which cannot separate them, and I say so rather than reading 18% vs 0% of
two events as support. The load-bearing observation for the mechanism is
the corpus's 21-vs-33, not mine.

The discriminating experiment is named and not run: log Xenia's
D1MODE_V_COUNTER beside each present and check every step is exactly
17 x (vblanks elapsed).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-02 15:05:03 +00:00
sylph-decoder
a7013a8fe1 re: the long capture ran and fell 32% short -- sized the next one from measurement
Attempted the capture this page named: FRAMES=8000, MAXDRAWS=400000, 700 s.
Reached frame 5954, still in the movie, zero UI quads after it.

Neither cap fired -- 24 213 draws of a 400 000 cap, 5954 frames of 8000 --
so it ended on the script's wall-clock timeout and nothing about the method
is wrong. It needs a longer window, not a different approach.

Sized from what this run measured rather than guessed: ~460 presents for
the splashes, a 137.714 s movie at 30.000 fps from the disc = 4131 decoded
frames, 2 presents per decoded frame measured, so ~8700 presents to clear
the movie. This reached 5954, about 68%, at ~22 presents/s armed. So
FRAMES=9000 and a timeout of at least 1200 s.

Also noting a saving I did not take: the h= content hash reads guest memory
for every sampled texture and the movie binds three planes per draw, but
the clock-origin measurement needs vertex alpha and not hashes. That field
is unconditional in canary-patches/0004; putting it behind its own cvar
would make this run materially faster.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 20:09:34 +00:00
sylph-decoder
e354e11f4c method: a finding is only as portable as the tool that produced it
Records today's trap where the corpus keeps its traps, so it outlives the
session that paid for it.

Four Canary commits existed only inside the container and were cited the
way one cites a public reference -- "canary sylpheed-re d90d14e02, already
built" -- a line that reads as a complete recipe and is reachable from
nowhere but that box.

The failure is silent and delayed by design: the recipe looks complete so
nobody checks it, and it fails only for someone on a different machine long
after its author could say what the flag did. Nothing in the repository
disagrees with itself meanwhile, so no consistency check fires.

Notes why citation checkers do not cover the class -- they scan repository
paths, and an instrument in another container is not a path -- so they
catch the recoverable case (a stale pointer to a committed artefact) and
slide past the lost one.

And that the audit only works pointed at yourself: both agents ran it on
the same day, one finding a stale path to a committed artefact and the
other four artefacts that existed nowhere else, neither able to find the
other's from the far side of the wall.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 20:01:03 +00:00
sylph-decoder
3f114a28af tools: export ALL FOUR container-only Canary commits, not just my own
Applying my own lesson to my own corpus rather than only stating it. I
exported the content-hash patch and stopped; auditing the docs for
"/canary sha" citations found three pages naming d90d14e02, and checking
/canary's history found the exposure is four commits deep, not one.

Bounded by measurement rather than guess: branch -r --contains puts
590912722 on origin/sylpheed-re and finds no remote for anything after it,
so the container-only stack is exactly these four.

  0f920e645  blend= per draw          <- the ENTIRE blend decode rests on this
  fa1e4c221  vertex dump 8 -> 64      <- at 8 the log silently dropped four
                                         quads of the EXTRAS 24-index batch
  d90d14e02  RT state, resolves, PS constants
  ab3203f79  h= content hash

The sharpest case is 0f920e645. Without it a draw log records no blend
state at all, so ui-blend-mode-decoded.md's 35-element oracle -- which
overturned a REFUTED entry and deleted the port's authored blend map --
could not be re-derived by anyone who cloned this repository.

The failure mode is silent: the recipe LOOKS complete and only fails for
someone on a different machine, long after its author could say what the
flag did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:59:14 +00:00
sylph-decoder
afec2ae592 tools: export the Canary logger patch the clock findings depend on
/canary is a separate checkout that lives only in the container and is
pushed nowhere. The content-hash field in the UI draw logger is what
separates "the buffer rotated" from "a frame was decoded", and two
committed findings -- guest-frame-rate-resolved.md and
clock-is-frame-based-one-unit-per-present.md -- cannot be reproduced
without it.

Committed in /canary as ab3203f79 on branch sylpheed-re for a nameable sha,
and exported here as a patch because that sha is not reachable from
anywhere outside this box.

Includes the rebuild recipe, since the build needs the /work/xenia-canary
symlink present and that is not obvious from the failure it gives without
it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:56:29 +00:00
sylph-decoder
3e067decef re: the clock origin is blocked -- a 600-present boot capture has no title in it
The clock origin is the last surviving candidate for finding 3, and now
that the clock is known to advance 1 unit per present it is directly
measurable as a count: observe the plate at a known declared alpha, count
presents back to the title's first draw, and the difference is the title's
clock value at its own first draw.

No capture I have contains the title. Three captures agree on what the boot
does: publisher splash (219/228/244 presents), developer splash
(186/185/204), then the attract movie at 422/429/463. Two splashes, then
the movie. There is no title segment.

This re-frames an old blocker as expected rather than mysterious. The
corpus records "three runs, two locales, two launch paths, ~35 minutes of
emulator time, no interactive title" as unexplained. MISSION's own boot
order is splash -> intro video -> title, ADV.wmv is 137.7 s from the disc,
and 600 presents at ~50/s is ~12 s. The title is on the far side of a
two-minute movie; a capture that never reaches it is behaving correctly.

Two ways to settle it. Tapping A skips the movie but risks the save-data
probe that crashed the guest on 2026-08-18, per the capture script's own
header. Capturing through the whole movie needs ~6900 presents against the
600 used here, needs no pad input and cannot crash the guest, so that is
the one to run.

Not run this iteration, deliberately: I would rather pre-register the
origin prediction than start a long capture at the end of an iteration. The
prediction is stated on the page so the next run is not exploratory -- the
plate's a=17 must land 215 presents after the title's first draw if the
clock starts there, and any shortfall is the offset in units.

Reach: the negative is specific. Within the first ~460 presents of boot the
title does not draw. It says nothing about after the attract movie, which
is where the answer is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:44:33 +00:00
sylph-decoder
405f16e382 handoff: the forced-frame-rate run refuted me; the game is frame-based, the port's time-based clock is correct
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:40:16 +00:00
sylph-decoder
705a8485dc re: the clock is FRAME-based, 1 unit per present -- my own test refuted my claim
Ran --framerate_limit=30 against predictions committed beforehand. Every
discriminating row went to the frame-based column:

                       frame-based   time-based (mine)   measured
  presents/s           ~27           ~27                 28.4
  modal alpha step     17 unchanged  34 doubled          17 UNCHANGED
  units/s              ~30 halved    ~60 unchanged       30.2 / 30.3
  publisher dwell      ~8.5 s        ~4.2 s              8.450 s DOUBLED
  developer dwell      ~7.0 s        ~3.5 s              6.923 s DOUBLED

Both controls passed first. The limiter took effect (28.4 presents/host-s
against 51-55, interval mass moving from one 60 Hz vblank to two, 422 of
468), and all 8/8 splash quad rects are identical so nothing but the frame
rate differs.

So the UI clock advances exactly 1 unit per presented frame. The step is 17
on every quad at 28.4, 51.4 and 54.8 presents/s, and 255*1/15 = 17 with the
declared T=15. units/second = presents/second, and seconds are not a
property of the game.

The port's 60 stands: the guest presents once per 60 Hz vblank
unconstrained, and 1 unit per present at 60/s is 60 units/s. Same answer as
my first position, finally with a tested mechanism instead of an inference.

This withdraws units-per-frame-is-not-a-constant.md in its central claim.
My "a time-based clock is immune to dropped frames so the dwell is stable"
was a real prediction and it failed -- the dwell doubled. The four-run
agreement I read as evidence was four runs at similar frame rates.

h3-units-per-frame-measured.md's +34 is now the anomaly rather than the
rule: 34 per label at 27.2 labels/s against 17 per present at 28.4
presents/s. Both cannot be presents. Not asserting it is wrong, only that
one of them must explain the disagreement.

Three of my four positions came from inference over a measured quantity;
this one came from changing an input and watching what moved. The
opportunistic comparison pointed exactly the wrong way because nothing
controlled what else differed between those captures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:39:30 +00:00
sylph-decoder
5d72bda77d re: PRE-REGISTER the forced-frame-rate test of the time-based clock
The time-based-clock claim rests on two captures that happened to run at
different speeds. Nobody has changed the frame rate on purpose and watched.

--framerate_limit=30 halves Xenia's vblank ceiling. Predictions committed
before the run:

  quantity          frame-based        time-based (my claim)
  presents/s        ~27                ~27
  modal alpha step  17, unchanged      34, DOUBLED
  units/s           ~30, halved        ~60, unchanged
  splash dwells     ~8.5 / ~7.0 s      ~4.2 / ~3.5 s, unchanged

Accept time-based only if the step lands in 30-38 AND the dwell stays
within 10% of 4.2/3.5 s. If the step stays 17 and the dwell doubles, the
claim is refuted, the clock is frame-based, and the port's 60 is unsupported
again.

The control is the present rate itself, read FIRST: a doubled step also
appears if the limiter did nothing, so if presents/s does not fall to ~27
neither prediction is tested. Second control: the eight splash quad rects
must be unchanged, or something other than the frame rate differs between
runs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:37:41 +00:00
sylph-decoder
73f5f57966 re: WITHDRAW 120 -- units per FRAME is not a constant, the clock is time-based, 60 is right
My fourth position today, and it returns to the port's.

Splash B's logo quads in this capture step +17 per present, 14 gap-free
steps, four quads agreeing. h3-units-per-frame-measured.md measured the
SAME elements at +34 and concluded 2 units per frame.

Both are right. With the declared T=15, dA/present = 255*(units/present)/T:

  h3 capture    27.2 presents/s   +34   2.0 units/present   54.4 units/s
  this capture  51.4 presents/s   +17   1.0 units/present   51.4 units/s

Units per present halved when the presentation rate doubled. Units per
second did not move. The UI clock advances by ELAPSED TIME, not by frame
count, and "2 units per frame" was a property of a capture that ran at
27 fps, never of the game.

So my 120 units/s is withdrawn: it was 2 units/present x 60 presents/s, and
the first factor is not a constant.

The movie result is re-explained rather than refuted. 2 presents per
decoded movie frame at 51.4 presents/s is a movie decoding at 25.7 fps -- a
30 fps movie at 86% under a slow emulator. The measurement held; the
inference assumed the movie decoded at 30/s in real time, which it does not
when the emulator is slow. Same shape as the first withdrawal.

60 is now positively supported rather than merely undefended. A time-based
clock is immune to dropped frames, which predicts the dwell in seconds is
stable across runs at different frame rates -- and it is, across four runs
whose present rates differ by 1.9x: 255/4.27 = 59.7 and 210/3.46 = 60.7,
both within 1% of 60.

h3-units-per-frame-measured.md's conclusion needs demoting: its measurement
stands, its law is a single-capture artefact, and it is the origin of the
constant this question has thrashed on.

Finding 3 is open again with no surviving named cause.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:35:24 +00:00
sylph-decoder
33f141a3df re: the dwell corpus does not falsify 120 -- it measures the screen, not the animation
The port raised this as load-bearing and it is answered, without a speed
factor.

I expected to find the three cold boots slow and argue contamination. They
are not. My capture reproduces them: publisher 4.263 s against 4.297 /
4.604 / 4.370, developer 3.457 s against 3.508 / 3.503 / 3.366. Four runs
agree, so that defence is unavailable and I am not using it.

The flaw is in the comparison. 2.125 s is the publisher's declared
ANIMATION length; 4.3 s is how long the SCREEN is up, and the screen holds
after the timeline ends. Measured as counts in one capture: the publisher
is on screen for 219 presents and animates for about 128 of them. The
falsifier would have found a contradiction at any units-per-second.

The decisive number needs no speed factor: 51.4 presents per host-second on
the publisher splash, 53.8 on the developer. Xenia's limiter marks vblank
at 60 Hz and caps presents there. A 30 fps guest presents every second
vblank, at most 30 per second, and a slow emulator can only make intervals
longer. 51.4 > 30, so a 30 fps guest cannot produce this. A 60 fps guest
can: 51.4 is 86% of 60, matching the vblank histogram's 14% drops.

So 60 units/s is refuted by a count against a hard limit rather than by a
duration against a fitted factor -- the argument the 2.13 s reconciliation
could not make.

The dwell corpus stands in its own terms. Those seconds are the screen's
dwell on this emulator, reproducible, and were never a statement about
units per second.

Recording what I got wrong on the way: I first segmented the atlas eras as
"both splashes then the title" and briefly had a 2x discrepancy that would
have let me declare the dwell corpus contaminated. The segmentation was
wrong, and the durations matching the corpus to 1% is what exposed it. A
convenient answer from an unchecked segmentation is the same trap as a
clean answer from an unguarded assumption.

Reach unchanged: still one boot for the hash ratio.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:30:02 +00:00
sylph-decoder
058a450ec5 handoff: 120 units/s, the plate is ~2 s late, and every second I quoted is halved
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:24:05 +00:00
sylph-decoder
60145720ed re: the guest presents at 60 fps -- 120 units/s, and the port's plate IS ~2 s late
Answered against the pre-registration committed before the capture, with a
content hash added to the draw logger.

The buffer rotates three times faster than the content changes: 177
presents carry 3 base addresses but only 102 distinct content hashes, and
the modal run is exactly 2 presents per decoded frame. Consecutive presents
with changed content = 0.5739, inside the pre-registered R band of
0.40-0.60.

That is precisely the failure that invalidated my first answer this
morning. The base address changed every present, which I measured and read
as one decode per present. The content did not.

ADV.wmv is authored at 30.000 fps, so 2 presents per movie frame is 60
presents/s, and 2 units/present x 60 = 120 units/s.

Both controls pass, and they are the ones the withdrawn version lacked --
its two guards tested how I READ the buffer, neither tested whether a
buffer change meant a decode.

Control 1, a static texture must hash constant: the splash atlas changes
once, at an era boundary, and never within an era -- 1 change in 403
samples. Noting that I first wrote this control as "must be constant" and
it read FAIL; stated that way it was wrong, because a re-upload is real
content change and the control has to separate temporal from alternating.
A control that is too strong gets waved away, which is its own failure.

Control 2, the movie luma hash must not be constant: 102 distinct.

Consequence: the plate's t=236 is 1.97 s, not 3.93 s, and the port shows it
~1.96 s late. That is play-test finding 3, and "about two seconds" is the
size the human reported. Every declared duration in seconds across the
corpus is half what we have been quoting; unit counts are untouched.

The 2.13 s third route is explained by emulator speed, and that explanation
is labelled POST-HOC and is not offered as support -- fitting a speed
factor to close a gap is what this corpus keeps losing claims to.

Reach: one boot. This number has moved twice today and a second independent
boot should come before the port rewrites a timeline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:23:13 +00:00
sylph-decoder
56ae05a18b re: PRE-REGISTER the decode-vs-rotate test, and add a content hash to the logger
The experiment guest-frame-rate-WITHDRAWN.md named. A triple buffer
rotating once per present visits the same three base addresses whether or
not anything was decoded into them, so base identity cannot separate
"decode per present" (30 fps guest, 60 units/s) from "rotate per present"
(60 fps guest, 120 units/s). A content hash can.

command_processor.cc now emits h=<FNV-1a over 4096 sampled bytes> beside
every sampled texture, omitted rather than faked when the address does not
translate, so a missing hash cannot read as a matching one. Incremental
build, one translation unit.

Predictions committed before the capture: consecutive presents with changed
luma content is ~1.00 under decode-per-present and ~0.50 under
rotate-per-present, with acceptance bands and "neither" reported rather
than rounded.

The control is the part I got wrong last time. A STATIC texture must hash
constant: the splash sprite page 0x11A50000 is a fixed atlas, and if its
hash varies between presents then reading guest memory at draw time races
the decoder and nothing in the log may be read. That fails loudly in the
direction which would otherwise manufacture the answer I previously
reached -- the property my last control lacked. A second control in the
other direction requires the movie luma hash NOT to be constant, which
would mean hashing the wrong bytes and would manufacture the opposite
answer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:21:04 +00:00
sylph-decoder
eeb4473b4f re: the port's 12-unit bracket does not exclude 120 -- its low end is the sampler's floor
The port kept 60 on a stated constraint: the transition quad is declared
black for 12 units, measured at 0.14-0.30 s, giving 40-86 units/s, so 60 is
in and 120 is out. Attempted to refute it, and it does not hold.

Two reasons, either sufficient.

The low end is the instrument's floor. title-plate-delay-measured.md says
of that number, in its own words, "at a sampling resolution (0.125 s) that
cannot do better". 0.14 s IS one sample. At 120 units/s, 12 units is
0.100 s, which a 0.125 s sampler reports as roughly 0.14 s -- exactly the
value read as excluding it. The 86 units/s upper limit is an artefact of
dividing by a floored duration.

And a wall-clock duration off Canary is not independent of the unknown.
Apparent units/s = true units/s x speed factor, and the speed factor is
precisely what makes the three routes disagree. The bracket says "if Canary
ran at real time, 40-86" and whether it did is the question.

What survives is the declared side, and it is a disc fact worth keeping:
the transition opens over 12 units, independently confirmed as 6 frames by
screen-transitions.md's 255/6-per-frame ramp. That leg has no wall clock in
it and is real evidence -- for units per FRAME, which was never in dispute.

This does not argue for 120. Nothing supports 120 either. It removes a
reason for excluding it, and my position is unchanged: the value is
authored until the content-hash experiment runs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:15:34 +00:00
sylph-decoder
ca401d8b04 re: WITHDRAW "the guest presents at 30 fps" -- the clean result WAS the failure mode
Published this morning, withdrawn the same day. The measurement was real;
the inference was not established.

My own pre-registration named three ways the instrument could lie and
guarded two. The third -- "the guest may be frame-locked to its own
presentation rather than to the movie clock" -- is the one that occurred,
and a perfect 1.0000 is exactly what it produces: a triple buffer rotating
once per present gives run-length 1 at ANY frame rate. So the measurement
cannot separate a 30 fps guest decoding one movie frame per present from a
60 fps guest rotating a buffer per present.

The methodological error is the part worth keeping. I wrote the guard down,
saw a result so clean it had no tail, and read the cleanness as strength. A
clean result on an instrument whose key assumption is unguarded is not
confirmation -- the cleanness may be the failure mode's own signature. Both
guards I did build tested how the buffer was READ; neither tested whether a
buffer change means a decode.

What surfaced it: the draw log carries a per-frame gtick marker I had not
noticed. It is host time rescaled (Clock::QueryGuestTickCount is
host_tick_count * guest_tick_ratio, scalar 1.0), so it is a wall clock and
cannot be read as a rate -- but its SHAPE has no phase. Xenia locks vblank
to 60 Hz, and the present interval is ONE vblank 71.7% of the time and two
24.6%. A guest hard-locked to 30 fps presents every second vblank and would
put the mass at 2.

I am NOT replacing it with 120. Three routes now disagree: the withdrawn
movie cadence says 60, the vblank cadence says ~120, and
title-plate-delay's 120 declared units in 2.13 s measured twice to 6 ms
says ~56. Two of the three must be wrong and I do not know which.
Publishing 120 would repeat the mistake this commit withdraws.

The port is told to keep 60 for now, and told plainly that it is an
authored value rather than a measured one.

The settling experiment is named: hash the movie luma plane's CONTENTS per
present rather than its base address, which separates "the buffer rotated"
from "a frame was decoded".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:11:05 +00:00
sylph-decoder
fa27509937 formats: teach the reference renderer the additive blend, and re-open 8 claims
The blend bit has been decoded against RB_BLENDCONTROL0 since 2026-08-31,
but ui_layout::blit could not draw it, and said so in a comment citing a
refutation that is <render-vs-capture> -- this renderer disagreeing with
itself while it had a stale keyframe association, no leaf geometry and no
rotation.

The consequence the port raised: verify-screen compares two renderers, so a
renderer that structurally cannot express a declared field makes the check
incapable on every screen that uses it -- 12 of 16 -- and the tolerance
silently excuses all of them. A quiet check is worse than a failing one.

Both equations come off the game's own pixel shader, which premultiplies
(oC0 = rgb*A, A), so only the blend register differs: 0x07010701 gives
rgb*A + dst*(1-A), 0x01010101 gives rgb*A + dst. Additive therefore
saturates rather than wrapping, and a transparent or black source is the
identity -- neither is a choice.

No plumbing needed: t8ad::parse already stores +0x04 as T8adImage::flags.

Four controls, pinned against arithmetic per the rotation precedent. The
fourth is the only one that can fail for the right reason: the first three
pass just as well if blit ignores the flag and draws everything additive,
so the discriminator flips only the blend on one sprite and requires two
different answers, each equal to its own equation. That is the same failure
class as the port's non-inverting latch check and my own backward scan that
resolved every guard to "internal".

120 passed, 0 failed on the full lib suite.

67 sprites over 14 screens were being drawn with the wrong blend, including
10 of 18 on the title and ptbtn00f, the PRESS (A) plate's highlight.

R1: tools/stale-instrument render-vs-capture lists 8 claims that died to
this instrument, including both legs of the rest() pair and "the plate-free
title capture may be too early to be settled", which sits on play-test
finding 3. None is re-derived here; this only records that the instrument
no longer exists in that form.

Also corroborates the port's H5: pgloading_loop5 is an ELEMENT resolving to
sprite pgloading_ring.t32, which is additive. I could not find loop5 as a
sprite in any pak and nearly reported a false contradiction from the
element/sprite name split.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:03:53 +00:00
sylph-decoder
9ea6ee7555 re: the blend bit was challenged on pteff10 and SURVIVES; finding 3 loses its second candidate
The port isolated main_menu's 10.88 -> 13.02 regression to pteff10 and
asked whether the per-draw log shows it alpha-over, which would be a
counter-example to ui-blend-mode-decoded.md.

It does not. blend-bit-vs-oracle.txt has pteff10 ADDITIVE on entry 5 (main
menu) AND entry 6 (extras), both labels read out of the guest command
stream, and HANDOFF states it from three independent menu sessions, every
frame.

The premise came from a stale coverage table of mine that the same HANDOFF
entry had already corrected in place. Recording that: a correction which
leaves the wrong table visible upstream of it has not landed.

And the regression was predicted on this exact element before adoption --
HANDOFF flagged pteff10 as the one row the port's renderer would not
corroborate, because for a dim wholly-semi-transparent glow (max alpha 130)
over a dark background additive and alpha-over nearly coincide. A renderer
metric getting worse while the render gets more correct is the standing
rule with a number on it.

Separately, the port answered my finding-3 candidate: a frozen sweep of the
plate region rises monotonically across the declared 214->236, so the port
fades rather than pops and its t=236 is a completion. That kills the onset
branch.

Two of the play-test's four named candidates for finding 3 are now dead --
units/s (measured at 60) and the ramp. Finding 3 has no surviving named
cause. The clock origin is the one to take next, because every measurement
so far is a DIFFERENCE between two events and a difference cannot detect a
common offset.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 18:55:50 +00:00
sylph-decoder
27f81d6d91 re: the guest presents at 30 fps -- 60 units/s, and the port was right
Answered against the pre-registration committed before the capture.

Units per second was the last open number on the PRESS (A) plate, and both
prior measurements of it were wall-clock readings off an emulator that runs
the guest slow by an unknown factor. They disagreed by 2.9x, because a 30 Hz
guest at full speed and a 60 Hz guest at half speed look identical on a wall
clock.

The ruler here is not a clock. ADV.wmv declares 30.0000 fps in its own ASF
header, so a decoded movie frame is a tick the emulator's speed cannot
stretch. Presented frames per decoded movie frame is guest_fps/30 with no
wall clock in the chain.

  predicted  H_A 30 fps ->  60 units/s -> 1.0
             H_B 60 fps -> 120 units/s -> 2.0
  measured                                1.0000

Both pre-registered guards pass. Guard 2: a perfect repeating 3-buffer
cycle, 52 uses each (exactly 156/3), 2 chroma planes per luma on 156 of 156.
Guard 1: run lengths are 156 runs ALL of length 1 -- no smear, so the
dropped-movie-frame bias that would have pushed the answer toward 120 is
measurably absent rather than argued away.

So H_A. The port keeps its 60 and changes nothing.

REFUTES the live H3 hypothesis that 120 units/s explains the play-test's
late plate. That hypothesis was well-formed and attractive precisely because
it would have explained the complaint, which is why it needed a ruler that
is not a clock.

Which means finding 3 still has no cause. The strongest remaining candidate
is decoded rather than speculative: the plate's declared onset is t=214, not
t=236 -- a 22-unit fade, matching the T=22 the oracle confirmed by measuring
+23 alpha per presented frame on that element.

The pre-registered control could NOT be run: this logger build emits vb=
addresses, not vertex contents, so there was no alpha to check +34 against.
A weaker control is substituted and labelled -- the splash shader/blend
census, which validates the log's structure (what this measurement uses) and
not alpha extraction (which it does not).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 18:49:40 +00:00
sylph-decoder
f0185fba52 re: PRE-REGISTER the guest frame-rate test -- the movie is the ruler
Units per second is the one number left on the PRESS (A) plate, and both
existing measurements of it are wall-clock readings off an emulator that
runs the guest slower than real time by an unknown factor. They disagree
by 2.9x, which is what that method is worth here.

ADV.wmv declares 30.0000 fps exactly in its own ASF header (stream #2,
avgTimePerFrame = 333333 x100ns). That is a disc fact, so a decoded movie
frame is a tick of a clock Canary's speed cannot stretch.

The measurement is a ratio of counts with no wall clock in it: how many
consecutive swap labels bind the same movie luma texture base.

  H_A  guest 30 fps ->  60 units/s -> 1.0 labels per movie frame
  H_B  guest 60 fps -> 120 units/s -> 2.0 labels per movie frame

Committed BEFORE the capture so the number cannot be chosen afterwards,
with acceptance bands, the three ways the instrument could lie, a guard
for two of them, and a named control (the splashes' established +34/frame
must reproduce in the same log, or the log is not comparable).

Noting the trap I nearly fell into: stream #1's avgTimePerFrame is a
packet rate and reads as 3.05 fps. Reading the wrong stream is the obvious
way to get this wrong, so it is written down.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 18:43:13 +00:00
sylph-decoder
4518b5c76a re: the pad word is REMAPPED -- my own bit table was mislabelled throughout
input-pad-read-path.md says of the word the C_PAD_DECODER reads: "There is
no shift and no remap on the way in -- the bit positions are XINPUT's own."
That is wrong. sub_8220D500 rebuilds the word out of XINPUT_GAMEPAD before
anything else sees it, into the game's own numbering.

  bits  0-3   A B X Y
  bits  4-7   left stick  UP DOWN LEFT RIGHT   (+/-20000 of 32767)
  bits  8-11  right stick UP DOWN LEFT RIGHT
  bits 12-15  D-pad       UP DOWN LEFT RIGHT
  bits 16-17  START, BACK
  bits 18-19  LB, RB
  bits 20-21  LT, RT  -- digital, threshold >220 of 255
  bits 22-23  L3, R3

Extracted mechanically from the image, no row typed by hand. The control is
the shape of the result: the 24 assignments land on bits 0..23, each used
exactly once, none repeated. A misdecode does not produce a bijection over a
contiguous range, and coincidence does not put the stick and D-pad
directions in the same order in two aligned nibbles.

So every mask in that page's tables names the wrong button. The 0xE000 x18
site, read there as "B | X | Y", is "D-pad DOWN | LEFT | RIGHT" -- eighteen
sites testing a menu cursor, which is what 18 sites should be.

And its headline negative is REFUTED: "LB and RB are not menu inputs" is
false. They are bound at config fields this+0x70 and this+0x84, LT/RT at
+0x74/+0x80. The negative was searched for 0x0100/0x0200 -- LB and RB in
XINPUT's numbering -- in a word where they live at 0x40000/0x80000. Right
function, right buttons, wrong bit positions, so it could only come back
empty. A negative is only as good as the numbering it was searched in.

Also decodes the ring record: +12 HELD, +16 PRESSED, +20 RELEASED, +28/+32
raw trigger bytes. Edge and level are one struct four bytes apart, which
displaces that page's guess that press-vs-hold was split between GetState
and the XamInputGetKeystrokeEx queue.

The superset claim in that page survives and is untouched: sub_82457038
really does compare every XINPUT_GAMEPAD field, and it really is
XINPUT-layout. This page depends on it.

Not decoded: which output bit means which ACTION, and per-screen sets. 5 of
18 output-bit sites did not resolve to a pad guard, so the output map is a
lower bound -- in particular "START is not tested" is NOT claimed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 18:33:42 +00:00
sylph-decoder
3ad8e7228f Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-01 18:26:34 +00:00
sylph-decoder
e263041337 re: the splash blur is a TEXTURE -- palogo_*_eff is a baked 10-px glow
Play-test finding 4, answered as a mechanism and from the disc, so it
generalises instead of describing one boot.

ui-splash-draw-pass.md excluded a post-process from GPU state and closed
with "that softness is in the texture or in which quads are drawn, not in
a pass", leaving the two unseparated. It is both, and they are one fact:
each logo ships a second texture that IS the blur -- the same artwork
outset by exactly 10 px per side, concentric to <=1.5 px, drawn as its
own alpha-over quad.

Three results, each with its control:

* The capture's eight anonymous quads are NAMED from the disc. Predicting
  each NDC rect from declared position + decoded sprite size matches all
  eight bijectively; every match <=0.0061, every runner-up >=0.0272, a
  4.5-8.9x margin. That margin is the control -- eight similar boxes
  would match anything.

* REFUTES splash-quad-timeline.txt's "the same three rects scaled
  slightly larger" (my own earlier wording). The x and y scale factors
  differ by up to 0.28; a uniform scale cannot do that, a fixed 10-px
  border can. The conclusion it supported (draw all six quads) stands;
  the model was wrong, and the wrong model tells a port to scale a
  sprite.

* The T8aD blend bit tested OUT of sample on entries 10/11, which were
  not in its 35-row fit and are the screens under complaint.
  Pre-registered additive=false for all eight against 0 additive draws in
  1048; held 8/8, with the control still reporting 9 additive on entry 6.

Also resolves a REFUTED.md 🟡 <our-reader> in the reader's favour: the
prediction is ours and the target is the oracle, so the agreement is
evidence about the reader rather than a claim resting on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 18:24:14 +00:00
sylph-decoder
958eca6b6b formats: expose the T8aD blend bit on the public API, with a control
`ui-blend-mode-decoded.md` established the field but nothing on `Element`
reached it, so the exporter could only key a blend map by SCREEN NAME --
which asserted-by-omission that the Japanese menus blend differently from
the English ones.

Adds `sprite_header_word_04`, `header_word_04_by_name`,
`sprite_blend_additive` and `blend_additive_by_name`, plus
`examples/blend_api_check.rs`: the accessor the exporter will actually
call, checked against the same 35 oracle rows read out of the guest
command stream.

22/22 agree, 0 mismatched. The control requires entry 6 to report BOTH
values (additive=9, alpha-over=7), so an accessor stuck at one answer
fails rather than scoring 100%.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 18:18:47 +00:00
sylph-decoder
df51101faf handoff: withdraw the splash rate, and strike the section that carried it
Told the port plainly: their arithmetic was right, the 35-40 is withdrawn,
keep 60 for every screen, and do not average or split anything. Struck the
previous section's heading in place rather than deleting it.

Carried the instrument lesson across, because it is worth more than the
number: the guest timebase does not remove the pacing artefact, since the
game's animation clock is frame-coupled rather than being the guest
timebase. My control verified capability -- does this clock track real time
-- when the question was configuration: is the quantity I divide by coupled
to the frame rate.

Also told them what this leaves: both halves of the human's finding 4 that
were mine are answered and neither points at their export, so their own
unbound-A observation is now the strongest candidate and it is theirs.
2026-09-01 17:30:24 +00:00
sylph-decoder
c1c8aa4288 re: WITHDRAW 'the unit rate is per-GamePart' -- it was the emulator's frame rate
The Port's arithmetic was right: a 160-unit sub-interval cannot outlast the
210-unit group containing it, and my hold (4.514 s) outlasted three cold-boot
measurements of the whole group (3.37/3.50/3.51 s).

My own capture says why, once asked the right question. The three numbers I
quoted came from three regions of ONE run, and I never asked how fast the
emulator was going in each:

  splash B (the hold)      3.39 labels/guest-second  -> I reported 35.4
  splash A (publisher)    15.33                      -> I reported 40.0
  the title (the plate)   23.20                      -> I reported 56.8

Monotonic. The 'per-GamePart rate' is the pacing of the region it was
measured in. Splash B was captured at 3.4 fps, an eighth of the title
region.

And the corpus already had this. boot-splash-dwells-are-declared.md says in
its own words that the wall-clock dwell is an emulator-pacing artefact that
varies run to run, with a no-input boot 15-20% long on the same declared
timeline. I re-derived a documented artefact as a discovery and drew a false
conclusion from it.

The instrument lesson, which is the part worth keeping: I believed the guest
timebase removed the artefact. It does not. The game's animation clock is not
the guest timebase -- it is frame-coupled -- so a slow run advances less
animation per guest second and no clock can see that from inside. My control
asked 'does this timebase track real time', which is capability. The question
that mattered was 'is the quantity I divide by coupled to the frame rate',
and nothing I ran asked it. That is PROTOCOL's own warning, which I quoted at
the other agent two iterations ago and then walked into.

Restated: the clock is neither purely frame-counted (21 vs 33 labels for one
animation) nor purely time-integrated (rate scales with frame rate).
Consistent with a clamped per-frame delta, untested, and now the real open
question.

Consequence: no rate measured on this emulator is the console's; all are
biased low. Best estimate stays the declared timeline against the fastest
runs -- 60 units/s, 1.1% on the developer splash. The port keeps 60 for every
screen and nothing needs averaging.

Untouched: section 1 of splash-declared-vs-captured.md. It compares a disc
table against vertex alphas at integer t and never divides by a duration, so
the pacing artefact cannot reach it.
2026-09-01 17:29:52 +00:00
sylph-decoder
227d9b0439 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.
2026-09-01 17:20:59 +00:00
sylph-decoder
4b5ac88f0a re: the declared timeline DOES reproduce the splash -- and the unit rate is per-GamePart
Two results, one of which corrects me.

1. The R1-re-opened 'declared keyframe timeline reproduces the captured
splash' resolves in FAVOUR of the declared timeline. Instrument is a disc
keyframe table against the guest's vertex stream -- no renderer in the chain,
which is what the 'our-reader' tag demanded. Calibration-free test: is each
captured alpha an exact member of the declared piecewise-linear value set at
integer t? 39/50 exact under truncation, 30/50 under rounding, and the worst
error under either rule is ONE alpha level in 255. All 11 non-exact samples
are low by exactly 1 and all are on falling segments. The old refutation
rested on 'still at a=255 nine frames after its declared a=32' -- under the
fixed layout a=32 is at t=206, four units from the end of a 210-unit
timeline. That was the off-by-one association.

2. The unit->seconds rate is PER-GAMEPART, which corrects what I told the
port an hour ago. Title ~57 units/guest-second; splash ~35-40. The splash
figure is confirmed two ways that share no algebra: a 15-unit ramp (T read
off the disc, not borrowed) and a 160-unit HOLD, which is a declared
duration with no T, no alpha slope and no interpolation in it.

And my 'the borrowed T=15 does not apply' was wrong in the other direction:
the disc says T=15 plainly. What failed was the premise of a single global
rate, not the T. Noted at the foot of that page rather than by editing it.

The trap worth recording: all four elements give 650-679 alpha/s, agreeing
to 2%, which reads exactly like one clock. It is a coincidence -- T differs
22 vs 15 and the rates differ 57 vs 37, and the ratios nearly cancel. A
quantity that looks constant across screens is not evidence of one clock
when the thing that would vary is inside it. The hold breaks the tie.

For the port: a single keyframe_units_per_second cannot be right, and a
splash played at 60 runs 1.5-1.7x too fast -- shorter, sharper fades than
the game's, which is the direction the play-test reported.
2026-09-01 17:19:59 +00:00
sylph-decoder
4e0f7bf6cb handoff: the rate resolved to 56.8 units/guest-second -- keep 60, and H3's last candidate closes
Told them plainly: 56.8 is inside my pre-registered band, the control passes
at 1.15%, 30 and 120 are excluded, and my own earlier ~30 was a borrowed T
that does not apply to those elements.

Three instructions: keep 60 (5.6% away against ~5% resolution, not refuted);
units = 2 x frames stays dead because only the constant survives and not the
route; and the unit constant is now ELIMINATED as the cause of a late plate,
since at 56.8 the plate lands at 4.15 s against their 3.93 s -- they are
fractionally early. That closes H3's last candidate from their side.
2026-09-01 17:11:46 +00:00
sylph-decoder
3d1c3c9564 re: fix the stale headline on the units-per-second page
The title still said 'not yet a number' after the second half resolved it to
56.8. Kept the failed first half in place and in order -- the borrowed T is
the lesson -- but a reader must not stop at the header.
2026-09-01 17:11:28 +00:00
sylph-decoder
d67aaaf30b re: the rate is 56.8 units per guest second -- both predictions hold, control passes
The capture reached the title AFTER the harness stopped classifying, so the
plate's ramp was in the log with tick stamps after all.

ptbtn00: alpha 11->231 over 334.4 guest ms = 657.9 alpha/s. With its
independently attested T=22 that is 56.8 units per guest second, inside the
pre-registered 55-65 band. The final step of every ramp is excluded because
it clamps at 255 and reports more elapsed time than it consumed -- including
it drags the plate to 633.0 alpha/s, a 4% error entirely inside the clamp.

Control passes at 1.15%: ptcopyright gives 650.4 alpha/s, and at one shared
clock that makes its own segment T=22.25. Two elements agreeing on a rate
AND independently landing on a round declared length is stronger than either.

Why my earlier 29.9 was wrong, and it is the failure the page predicted: it
used T=15 borrowed from a row that is about A element with a 15-unit fade,
generalised to splash B's quads, which is not what that row says. At 56.8 the
splash elements' implied T is 23-34, none of them 15. And the step quantum
does not rescue 15: splash steps are multiples of 17 = 255/15, which is what
made 15 look confirmed, but at T=28.5 a step of 17 is simply TWO units of
8.9. A quantum fixes T only if you already know the step is one unit.

60 is NOT refuted -- 5.6% away against ~5% quantisation resolution -- so the
port keeps it. But this DOES eliminate the unit constant as a cause of a late
plate: at 56.8 units/s t=236 lands at 4.15 s against the port's 3.93 s, so
the port is fractionally early.
2026-09-01 17:11:19 +00:00
sylph-decoder
1ac388b0c1 handoff: walk back 2-units-per-frame as a mechanism, and answer the port's blend-space ask
Two sections, the retraction first.

The clock is time-integrated, not frame-counted, so 'units = 2 x frames' --
which I sent them two hours ago -- computes an emulator artefact. Told them
what still stands from that message (the T-vs-step arithmetic and the t~160
anchor, both ratios inside one run) and what does not.

Also told them explicitly to KEEP 60 units/s and act on nothing today: my
own measured 29.9 rests on a T whose usual derivation is circular with the
thing just retired, and a failed prediction is not a licence to move their
constant.

Their H4, the blend space: the game blends in the ENCODED space.
RB_COLOR_INFO.color_format is k_8_8_8_8 on 2402/2402 splash draws and
33779/33791 of the boot-to-title capture; k_8_8_8_8_GAMMA appears zero times
and color_exp_bias is 0 everywhere. Mechanism from Canary's own source:
k_8_8_8_8_GAMMA is the only colour format around which a PWL gamma<->linear
conversion is applied. So a renderer that linearises and re-encodes is doing
a different operation, and the difference is gamma-shaped and zero on
unblended pixels -- their reported signature.
2026-09-01 17:05:09 +00:00
sylph-decoder
781a70af9a re: the animation clock is TIME-INTEGRATED -- one prediction held, one failed
Reported against the pre-registration, failure first.

HELD, and by a cleaner argument than the regression: the clock is NOT
frame-counted. The same animation takes 21 frame labels in one capture and
33 in another, and splash A's logo steps +136,+34 in one and
+17,+51,+34,+34,+17,+17 in the other. A fixed per-frame increment cannot do
that. Steps are always integer multiples of 17 (255/15 = one unit), so the
clock advances in whole units at a rate set by how long the frame took.

That retires '2 units per submitted frame' as a MECHANISM -- including my own
page from two hours ago. The measurement stands; 2 was that run's frame
pacing. units = 2 x frames computes an emulator artefact. Recorded as a
proposal against the register, not enacted, and noted at the head of the H3
page rather than by editing it.

FAILED: predicted 60 units per guest second, accept 55-65. Measured median
29.9 over six elapsed-ratio estimates (25.2-36.6). Prediction 3 said 30 was
excluded and 30 is what came out.

Why the rate is not a number yet: units/s = (d_alpha/dt) * T/255, and T is
the load-bearing term. d_alpha/dt is measured cleanly six ways. T=15 for
these elements comes from a corpus row whose usual derivation is circular
with the thing just retired -- a step of 34/frame implies T=15 only GIVEN 2
units/frame. T=30 would give ~60. No amount of re-measuring alpha settles it.

Settles with ptbtn00, whose T=22 is attested by two independent readers with
no clock anywhere in the chain. That capture did not reach the title in 531 s
of attract loop against 243 s in the previous run -- the variable attract
loop capture-harness-status.md already documents at up to 604 s. Instrument
built and control-passed; one run is missing.

Instrument: guest timebase, 50 MHz per emulator.cc:225, scalar 1.0 per
clock.cc:37, so no host wall clock enters any number. Control: 123.24 guest
seconds across a capture running ~118 wall seconds.

Told the port to change NOTHING today: ~30 rests on an unverified T, and
retiring 2 x frames does not by itself supply a replacement.
2026-09-01 17:04:23 +00:00
sylph-decoder
60b05bcd90 re: the game blends in the ENCODED space -- no gamma render target, anywhere
The Port asks whether the blend is evaluated on sRGB-encoded values or
linearised and re-encoded. It is answered by one register field I already
log, and the answer is the same on every draw of two full captures.

RB_COLOR_INFO.color_format is k_8_8_8_8 (0) on 2402/2402 splash draws and
33779/33791 draws of the boot-through-title capture; the other 12 are
k_32_FLOAT and k_16_16_FLOAT and are not colour passes. k_8_8_8_8_GAMMA (1)
appears ZERO times, and color_exp_bias is 0 everywhere so nothing stands in
for a gamma either.

The mechanism is Canary's own source, not our inference: k_8_8_8_8_GAMMA is
the ONLY colour format around which a piecewise-linear gamma<->linear
conversion is applied (spirv_shader_translator.h:510 PWLGammaToLinear /
LinearToPWLGamma, render_target_cache.h:720, dxbc_shader_translator_om.cc).
With k_8_8_8_8 there is none, so the blender operates on the stored values
as they are.

So a renderer that linearises before blending and re-encodes after is doing
a different operation -- and the difference is gamma-shaped and exactly zero
on unblended pixels, which is the divergence signature the port reports.

Also renamed my units-per-second pre-registration off the 'h4' prefix: the
Port's BLOCKED.md numbers this blend-space question H4 and two different H4s
in one corpus is how a citation goes wrong.
2026-09-01 17:01:11 +00:00
sylph-decoder
8dac5aa264 re: pre-register H4 -- is the animation clock frame-counted or time-integrated?
H3 pinned 2 units per guest FRAME. The port needs units per SECOND, and that
decomposition is only valid if the clock counts frames. If it integrates
elapsed time then units/second is the invariant and units/frame is an
artefact of whatever rate the host managed.

Evidence it is time-integrated is already in hand and is the caveat H3 had
to quote: across empty label 5376 the plate's alpha moved +82 where three
adjacent labels each moved +23. 82/23 = 3.57, not an integer number of
ticks, and a fixed per-frame increment cannot produce a fractional multiple
of itself.

Instrument: the draw logger now stamps each frame boundary with
Clock::QueryGuestTickCount() and guest_tick_frequency() -- the GUEST's
timebase, 50 MHz per emulator.cc:225, scalar 1.0 per clock.cc:37. No host
wall clock enters the calculation.

Discriminator, within one run: regress alpha step against the label's guest
duration. Flat => frame-counted. Proportional => time-integrated, and the
slope is the answer.

Predicted before the run: time-integrated with r>0.9, at 60 units per guest
second, accept 55-65, 120 and 30 excluded. Stated honestly as a CONSISTENCY
prediction -- it is what the previous capture's run average implies -- not a
blind one.

Control: the same regression on ptcopyright's ramp, a different element with
a different declared segment. Two elements must agree under the
time-integrated model and need not otherwise.
2026-09-01 16:54:13 +00:00
sylph-decoder
0565098fa2 handoff+index: H3 answered, the settle anchor, and the pad's full field set
Three rows the port is blocked on:

H3 -- 2 units per guest frame, measured on the plate's own ramp against a
pre-registration. Their 5 excluded by >2x, and the reason named: an alpha
step is not a clock rate without the element's declared T, and my own
splash-quad-timeline.txt published alpha against frame with no T column.
That file now warns at its head.

The title settle anchor is t~160, not t=118 -- it is ptcopyright, the last
build-in element and the only glyph one. Said plainly that this is the
reading under which their clock:'shared' collapses, and that a consequence
is not a counter-argument.

Told them NOT to change their 60 units/s yet: units/second is untouched by
this and two of my own captures disagree ~2.9x on frames->seconds.

The pad: sub_82457038 reads every field of XINPUT_GAMEPAD, 14/14 loads
verified against the image, plus a second keystroke-queue path. Flagged as
the superset the game can SEE, not the per-screen set, so it is used to
check a binding table and not to write one.
2026-09-01 16:50:52 +00:00
sylph-decoder
6aab30253a re: H3 answered -- 2 units per guest frame, and the settle anchor is t~160
The Port asked which of two of my measurements to believe, 55 units/s vs
~150, a factor of 2.7 off one game. Measured on the plate's own declared
ramp, against a pre-registration committed first.

PREDICTED 11 frames at 2 units/frame, 4.4 at the Port's inferred 5, +/-1.
MEASURED 10 labels, and three consecutive gap-free steps of EXACTLY 23,
which is 255*2/22 on the nose. 5 units/frame is excluded by >2x.

Why the splash read as 5: an alpha step is not a clock rate. For a linear
segment d(alpha)/frame = 255*(units/frame)/T. Splash B's quads step 34 with
a declared T=15; the plate steps 23 with a declared T=22; ONE clock, two
steps 1.5x apart. And the Port's intervals start at each quad's first
submission, which on splash A is already alpha=85 -- not the element's t
where alpha=0, and biased by a different amount per element because T
differs. My own splash-quad-timeline.txt published alpha against frame with
no T beside it, which is the column that makes the conversion possible; it
now carries the warning.

The other half: the 'title settled' anchor is ptcopyright reaching full
alpha -- the last build-in element and the ONLY glyph one, which is what a
glyph counter settling means. Calibrated on the plate's own ramp it lands at
t~168 (t~176 at a flat 2.0/label). The Port's candidates are 118 and 160, 42
units apart: this is 8-16 units from 160 and 50-58 from 118. It is 160.

Instrument fact that bounds all of it: labels with zero draws exist, ~1 in 5,
and the clock does NOT advance a fixed amount across them -- across label
5376 the plate moved +82 where three adjacent labels each moved +23. So an
empty label is a real advance, not a logger artefact, and spans that cross
one are approximate. The conclusion rests on the gap-free steps.

Also recorded: the sweep leaves never settle. They translate monotonically
through every label examined and are still moving when the plate arrives, so
'settled' can only mean the build-in elements are done.

NOT answered, and it is what the port actually needs: units per SECOND.
units/s = (units/frame) x (guest fps); this pins the first at 2 and says
nothing about the second, and 2x30 vs 2x60 differ by exactly the ~2 s the
human reported. My own title-plate-delay-measured.md's 2.13 s does not
reconcile with this capture's 20 labels for the same two anchors -- a real
~2.9x disagreement, now localised to frames->seconds rather than
units->frames. Settling it needs the guest's own frame counter, which
neither capture read.
2026-09-01 16:49:08 +00:00
sylph-decoder
19aa1a89a3 re: pre-register the H3 measurement before reading the capture
The Port asks which of two of my measurements to believe -- 55 units/s from
the plate page, ~150 from their reading of my splash timeline, a factor of
2.7 off one game.

Neither is safe and for the same reason: both convert an ALPHA STEP into a
CLOCK RATE, which needs the element's declared ramp length, because
d(alpha)/frame = 255 * (units/frame) / T. My own splash capture shows that
biting: splash B steps 34/label while splash A's logo steps 68 or 136 across
one label pair. Same boot, 2x or 4x apart. An alpha step is not a clock rate.

So measure on an element whose T is declared: ptbtn00, the plate itself,
t=214 alpha=0 -> t=236 alpha=255, T=22 units.

Predicted, before looking: 11 frames at the corpus's 2 units/frame, 4.4 at
the Port's inferred 5. Accept +/-1. Committed first so it cannot be edited
afterwards.
2026-09-01 16:40:11 +00:00
sylph-decoder
c85e5b7c56 re: record that stale-instrument was run for the logger change, and returned nothing
R1 asks for tools/stale-instrument when an instrument improves. The draw
logger improved this iteration; all eight claims that <harness> killed are
about the SCREENSHOT harness -- polling cadence, x11grab latency, the
title/plate classifier -- and none of them ever used the draw logger, so
none re-open. Written down because 'ran it, nothing changed' and 'did not
run it' are otherwise the same absence.
2026-09-01 16:21:39 +00:00
sylph-decoder
4bb67fa166 re: the splashes have NO post-process -- one pass, source-over, alpha in the vertex stream
Play-test finding 4 asked, in order: is there a pass, what is it, where do
its parameters come from, only then what curve. All four, from GPU state.

1. NO post-process pass. Over all 1 048 draws of frames 4..226 (both boot
   splashes): rt0=[tile=0 fmt=0 exp=0] on 1048/1048, pitch=1280 msaa=0 on
   1048/1048, edram_mode only ever kColorDepth or kCopy, resolve dests only
   the two alternating front buffers, and NO texture base anywhere in the
   capture equals a resolve destination. The only texture bound in the whole
   splash region is the sprite page 0x11A50000. No blur, no bloom, no fade
   quad over a resolved image, no tone curve, no resolve-and-resample.

2. What it is: per frame, a full-screen replace triangle (the clear), a
   full-screen black quad through the ordinary blend, ONE batched sprite
   draw carrying every visible element (indices 4/8/12/24), and the two
   presentation resolves.

3. Where the parameters come from: NOT the constant banks -- the splash
   pixel shaders read zero float constants, ps_c[n=0] on 1048/1048, taken
   off each shader's own float_bitmap. NOT immediates. The fade is the
   per-vertex k_8_8_8_8 colour in a vertex buffer the guest rewrites every
   frame.

4. The curve falls out of 3 and is the corpus's existing 34/frame law,
   reproduced on an independent capture. Not claimed as new.

And the composite is ORDINARY SOURCE-OVER, confirmed from the shader ucode
rather than inferred from the blend register: the register reads
ONE/ONE_MINUS_SRC_ALPHA, which looks premultiplied, and is -- because the
shader premultiplies. The two together are src*A + dst*(1-A). So the 'more
pronounced' fade is neither a blend difference nor a pass.

The likely mechanism instead: the developer splash submits SIX quads, three
logos plus three slightly-larger companions that lead them by 8 frames and
are gone 79 frames early. Two over-blended copies of the same art at
different scale is a halo, on screen only during the entry.

Refutation attempt, recorded: REFUTED.md's re-opened rest() pair states its
settling condition as 'a draw capture of the developer splash naming which
of the three glows is submitted at rest'. This is that capture. All three
companions ARE submitted in all 21 frames -- so no rule that hides one
describes this stream -- but they are NOT interchangeable: Q6 leaves the
plateau on its own -5.6/frame decay while Q4 and Q5 hold 255. The one-byte
sibling difference is drawn.

Trap recorded with the evidence: censusing the whole 600-frame log finds six
640x360 textures sampled ~330 times each, which reads exactly like a
half-resolution blur chain. They are the attract movie's chroma planes and
first appear at frame 234, after both splashes. Restricting the window is
what separates them.

Evidence: docs/re/data/splash-draw-pass-census.txt,
docs/re/data/splash-quad-timeline.txt, docs/re/data/shaders/*.ucode.frag.
Logger: canary sylpheed-re d90d14e02.
2026-09-01 16:21:17 +00:00
sylph-decoder
904cbeb99b Merge remote-tracking branch 'origin/human/r1-register-reclassification' into auto/frame-blend-draw-path 2026-09-01 16:01:45 +00:00
sylph-decoder
8008170168 Merge remote-tracking branch 'origin/main' into auto/frame-blend-draw-path 2026-09-01 16:01:42 +00:00
MechaCat02
3e60560344 register: reclassify under R1 -- name every instrument, re-open the ten our own killed
Both agents asked for this and neither could do it: the register is the file
they both read to decide what NOT to try, so two agents agreeing is not the
authority for changing it (RETRO-2026-08-31-agreed §7.1).

R1: a refutation whose instrument is one of our renderers is not a refutation,
it is "our renderer disagrees" -- 🟡, not . The motivating case was not
careless work. "Blending those sprites additively worsens every measure against
the capture" killed a real disc field for weeks, and read exactly like a
publishable negative; the renderer behind it had a stale keyframe association,
no leaf geometry and no rotation. Nothing in the entry could have told you.

All 222 entries now end with ⟨instrument⟩, read off each entry's OWN stated
evidence -- never inferred. An entry that states none gets `unrecorded`, which
is 83 of them.

Ten moved  -> 🟡, each naming what would settle it: 8 render-vs-capture,
1 our-reader, 1 harness.

Three things the pass turned up:

* The rest() question is OPEN and had been reading as settled in both
  directions -- "rest = last keyframe" was refuted by a sibling argument, and
  that refutation refuted by correlating our render against captures. Both legs
  are our renderer. Which one you believed depended on which entry you found
  first, and it decides the pose every plateau-less element is drawn at.
* A withdrawal never reached its sibling: "2 391 frames, max glyph 0" was
  withdrawn because a long-lived x11grab stream freezes and repeats a stale
  frame; the 1 674-sample negative three lines above it, same probe, was left
  standing as a reinstated measurement.
* 83 of 222 -- 37 % -- record no instrument at all. Not disputed, not safe:
  unauditable, and larger than every other group combined.

tools/stale-instrument is the --stale query the rule needs, because a colour
alone re-opens nothing: the failure was that nothing re-opened a claim when the
instrument that killed it improved. Its own --check found a real bug on the
first run -- sys.exit("text") exits 1, so three faults documented as exit 2
were reporting the same code as an ordinary miss.

R1 is now standing text in PROTOCOL.md, with R5's exception: our tool is the
right instrument for a question about our tool.
2026-09-01 17:21:17 +02:00
sylph-decoder
b0bf54b4a0 retro: record the error path that fired on success, in the file not the message
The R11 self-catch existed only in a commit message and a script comment. §5's
own rule says the file carries the finding, so it belongs in the retro.

Writing the BLOCKED.md pointer, the obvious form -- git show || { echo missing;
exit 4; } -- prints "the file is missing" for a file it has just printed in full,
because piping into head closes the pipe and git dies of SIGPIPE. An error path
that fires on success is worth no more than one that never fires.

Same family as the port's MIX default and my vertex cap, with one difference
worth keeping: both of those needed an outside observer, and this one did not,
because all four paths were exercised rather than the happy one. A script with
three failure branches has three tests and they cost a line each.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 11:17:27 +00:00
sylph-decoder
b86e82150d retro §6: route the Port's BLOCKED.md through HANDOFF, and make the pointer fail loudly
The Port's standing ask list is not in my loop brief, which BLOCKED.md itself
records as having cost three sessions. My brief does force HANDOFF.md open every
iteration and HANDOFF is mine to write, so the pointer lives there. One line in a
file I own; no brief change and no human needed.

R11 says a cross-agent pointer must fail loudly when it goes stale, because every
staleness incident here has been silent. peer_asks.sh exits 2, 3 or 4 with a
message for a missing remote, a renamed branch or a moved file, and lists the
branches it can see so the fix is obvious. A blank output is a failure, not an
empty ask list.

Its own first version was wrong in the way this retro is about. Written as
`git show ... || { echo missing; exit 4; }`, piping it into `head` closed the
pipe, git died of SIGPIPE, and the fallback printed 'the file is missing' for a
file it had just printed in full. An error path that fires on success is worth no
more than one that never fires. Existence is now checked with `cat-file -e` and
the content exec'd; all four paths were exercised before this commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 11:16:10 +00:00
sylph-decoder
4ad4ca3680 retro: the Decoder side, and the integrity check it forced
The human asked both agents for a critical retro; it reached me relayed through
sylpheed-port, and I am treating it as a message rather than as their word while
staying paused on RE iterations.

Worst failure first: I READ the refutation that mattered and routed around it
instead of auditing it. REFUTED.md killed the blend bit with our own renderer as
its instrument, and I quoted the 'a claim resting on our renderer is a claim
about our renderer' rule at the port in the same session while not applying it to
my own register.

Underneath it is the sharper one: I twice accepted render-derived labels for a
disc-side question. My 'no field separates them' negative was tested against a
partition that was wrong in six places, all six of which the oracle later called
additive.

Also recorded: the silent vertex truncation, a coverage claim written rather than
computed and wrong by four, a batching generalisation refuted by the log it was
written from, and navigation whose fix was worse than the bug.

Two additions to the port's list of shared costs: neither of us has ever given a
negative a positive control, so 'absent' and 'my search does not work' are
indistinguishable in every undecodable page I have written; and we keep
attributing a three-way residual to whichever leg we happen to be looking at.

Their eight proposals attacked one by one -- P2 sharpened into a
re-classification rather than bookkeeping, P5 pushed back on ('suppression
localises disagreement; only the oracle labels it'), the rest agreed with
amendments.

And the check the retro forced: my rival sweep covered the T8aD header and not
the 60-byte declaration entry, whose earlier hunt used the corrupted labels. Swept
properly, 16 of the 35 measured elements have no declaration entry at all and 0
declaration bits separate the other 19. The decode is not underdetermined -- run
because it could have gone the other way.

The PROTOCOL delta is presented, not applied.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 11:08:34 +00:00
sylph-decoder
d9cdfff0a8 handoff: the blend is a bit on the disc, and their three asks
Delivered: T8aD +0x04 bit 0x02 selects additive, so the port derives the blend
instead of transcribing my table -- including for screens neither of us has
captured. With why I got it wrong first: the bit was already in REFUTED.md,
killed by a comparison of two renders made while our renderer had a stale
keyframe association, no leaf geometry and no rotation.

Their asks: pteff10 IS additive on the main menu, three sessions, every frame,
and my coverage table listing it uncovered there is corrected. The sweep ramp is
four leaf keyframes on the disc, with the oracle agreeing on sign and magnitude
and a second identification from the sub-128 alpha. And kind & 0x2 is not mine
to grant -- stated what the decode supports (0 violations in 15493 entries, and
it means the declaration marks the element focusable, not that the cursor can
reach it) and left the adoption to them.

ui-blend-mode-measured.md is superseded in its classification and keeps its
measurements, which are what the decode is fitted to.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:20:50 +00:00
sylph-decoder
bac8e17a7f re: the blend mode IS on the disc -- T8aD +0x04 bit 0x02, DECODED
Reverses two of my own pages. t32-blend-mode-not-on-disc.md said the mode is not
on the disc; ui-blend-mode-measured.md classified it measured and told the port
that which field selects it was unknown. Both were honest and neither is current.

Bit 0x02 of +0x04 set means the game draws that sprite ADDITIVE
(RB_BLENDCONTROL0 = 0x01010101); clear means premultiplied alpha-over.

Fit: 35 elements over three screens, 16 set/additive and 19 clear/alpha-over,
zero errors, every label read out of the guest command stream rather than off a
render.

Control: of every bit of the first twelve header words, exactly one separates
those 35 without error. Nothing ties with it -- which is precisely what the
+0x08 = 0x8050 candidate failed.

Within-pair: ptbtn00 0x0110 alpha-over against ptbtn00f 0x0112 additive, same
screen, same bundle, adjacent draws, one bit apart. And other f variants are
bit-clear and alpha-over, so it is not 'focused variants are additive'.

Out of sample: a prediction committed at 088df91, before its capture, on a
different archive -- GP_OPTIONS entry 19, 3 additive of 16, falsified if any
other element drew additive. The game drew exactly po_menu_eff01/02/03 additive
and nothing else.

This revives a claim REFUTED.md killed. The refutation said blending those
sprites additively worsens every measure against the capture -- a claim about
our renderer, made while that renderer had a stale keyframe association, no leaf
geometry and no rotation. Recorded as a revival with its evidence;
check_refuted.py passes with 0 unmarked assertions.

Two other readings of the same bit stay refuted and are explicitly not revived:
'the name contains eff' and 'premultiplied storage'. Those were the bit's
meaning; this is its effect.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:20:12 +00:00
sylph-decoder
d694bcc53f re: the sweep ramp is DECODED -- four leaf keyframes, and the GPU agrees on sign and magnitude
The port asked for the sweep strips' vertex alpha as a function of position. It
is not a runtime curve to sample: ptloop01/ptloop02's nested leaves declare four
keyframes each, with x, alpha, rotation, scale and time.

  pteff03   loop 600u  x -639 -> 1521, alpha 255 -> 128 -> 255, rot +30, sy 600 %
  pteff03a  loop 720u  x 1721 -> -839, alpha   0 -> 128 -> 255, rot -45, sy 800 %

Checked against three sessions of GPU draws: both signs right every time, and
magnitudes within ~15 % of the declared slopes.

The independent bit worth having: across sessions the measured alpha spans
45..242, and only pteff03a declares alpha below 128 -- pteff03's ramp never
leaves [128,255]. The strip measured at 45 is the 1303-tall one, which the AABB
geometry says is pteff03a for a completely different reason. Two identifications
agreeing.

Stated as limits rather than buried: this cannot separate the two declared
slopes, which are 25 % apart against a quantisation of 6.4 px and one alpha
level over 3-4 frames; and absolute phase is unchecked because the AABB-left to
element-x mapping under rotation and pivot is not established.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:11:09 +00:00
sylph-decoder
3d8b1c2d4b tools: the sweep leaf's declared ramp, and the slope measured off the GPU
sweep_leaf_ramp dumps the nested ptloop01/ptloop02 leaf keyframes -- position,
alpha, rotation, scale and time -- which is where the ramp the port asked for
actually lives.

sweep_positions now also pools alpha against position per strip and prints the
slope, with the quantisation stated: NDC prints to two decimals, so one frame's
dx is 6.4 px and alpha is one level, and at three or four frames the two
declared slopes (+0.0814 and -0.0651) are inside that noise. It is a direction
and magnitude check, not a discrimination.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:10:35 +00:00
sylph-decoder
871e80ba85 tools: reach OPTIONS by the WRAP, not by counting presses
options_draw_capture.sh counted three DOWNs. A dropped press lands the cursor on
TUTORIAL, whose (A) starts the tutorial. My two attempts to avoid counting were
both worse: 'press until the cursor stops moving' is unreachable on a wrapping
menu, and an earlier version of it read the same row twice after a lost press
and pressed (A) on NEW GAME.

The wrap is the landmark. Press down until the row DECREASES -- the cursor is
then on item 1 whatever it started on -- and take three steps, retrying any
press that does not move the cursor, aborting rather than pressing (A) if one
never lands. Needs the row to be monotone in the item, not calibrated.

Also: 1200 s title deadline, and the emulator is killed at the end.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:06:49 +00:00
sylph-decoder
088df913b2 re: T8aD +0x04 bit 0x02 predicts the MEASURED blend, 35/35 -- and a prediction to test it
REFUTED.md kills this claim: 'T8aD +0x04 bit 0x02 selects an additive blend ->
mine, and refuted. Blending those sprites additively worsens every measure
against the capture.' That refutation rests entirely on our renderer, which the
corpus's own rule calls a hypothesis under test. The blend is now measured off
the GPU, so the claim can be tested against the oracle.

35 elements over three screens, every label an RB_BLENDCONTROL0 value read from
the command stream: 16 bit-set and additive, 19 bit-clear and alpha-over, zero
false positives, zero false negatives.

The control that makes it a decode rather than a coincidence: of every bit of
the first 12 header words, EXACTLY ONE separates those 35 elements without
error. Nothing ties with it. A perfect partition on a small sample is worthless
if half the header partitions equally well, which is the mistake +0x08 = 0x8050
was.

And the pair no confound survives: ptbtn00 = 0x0110, ptbtn00f = 0x0112 -- the
PRESS (A) plate and its own highlight, same screen, differing in exactly this
bit, drawn alpha-over and additive respectively.

Committed alongside is a PREDICTION for GP_OPTIONS, written before the capture
that tests it: a different archive, a different element set, and a MIXED
prediction -- po_menu_eff01/02/03 additive, 592 elements alpha-over. Falsified
if those three draw alpha-over or anything else draws additive. The developer
splash was considered first and rejected as a test: both its elements predict
alpha-over, so it can fail but cannot discriminate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:06:07 +00:00
sylph-decoder
6267245920 method: a truncating instrument, and an unreachable stop condition
The UI draw capture printed 8 vertices = two quads per draw, so a batched draw
dropped the rest silently. Four EXTRAS elements therefore appeared in no draw on
any screen, which reads as 'the game does not draw these' -- and the port spent
an iteration measuring them as the worst on the screen and asking about them.
When an instrument says an element never appears, check its limits before
believing the game.

And 'press down until the cursor stops moving' is not a stop condition on a
menu that WRAPS: it was unreachable, the loop only exited by exhausting its
budget, and it landed on EXTRAS because a dropped press cancelled one lap. An
earlier version of the same loop pressed (A) on NEW GAME after two identical
readings caused by a dropped press.

What held throughout is the part worth keeping: verify the state you measured,
never the actions you took.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 07:00:41 +00:00
sylph-decoder
78a29e01fa handoff: the standing ask answered, the title, the sweeps, and my wrong coverage claim
ptframe4, pteff21/22/23 and pteff10 are ADDITIVE, measured. They were missing
because Canary's vertex dump was capped at two quads, not because the game does
not draw them.

The title: everything alpha-over except the sweep strips and ptbtn00f, the PRESS
(A) plate's focused variant, whose base is not -- which is what the pulse is made
of. And ptlogo_back2 / ptlogo_back2eff are alpha-over despite having every
surface property the ptframe* elements have, so the obvious generalisation is
refuted on the one screen that could test it.

The sweeps are on screen on the main menu and move between frames, in two
sessions at different phases.

And the coverage claim they checked was wrong -- five elements, not one -- with
the correction and their 'every button' point both recorded.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:59:46 +00:00
sylph-decoder
fa887b4e5f re: EXTRAS complete -- ptframe4, pteff21/22/23 and pteff10 are all ADDITIVE
The four elements the port measured as the worst on EXTRAS, and which appeared
in no draw, were in a draw all along: the 24-index additive batch holds six
quads and Canary printed the first two. Cap raised to 64, screen re-captured,
all six named. Same draw as ptframe3, whose state was already measured -- the
one-way implication doing real work.

pteff10 is identified too, and it needed the resting SCALE: it ships as 409x144
and is drawn at 200 % x 500 % = 816x720. The matcher's 'try 1x and 2x' rule
could not name it at any scale and reported a near miss against something else,
which is a failure wearing the clothes of an answer. Candidates are now the
declaration's pivot*2 scaled by the resting keyframe as well as the texture at
1x and 2x, and the tolerance is the log's own NDC print quantisation rather than
a chosen number.

Flagged rather than buried: pteff10 measuring additive is in tension with the
port measuring it nearly exact under alpha-over. Both can be true for a dim
semi-transparent glow over a dark background, and it is the one row a rendering
check does not corroborate.

Also stated: the three full-screen alpha-over draws are NOT individually
identified -- four elements declare 1280x720 -- so the label on those rows is a
candidate, not an identification.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:59:11 +00:00
sylph-decoder
f0b4f0ad5f re: correct the blend page's reach sentence -- five elements uncovered, not one
sylpheed-port checked the coverage claim element by element and it was wrong.
The page said everything on the two screens was covered but for pteff10; on
EXTRAS, ptframe4, pteff21, pteff22 and pteff23 were also in neither the per-draw
log nor a prose row -- and they are exactly the four the port measures as the
worst elements on that screen.

The result rows were never wrong. The claim about what they covered was, and it
is the kind that reads as reassurance.

Also flagged, and fair: 'every button' is a class generalisation in the page
whose own instruction is to read it as per-element facts. It came from one
element on the main menu. Now stated as such.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:48:41 +00:00
sylph-decoder
529cf13f2a re: the TITLE's blend states, the menu replicated twice, and the sweeps are on screen
Two more emulator runs close two of the three reach limits on the blend page.

THE TITLE (entries 4 + 2 composited). Everything alpha-over except the two
rotated sweep strips and -- the finding -- ptbtn00f, the PRESS (A) plate's
focused variant, which is ADDITIVE while its own base ptbtn00 is not. That is
what the documented plate pulse is made of, and a port drawing both alpha-over
cannot reach the pulse's peak by any pacing.

And ptlogo_back2 / ptlogo_back2eff are ALPHA-OVER. They are frame-shaped, large,
dark and 94 %/87 % transparent -- every surface property the menu's ptframe* have
-- so 'frame-shaped and mostly transparent implies additive' is refuted on the
one screen that could test it.

THE MENU replicates draw for draw in two further sessions; the one-session
caveat is retired.

THE VERTEX CAP was 8 = two quads, so a batched draw reported its first two
elements and dropped the rest. Raised to 64. This is why ptframe4, pteff21,
pteff22 and pteff23 looked like elements the game never draws: EXTRAS' 24-index
additive draw holds six quads and the log printed two.

THE SWEEPS are on screen on the main menu in every captured frame, stepping
~0.03 NDC per frame in opposite directions with their vertex alpha ramping, at
different phases in two sessions. The leaf group runs on the menu. What that
does not say is how much they contribute.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:42:05 +00:00
sylph-decoder
1ce4eca706 tools: the EXTRAS walk pressed (A) on NEW GAME -- fix the stop test
'Press until the cursor stops moving' broke on its first comparison: one DOWN
was dropped, the row read the same twice, and it concluded the cursor had
stopped while sitting on the first item. It then pressed (A) on NEW GAME. No
harm this time -- neither press registered and the screen stayed put -- but that
is luck, not the design.

A stop test that cannot distinguish 'at the end' from 'the press was lost' is
the press-counting bug wearing a different hat. Now: a non-move ends the walk
only after at least one move has been observed, four consecutive dropped presses
abort, and (A) is pressed only if the cursor demonstrably moved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:40:12 +00:00
sylph-decoder
c8f488b3cd tools: separate 'submitted' from 'on screen' in a draw log
The blend map reports a quad's SIZE, which identifies an element and says nothing
about whether it is visible -- a parked quad is still a draw call. This prints
the NDC x/y range and per-vertex colour of every additive draw, per frame, so
movement between frames and overlap with the [-1,1] box are readable directly.

Written because sylpheed-port flagged exactly that conflation in my blend page:
the blend and the visibility arrived in the same artefact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:24:57 +00:00
sylph-decoder
698409fdfe tools: walk to EXTRAS by cursor movement, and size-match against several builds
menu_blend_capture.sh counted two DOWNs to reach EXTRAS, which is wrong twice
over -- EXTRAS is the fifth item, and on 2026-08-31 four DOWNs landed on OPTIONS
because one press was dropped. It now presses until the cursor stops moving,
which needs no item count and no row calibration. Its title deadline follows the
same change as title_blend_capture.sh, 1200 s not 420.

ui_blend_map.py takes a comma-separated build list, because the live title is
TWO builds composited -- 4 draws the art, 2 draws the PRESS (A) plate -- and a
one-build size table cannot name the elements of a title capture.
frame_alpha_census takes its builds from argv for the same reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:22:53 +00:00
sylph-decoder
020f456974 re: retract 'the game batches elements that share a mode' -- its own log refutes it
I wrote that yesterday in HANDOFF, the finding page and INDEX. It is false: in
one main-menu frame, draws 5, 6 and 7 are three separate additive draws --
consecutive, identical blend state, not merged.

Only the one-way implication holds: elements inside one draw share a blend
state; sharing a state does not put elements in one draw. The wrong version
would have licensed the port inferring a mode for an element nobody observed,
which is the one thing that page must not do. The ptframe4 conclusion is
unaffected -- it is in the same DRAW as ptframe3, not merely the same mode.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:16:37 +00:00
sylph-decoder
880a4d562b re: kind bit 0x2 is the FOCUSABLE flag -- decoded, 0 violations in 15493 entries
The declaration entry's kind word (+0x28) and its focus/nav index (+0x2C) are the
same fact twice: kind & 0x2 is set iff the focus index is >= 0. Checked over 24
UI paks and every parseable build in each -- 1062 focusable elements, 14431 not,
zero exceptions. The test is two-sided, so it would fail if any focusable element
lacked the bit or any non-focusable element carried it.

Consequence: kind == 0x3002 is not the test for a button. It catches 778 of 1062
and misses 284 (26.7 %) at 0x2, 0x2002, 0x3003, 0x73002, 0x73003 -- including
ptbtn00.rat on GP_TITLE's PRESS (A) plate, which is 0x73002. And 0x3000, 817
elements, looks like a button and is not focusable.

This is also the refutation attempt on sylpheed-port's kind census. Their claim
-- every decoration 0x0, every button 0x3002 -- is exactly right on the two
screens they checked, reproduced here independently, and fails one build over on
the title they have not run yet.

The other kind bits are reported as observed structure and explicitly not
claimed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:16:09 +00:00
sylph-decoder
01025ab494 tools: capture the title's blend states, and replicate the menu in a second session
Completes the reach of ui-blend-mode-measured.md, which was explicitly two
screens and one session and explicitly not the title.

Three things it does differently from menu_blend_capture.sh, each one paid for
yesterday: a 1200 s title deadline instead of 420 (the 420 fired while the game
was minutes from the settled title); the title arm is gated on the plate pulse
because build 2's PRESS (A) plate is part of what is being measured; and on
timeout it leaves the emulator up and says to attach rather than reboot.

Committed before it is run, per METHOD.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:11:50 +00:00
sylph-decoder
4718e90c16 refuted: my own 0x8050 candidate (twice), and the port's frame sharpener
0x8050 dies disc-wide (38 sprites, high byte tracks the archive) and again on
EXTRAS, where pteff21/22/23 share it with the frames.

The port's 'neither frame has a fully-opaque pixel' is true and is not the
discriminator: pteff10 has max alpha 130, no opaque pixel, and they measure it as
nearly exact. Their direction survives -- the draw path did answer -- so what is
refuted is the reason, not the conclusion.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:09:05 +00:00
sylph-decoder
2353983df8 method: a refusing instrument, and a boot that outlasts its capture script
Two traps this run paid for.

ring_row.py's ROW0/SPACING are x11grab constants. On a /sylph-home/re/shots/shot-0001.png grab of the
same live main menu the rows read 180.5/419.5/502.0 -- ROW0 is 45 px out, 0.57
of a step. The module refused rather than naming the wrong item, which is the
good failure, and is_main_menu() therefore returned False ON A REAL MAIN MENU. A
run gated on it would conclude 'not the menu' while sitting on the menu. Not
recalibrated: three rows from one session are not a calibration and other tools
share the constants; the module now says so where the numbers are.

menu_draw_capture.sh's 420 s title deadline fired, and the emulator left running
was at the settled title minutes later, took one A, and reached the menu first
try. A timeout is a measurement of the timeout. Leaving the emulator up after a
failed script rescued this run for one minute against a twenty-minute reboot.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:08:41 +00:00
sylph-decoder
0af81d7549 handoff: deliver ADDITIVE, and correct the 'any blend you choose is authored' instruction
HANDOFF gets the measured table, the two controls, the three caveats that travel
with it (src=ONE is not evidence of premultiplied textures; the frames share a
draw call so ptframe4 comes free; read it as per-element facts because the
selecting field is still unknown), and the correction to the port's own
sharpener -- 'neither frame has a fully-opaque pixel' is true and is not the
discriminator, because pteff10 has none either and renders accurately.

t32-blend-mode-not-on-disc.md keeps its negative and its reach and loses its
conclusion. INDEX gets the row.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:07:36 +00:00
sylph-decoder
e61c60029a re: the UI blend mode is MEASURED -- the frames are drawn ADDITIVE
Closes the one route t32-blend-mode-not-on-disc.md left open: the executable's
draw path. Canary's UI draw capture now logs RB_BLENDCONTROL0 per draw, and the
game was driven to the main menu and to EXTRAS with F10 at each.

The title-side UI uses two blend states and ONE pixel shader:

  0x07010701  src=ONE dst=1-SRC_ALPHA  alpha-over (premultiplied)
              ptbase, pteff05, the fade quad, ptmsg, ptmsg2, pttitle, buttons
  0x01010101  src=ONE dst=ONE          ADDITIVE
              ptframe1, ptframe2, ptframe3, pteff20, both rotated sweep strips

Two controls, both run before the result was read:

* the NDC->pixel conversion that identifies a draw by its quad size reproduces
  1134 and 1303 px for the two rotated sweep strips -- numbers measured by a
  different tool in a different session -- on BOTH screens. The tool prints
  PASS/FAIL and disclaims its own output on FAIL.
* pixel shader 0xE59B2B3DA4AA9008 is used with BOTH states, 12 draws additive
  and 18 alpha-over. ptframe1 and ptbase run the same shader; only the blend
  register differs. So this is a blend result, not a shader result.

This confirms the port's independent measurement -- it solved the composite per
pixel from two backgrounds and found additive halves alpha-over's error on both
frames -- by a route with nothing in common with it.

So the blend is no longer authored: 'any blend you choose is authored' was true
of the disc and is not true of the game. What is still unknown is which field
selects it; elements sharing a mode are batched into one draw call, so the
selection happens before the draw.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:06:30 +00:00
sylph-decoder
2c7c6c255e tools: map a Canary UI draw log's blend states onto named sprites
Identifies each draw by the pixel size of its quad -- NDC extents times the
1280x720 surface -- matched against sprite dimensions read off the disc, since
the log names no elements.

Carries its own control: build 5 draws two rotated sweep strips whose heights
were measured independently at 1134 and 1303 px in
docs/re/data/title-sweep-drawn-at-rest.txt. If the conversion does not reproduce
those, every size it prints is wrong and it says so.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 06:02:12 +00:00
sylph-decoder
6f53c2cc9f notes: refute 'any Canary change is a full reconfigure plus a full compile'
CONTAINER-NOTES said a Canary source change costs a full reconfigure against
/canary and a full compile, and told the reader to budget a session for it. It
was right about the defect -- the warm build tree at /sylph-home/re/canary-build
is configured with CMAKE_HOME_DIRECTORY=/work/xenia-canary, which does not exist
here -- and wrong about the consequence.

Symlinking /work/xenia-canary -> /canary restores the path the tree was
configured with. A one-file edit to command_processor.cc then rebuilt and
relinked xenia_canary in under 10 minutes at -j4, exit 0, no reconfigure and no
OOM. This is how the blend-state logging in the same session got built.

The symlink is untracked inside the repository, so the note also says to remove
it afterwards.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 05:50:02 +00:00
sylph-decoder
e568a3494d tools: capture the BLEND STATE of every UI draw on the main menu
Canary's CaptureUiDrawForRE now logs RB_BLENDCONTROL0, RB_COLORCONTROL and
RB_COLOR_MASK per draw, raw and decoded, alongside the shader hashes and bound
texture it already logged. This script drives the game to the main menu and arms
it there.

Unlike menu_draw_capture.sh it does NOT pass --log_ui_draws: Canary's own source
records that arming is unconditional now and that launching with the flag
correlates with the title refusing (A), 0 of 7 runs against 4 of 5 without.

Committed before it is run, per METHOD.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 05:38:31 +00:00
sylph-decoder
dad9f2761a re: no per-element field on the disc separates the four too-dark frames
The port measures four elements as rendering too dark against the capture --
ptframe1/2 on the main menu, ptframe3/4 on EXTRAS -- with the shortfall
correlating +0.77/+0.80 with the BACKGROUND and only +0.24 with the element's
own contribution. That is the signature of a blend that scales what is already
there. It asked whether the disc selects one.

Three examples, one negative, wider than the one I gave last iteration:

* frame_alpha_census -- every T8aD sprite on builds 5 and 6 by alpha. It
  REFUTES the port's own sharpener: 'neither frame has a single fully-opaque
  pixel, against ptbase's 99.1 %' is true, and pteff10 (max alpha 130, 100 %
  partial, no opaque pixel) is measured by the port as NEARLY EXACT. So being
  wholly semi-transparent is not what makes the frames special.

* frame_vs_accurate_words -- all 12 T8aD header words for both screens, plus a
  per-BIT sweep of +0x04 and +0x08. NO word and NO bit puts the four frames on
  one side and pteff10 on the other. It also kills my own remaining candidate a
  second time: +0x08 = 0x8050 is shared with pteff21/22/23 on EXTRAS.

* frame_keyframe_unknowns -- the keyframe record's fade, tint, rotation and its
  two unexplained signed words. unknown_4 and unknown_8 are ZERO on every
  keyframe of both screens, so they carry nothing here; no frame takes a value
  of any field that another element does not.

Reach: the 60-byte declaration entry, the T8aD header word-wise and bit-wise,
and the keyframe record. Four elements, two screens. Not the executable's draw
path, which is the next commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 05:37:43 +00:00
sylph-decoder
a4b65e88db handoff: answer the blend-mode ask -- not on the disc, with the reach and one refuted candidate
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 05:13:52 +00:00
sylph-decoder
abab343d2e re: a .t32 element carries no blend/alpha mode -- undecodable, with reach
Answers the port's ask about ptframe1/ptframe2, whose residual is uniquely higher on
flat pixels than edges and signed one direction -- a body-intensity difference.

Prior work covers .prm primitives and a refuted T8aD +0x04 bit; neither covers a
.t32 element. All 15 words of the 60-byte declaration entry are read: 3 are the
name, 8 constant, the rest kind, focus index, position and pivot. The frames are
kind 0, identical to every other plain sprite.

One candidate found and refuted by myself: T8aD +0x08 is the only word where both
frames agree uniquely on that screen, at 0x8050 -- but 38 sprites carry it
disc-wide, only 8 named frame, and the high byte tracks the archive. It is an
atlas/format word, not a mode.

Also records a false positive of my own test: +0x00 and +0x08 first read as
'separating the frames' because those words are the name string.

So any blend the port picks is authored. Reach: not looked at the executable's draw
path, where a mode selected in code rather than data would live.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 05:13:27 +00:00
sylph-decoder
c06654293c re: name the elements under the port's hot residual tiles -- a frame, a button and an effect
sylpheed-port mapped the menu's edge residual at 64 px tiles and handed over
coordinates without names, which is the division I proposed: the map is theirs, the
element inventory is mine.

Under the hot band at x 384..704, y 64..256 sit ptframe1.t32, ptbtn01.rat (the NEW
GAME button) and pteff12.t32, an effect element -- all three hot under BOTH
coordinate readings, so the answer does not depend on whether their tiles are in
design or capture space. ptbtn02 is hot in design space only.

So the hot region is not one element but three of different kinds overlapping, which
is consistent with their null: they looked for two families of tile and found one
continuous population, so the region has no character of its own.

This names what is there, not what is wrong -- their map already excludes local
displacement in these tiles. Also records their control limit: a +2 px displacement
reads back +0.839 because the slope saturates, so any slope they report is a floor
on the displacement and never a ceiling.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 05:02:19 +00:00
sylph-decoder
1e93b6a2e2 re: the menu's edge residual is not global misregistration and not blur
sylpheed-port ran the signed-edge discriminator I proposed but could not execute --
it needs their render beside the capture. Recorded as their measurement, with their
tool and commit.

Controls against deliberately damaged copies of their own render: a known +1 px
shift reads back as +0.938 px, a known blur as r -0.896 on the laplacian, neither
leaking into the other's channel. The menu against the capture gives -0.010 px
horizontal, -0.009 px vertical, laplacian r +0.103 -- and the weak blur term is the
opposite sign to the blur control.

So global misregistration and blur are both excluded, and of the three candidates I
named the misplaced soft element is the only one left.

Reach is the whole reach: a whole-frame fit excludes a global translation, not a
local one, since one misplaced element is a small share of 38752 edge pixels. The
next test is local and needs the residual map, which is theirs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:57:38 +00:00
sylph-decoder
1c85a9611c handoff: GP_DIALOG 2/3 are an EN/JP pair, measured on both locales
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:53:33 +00:00
sylph-decoder
93653dcb74 re: the tone-vs-geometry positive control rested on a number that cannot carry it
sylpheed-port found that my control's premise misreads their figure. The 0.06 %
counts pixels surviving -threshold 25%, differing by more than ~64 levels -- a
gross-displacement detector, blind to sub-pixel offsets and antialiasing, which are
exactly what a per-level LUT also cannot close. It says no gross displacement, not
geometry is right, and I read one as the other.

Their direct measurement, attributed and not reproduced here: after the LUT the
menu's residual is 6.94 on edge pixels against 2.20 on flat, with a known negative
leaving 0.00. So the menu carries spatial error and is not a geometry-free control.

The 32/68 result does not rest on it -- 'whatever a fitted per-level LUT cannot
close is not a per-level effect' is the method's own basis and is self-standing.
What the control shows is narrower than claimed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:53:33 +00:00
sylph-decoder
00172f5877 re: GP_DIALOG 2/3 ARE an English/Japanese pair -- measured, closing a withdrawn claim
The ja capture of DIFFICULTY is taken. EN and JP differ in 1.82 % of pixels, in four
bands and nowhere else: the heading (DIFFICULTY -> 難易度選択), a 2 px ring shift, the
BACK label (-> 戻る) and the footer. EASY/NORMAL/HARD do not appear in the differing
set -- the Japanese release leaves the three difficulty names in Latin script.

So 2/3 are a language pair, and the disc agrees quantitatively: 2.77 % of bytes
differ against 1.82 % of pixels on screen. This closes the item left open when I
withdrew 'an EN/JP pair' as a bare assertion, and it is now measured rather than
inferred from the disc's convention.

The JP screen also opens on NORMAL like the English one, and the sweep reproduced
the reset finding in Japanese.

Reach: one JP boot, one screen. It does not generalise -- GP_TITLE 4/7 is already
known to differ by more than text.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:52:19 +00:00
sylph-decoder
df0d4f058d tools: the ja DIFFICULTY run uses --reach-only, which is why the first attempt failed
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:41:41 +00:00
sylph-decoder
1e0d819108 tools: add --reach-only, so a caller that just needs the menu does not run the round trip
The ja DIFFICULTY capture failed because focus_persistence.py's round trip --
menu, B to title, A back -- did not return, leaving the game off-menu, and the
sweep that followed timed out with nothing to work with. Arriving at the menu is
the cheap part; the round trip is that probe's own experiment and is not every
caller's.

--reach-only stops once the menu is reached, and the session script passes it
through REACH_ONLY.

Committed before running.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:41:30 +00:00
sylph-decoder
f2e8d4f786 re: record the disc-side corroboration as a separate quantity, and the log-line substitution
sylpheed-port checked the JP layout from their export: the disc declares identical
button rows for EN and JP on main_menu and extras. Recorded separately rather than
merged with mine, because they are different quantities -- their rows are declared
rest positions, my 225.5 is a runtime ring row on a surface offset ~65 px from
design space. Either could have disagreed, which is what makes them independent
legs, after a week of finding legs that were not.

Neither is evidence for GP_DIALOG 2/3; both are about GP_TITLE.

Also records the mid-run substitution: I diagnosed a detector failure from a log
line showing glyph 11654 when the capture was one read away and showed the detector
working. A log line is a summary someone wrote, and reading it as the observation is
the same substitution as trusting a harness note.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:33:06 +00:00
sylph-decoder
2f5d25fb13 handoff: first JP main-menu capture -- initial focus 新規, layout identical, dialog question still open
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:31:11 +00:00
sylph-decoder
c7fdc55d12 re: JP DIFFICULTY not reached -- but the first JP main-menu capture, and initial focus is 新規
The run was launched to settle whether GP_DIALOG 2/3 are specifically EN and JP. It
did not reach DIFFICULTY: the reach probe's round trip failed at the final A, the
game sat off-menu at glyph 11654, and the sweep then timed out without pressing NEW
GAME.

Not a detector problem, which is what I assumed while watching. The JP menu detects
perfectly at glyph 320 against English's 327, both inside the 250..420 band; the
11654 is a later phase.

What it did establish: the locale took, and this is the first JP main-menu capture
in the corpus. JP initial focus is 新規 -- NEW GAME, top item, ring y 225.5, the same
item and row as six English boots. And the ring rows match English exactly, so the
JP build places its buttons where the English one does. That is language-pair
structure at the MENU, which is not the dialog pair the question is about.

Locale restored and verified at language = 1 by the trap, on a failing exit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:30:57 +00:00
sylph-decoder
6ee422b2d4 agents: the ancestor check prints nothing on success -- add the echo
sylpheed-port found this in their own §6 and it is in mine identically. I stated the
pass condition as 'exit 0' but left the command silent, so a reader running it as
written sees an empty line and cannot tell success from failure. Worse than a number
without a pass condition, because there is no number.

Now carries '; echo $?' and says why.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:12:36 +00:00
sylph-decoder
73bf90eb8d tools: a ja capture of DIFFICULTY, to settle whether GP_DIALOG 2/3 are a language pair
The byte comparison showed 2/3 differ in 2.77 % while sharing every element name --
what a language pair looks like -- but that they are ENGLISH and JAPANESE rested on
the disc's convention rather than on this screen. This captures it in ja.

Reuses submenu_focus_sweep.py with SWEEP_TARGETS=0 rather than a new probe, so the
JP capture is taken by the same navigation that produced the English one. The locale
is restored on ANY exit including a crash, and the probe never presses A inside a
submenu, so it cannot reach SELECT DATA and the guest throw.

Committed before running.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:11:47 +00:00
sylph-decoder
f427e4569d agents: give the merge-state commands their pass conditions, and run them as written
sylpheed-port's standard, applied here: a documented command nobody has executed is
the same class as a control that does not execute. Mine did execute, but they were
published without expected outputs, and a command with no pass condition is half a
check -- a reader gets a number and no way to know whether it is the right one.

Each command now carries its pass condition, the placeholders are real shell
variables rather than <branch>, and the last run's results are recorded: 330, exit
0, 0, 1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:10:19 +00:00
sylph-decoder
a9164aada3 agents: the merge-state counts go stale by construction -- say so and give the commands
sylpheed-port re-derived this the same day and read 329 for my branch where I had
written 328, because a commit landed between the measurement and the check. The
counts rise with every commit on either branch, so they are not the claim.

What does not move with them: main is an ancestor of both, the change sets touch
zero files in common, and the dry-run merge is clean. The document now says that and
carries the commands to re-derive all of it.

A number that goes stale the moment it is written, sitting in a document meant to
inform a decision, is the same shape this week has been full of -- and this one was
mine, one message after recording the class.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:08:09 +00:00
sylph-decoder
f7521df738 agents: measure the merge state instead of describing it -- both branches are clean
PROTOCOL says a human merges, and both agents have been blocked behind that while
describing it rather than measuring it.

Decoder branch is 328 ahead of main and 0 behind; port branch 257 ahead and 0
behind. main is an ancestor of both, so each is individually a fast-forward.

And they do not conflict with each other: from their merge base the two change sets
touch ZERO files in common, and git merge-tree --write-tree of the two heads exits
clean with no conflict markers. Both can be merged in either order with zero
conflicts.

Nothing was merged. merge-tree is read-only and no branch was modified -- this is a
measurement, and merging remains the human's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:06:04 +00:00
sylph-decoder
293040b61f re: verify that static records' declared cycles are visually inert in GP_TITLE
sylpheed-port turned my point -- that a static record still declares a cycle, so a
nonzero +0x08 against a largest time of 0 is a real disagreement -- into a check on
the screens they ship. Re-derived from my reader and it reproduces exactly: 65
nested records in GP_TITLE, 20 declaring a cycle with every pose at t == 0, and 0 of
those with any element carrying more than one pose.

A record whose elements each hold a single pose renders identically looped or held,
so holding them still is correct and now measured.

It includes ptbtn11/12/13, EXTRAS' buttons in both language entries, each declaring
120 units with one pose per element. Had any carried two poses, a menu button the
disc says animates would have been held still on the one submenu the port's P5 gate
walks.

Reach: GP_TITLE only; 1530 static records exist disc-wide against the 20 here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:03:32 +00:00
sylph-decoder
e2b7139273 re: settle the 49.6/92.3 split -- both are real, and the second explanation was wrong too
sylpheed-port corrected their own reconciliation and I reproduced it: 0 nested
records on this disc lack a timed keyframe. All 1530 are static -- timed, every pose
at t == 0 -- so the question is well-formed there and 'not exact' is a real answer,
not an absent one. A static record still declares a cycle length.

So the two percentages are two populations and neither corrects the other: 92.3 % of
animated records, 49.6 % of all nested records including static ones, same numerator
1643. Both need their population attached.

Two wrong explanations preceded this, both mine to carry: that my scan filtered
untimed records, which .max() returning Some(0) prevents, and then their 'questions
never asked' framing which I adopted.

The page is rewritten to the settled state rather than stacked. Nothing the port
depends on moved at any point.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:01:01 +00:00
sylph-decoder
e6a9d372f3 re: reconcile the 49.6/92.3 split -- same numerator, and my explanation of it was wrong
sylpheed-port reconciled the population gap exactly and I reproduced it: filtering
max_t > 0 gives 1781 records and 92.3 %, their figures precisely. Same numerator,
1643, both ways.

My stated explanation was wrong. I said the scan requires a timed keyframe; it does
not, because .max() returns Some(0) rather than None for records whose keyframes are
all at time 0, so 1530 records where the question has no content stayed in my
denominator and counted as failures by construction.

The conclusion is untouched -- +0x04 is 0 % under either denominator.

Records their diagnosis of why it stayed invisible: the numerator agreed to the
unit, so a shared 1643 read as agreement and neither of us looked there. And both
halves needed a qualifier neither carried -- 92.3 % is of the records where the
question is meaningful, not of nested records.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:57:21 +00:00
sylph-decoder
73c2b31e1b re: the +0x08 falsifier does not identify +0x08 -- the value is right, my argument was wrong
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
2026-08-31 03:52:09 +00:00
sylph-decoder
91767801c1 method: a record layout is only decidable at the table's boundaries
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:46:52 +00:00
sylph-decoder
2bc20ec31d tools: a layout control for structural claims -- and the obvious version does not work
sylpheed-port named a gap in their own rule: the fourth aside of mine to reach their
authored data was a STRUCTURE, not a decoration, and 'the unchecked things carry no
weight' did not cover it because a wrong field order looks like a fact. It carried
no weight only by luck. The fix belongs at my end, so this is the control that
should have existed when I published the layout.

The obvious form fails, and its failure is the useful part: checking that all
records are type-plausible passes on the SHIFTED alignments too, 69 of 70 in both
directions. A homogeneous repeated table has the same field types in sequence, so
any window starting on a field boundary type-checks and the interior carries no
information about phase.

Only the BOUNDARIES do. A shifted reading must consume a word from outside the table
at one end, and that word does not obey the field's type -- which is exactly how the
original error surfaced, record 0's handler reading as 0x10000000. Two-sided: the
published alignment survives at both edges and both shifts fail.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:46:52 +00:00
sylph-decoder
79704f360f handoff: correct the dialog record layout -- ids and names unaffected
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:43:35 +00:00
sylph-decoder
8eb9f90558 re: correct the dialog record alignment, and close the static route to the id-entry join
Two things, both from reading the image.

The record layout is {id, name_ptr, handler}, not {handler, id, name_ptr} as first
published -- the same three fields shifted by one word, so every record was credited
with the previous record's handler. Caught by a control dump: under the old
alignment record 0 had a 'handler' of 0x10000000, not a code address. ids and names
are unaffected and DLG_SELECT_DIFFICULTY is still id 2000; only the attribution
moved. Corrected histogram over 70 records: 0x821D0808 x43, 0x821D05D8 x24,
0x821CFD80 x3.

And the id-to-pak-entry join is not reachable this way. All three handlers load the
same global at 0x828E2B14 and two take addresses at 0x828E45E0/4640/467C, and every
one of those sits inside a 364 601-byte contiguous zero run -- BSS, populated only
at runtime. Controlled: the dialog table itself reads non-zero through the same
arithmetic, so the addressing is right and the data is genuinely absent.

Reach stated: this closes one route, not the question. 'Not in the image' is not
established -- 'not reachable from the dialog handlers' is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:43:25 +00:00
sylph-decoder
af94174717 method: tested the port's quality-correlated blind spot here -- it does not reproduce
Their sharpened form is that well-argued prose never cited anything, the detail
being what made it look sourced. In this corpus cited sections have a median of 2502
characters and uncited 2386 -- indistinguishable, so care does not predict citation.

The predictor is recency: 79 % cited on 2026-08-29, 96 % on 08-30, 100 % on 08-31.
Caveat recorded: the improvement coincides with this exchange, so the norm becoming
salient is part of what produced it, and it is not evidence of a durable habit.

The distinction matters because the prognoses differ. Theirs is generative -- a
quality-correlated blind spot keeps producing instances. Mine is a legacy residue,
finite and closable by a backfill. Reading their diagnosis onto my corpus would have
implied work that is not needed and missed work that is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:40:03 +00:00
sylph-decoder
2227ebdabf handoff: a delivered measurement cited nothing openable -- 84 % of such sections do
sylpheed-port found an authored value whose why said 'ask the RE agent' without
naming where the question is recorded, and their rule transfers: without a citation,
an invented value and a placeholder for a measurement read identically.

Measured the analogue. Of 57 HANDOFF sections asserting measured, undecodable,
authored or , nine cite nothing openable. Two are legend sections. One is a real
measurement -- 'B from EXTRAS DOES go black' -- delivered as an inline frame table
with no file cited, while data/fade-four-transitions.txt carried that leg and eight
others the whole time. Citation added.

Records their mechanism as the transferable part: a blind spot that correlates with
quality is invisible by construction. Their unlabelled entries were the
well-evidenced ones, because both audits measure self-declaration rather than
grounding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:36:33 +00:00
sylph-decoder
b6771fe9c0 method: liveness has a second form -- failing correctly over a fraction of the corpus
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:33:00 +00:00
sylph-decoder
976d657808 tools: the register now prints its own scope, not just its verdict
sylpheed-port found audit-kinds auditing 16 of 71 authored justifications and never
saying so -- a checker that fails correctly while describing a sixth of the corpus.
Their line is the one that generalises: 'I checked and it was fine' and 'I checked
the part that declared itself' read identically in a log, and only one of them is
what gets quoted.

Measured here: of 86 refutation-shaped bullets in REFUTED.md, 83 are in the
registered form. 97 %, which is better than their 16/71 but was equally unstated.

The three gaps are deliberate, not a bug. They quote their claim in backticks and
are bare identifiers -- +0x29d0, position = instance - 0x12c -- so registering them
would match every live mention of the same offset and train the check to be
ignored. Reported rather than forced to 100 %, for the same reason they report the
ratio instead of demanding it: forcing a counter invites mislabelling, which is
worse than the gap.

Selftest and the real run both still exit 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:33:00 +00:00
sylph-decoder
cd4156aae9 re: attempted an instrument for stale justifications in tools -- it failed
sylpheed-port has found four retractions that never reached their source and I found
one. A register cannot catch the general class, since it holds only claims already
retracted. Tried to build something that does not need the retraction.

Attempt one, flagging tools whose cited page is newer, gave 126 candidates and no
signal -- pages are appended to constantly. Attempt two, narrowing to pages that
later received a commit whose subject marks a correction, gave 43. Sampled three
and all three are false positives: each tool cites its page for one fact while the
correction concerns another.

The proxy fails structurally -- co-citation is not co-reference -- so it is not
published. Reach: 3 of 43 sampled, rate not established, only shown low enough that
the report is not worth reading.

What found all five real instances was a person reading a sentence for its own sake.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:28:05 +00:00
sylph-decoder
118c43a750 method: the register never scanned code, and their limit on it is not closed
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:22:55 +00:00
sylph-decoder
dda1bc183b tools: the refuted-claim register never scanned code, and code is where a retraction fails to land
sylpheed-port found three live stale claims in their own source, each already
retracted in their log days earlier. Their framing is the one that matters: a
correction that does not reach the artifact a consumer reads has not been made, and
a comment sits beside the thing it describes.

check_refuted.py scanned docs/ only. Running it over tools/ and crates/ for the
first time found one here too: jp_title_session.sh justified its own existence with
'a free-running clock lands somewhere else on a fresh boot' -- a claim I refuted
myself the day before, when I measured the plate-pulse gate phase-locking the
shutter to 1.6 % of the sweep traverse. The script's stated rationale rested on a
premise I had already killed.

Fixed the file with the correction in place, including what it means for what that
script actually measures: a second capture through the same gate is a second sample
at nearly the same animation phase, so its RMSE 0.32 is a phase-locked lower bound.

Taught the register to scan code behind --code, excluding crates/sylpheed-viewer,
which is the human's tool. Controlled three ways: a planted code revival exits 1
with --code, exits 0 without it -- which is the proof the gap was real -- and 0
again once removed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:22:55 +00:00
sylph-decoder
f1f23fc74c method: nothing checks the prose a tool prints or documents beside its numbers
sylpheed-port found a harness note asserting an unestablished fact under a
load-bearing number. Swept my printed output: 38 lines assert a screen or game fact
and the assertive ones are computed in the same run, so no instance there -- though
the sweep is keyword-based and the criterion is a judgement.

The class is real on the larger surface, and I have a known instance: ring_row.py
documented its calibration as 49.5 + 1.060*design_y, wrong because it was fitted
against menu_focus.py's approximate rows rather than the disc's. It sat in the file
underpinning every focus finding and was found by accident.

Tool docstrings carry calibrations, thresholds and claims about the game, nothing
verifies any of it, and unlike a why in an authored file there is no convention
demanding a citation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:15:59 +00:00
sylph-decoder
6f76512ecb handoff: 0/1 is a duplicate, 2/3 is a structural pair -- restoring a withdrawal at lower strength
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:13:12 +00:00
sylph-decoder
7626f9e646 re: GP_DIALOG 0/1 is a byte-identical duplicate; 2/3 is a structural pair
The two adjacent pairs with identical element sets split. 0/1 are the same 59 810
bytes stored twice -- a duplicate, not a language pair. 2/3, the DIFFICULTY build,
differ in size and in 2.77 % of bytes from offset 0x1BB while sharing every element
name, which is what a language pair looks like.

Control: entries 10/11, known to be two different dialogs, differ in 54.90 % of the
common prefix, so the comparator separates unrelated dialogs.

Supported, not proven, with the untested step named: I have not captured DIFFICULTY
in ja. That the two are ENGLISH and JAPANESE rests on the disc's convention, not on
a capture of this screen. This partially restores a claim I withdrew, at lower
strength than the original phrasing.

Also records a refutation attempt on the port's BGM_103 exclusion: it survives and
is tighter than they stated -- of 32 census rows, exactly one bank carries EITHER
wave size, not merely both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:12:59 +00:00
sylph-decoder
dc98fd1b2f handoff: 'three independent routes' overstated -- corrected to the reasoning, not the count
sylpheed-port found the tell for decorative legs -- claims announcing their own leg
count -- and their audio.json case had two of three legs turn out to be one
disc-to-runtime comparison. Ran it here and my DIFFICULTY delivery has the same
shape.

The image leg says DIFFICULTY is a dialog and names no entry. The disc and oracle
legs are one compound argument, since the capture is compared against the disc's
rows. What makes that discriminating is the exclusion scan -- zero rival builds
disc-wide -- which is exactly what the word 'three' was taking credit for.

Corrected in place to state the reasoning rather than the count. The conclusion is
unchanged; the evidence is two arguments, not three.

Reach: 1 of 272 leg-count claims audited. One verified case is not a verified set.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:10:00 +00:00
sylph-decoder
e76fc0d9fb re: withdraw the sprite-count leg -- it does not reproduce, and the conclusion never needed it
sylpheed-port re-ran my closing of the 37 and one of its two legs fails. I wrote
that sprite counts differ between adjacent stage-title dialogs; 12/13 is equal,
thirteen each, and it is visible in my own printed output which I generalised from
the 10/11 example beside it. Our absolute numbers also disagreed because we counted
different things and I did not say which I meant.

The conclusion is untouched -- the stage numbers settle it alone. The shape is the
point: the leg carrying no weight is the one that went unchecked, which is the
EN/JP pair failure one step out, committed while writing up that very failure.

Also records that a conclusion with two supports reads as better evidenced than one
with a single support, so a decorative support makes the appearance of redundancy
itself misleading.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:06:39 +00:00
sylph-decoder
9125783cff re: the 37 are refuted too -- adjacent GP_DIALOG entries carry different STAGES
Both agents left the language reading standing for the 37 pairs that differ without
a button-count mismatch, and both observed that nothing rewarded closing it. Two
scans closed it, against my own reading.

All 39 equal-button-count pairs share button names and rows exactly, which does not
settle it -- two dialogs sharing a button template look identical by that test. What
differs does settle it: pzstg10 against pzstg02, pzstg11 against pzstg03, pzstg12
against pzstg13. These are the DLG_STAGE_TITLE01..16 dialogs and an adjacent pair
carries two different stages, with different sprite counts, which is a different
amount of text rather than a translation of the same text.

So the whole 63 is explained by one fact -- adjacent entries are unrelated dialogs
-- with no residue. The 2 identical pairs remain unexplained but are no longer
anomalous against a hypothesis, because the hypothesis is gone.

Recorded about process rather than the disc: a bound nobody is incentivised to test
is exactly where a convenient claim survives, and the next reader cannot tell
whether a bound was respected or merely never revisited.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:04:40 +00:00
sylph-decoder
ee3be08750 re: an unchecked aside said a .prm is 'skipped as everywhere else' -- it is the black backdrop
sylpheed-port named the mechanism after copying an unchecked aside of mine into an
authored file twice, inside the same why that carefully said their re-derivation
does not name the screen. Scrutiny goes where the weight is, so a claim carrying no
weight attracts none, and then it reads as measured.

Swept this corpus for the shape and found one in the port's own domain.
ui-composable-bundles.md said a .prm element 'has no sprite and is skipped as
everywhere else'. True of our compositor, false of the game: the element is
palogo_eff0.prm, which ui-forced-backdrop.md decodes as the full-screen opaque
black backdrop, forced first, measured off the running game. The page's
load-bearing draw order was pinned by a disc test and checked; the aside was not.

The generalising phrase is the tell -- 'as everywhere else' is what turns a
statement about our tooling into one about the disc.

Also records that a refutation is exactly as wide as the job a claim was offered
for: 37 of the 63 pairs differ without a button-count mismatch, where my reading is
unsupported rather than refuted, and they wrote the bound when the wider version
was available.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 03:00:41 +00:00
sylph-decoder
653491a91f re: my language-sprite reading is refuted, and 'EN/JP pair' is withdrawn from the DIFFICULTY row
sylpheed-port refuted the untested reading I recorded yesterday with a count, and I
reproduced it: 26 of 65 adjacent GP_DIALOG pairs differ in BUTTON COUNT, which two
languages of one dialog cannot. The names agree once read rather than counted --
ranking_NEXT against ranking_JUMP, py_ranking against pzeff, pzstg10 against
pzstg02.

So adjacent entries are unrelated dialogs, the 63 never needed the language
reading, the 2 matching pairs need no special account, and the 140:70 ratio is a
counting coincidence -- the same fact my halves-pairing zero was showing from the
other side.

Preserving their caution: this does not establish that 0/1 and 2/3 ARE language
pairs. Identical element sets is equally consistent with a duplicate, and for the
37 pairs differing without a button-count mismatch the language reading is
unsupported rather than refuted.

Withdraws a delivered claim: I called entries 2/3 'an EN/JP pair' in HANDOFF. The
DIFFICULTY identification does not rest on it -- unique geometry plus the capture
does -- but it was stated as fact and was not one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:57:47 +00:00
sylph-decoder
2dba970c29 re: the dialog id to pak-entry join is not positional -- hypothesis refuted
GP_DIALOG has exactly 140 entries against the table's 70 records, a 2:1 ratio that
would make the unbound join an ordering question. It does not hold: adjacent
pairing gives identical element-name sets on 2 of 65 pairs, halves pairing on 0.
GP_TITLE's language pairs share element sets exactly, so identical sets are the
signature there; in GP_DIALOG almost nothing matches.

Residual and unexplained: the only two adjacent pairs that DO match are entries 0/1
and 2/3, and 2/3 is the DIFFICULTY build.

A reading I am not asserting: dialog text may be baked into language-specific
sprites, which would explain the 63 by construction but leaves the 2 needing their
own explanation. Not tested.

The join stays unbound; positional ordering is now ruled out, which narrows where
to look next.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:54:46 +00:00
sylph-decoder
2d42ad2581 handoff: the dialog table is decoded and the DIFFICULTY reach is now bounded
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:50:47 +00:00
sylph-decoder
06f9af75ea re: decode the dialog table -- 70/70 records, DLG_SELECT_DIFFICULTY is id 2000
Chasing the reach I recorded this morning found the binding it said was missing.
Every DLG_ string in the image is pointed at by one aligned word at a 12-byte
stride: {u32 handler, u32 id, u32 name_ptr}, spanning 0x820A0A2C..0x820A0D68 with
three distinct handlers. Complete -- 70 names, 70 records, none unmatched -- and the
ids are banded and monotonic with a single gap at 24. Read from the image directly.

Refutation attempt on the shared reach, which both agents had recorded: 'another
four-button dialog with the same rows would be indistinguishable'. Scanned every
build in every pak for four buttons within 6 px of 259/329/399/469. Control found
both incumbents; zero rivals exist anywhere on the disc. So the geometric
identification is unique disc-wide, which is stronger than what either of us
claimed.

Still unbound: id 2000 to a pak entry. The tie remains uniqueness plus the oracle
capture, not a pointer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:50:35 +00:00
sylph-decoder
44c17d38d1 handoff: DIFFICULTY is a dialog, and it loosens Q6's count-match
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:44:55 +00:00
sylph-decoder
6ba003219b re: DIFFICULTY is a dialog -- DLG_SELECT_DIFFICULTY, GP_DIALOG entries 2/3
Closes a negative of mine whose failed assumption I had named: I searched for an
8-record btn-named build in an archive of its own, assuming DIFFICULTY's four items
pair with f variants the way GP_TITLE's screens do. It has its own prefix and is
not a GamePart screen at all.

Three independent routes agree. The image lists DLG_SELECT_DIFFICULTY among the
DLG_* dialog names at 0x820A41BB, and GP_DIFFICULTY appears zero times. GP_DIALOG
entries 2/3 are the only builds there with pcbtn00..03 -- four buttons at design
rows 259/329/399/469, spacing 70, an EN/JP pair. And my capture of the running
screen puts its four rows within 4 px of those, with spacing 70.5/69.5/70.0 against
the disc's 70/70/70.

Reach stated: the entries are identified by button count and geometry, not by a
binding from the DLG_ name to a pak entry. No such binding was found.

Also notes the consequence for Q6's count-match: NEW GAME opens a DIALOG from an
external archive, which still matches the count but is not the same category as
OPTIONS or TUTORIAL opening a GamePart.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:44:39 +00:00
sylph-decoder
2922217764 method: cross-agent registers can flag live claims, and relaying dead claims instantiates them
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:40:01 +00:00
sylph-decoder
cceec457e4 re: the relay loop is measured, and a cross-convention collision found
Re-ran the peer cross-scan with their known-positive assertion and my earlier count
was wrong. Third phantom reader in one session: a second parse of the same file in
the same minute returned a clean table with total 0, because their register rows
are bare phrases and that parse searched each row for a quoted string. My first
parse worked only by falling back to the whole line.

Real count: 11 occurrences of their 12 registered claims in my corpus. Three of
them are in the file I wrote to report on their claims -- so I produced the relay
loop they described while documenting it, and the effect is now measured rather
than asserted.

New: a cross-convention collision. '1 of 3 streams' is a dead claim in their
register and a live warning in mine -- both my occurrences read that the warning
STANDS. Not a revival; two corpora using the same words for different propositions.
That is the strongest argument yet for keeping cross-agent checks advisory, and it
is an instance rather than a worry.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:39:46 +00:00
sylph-decoder
dc5416fb9a re: cross-scan the peer register -- none of their refuted claims is live in my corpus
They asked in the right form after their own 'latent, not active' turned out to be
a stale-copy artefact. My version: zero of my registered claims appear in their
files, from my tree AND from their branch head, controlled with a live probe
because a zero from a broken reader looks identical.

Then the part they left to me. My first reader of their register was broken and
returned a false zero: I regexed quoted strings out of their script and got 63
phantom phrases. The register is a heredoc of 12 rows. Parsing it properly finds 3
of their claims in my files, across 4 locations -- one of which is my stale copy of
their own BLOCKED.md and not mine to judge.

None is a live revival. Every one sits on a page whose subject is the corrections
themselves, which is what they predicted without asserting.

Their restraint is the transferable part: their first fix counted the six as
failures, applying their [refuted] convention to a corpus that marks corrections
its own way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:35:33 +00:00
sylph-decoder
f88839dcde method: a checker inherits the staleness of every file it scans
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:30:30 +00:00
sylph-decoder
1182c3768d tools: check_refuted now says when it judged a peer-owned file from a stale copy
It scans all of docs/, which includes files sylpheed-port authors, and my copies of
those come from main -- six of seven are days behind their branch head and one I do
not have at all. So a verdict here about one of their files is a verdict about my
stale copy.

The direction that matters is the false positive, and it is not hypothetical: on
2026-08-31 I did it by hand, telling them a BLOCKED.md row was wrong when it had
been struck for days, with their live file one git show away in a ref already
fetched here.

Reported, not excluded. Skipping their files silently would hide the exposure, and
being behind a peer's topic branch is the normal state -- making it an error would
be scenery within a day, which is sylpheed-port's call on their own peer-head tool
and the right one.

Zero hits land in those files today, so this is latent rather than active. Selftest
and the real run both still exit 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:30:17 +00:00
sylph-decoder
8321e43622 handoff: withdraw the instruction to check a BLOCKED row that was already corrected
The finding stands -- my own page said the menu's bank was undecodable from the disc
while decoding it three ways lower down. The instruction did not: I told the port to
check a row that had been struck for days, because I read my checkout's 2026-08-29
copy of their file instead of their branch head.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:26:39 +00:00
sylph-decoder
e5ac73a4a7 method: read the peer's branch, not your checkout's stale copy of their file
I reported a defect in the port's BLOCKED.md that had been struck and corrected for
days, and whose correction already contained the diagnosis I thought I had found
independently. I was reading my working tree's copy, last touched 2026-08-29 and
234 commits behind, while their live file sits on auto/port-p6-audio -- a ref
already fetched in this checkout and readable with one git show.

The exact mirror of the gap I had been reporting about them. They read main's stale
HANDOFF while mine was on my branch; I diagnosed that as needing a human merge, then
made the same error in the other direction with the fix one command away. They had
already been reading my branch directly, citing my commits by sha. I had not been
reading theirs.

So the shared-state problem is two gaps, not one, and only the second needs a merge:
what a peer HOLDS is readable now from any topic branch; what a peer must be TOLD
still needs main.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:26:26 +00:00
sylph-decoder
12dd3a1138 handoff: correct 'the menu's bank is not on the disc' -- it is decoded, and the phrasing came from me
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:22:41 +00:00
sylph-decoder
5451e00806 re: bgm-two-stems.md said the menu's bank is undecodable from the disc, and its own page decodes it
The Status line and the section heading both read 'undecodable from the disc' while
a later section of the same page decodes it three ways, one of them static from the
executable -- GamePart_Title's handler does li r5, 1103. A reader who stops at the
top concludes the opposite of what the page establishes.

The surviving content is the reason the CUE TABLE cannot answer it: 32 BGM cues
named by number with no screen name, with SOUNDS, FILES and the bank headers all
searched. A negative about one search location, written as a negative about the
disc -- the same method-versus-subject error as the SE-audio heading, in the first
line a reader sees.

It propagated: the port's BLOCKED.md carries 'which BGM the menu plays -- not on
the disc' in the same words.

Found by applying sylpheed-port's 'get the category right' discipline to my own
noisy impossibility sweep, after measuring what the false positives actually were
rather than assuming they were infrastructural.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:22:28 +00:00
sylph-decoder
896491e28c method: a real failure with a fabricated reason -- three instances now
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:18:36 +00:00
sylph-decoder
87aa47fe10 handoff: Q6's count-match has disc support for its structure, and is still not a decode
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:18:21 +00:00
sylph-decoder
3f46b9cf16 re: GP_TITLE holds exactly three button screens, and EXTRAS is the only internal destination
Serves Q6's open question. boot-config-and-gamepart-registry.md records a
count-match for the title part's event numbers -- four menu items load an external
archive, EXTRAS stays inside GP_TITLE -- explicitly as an observation rather than a
decode. Half of it is disc-checkable and now has support.

Every button record in all 16 GP_TITLE entries: ptbtn00 (the plate), ptbtn01..05
(main menu), ptbtn11..13 (EXTRAS). No fourth button screen, so no DIFFICULTY build,
and DIFFICULTY is what NEW GAME opens. The other four destinations have their own
paks -- GP_OPTIONS, GP_SAVE_LOAD, GP_TUTORIAL -- while EXTRAS' two children are
GP_MISSION_SELECT and GP_MOVIE_THEATER, so EXTRAS is internal and its children are
not.

Still NOT a decode of the event numbers: the shape the count-match asserts is real
on the disc, but nothing shows a given event is a given row.

Negative recorded with its reach: DIFFICULTY's build is not located. I searched for
an 8-button-record build on the assumption its four items pair with f variants, as
GP_TITLE's screens do. They may not, so the negative is narrower than 'not found'.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:18:06 +00:00
sylph-decoder
53572029e6 method: ask whether the measurement is live, not only whether it agrees
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:00:21 +00:00
sylph-decoder
1dfcdd81ee tools: ring_row gets a self-test, which found that a TITLE frame reads as NEW GAME
sylpheed-port closed their last harness gap on a control that never asked whether
the measurement was LIVE -- an empty band list made identity and the real pair both
pass. Applying that to ring_row.py, which underpins every focus finding I have made
and had no self-test at all.

It found a real defect immediately: main_menu_item(ring_row(f)) is not None was
being used as a main-menu test, and on a TITLE frame the gutter carries a bright
cluster at y=243, inside tolerance of row 0, so the title reads as NEW GAME. Glyph
714 against the menu's 327 separates them cleanly; the ring row alone does not.

It never misfired in the sweeps, because B from a submenu goes to the menu rather
than the title -- the test was simply weaker than it was being trusted to be. Added
is_main_menu(), which requires the row AND the glyph signature, and the sweep's two
menu tests now use it.

The self-test asserts the defect it guards, and includes a liveness case: a blanked
frame must return None rather than a number.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 02:00:07 +00:00
sylph-decoder
b4ed61373e handoff: focus does not survive a reboot, and the ptbtn11 refutation attempt survives
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:51:18 +00:00
sylph-decoder
1bf619460a re: menu focus does not survive a reboot -- six fresh boots, three following a session that ended elsewhere
No new boot was spent: six runs had already captured the first menu entry of a
fresh boot, and all six read NEW GAME. Three of them follow a session that ended
with the cursor on EXTRAS or OPTIONS, which is what makes it a test of persistence
rather than a repeated observation.

Reach stated rather than implied: every session ends with the emulator KILLED, so a
game that writes menu state on a clean shutdown would never get the chance. This
measures 'does not survive a killed session'.

Refutation attempt on the port's extras/initial_focus: ptbtn11 -- it SURVIVES.
ptbtn11 is the top button on the EXTRAS build, with the main menu as a control
where ptbtn01 is top and is known to be NEW GAME.

Incidentally corrects ring_row.py's stated calibration. It cited capture_y = 49.5 +
1.060*design_y, fitted against menu_focus.py's row centres, which are NOT the
disc's button rows -- the disc says 162/242/322/401/482, spacing 80, and
menu_focus.py drifts up to 17 px against them. Re-fitted: 64.82 + 0.9919*design_y,
residuals under 0.7 px. No item assignment changes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:51:03 +00:00
sylph-decoder
924f16c2a1 re: settled -- a submenu resets to the item it OPENS on, not to its top item
DIFFICULTY is the screen that separates the readings: it opens on NORMAL, second of
EASY/NORMAL/HARD/BACK. Reproduced on a fresh boot rather than inherited from the
2026-08-29 capture. After one confirmed DOWN to HARD, B out and A back in, it
returns to NORMAL -- in-cursor 1.0 from opened against 93.9 from where left.

So reset targets a per-screen opening default that need not be the first item. The
other four submenus could not settle it because on each of them the opening item IS
the first, so both readings predict the same observation.

sylpheed-port's refusal to promote 4/4 to a rule was right on the evidence: a
generalisation from those four would have got this fifth screen wrong.

The probe never presses A inside a submenu, so it cannot reach SELECT DATA and the
guest throw at PC 0x82307128 -- recorded in the tool's source.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:47:29 +00:00
sylph-decoder
20d4694378 tools: let the submenu sweep target NEW GAME, for the DIFFICULTY reset question
DIFFICULTY opens on NORMAL, the second of four, so it is the screen that separates
'resets to the named item' from 'resets to the top item' -- the question
sylpheed-port has had open for several iterations.

The probe is safe on this path without modification: it presses A to enter, one
DOWN, then B to leave, and never presses A inside a submenu, so it cannot reach
SELECT DATA and the guest throw at PC 0x82307128. Noted in the source so nobody
adds one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:38:26 +00:00
sylph-decoder
40ae9adb09 re: DIFFICULTY opens on NORMAL -- the non-first opening item, already in the corpus
sylpheed-port has been asking for a submenu whose opening item is not its first,
because that separates 'resets to the named item' from 'resets to the top item'. I
told them none of the screens I measured was one, while line 248 of the page I was
editing records DIFFICULTY as opening focused on NORMAL, the second of four.

Provenance is clean: the run drove NEW GAME with no d-pad, the screen sat unchanged
for 90 s, and s00a-drive-blocked-by-focus.md confirms the step matched the committed
capture at r=+0.999.

So 'a screen opens on its first item' is refuted as a general description, and the
distinction is real in this game rather than academic -- on EXTRAS, TUTORIAL and
OPTIONS the two readings coincide only by accident.

It does not settle their question, which is about reset rather than opening. That
needs one experiment on DIFFICULTY, going back rather than forward, since its
forward path crashes the guest.

The failure is mine: I searched among the screens I was measuring and never grepped
the page I was editing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:35:26 +00:00
sylph-decoder
e0f9e2b6d8 tools: assert the scan boundary in check_refuted's self-test
sylpheed-port's point: a control that runs where the tool does not look proves
nothing about the tool. Case 2 plants a revival INSIDE the scanned root and demands
exit 1; a new case plants the same text OUTSIDE it and demands exit 0. The pair
asserts the scan boundary is real rather than leaving it to be reasoned about --
which is how I had it, correctly but only in my head.

Verified first by hand: identical plant text gives exit 1 inside the root and 0
outside it. Five cases now, all passing, and the real corpus still runs clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:24:51 +00:00
sylph-decoder
5149c7be5d re: all four measured submenus reset -- the main menu is the only screen that remembers
LOAD GAME, TUTORIAL and OPTIONS all reset on re-entry, joining EXTRAS. With the
main menu persisting, the rule is four of four submenus resetting and one
exception -- the opposite of what a single screen had suggested.

Fourth attempt, and every control in it is a previous failure: the decision uses
the cursor's own region so no per-screen geometry is assumed (sweep 1 read the main
menu's gutter on screens whose cursors are elsewhere); the back-on-the-menu test is
the narrow ring row (sweep 2 died when a crash dialog defeated whole-frame
comparison); absolute row checks after every press (a constant offset passes a
differential control); and a two-sided self-test that constructs both verdicts,
which had already caught a rule I broke myself.

Screens confirmed by eye and committed as evidence, because an earlier run was
fooled about which screen it was on. LOAD GAME's 21.6 is explained by its list
scrolling rather than moving a ring.

Still not separated: resets-to-named-item vs resets-to-top-item. None of these
three has an opening item that is not its first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:23:28 +00:00
sylph-decoder
e4460b0eff tools: let the submenu sweep's self-test be checked without starting a run
Verifying it previously meant launching the script, which then waits ~150 s for a
main menu and opens x11grab captures -- so the question "did the self-test pass?"
could not be answered without disturbing whatever else was using the display. That
is how a check-the-tool step turned into competing load during a measurement once
already.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:14:53 +00:00
sylph-decoder
459bf421b7 method: a harness self-test, and the empty-register hole it found on its first run
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:12:09 +00:00
sylph-decoder
6509927000 tools: check_refuted gets a harness self-test, which found it could not fail on an empty register
sylpheed-port closed this gap first: their controls asserted failure-on-perturbation
but nothing asserted that a BROKEN harness reports broken. Their stub is a check
that cannot fail; the equivalent here is a register that loaded no claims, which
reported clean forever.

The self-test drives the REAL machinery over synthetic corpora as subprocesses and
reads actual exit codes -- their first version reasoned about what the machinery
would do instead of running it, which is the error this whole thread is about
committed inside the tool built to prevent it.

Four cases, all passing: clean corpus 0, verbatim revival 1, marked revival 0, and
empty register 2. The fourth was a real hole, not a modelled one: the tool now
refuses instead of passing when it parses no claims. Exit convention is theirs --
0 fine, 1 a real check failed, 2 the harness is broken.

Also confirms the real corpus still runs clean at exit 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:12:09 +00:00
sylph-decoder
5bdc4c0104 method: commit the tool before running it, and never edit it mid-run
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:01:31 +00:00
sylph-decoder
6d708cd2ed re: third submenu sweep void -- the self-test caught a fault I introduced myself
The rework was sound and controlled. The run died because I edited and
deliberately broke the sweep script while its own run was in flight, and the sweep
read the script at its start, which fell in that window.

The self-test refused to run: constructed PERSISTS came back RESETS. Without it the
sweep would have reported RESETS for all three screens -- confident, uniform and
fabricated. First save, on the day it was written.

Three further self-inflicted faults recorded: a competing x11grab during a
measurement (the concurrency confound the port warned of), a pkill -f that can kill
the running sweep's own capture, and a restore that sat as the last line of a
timed-out command so it never ran. The process fix is to commit the tool before
running it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:01:19 +00:00
sylph-decoder
202cf13f29 tools: submenu sweep gets a cursor-region rule and a two-sided self-test
Sweep 1 failed because ring_row scans the MAIN MENU's gutter and these screens put
their cursors elsewhere; sweep 2 failed because a whole-frame identity test cannot
match once a crash dialog covers the centre. This rework fixes both: the decision
uses the region that CHANGED when the cursor moved, so no per-screen geometry is
assumed, and the back-on-the-menu test is the narrow ring row, which is what kept
reading correctly under the dialog.

The self-test is sylpheed-port's sharpened rule -- a control must construct the
failure it is named after. Mine was one-sided: I checked only that the rule reports
RESETS on a known-RESETS triple, so a rule biased entirely to RESETS would have
passed. It now constructs both verdicts from the same frames and exits 3 if either
is wrong.

Committed BEFORE running, which is the process fix: the previous run aborted
because I was editing and deliberately breaking this file while its own run was in
flight, and the sweep read the broken version.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 01:00:56 +00:00
sylph-decoder
7300428416 method: backticks in a double-quoted commit message are command substitution
Second instance across two agents, and mine landed in the message describing the
defect class itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:40:55 +00:00
sylph-decoder
e21f05a6be correction: the previous commit message lost three words to shell substitution
Commit b/HEAD~1's body reads "a  swallowed the verdict". It should read "a
`return 0` swallowed the band verdict" -- the backticked text was command
substitution inside a double-quoted -m, so bash executed it and spliced in the
empty result, and "band" went with it.

This is the second instance across two agents: sylpheed-port reported the same
thing days ago and left it uncorrected because it was pushed. The property that
makes it dangerous is theirs to name -- a dropped noun leaves grammar intact, so
the sentence still parses and nothing looks wrong.

Recorded as an empty commit rather than a rewrite, because the history is shared
and rewriting it is forbidden.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:40:55 +00:00
sylph-decoder
8ecb6e8494 method: a checker that cannot fail, and the loud failure mode hiding the quiet one
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:40:25 +00:00
sylph-decoder
96c1fa497d tools: both of my checkers exited 0 no matter what -- neither could fail
sylpheed-port found an asserting step in their suite that could not fail: a
 swallowed the verdict. Tested the same thing here and both of mine had
it. check_refuted.py found a PLANTED unmarked revival, printed it, and exited 0.
impossibility_scope.py printed 'CONTROL FAILED' and exited 0 -- in a tool written
today, one message after they described the shape.

Now: unmarked assertions exit 1; a failed control exits 2. Suppressed mentions do
not fail, since they are unverified rather than wrong and failing on them would put
the clean state out of reach.

Controlled in both directions -- clean 0, planted revival 1, control passing 0,
control deliberately broken 2.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:40:24 +00:00
sylph-decoder
5ae715a6ce re: refutation attempt on the band-energy check -- survives, with the margin quantified
A 1 s misalignment costs 0.16 dB against their 0.66 dB pass band, so the
alignment-free claim holds. Two caveats measured: at 10 s it reaches 1.00 dB, since
a fixed window covers different material once the shift is large; and the
separation floor is material-dependent -- two unrelated music banks give 5.28 dB
where an unrelated movie gave them 19-20, so the threshold's margin depends on the
known-negative chosen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:14:38 +00:00
sylph-decoder
a86d90408f re: sweep for negatives stated as world-properties -- the tool failed its control twice first
The mission's third classification is 'undecodable, with reach', and a negative
written about the subject when it is about the method is the failure that put 'an
individual SE's audio is not extractable yet' at the head of a page whose own later
section located the waves.

The tool failed its control -- the one known instance -- twice. First the pattern
required a sentence-ending period, and headings do not end in periods, so it matched
nothing in any heading and a clean report would have been vacuous. Then the scoring
hid it, because 'yet' was in my list of scope words. It is not one: 'yet' and 'so
far' are temporal hedges naming no instrument, no search and no place looked, which
is exactly what made that heading read as bounded.

With the control passing, the two amplifier files are clean: every INDEX and HANDOFF
hit read, all legitimate. 130 unscoped candidates remain unread corpus-wide, and the
regex has a high false-positive rate -- recorded as reach, not as a clean bill.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:14:23 +00:00
sylph-decoder
e445abbdb7 method: ask whether an instrument returns zero for no difference
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:09:56 +00:00
sylph-decoder
c7d8b2e21c re: run the identity control on the coherence estimator -- it is exact, and the refutation strengthens
sylpheed-port disqualified a difference instrument of their own and named the rule:
before asking whether an instrument can measure a difference, ask whether it
returns zero for no difference. Mine had never had that test -- its positive
control was a filtered copy at 0.94, which I had taken as the ceiling.

Identity reads 1.0000 in every band, and a linear filter with NO delay also reads
1.0000. The 0.94 was entirely the 12 ms delay's windowing cost. So the ceiling for
a filtered copy is 1.0 and the measured 0.027 midrange is further from it than the
original control implied.

It also adds an argument the first pass missed: a delay depresses coherence
uniformly (0.9288..0.9380 flat), while the measurement is 0.027 midrange against
0.83 at HF. The shape is inconsistent with a delayed filtered copy too, which was
the remaining route by which a rear pair could have produced it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 00:09:43 +00:00
sylph-decoder
fb6291ffb8 method: marking a live row stale; and a quoted heading duplicates an anchor
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:58:14 +00:00
sylph-decoder
549f5b520b re: correct my own report -- the port's A-skips row was NOT stale
I told them two BLOCKED rows were stale. One was. Their skip row reads '(a)
ANSWERED, (b) still open' and cites Q9; (b) is a different question and the 🟡
carries it correctly. I read an emoji and inferred a status, which is the same
error as leaving a stale row live -- and the error this audit is about. They
pushed back rather than accepting it, which was right.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:58:12 +00:00
sylph-decoder
7067b2423b handoff: stop the forward markers duplicating headings -- a duplicate disarmed a check
sylpheed-port's contract-check perturbs the FIRST occurrence of an anchor. My
supersession marker quoted the 'EXTRAS resets, the main menu persists' heading
verbatim, so the sentence appeared twice and the control read the untouched
duplicate and passed a wrong contract.

The marker existed because they had told me a grep lands mid-document, so the fix
for one navigation problem created another. Pointers now name their targets by date
and subject instead of reproducing the heading.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:57:44 +00:00
sylph-decoder
24ad81e75c method: a stale index nearly cost a run, and the exact-match register could not see it
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:44:37 +00:00
sylph-decoder
bf1e29bb5a re: menu-audio-cues.md contradicted itself -- a negative about the method read as one about the audio
Its line 81 headed 'an individual SE's audio is not extractable yet' while line 189
of the same page says the waves are located and the port can have the audio. The
surviving content is the reason Static.slb resists STATIC scanning -- no RIFF/seek/
WAVE delimiters -- which is why the extraction had to be dynamic. The heading
generalised that into a claim about the audio.

Marked rather than deleted, since it is the evidence for why the route had to be
dynamic. INDEX was still quoting the wrong form of it days later.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:44:22 +00:00
sylph-decoder
0ea2b8e00d re: first audit of INDEX against the pages it links -- 3 of 8 rows were stale
INDEX is read every iteration and is the first thing a new reader meets, and I had
admitted three times to never auditing it. Found by accident: I was about to spend
a boot measuring whether A skips a movie because INDEX said 🟡, when movie-binding.md
had it settled since 2026-08-28 with a three-boot baseline and a delivery counter,
and HANDOFF carried it correctly. The staleness was in the index alone.

Three stale rows fixed: movie skippability, SE audio extractability, and B leaving
the main menu. Five other hits read and left alone -- index and page were talking
about different clauses.

One of the three should have been caught by check_refuted.py: REFUTED holds the
same dead claim with a different second clause, and the register matches exact
wording. Its docstring documents that weakness; this is the first live instance.

Also flags a within-page contradiction not fixed here: menu-audio-cues.md line 81
still heads a section saying SE audio is not extractable, which its own line 189
refutes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:44:01 +00:00
sylph-decoder
388a7beb14 method: four instances of an instrument answering with a property of itself
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:36:57 +00:00
sylph-decoder
ed409ded90 re: reproduce the container-seek trap on this disc, and clear the Explorer of it
sylpheed-port asked whether my capture or extraction paths seek with -ss before -i.
Reproduced on this disc's own movies: a 4.0 s audio request returns 4.597 s (ADV)
and 4.256 s (S00A), with correlations of -0.03 and -0.34 at zero shift, so the
windows are different content rather than shifted. The 4.597 matches their 4.6.

But the VIDEO seek here is exact -- container-seek frame at 20.0 s is byte-identical
to the frame from a full decode with no seek. So the trap is a property of the audio
stream, not of -ss placement as such.

The Explorer has two -ss sites, both video, and its audio path (decode_audio_wav)
never seeks -- so it is not affected. Read only; the viewer is the human's tool and
was not modified.

My own instrument failed twice first: a vstats line read as a timestamp, then
showinfo reporting frames from before an output-side -ss discard. The pixel
comparison needed no interpretation and settled it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:36:42 +00:00
sylph-decoder
ccfdc47062 method: ask what else was running; and an absence from one search path is not an absence
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:28:53 +00:00
sylph-decoder
2adde3a8b5 re: both routes to the frame clock are blocked, and my no-PulseAudio claim was wrong
Route 1, the port's hardware-consumption reference: I wrote 'no /dev/snd, no ALSA
and no PulseAudio'. The first two hold; the third is false -- I checked only
/run/user/*/pulse and concluded absence from one path, while pactl reaches a server
at /tmp/pulse-*. The route is still blocked, accurately: the only sink is a
module-null-sink, which is software-timed, so there is no hardware rate here.

Route 2, varying host load: void. The 60 Hz and 30 Hz captures disagree by 2.8x, so
neither is a guest rate, and x11grab achieved 17.5 of 60 requested fps -- the
capture path is itself starved and cannot sample a ~28 fps guest.

Records the concurrency confound against my own practice: this session ran cargo
builds alongside emulator boots at least twice, and the older fps and dwell figures
cannot now be audited for it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:28:40 +00:00
sylph-decoder
346e5574b4 re: strike the resolution contrast and the skipping claim -- both refuted by the port's own probe
Their frame counter counts engine frames, an upper bound rather than a count: quiet,
ADV drew 6480 engine frames across a 4123-frame video, so above that crossover it
constrains nothing. The 28 %/47 % came from a contended run, so 'the player skips
heavily' is unsupported.

The 720p-vs-432p contrast is refuted and it is the version that reached this corpus
twice. Quiet, both videos run +6.7 %..+6.9 %, 5 runs, resolution-independent. The
-0.5 % was contention, not resolution.

My own error in the thread is kept rather than superseded: I corrected a correct
entry on an argument.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:28:02 +00:00
sylph-decoder
6df924f005 method: land the pacing re-correction itself
The previous commit's message described this change but an exact-match miss meant
only the ui-keyframe-time-unit.md half landed. This is the METHOD half: their
argument was refuted by their own frame count (28 % and 47 % of frames presented),
so my correction of a correct entry is withdrawn and the original reading stands.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:08:48 +00:00
sylph-decoder
905e754006 method: re-correct the pacing entry -- their argument was wrong, my original reading was right
They measured what they had argued: the player presents 28 % of S00A's frames and
47 % of ADV's. S00A held real time BECAUSE it dropped three frames in four, so the
overrun is not evidence against skipping, and the entry I rewrote on their argument
was correct before I touched it.

I corrected a correct entry on an argument, having just written that a consumption
counter is what makes an audit. Accepting an argument from an absence is the same
error as making one.

Their figure is also a spread, not a value: 146.42 / 146.60 / 140.77 s = +2.4 % to
+6.7 %, n=3, load-dependent, and a lower bound measured under skipping. Both places
this corpus quoted +6.7 % are updated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 23:08:27 +00:00
sylph-decoder
0620967e79 method: the overtaken-section sweep invents defects -- 7 flags, 0 real
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:57:17 +00:00
sylph-decoder
27ed06cfd5 handoff: mark the overtaken initial-focus section, which still read as live
sylpheed-port pointed out that a newest-first convention protects a top-down
reader while a grep lands mid-document. Both of that section's claims have since
been overtaken -- the disagreement is settled at NEW GAME, and the persistence
question has been run -- and it carried no forward marker.

Kept rather than deleted: it is what the port was told at the time, and a reader
arriving by grep needs to know it was superseded.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:56:45 +00:00
sylph-decoder
34ac4ec8fd method: correct my characterisation of the port's pacing test -- the overrun is the evidence
I called their video timing the skippable kind. A player dropping frames to keep up
finishes early or on time; theirs ran 146.6 s for 137.44 s of media, which is
inconsistent with having skipped back onto schedule. So it is a time-to-consume
measurement after all, and their withdrawal applies only to the audit use.

Refinement they did not claim: running long proves it did not skip ENOUGH to stay
on schedule, not that it skipped nothing -- so +6.7 % is a lower bound on the
deficit, which favours their conclusion.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:56:22 +00:00
sylph-decoder
29208cd70e method: a consumption counter is an audit, a presentation timeline is not
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:52:42 +00:00
sylph-decoder
e88ac3a002 re: the frame-vs-audio clock run is void -- four instrument faults, control caught it
The estimator had to recover the plate's known 2.53 s period and returned 0.599 s,
its own search floor, meaning no peak was found. plate-pulse-measured.md already
records that this fast-rise/slow-decay waveform defeats sinusoid fitting;
autocorrelation fails for the same reason, so the trap was written down and I
walked into it.

I also reimplemented the title gate without its twelve-sample hold, so the window
straddled the build-in -- the signal ranges 0..5433 where the plate never goes
below 159. And no Looped Data lines were captured at all: Apu logging was on, but
those lines appear only on a wrap, and BGM_103's first wrap is ~96 s after the
music starts against a 90 s window.

The audio-clock result from committed data stands and is unaffected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:52:26 +00:00
sylph-decoder
a5795d47d1 re: the container's audio clock is within 1.5 % of real time -- a uniform slowdown is refuted
BGM_103's loop bounds are bit offsets in the decoder context, and each wave's
duration follows from its declared byte rate, cross-checked against decoded PCM to
0.007 %. Cycle media length 62.34 / 63.29 s against 61.87 s wall: ratio 0.985,
where a uniform 8.5 % slowdown predicts 1.085 -- 10 % away and on the other side
of 1.0.

The method's error bar is its own 1.5 % self-disagreement between two stems that
must have equal duration, which is why the loop page refused this conversion for a
finer question. It is adequate for an 8.5 % effect.

Does NOT settle the frame clock: audio can hold real time on a timer while
rendering lags, and 27.6 fps and the 8.5 % splash excess are both frame-clock
numbers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:45:33 +00:00
sylph-decoder
df08b2fddf re: the 27.6 fps rate is not separated from this container running the guest slow
sylpheed-port warned that wall clock on their box carries a +6.7 % decode deficit
and that cross-agent timing comparisons must go through media length. It reaches
this page's headline: a guest at ~92 % of real time and a game presenting at 27.6
fps produce identical measurements, and the three trials share the container, so
they are three samples of one confound rather than three confirmations. Same shape
as the plate-pulse phase lock.

The 8.5 % splash-dwell excess is the same number from the other side.

The port is not exposed -- it authors declared units and reads seconds from nothing
here. And the BGM_103 loop figures cannot audit it: that page states both
derivations are wall-clock, converting no bits to seconds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:37:32 +00:00
sylph-decoder
b60a104ca3 method: replacing a failed instrument with its opposite trades one blindness for another
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:25:25 +00:00
sylph-decoder
83ace47d46 re: two sweeps, two instrument faults -- the three submenus are still unmeasured
Sweep 1: ring_row.py scans x 500:542, the main menu's gutter. EXTRAS happened to
put its ring there; LOAD GAME, TUTORIAL and OPTIONS do not, so the reader found a
static element and all three voided on 'the ring did not move'. Differencing S1
against S2 shows the cursors moved at x 97..231, 338..1099 and 153..479.

Sweep 2: replaced the reader with a whole-frame comparison, controlled on the
EXTRAS frames whose answer is known. Then the guest crashed -- the already
documented STL map/set erase at PC 0x82307128, firing early in the boot, not
something B did -- and Xenia's crash dialog covers the screen centre, so a
whole-frame identity test can never match again. The narrow ring column the dialog
does not cover was reading correctly the whole time. I traded one blindness for
another, and did it because the first instrument had just failed.

Refutation attempt on 'B on a submenu restores the parent's focus' (4/4): it
SURVIVES, and the run I had written off is what corroborates it. The stuck frame
has the ring at y 303.5 = LOAD GAME, the item entered from. A fifth instance.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:25:04 +00:00
sylph-decoder
3f34c8c7f3 method: two screens, two behaviours -- and the two ways a gap gets filled
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:08:11 +00:00
sylph-decoder
3ec1fcd978 tools: focus_persistence.py used the reader that was two items out
Now uses the shared measured reader, which refuses to name a row outside the
calibration rather than guessing. Replaying this run's stored frames through it
gives NEW GAME / TUTORIAL / TUTORIAL, which is what the corrected record says.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:08:10 +00:00
sylph-decoder
df4fcd3c3b re: EXTRAS resets to MISSION SELECT while the main menu persists -- no menu-wide rule
Ring at 347.5 on entry, 427.5 after one confirmed DOWN, 347.5 on re-entry with the
frame 0.0 % different from the first entry. sylpheed-port asserted non-persistence
when nothing had measured it; the assertion was right and is now measured.

MISSION SELECT is therefore a genuine initial focus, because this screen resets --
unlike the main menu, where a single-entry reading measures history.

Every control here exists because run 1 failed without it: absolute row checks
after every navigation press (a constant offset passes a differential control),
screen identity against an in-run reference frame (main menu 327, EXTRAS 324 and
OPTIONS 317 all sit in the same glyph window), and raw ring rows inside the
submenu so no three-item geometry is assumed. The screen was also confirmed by eye.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:07:24 +00:00
sylph-decoder
e35c56a5ed re: refutation attempt on Q2's 'shipped twice' -- it survives, with one real caveat
The doubt was my own artefact: the entry dump printed only the first two sprite
names in HashMap order, making 11 and 14 look like different studios. Full sets
are identical.

7 of 8 pairs declare identical sprite sets, control included. 4/7 does not: entry
7 carries nine sprites entry 4 lacks, including ptlogo_jp and ptlogo_jpeff, so the
Japanese title is a different element inventory rather than the same screen
localised. That matches the JP capture work from the other side.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 22:05:03 +00:00
sylph-decoder
04e8c6d8a7 method: a control that only checks differences cannot fail on the origin
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:57:00 +00:00
sylph-decoder
ec9ab203af handoff: Q2 enumerated six of eight screens and mis-paired the splashes
sylpheed-port caught that a reader counting the Q2 row gets twelve entries with no
slot for the boot splashes -- in a row already corrected once for an
ordinal-versus-entry error.

Verified off the disc: the splashes are 10/13 (palogo_sqex, publisher) and 11/14
(palogo_gamearts/seta/anima, developer). The row said 'in entry space 10/11 are
the publisher and developer splashes', which names one half of each of two
different pairs rather than a pair. All eight screens now enumerated, with the
per-entry names committed as reference data.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:56:45 +00:00
sylph-decoder
8ebbfc70c1 re: the focus reader was two items out -- initial focus is NEW GAME, and my labels were wrong
menu_focus.py's row centres are design-space rows from screenshot output; my
probes fed it whole-display x11grab frames carrying Xenia's chrome and a surface
scaled 1.060. Caught by ground truth, not by a control: the probe announced 'on
EXTRAS', pressed A, and opened OPTIONS.

Measured directly with ring_row.py: initial focus on a fresh boot is NEW GAME,
2/2 fresh boots, both the first menu entry. That agrees with boot_menu.sh's own
line and menu-state-in-memory.md's four-downs, and withdraws this page's
'TUTORIAL 2/2' as the outlier.

Persistence stands and is now geometry-free -- 384.0 vs 385.5, 1.5 px apart. An
equality test is immune to a constant offset, which is why the conclusion survived
a broken reader when the published item names did not.

The control was structurally blind: 'two DOWNs move two items' tests relative
motion, and a constant offset preserves it exactly.

EXTRAS remains unmeasured; that run navigated to OPTIONS.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:54:32 +00:00
sylph-decoder
addf753c44 method: confirm every input, not just the ones that once failed; and prose drifting from corrected code
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:29:18 +00:00
sylph-decoder
8bcb1d1976 re: the main menu remembers its cursor across menu -> title -> menu
F1 TUTORIAL, two delivery-confirmed DOWNs to EXTRAS, B to the title, A back:
F3 is EXTRAS. Re-entry restores the item you left.

Reframes the initial-focus disagreement rather than settling it: if focus
persists, any 'initial focus' reading not taken on a fresh boot's first menu entry
measures history. It still says nothing about what the menu opens on -- this run's
F1 was itself carried over from a prior probe's press.

Reached on the plate-pulse gate, not boot_menu.sh, whose stillness test cannot fire
on this title -- TITLE at 422.7 s on a boot skip_intro could not gate at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:29:01 +00:00
sylph-decoder
a89406cebe re: the initial-focus 🟡 is contradicted by two other records, and I could not settle it
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:16:06 +00:00
sylph-decoder
982b6349c6 re: two boots failed because the title gate tests for stillness on a screen that never stills
skip_intro.sh admits a static screen at d <= 1500 between grabs 0.6 s apart. Over
72 samples of the failing boot the MINIMUM was 1551 -- zero could ever pass. The
timeout is unreachable by construction, not bad luck about intro length.

The premise is in the script's own comment ('the resting title barely changes')
and it is refuted by this session's own draw capture: the title free-runs two
full-screen-height sweep leaves and pulses the plate. HANDOFF already said a
settled screen is not a static screen. wait_plate_pulse.py, which counts glyph
pixels instead of demanding stillness, reached TITLE SETTLED at 245.6 s on the
same game the same day.

Threshold deliberately NOT raised: 7 of 72 samples fall under 2000, so a gate loose
enough to admit this title would also admit movie frames -- the confusion the
script's own header records paying for once already.

Cost recorded: the focus-persistence question it was booted for is unanswered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:15:48 +00:00
sylph-decoder
e6d0f14ea7 handoff: record that deliveries here are anchor-coupled, and unreachable from main
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 21:04:07 +00:00
sylph-decoder
e5f1b7c2d4 formats: expose loop_length_units -- the port was reading +0x08 itself
sylpheed-port reports that a record's loop length is on no public ref at all
(example, test and docs/re/ only), so their screen.rs parses the four bytes with
its own RATC guard. That is my field to publish.

One function serves both levels, since a nested .rat leaf is itself a RATC bundle
with the same header shape. Returns None for a non-RATC or short slice so callers
need no guard of their own.

Verified against the disc, controls first: rejects a non-RATC slice, rejects one
too short for the field, reads big-endian at +0x08 -- then reproduces every
published value (ptbtn00f 120, ptloop01 600, ptloop02 720) over 65 GP_TITLE
records with 0 violations of +0x08 >= largest keyframe time.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:54:16 +00:00
sylph-decoder
f6e1f12728 re: read the suppressed set -- 7 correction contexts, zero live revivals
Also dedups the suppressed listing: two registered claims can be substrings of one
line, which reported that line twice (8 -> 7).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:45:33 +00:00
sylph-decoder
5c97d3819d re: check_refuted.py's clean run was not a pass -- 8 of 8 mentions were suppressed silently
A real revival planted inside a paragraph that merely discussed corrections was
missed: the words 'refuted' and 'withdrawn' in the surrounding prose vouched for it.
Measured reach: 100 % of registered-claim mentions in the corpus are suppressed by
marker language, so the reported 0 was 0 regardless of whether any was live, and I
had been reading it as a pass.

sylpheed-port's token-based hook has the opposite bias -- it over-reports on
well-written corrections, which is the safe direction. Under-reporting is disguised
as success.

Fixed by making the suppression visible rather than removing it: suppressed mentions
are counted and listed with --show-marked as not verified, only vouched for.
Controlled -- the planted revival moves the suppressed count 8 -> 9 and appears in
the listing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:27:17 +00:00
sylph-decoder
390cdef5db method: the refuted register and a good correction pull against each other
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:19:54 +00:00
sylph-decoder
b4c6095c47 handoff: the stem question is narrowed, not settled -- and it does not change what the port does
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:17:37 +00:00
sylph-decoder
4dd6a3f325 re: a bank's wave 1 is not a filtered copy of wave 0 -- and my own discriminator cannot finish the job
Coherence on BGM_103, the menu's bank, with controls run first: a real linear
filter of wave 0 reads 0.93-0.94 in every band, a different bank reads 0.001, and
wave 0 misaligned by 1 s reads 0.004-0.057. The measurement reads 0.027 at 1-4 kHz,
so the 'wave 1 is wave 0 filtered' model is refuted.

The frequency structure is inverted relative to any mic-pair or reverb model:
coherence rises with frequency (0.169 -> 0.827) while energy falls (71 % -> 0.2 %),
and a rear pair decorrelates fastest at HF. In the midrange the two waves are 13x
further apart than the two channels of one wave.

But the L-R control is what limits the tool and it is recorded as such: within one
wave, genuinely one performance in two channels, coherence is only 0.221-0.497. So
'same performance' does not imply high coherence here, my positive control was the
wrong model of the rear-pair reading, and the 🟡 is NOT settled. The tool tests for
linear filtering and neither surviving reading requires it.

Also corrects MISSION's Q10 row, which still carried the refuted three-sub-wave
premise and had directed work at a dead question for days. Its gate is in fact met.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:17:23 +00:00
sylph-decoder
95ceb70cb5 re: the refuted register ignored the deaths I just wrote, and two false positives shared a cause
Three refutations written as prose under ### headings never entered the register:
check_refuted.py parses * "claim" lines, so the count stayed at 188. Registered
them properly (188 -> 192). A register that parses one syntax silently ignores
every other, and it is invisible from the author's side -- ask the register what it
holds, do not re-read what you wrote.

Both standing false positives were bullets under a header that retracts the whole
list, with no marker in the +-4-line window: scope marks them, not proximity. The
scan now includes the nearest preceding header and matches markers
case-insensitively ('An earlier version' was missed by the marker 'an earlier
version'). Controlled by planting a real revival and confirming it is still caught;
register now runs clean at 0.

Also records sylpheed-port's diagnosis of the phase-lock fallout: a number can be
inapplicable rather than wrong, and a tension built on one is manufactured. Plus
their point that some claims are not registrable in a substring register at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 20:02:21 +00:00
sylph-decoder
c5d685ba15 re: the sweep IS drawn on the JP title -- and my gate was phase-locking the shutter
The occlusion hypothesis is refuted: build 7 draws the same three ROT strips at
higher alpha than English, so there was never an absence to explain.

The 0.32-vs-11.9 tension that motivated it was an artefact of my own instrument.
Both JP captures were shuttered on the plate pulse, and the plate's pulse is part
of the animation -- so the gate synchronises the shutter to the animation's phase.
Measured at the shutter instant, the sweep sits 25-26 px apart across two runs in
different locales and different sessions: 1.6 % of a ~1600 px traverse.

So the 0.32 I recorded as between-session capture noise measures my trigger's
repeatability, and I read it as evidence the title is still when it is evidence
the gate works. The era adjudication is unaffected -- margin 16.72 clears even the
un-locked 11.9 -- and unaffected for the reason that file already gave: correlated
noise cancels in a margin.

Refutation attempt on sylpheed-port's positional-mechanism rejection: FAILED, the
claim stands. Its residual sits inside lit logos, and the logo ROI is
byte-identical across five differently-phased frames in two sessions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:52:15 +00:00
sylph-decoder
1ef6896f8e re: the absence half of the gate audit -- 3 flagged, 0 real, and the audit was narrower than its wording
sylpheed-port ran my two-half decomposition on their side and found the thing that
passes every check by being absent -- an authored value with no `why` at all.
Their first pass flagged 35 of 131; ancestor-aware, the real number was 0. The
analogue here is a page citing NO reference data, which my previous gate audit
would score "0 missing" and pass.

42 pages carry a measured/decoded/CONFIRMED status; 3 cite no data/ or captures/
path. INSPECTED BEFORE PUBLISHING, per their rule, and all three are false
positives, each verified rather than waved through:

  slb-bank-header-not-a-wave.md cites tests/slb_leading_segment_disc.rs, and that
  file exists in crates/sylpheed-formats/tests/ -- its evidence is a disc-wide
  check over 9 519 sound.pak entries plus regression tests.

  ui-screen-runtime.md carries 26 rows of inline evidence, live guest-memory reads
  matched field by field against the file.

  five-screens-acceptance.md is a consolidation page; its evidence is the six
  pages it links and the numbers it tabulates.

3 -> 0.

The real finding is about the EARLIER audit. This corpus carries evidence in at
least three forms -- committed data files, inline tables, committed disc tests --
and both checks look for exactly one. "48 citations, 0 missing" is a statement
about the data-file form, not about whether the gates are evidenced. The gates are
evidenced; the audit was narrower than its wording suggested.

METHOD gains their formulation with all four instances -- a first count from a new
detector is a measurement of the detector, and all four were caught by inspecting
the flagged items before publishing the number -- and the corollary that an audit
is narrower than its wording: name the form you checked, not the property you hope
it stands for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:39:25 +00:00
sylph-decoder
b93ff1d974 re: audit MISSION's own gates, both halves -- clean, with the checks stated
sylpheed-port found P0 complete-but-unindexed: the work existed, the artifact
existed, the gate record did not. They named it as the argued-versus-indexed split
one level up from the refutation register, which is a shape worth checking on my
own objective rather than only agreeing with.

MISSION's gate has two halves -- "a written docs/re/ result with the evidence, and
reference data committed alongside it" -- and all ten questions read answered.

Half one: all ten cite a docs/re/ result.

Half two: every data/ and captures/ path those nine pages cite was resolved
against the tree. 48 citations, 0 missing. Spot-checked six for substance rather
than existence, since the gate's PURPOSE is that the port can work without a disc
-- 1.2 KB to 20.7 KB, 15 to 324 numeric lines each. No stubs.

CLEAN, and unlike the port's P0 also indexed: HANDOFF's status table cites the
page and the page cites the data.

Reach stated, because a clean audit is worth exactly its checks. This tests that
CITED files EXIST and carry content. It does not test that the data supports the
claim, and it cannot see data a page should have cited and did not -- a page
citing nothing would have passed as "0 missing". None did, but the check would not
have caught it. Existence and substance, never sufficiency.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:36:16 +00:00
sylph-decoder
cf04a14958 re: the gamma ramp write -- direct observation attempted, blocked by the build tree
ui-render-tone-curve.md records the game's gamma-ramp write as "inferred from a
closed chain, not directly observed". The direct observation is a log in Canary's
own DC_LUT write path, which /canary being read-write makes available. Wrote it;
could not build it.

The patch logs each completed 256-entry sweep with samples against the identity
ramp the source documents (i * 0x3FF / 0xFF), so a written ramp is
distinguishable from an unwritten one by reading the log. Recorded in the page in
full so a future iteration with a working build can re-apply it.

BLOCKED: /sylph-home/re/canary-build was configured with -S/work/xenia-canary and
that path does not exist in this container. ninja fails at CMake regeneration
before compiling anything, and reconfiguring against /canary would trigger a
near-full Xenia rebuild -- not something to start on the way to one log line. Per
"do not improvise around a blocker", stopped and wrote it down.

REVERTED the patch and verified /canary byte-identical to its backup. Leaving
instrumented source the running binary does not contain is the
source-and-binary-disagree trap this session has caught three times; a later
reader would find the logging in the tree and conclude it was live.

Also of note for the corpus: the header edit initially failed silently because I
chained it with `||`, which hid the failure -- the "assert every edit" lesson from
four iterations ago, repeated. Caught by grepping for the symbol afterwards rather
than by trusting the command.

The ramp write remains inferred, not observed. What is new is the reach: the
experiment is written and the obstacle is a build-tree path, not anything about
the game.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:33:25 +00:00
sylph-decoder
2ea7b7eb3d re: my own MISSION correction was wrong on all three clauses
Two iterations ago I corrected MISSION.md's stale "🔴 Emulator-side questions are
blocked" banner and wrote, in its place, that the two items it named were
"unblocked, not answered ... both need a running menu, both now have one, and
neither has been attempted". I wrote that without reading either page.

Reading them:

  8AX vs ptbase was RESOLVED on 2026-08-29. Its status line says so -- both its
  questions closed, page kept for the evidence.

  The gamma control was attempted and half-answered, and its page records that
  the run "needed the emulator only to BOOT, not to reach a menu ... parked behind
  the title-screen blocker for no reason".

  So neither item ever needed a running menu, and the section's premise was wrong
  independently of whether the menu was reachable.

All three clauses false. The failure is specific and worth naming precisely:
replacing a stale status with an UNCHECKED one, in the same edit that criticised
the document for carrying unchecked status. sylpheed-port wrote a dead instruction
inside the commit fixing dead instructions; this is that shape, one document over.

METHOD: a correction is a new claim and needs the same check as the claim it
replaces. The urge to correct supplies confidence the correction has not earned --
check a replacement as hard as the thing it replaces, and hardest when the edit is
about checking.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:29:17 +00:00
sylph-decoder
897be7bfdd re: build the enforcement check REFUTED.md lacked -- 0 real revivals, and why
sylpheed-port's check-claims fails their run when a refuted claim is quoted
without an explicit token, and feeding it four withdrawals flagged three still
asserted unmarked -- each inside a correction they had written. REFUTED.md
publishes deaths without enforcing them, which is the gap I named last iteration
and did not close.

check_refuted.py is the prose equivalent: for each quoted claim in REFUTED.md it
searches docs/ for that text and reports occurrences whose neighbourhood carries
no refutation marker. Controlled first -- a claim planted unmarked in a scratch
file is detected, so a clean run means something.

9 raw hits, ZERO real revivals. All false positives, and the kinds are the
finding: 2 were text explicitly DECLINING to revive a claim; 1 a duplicate report;
4 were BACKLOG.md entries under a 2026-08-12 header, an append-only log recording
what was believed then; 2 were the claim quoted inside its own correction.

The structural limit is worth more than the clean result. A neighbourhood-language
detector cannot separate "asserted now" from "recorded as believed then", because
a dated log entry and a revival read identically. The port's design avoids this by
testing for a token an author must PLACE rather than for language -- theirs fires
correctly inside a correction, which is what caught their three, while mine fires
incorrectly there and would miss a revival reworded.

Stopped tuning at two remaining. Each marker phrase added fits the detector to this
corpus's habits of expression and away from being a test of them; tuning until it
reads zero would be fitting the instrument to the answer. Left over-reporting,
which is the safe direction.

Reach: it matches a claim's exact wording, so "no verbatim revival" is not "no
revival".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:26:00 +00:00
sylph-decoder
28b1a4c33c re: eight refutations from this session had never reached REFUTED.md
sylpheed-port audited the documents their brief names and found two stale
blockers in a table they are instructed to consult, having audited everything
else. Mine names eight documents; I had audited MISSION.md and never PROTOCOL,
REFUTED, INDEX or CONTAINER-NOTES.

REFUTED.md is the dangerous one, because a wrongly-dead entry stops someone
re-investigating something live. Checked the keyframe cluster first for the
opposite failure -- entries refuted USING the stale time association, which would
make their deaths unsound. They are sound: the additive-blend and pivot entries
rest on scale values and capture measurements that the association does not move,
and the one entry that did depend on it is already struck through.

The real gap is the other direction. EIGHT claims died this session -- the
fade-out duration "not in the file", the ~14 units as a black hold, the black
interval as a load, "(B) has no black interval", ptloop01/02 not free-running,
the splash dwells running 8.5 % long, EXTRAS's "structural" n=1, and the gap being
determined by the outgoing screen. Every one was recorded in its own page at the
time. NONE of them reached REFUTED.md, the file the brief says to grep before
proposing anything.

Added as a dated section with the true answer after each arrow, following the
file's stated format, and each carrying what made it wrong rather than only that
it was.

METHOD: a refutation that lives only where it was made is not reachable by the
person about to repeat it. The pages are where a refutation is argued; the index
is where it is found -- the same split as docs versus tool, and only the second
one saves anyone. The check is mechanical: after withdrawing a claim, grep
REFUTED.md for its noun.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:21:06 +00:00
sylph-decoder
d7b715d6ee re: try to name the two unidentified destinations -- rejected by my own calibration
sylpheed-port's caveat on the ninth transition: the destination is identified
after the fact by draw signature, which establishes THAT the two screens differ
but not WHICH either is, so the gap is attributed to a pair whose second member is
known only as "not the other one". Worth trying to remove.

Both runs saved a screenshot of the destination. Scored against the archives the
menu's non-EXTRAS buttons plausibly reach:

  m2o   best GP_OPTIONS 43.30, margin 5.88
  m2o2  best GP_SYSTEM  45.74, margin 2.28

REJECTED against this corpus's own calibration. which_title_screen.py's control
puts a true match at RMSE ~18-20 with margin ~10, and a "neither" at ~34 with
margin under 1. These best fits are roughly double a real match. Accepting "m2o is
GP_OPTIONS" on a margin of 5.88 would be the same weak-margin acceptance that a
threshold was added to the navigation search to prevent three iterations ago.

Reach of the negative: one build per archive was rendered -- the default, which is
the largest -- and the screen a button opens need not be the largest build. So
this fails to identify rather than refuting those archives, which is a different
statement. The port's caveat stands and the ninth pair keeps it.

METHOD: a calibrated instrument can reject its own answer, and should. Without the
calibration, "best match, margin 5.88" reads like an identification -- a ranked
list always has a winner, and nothing in the ranking says whether the winner is
good enough. Any nearest-match report needs a known-good score beside it or it
will name something every time it is asked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:17:03 +00:00
sylph-decoder
123cfc8561 re: MISSION.md carried three stale headings -- the document nobody audits
I have been reading MISSION.md every iteration as instructed and never once
audited it, while auditing headings, instructions, env vars and fallbacks
everywhere else. It carried three false section headings, each superseded in
HANDOFF.md and nowhere else:

  "🔴 Emulator-side questions are blocked -- the title is not reachable here"
      False. Twelve emulator runs on 2026-08-30 reached the settled title, gated
      on the plate pulse, and drove it into the menu, EXTRAS and out of the
      archive. The two items the section named -- the gamma control and
      separating 8AX from ptbase -- are UNBLOCKED, not answered, and neither has
      been attempted. That distinction is kept.

  "🟡 Needs one more run -- a Japanese-locale capture", describing "one capture we
      cannot take". Taken twice, both committed, via jp_title_session.sh. And both
      questions it blocked are closed, one of them confirmed against that very
      capture. ⚠️ I noticed this section was stale several iterations ago, said so
      in a message, and did not fix it.

  "🔵 Needs a human decision -- rotation". Decided and implemented the day it was
      raised: HANDOFF records "OPTION A IS DONE. The reference renderer rotates",
      and ui_layout.rs carries the rotated blit with a control test pinning 0° and
      360° byte-identical to the unrotated path. The field is now confirmed from
      the ORACLE too -- +30/-45 predicting AABB heights of 1135.3 and 1301.1
      against 1134 and 1303 measured, both under 0.2 %.

All three corrected leading with the correction, originals quoted and demoted
beneath. Only FACTS were changed; the questions and their gates are untouched,
since keeping the document true is maintenance and changing what it asks would be
overstepping.

METHOD: audit the document that defines the objective, because it is the one
nobody audits. A document read only for instructions is never read for review, and
the more central it is the more often it is consulted and the less often checked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:15:40 +00:00
sylph-decoder
06aa031980 re: a ninth transition -- the same origin gives gap 0 and 1 by destination
sylpheed-port confirmed "nothing declared predicts the gap" from their export
independently, and deliberately declined to search combinations: four pairs
against many candidate two-screen functions fits by construction. Right call, and
it applies to me unchanged. So this iteration adds a PAIR rather than a fit.

menu -> a second screen outside GP_TITLE, reached by stepping the cursor two
items before arming. The button is not controlled -- there is no focus readout --
so the destination is identified afterwards by its draw signature: incoming
primitive [255] at 7-9 draws/frame, against the first run's [127] at 12-13.
Different screens.

Outgoing quad rises 25, 51, 102, 229, 255 across frames 37-42, then at frame 44
the new screen is already drawing. NO empty frame anywhere. GAP = 0.

So the menu as origin gives four values across four destinations: title 0,
EXTRAS 1, other-1 1, other-2 0. The same origin yields both 0 and 1 depending on
where it goes, while the two repeated pairs stay internally identical (3,3,3 and
2,2). Further evidence for the ordered pair over the origin.

Recorded as an observation with its counter-example rather than fitted: the
incoming screen's own full-screen primitive is [255] where the gap is 0 and [127]
where it is 1, which suggests a screen beginning from opaque black needs no blank
frame. That FAILS on menu -> EXTRAS, which declares a black backdrop and still
gives 1. Nine transitions against many candidate functions is the construction
the port declined to search, and I am not searching it either.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:13:23 +00:00
sylph-decoder
5e2dd62732 re: the gap is a property of the ORDERED PAIR -- and the guard verified in a run
Two things in one run, on the screen that motivated both.

First, the effective-config guard I had flagged as "not yet verified" -- leaving a
doubt in my own file, which is the shape sylpheed-port had just caught themselves
in. Verified now:

    arming on       = menu  [screen_id: cannot separate menu/EXTRAS]
    discriminator   = extras  rmse=18.94  (other main_menu 30.09, margin 11.15)

Before the fix this run would have announced "arming on = menu" while armed on
EXTRAS. The ambiguity is visible instead of hidden.

Second, a replicate of the table's weakest cell. Second EXTRAS -> menu: outgoing
quad 229, 255, 255 across frames 29-31, then TWO empty frames at 32 and 33. Gap =
2, identical to the first.

Eight transitions now say something sharper than the outgoing-screen story, which
is superseded a second time:

  title  -> menu    3, 3, 3   n=3   repeats agree
  EXTRAS -> menu    2, 2      n=2   repeats agree
  menu   -> title   0         n=1
  menu   -> EXTRAS  1         n=1
  menu   -> other   1         n=1
  EXTRAS -> other   3         n=1

Every repeated pair is identical -- five replicates, no variation -- and every
differing value comes from a different pair. The same origin gives different
values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3). So the origin
CONSTRAINS the gap and the ORDERED PAIR determines it, reproducibly.

For the port: a constant black_hold_units is excluded and keying on the outgoing
screen is excluded too. Any keyed version must be keyed on the ordered pair, with
a measured value per pair -- six known, two replicated, none predicted by anything
declared.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 19:02:19 +00:00
sylph-decoder
09af29f1dd re: the symmetric audit -- port-sourced claims in my corpus are attributed
sylpheed-port promoted my unverified "EXTRAS is stuck at n=1, a structural limit"
out of a message into DECISIONS.md as an established fact, while holding the file
that refuted it -- their own authored/flow.json, recording ptbtn11 ->
GP_MISSION_SELECT. Their corollary is sharper than my original entry: distrust
"structural" and "impossible" hardest when SOMEONE ELSE writes them, because they
arrive without the doubt the author would have had.

Swept this side for the same shape. It is clean: port-supplied figures are
attributed in the text ("port reports 866 keyframes ... 0 untimed"), the
ui_layout.rs comment on the unreachable fallback cites MY OWN measurement of 0
untimed of 24 811 across 965 builds rather than their 866, and their quantisation
floor of 0.41 appears in no document of mine at all.

Reach stated: this tests attribution WORDING and the port-supplied figures I could
enumerate, not every reliance. A negative from a naive check is not proof of
absence, and saying so is the point of recording it.

What protected it was a habit rather than vigilance -- writing the source into the
sentence. That is now the third instance of one remedy: state what the number is a
number of; write the index space into the token (e10 rather than "build 10"); write
the source into the claim. Put the qualifier in the text, never in the reader's
memory.

Also fixes the half-guard the port called out. The effective-config block reported
`arming on` from screen_id.py, which cannot separate the main menu from EXTRAS --
so it announced "menu" while the run was armed on EXTRAS, a field the guard could
not resolve for exactly the two screens in question. It now prints both that value
AND the discriminator with its margin, so the ambiguity is visible rather than
hidden. NOT yet verified in a run -- per the port's own --no-hold lesson, parsed
and edited is not working.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:52:19 +00:00
sylph-decoder
cd829b6dad re: break the EXTRAS n=1 cap -- which I had wrongly called structural
I recorded EXTRAS as able to supply only one gap measurement because "its sole
exit is (B) to the menu", and called that n=1 STRUCTURAL -- a word that retires a
question. The disc refutes it in one command: build 6 declares three buttons,
ptbtn11/ptbtn12/ptbtn13, all kind 0x3002. The cap was an unverified assertion I
had already written into HANDOFF twice.

Measured EXTRAS -> a screen outside GP_TITLE via (A): outgoing quad rises across
frames 36-40 (4-5 frames, matching build 6's declared 10-unit close), then THREE
empty frames at 42, 43, 44, then a different archive builds (23-28 draws/frame
against GP_TITLE's 11-14). Gap = 3.

So EXTRAS as outgoing gives {2, 3}, and seven transitions now group as:
menu {0,1,1} n=3, EXTRAS {2,3} n=2, title {3,3,3} n=3.

A pairwise control that holds the destination class constant: menu -> another
archive gives 1, EXTRAS -> another archive gives 3. Same kind of destination, gap
differs by outgoing screen. That is the strongest support yet for the
outgoing-screen dependence because it removes the destination as the variable.

But the clean ordering is GONE: EXTRAS {2,3} and title {3,3,3} overlap at 3, so
"menu < EXTRAS < title" no longer separates them. What survives is weaker -- the
outgoing screen constrains the gap to a ~2-wide band and the bands are not
disjoint.

METHOD: a structural limit is a claim and needs checking like any other.
"Structural" and "impossible" are the two words most worth distrusting in your own
notes, because they retire a question rather than answering it and nothing later
re-opens them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:49:29 +00:00
sylph-decoder
e823cfe6fa re: a third menu-outgoing gap, and leaving the archive costs no extra black
sylpheed-port's BLOCKED row asks for a second value on one outgoing screen --
what would make "the gap tracks the outgoing screen" predictive rather than a
restatement of the data.

First, a correction their ask surfaced without needing a run: THE MENU ALREADY
HAD TWO VALUES AND THEY DIFFER -- 0 leaving for the title, 1 leaving for EXTRAS.
So "the outgoing screen determines the gap" was too strong and is withdrawn; what
holds is an ordering, not a determination. Also recorded: their ask is answerable
only from the menu, since the title's sole exit is (A) to the menu and EXTRAS's
sole exit is (B) to the menu.

Then took a third menu-outgoing measurement, to a screen outside GP_TITLE.
Confound named in advance rather than after: that transition leaves the ARCHIVE,
so a pak load could inflate the gap for reasons unrelated to the outgoing screen.

Result: outgoing quad rises across frames 24-28 (4-5 frames, matching build 5's
declared 10-unit close), then ONE empty frame at 30. Gap = 1, identical to
menu -> EXTRAS. So the confound is measured ABSENT -- leaving the archive costs no
extra black, which is worth having on its own.

Six transitions now group as: menu {0, 1, 1} over three different destinations
including another pak, EXTRAS {2}, title {3, 3, 3}. The ordering rests on 3+1+3
measurements and the menu's three agree to within one frame.

Still not predictive: outgoing closes are 5, 5, 4 frames against gaps {0,1}, {2},
{3}, and EXTRAS has n=1 with no way to obtain a second value.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:42:51 +00:00
sylph-decoder
36c01ae253 re: the black gap tracks the OUTGOING screen -- direction and button ruled out
Applied my own log-line rule to my own instrument first, which is the "rule
written down is not a rule applied" failure I have on record three times. Every
branch of fade_decompose.sh now announces its EFFECTIVE configuration -- derived
from the variables in force, not from $WHERE, per sylpheed-port's sharpening --
and the run REFUSES if no branch announced itself. That is the guard that would
have caught last iteration's silent fall-through at a glance.

With it in place, took the measurement that failed last time: menu -> EXTRAS, the
reverse of the pair measured at a 2-frame gap. Navigation verified both ways
(extras margin 11.23, back on menu 11.60) and the config block confirmed the right
branch.

Result: outgoing quad rises across 5 frames matching build 5's declared 10-unit
close, then ONE logged empty frame. Quoted as 1 with an upward uncertainty, since
its two neighbours carry no frame header at all.

Five transitions now order by the screen being LEFT:

  menu -> title    (B)     0        outgoing menu
  menu -> EXTRAS   (A)     1        outgoing menu
  EXTRAS -> menu   (B)     2        outgoing EXTRAS
  title -> menu    (A) x3  3,3,3    outgoing title

Direction is ruled out: EXTRAS->menu (2) and menu->EXTRAS (1) are the same pair
both ways and differ. Button is ruled out: (B) gives 0 and 2, (A) gives 1 and 3.
Incoming screen is ruled out: an incoming menu takes 3 from the title and 2 from
EXTRAS.

NOT a rule, and recorded as such. Three outgoing screens with one value each means
"each outgoing screen has its own gap" restates the data rather than predicting,
and nothing declared predicts it -- outgoing closes are 5,5,5,4 frames against
gaps 0/1,2,3, inverted if anything, on three points.

What it changes for the port: a UNIFORM black_hold_units is now positively
excluded rather than merely unsupported.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:33:40 +00:00
sylph-decoder
1b3a9e9086 re: a third title->menu replicate, from a run that ran the wrong experiment
Set out to measure menu -> EXTRAS, the reverse of the pair measured at a 2-frame
gap, to test whether the black gap is a property of the screen pair or of the
direction. The run did not do that.

A three-part patch to fade_decompose.sh asserted two of its three replacements
and left the third -- the branch condition -- unchecked. It silently failed, so
WHERE=menu2extras fell through to the `title` branch. The capture is well-formed
and is of a different transition than intended, which is the build-ordinal error's
shape again: right-looking output for the wrong object. What caught it was the log
LACKING the navigation lines the intended branch prints; the data itself looked
entirely fine.

Salvaged, because the accidental transition is one already measured twice:

  run   outgoing ramp             black   incoming decay
  1     67-70: 63,127,191,255     3       73-77
  2     64-67: 63,127,191,255     3       70-74
  3     92-95: 63,127,191,255     3       98-103

Three independent runs, gap = 3 frames every time, outgoing ramp byte-identical
in all three. That takes "the black gap is not a load" from two replicates to
three, and makes the 4-frame outgoing ramp as solid as anything measured here.

menu -> EXTRAS remains open; the condition is fixed (with an assertion this time)
and the run has not been taken.

METHOD gains two entries. Assert every edit, not most of them -- and have each
branch announce itself in the log, so a run that took the wrong path says so
before its numbers are read. And: "appears nowhere in crates/" is a claim about a
TREE. sylpheed-port found SYLPHEED_KF_TIME_SHIFT live at ui_layout.rs:497 on their
branch, which carries the stale era; both statements are true of different trees.
With main 145 commits behind and each agent on a topic branch, any claim about
what the code contains needs its ref attached.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:21:20 +00:00
sylph-decoder
e8e036f317 re: the inverse sweep -- 41 env vars read, 22 undocumented, none in the UI path
sylpheed-port inverted my documented->exists sweep into parsed->documented and
found three live undocumented flags, with the framing that a capability existing
only in an 11 000-line record is, to a reader of the interface, a capability that
does not exist. The mirror on my side is env vars the CODE reads, checked against
the docs. Like theirs it enumerates, so it completes rather than samples.

41 read by crates/, 19 documented, 22 not. The 22 split cleanly: 7 are read only
in examples/ (per-example filters and dump paths, reachable only by editing an
example's command line), and 15 are read in src/ -- live capabilities of the
library and CLI. Ten are mesh/3D toggles and five are XPR_* texture-decode
toggles.

FOR THE PORT: none of the 15 is in the UI path. Every env var ui_layout.rs and
the screen commands read is documented -- SYLPHEED_REST_RULE and
SYLPHEED_KF_TIME_LEGACY. The menu lane is clean in this direction. But the five
XPR_* are texture-decode toggles and the port consumes textures, so if a sprite
comparison ever disagrees those are the knobs and they are invisible from the
interface.

LIMIT, stated rather than glossed: I verified NONE of the 15 end to end.
`texture export` takes a loose file and the disc keeps its textures inside paks,
so the check cost more than the answer was worth here. That matters because the
port found --no-hold parsed, documented AND INERT under an interaction with
--time: "parsed and reachable" is not "works". The honest claim is that 15
undocumented env vars are READ, not that 15 capabilities exist.

METHOD: sweep the surface in both directions, and note that both directions
enumerate and therefore complete rather than sample -- rare enough in that file to
be worth preferring when available -- while neither establishes that the thing
works.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:12:21 +00:00
sylph-decoder
f9410cf878 re: METHOD -- rank silent instructions above loud ones
The refinement sylpheed-port earned by sweeping their own instruction surface and
finding all of it loud: a wrong path errors out and announces itself, while an
inert environment variable returns a clean, wrong result. Only the silent kind
manufactures evidence.

Records that the silent surface is ENUMERABLE and therefore sweepable rather than
sampleable -- every env var the docs name, checked against the code -- with the
result of doing it, and the proxy warning that absent-from-code also flags
container paths the brief sets and no code reads.

This entry failed to apply in the previous commit (an exact-match assertion on
surrounding text) while the two document fixes it describes did land. Committed
separately rather than amended.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:08:33 +00:00
sylph-decoder
70ee001327 re: sweep the SILENT instruction surface -- 5 files still named a dead gate
sylpheed-port refined my ranking: rank silent instructions above loud ones. All
of theirs were loud -- wrong paths that error out and announce themselves --
while mine was silent: an inert env var returning a clean, wrong result. Only the
silent kind manufactures evidence.

The silent surface is enumerable, so this is a sweep rather than a sample: every
environment variable the docs name, checked against the code.

SYLPHEED_KF_TIME_SHIFT was still live in FIVE doc files after I fixed one last
iteration. Two of the five were genuine hits rather than historical quotes:

  ui-resting-pose.md -- a RESULTS TABLE ROW labelled "with
  SYLPHEED_KF_TIME_SHIFT=1". Re-running it sets an inert variable, produces the
  DEFAULT row, and lets a reader conclude the two readings agree. A stale
  instruction inside a results table is the purest form of the evidence-
  manufacturing class.

  HANDOFF.md -- "experiment reachable via SYLPHEED_KF_TIME_SHIFT=1", a live
  instruction in the delivery contract.

And a live gate exists under a DIFFERENT NAME that the docs never pointed at:
SYLPHEED_KF_TIME_LEGACY, verified read at ui_layout.rs:595 -- the parser itself,
not only the tests, so it does reach screen info and screen render. Both hits now
redirect there.

Beware the proxy, which is the trap the port named about their own "parsed"
check: absent-from-code also flags SYLPHEED_DISC, XENIA_SRC and SYLPH_ISO, which
are container paths the brief sets and no code reads. Absent-from-code is
necessary, not sufficient, and I checked each rather than reporting the seven raw
hits.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:07:54 +00:00
sylph-decoder
7b505be769 re: a stale INSTRUCTION that no-ops -- worse than any stale description found yet
sylpheed-port generalised the heading rule: an index is an amplifier, since
anything republishing headings multiplies whatever they assert. Checked mine --
INDEX.md's generated table republishes each file's H1 and Status line, a narrower
amplifier than their TOC but the same mechanism -- and then swept headings for the
dead-rule vocabulary.

The strongest hit is not a heading. ui-keyframe-time-unit.md, the Q1 page, told
readers a comparison was "Gated by SYLPHEED_KF_TIME_SHIFT=1, default unchanged"
and referred to "the other reading behind SYLPHEED_KF_TIME_SHIFT=1". That
variable was REMOVED with the record-layout fix and appears nowhere in crates/.

A reader following it sets something inert, gets default behaviour, and concludes
the two readings agree. A stale instruction that no-ops MANUFACTURES A FALSE
CONFIRMATION -- strictly worse than a stale description, and the same shape as
screen-transitions.md telling the port to author a value that is decoded.

Also demoted the section heading "and the shifted reading wins every time": the
shifted reading was itself superseded, the fix having established the same
association by a better route and timed pose 0 as well, which the shifted reading
never did. The evidence stands and is now evidence for the corrected reading.

METHOD gains three things: rank instructions above descriptions when sweeping for
stale text; an index is an amplifier; and the denominator, stated because it is
unflattering -- this corpus has 2 989 headings, 401 of which make a negative or
absolute assertion, and I have audited this session's plus the dead-vocabulary
intersection. That is a sample, not a sweep, and older headings are likelier to be
stale for having had more chances to be overturned.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:04:19 +00:00
sylph-decoder
c184f8a783 re: a false HEADING standing 78 lines above its own correction
sylpheed-port diagnosed their four instances of fixed-code-under-unfixed-
description as a habit rather than inattention: corrections are ADDITIVE. They
append a correction block and leave the original standing above it -- right for a
record, wrong for a statement, because a reader takes the first assertion. Their
fix is to keep the quote but demote it grammatically.

Applied their diagnosis here and found a worse instance than theirs.
screen-transitions.md carried the heading "###  The fade-OUT duration is not in
this field", with a section beneath it that is false in every sentence:

  "The fourth block has no time -- a group's last block stops 4 bytes short and
   that word is already the next group's element index. So the disc gives the
   ramp's target (black) and not its length. That duration is measured below, and
   the port is authoring it."

All pre-fix. The record-layout fix times a group's final pose, so block 4 carries
t=80 (menu), 74 (EXTRAS) and 269 (title), and the fade-out ramp is DECODED at
70->80 = 10 units, 64->74 = 10, 261->269 = 8. The section told the port to author
a value that is decoded, and its correction sat 78 lines below.

It also carried the dead rule's exact vocabulary -- "stops 4 bytes short" -- which
is the grep I built for code last iteration and never ran against docs.

Rewritten leading with the correction, the original quoted and demoted beneath it.

METHOD: corrections are additive by default and that is wrong for a statement;
the worst form is a HEADING, which asserts with maximum reach and minimum
context, and a reader scanning headings never reaches the retraction. Audit
headings first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 18:00:38 +00:00
sylph-decoder
8d43e16c6f re: two fixed-code-under-unfixed-description hits in the crate the port pins
sylpheed-port named a pattern narrower than "docs go stale": a correct fix
sitting directly beneath a refuted description in the same file, within twenty
lines. Not drift -- editing at the point of failure without re-reading the frame
around it. Applied their grep (the vocabulary the OLD rule needed) to my crate
and found two.

ui_layout.rs:308, in rest_plateau's fallback: `continue; // the last frame
carries no time`. That is the pre-fix rule, on a branch that is now UNREACHABLE
-- measured at 0 untimed of 24 811 keyframes across 965 builds. Kept as a guard
because `time` is still Option<u32> and a malformed group could yield None, but
relabelled: it is no longer a description of the format.

ui_layout.rs:268, on the `lastall` rest override: "This is what the shifted time
reading predicts ... testing it against the captures is an independent check on
that reading." The shifted reading was refuted by the record-layout fix in the
same file. The override survives as a plain "take the last keyframe" diagnostic
alongside the documented `last` and `maxalpha`, and now says so.

Both corrections quote the original sentence so the change is visible rather than
silently overwritten -- the practice the port adopted from me this iteration.

Verified by artifact rather than by "it compiles": a comment-only edit must leave
output byte-identical, and the build-7 render's md5 is unchanged at
141771d8f1a2b3496cfd679c6cd45d1a.

METHOD records the pattern with the two greps that find it: the vocabulary of the
dead rule in code, and a HEDGE around something the current reader states exactly
in prose -- a "~0" marks where the old reader could not see.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:57:30 +00:00
sylph-decoder
66c3422dec re: sweep my pre-fix numbers -- one real hit, durations survive, argument corrected
sylpheed-port asked which of my figures predate the keyframe record-layout fix,
noting the sharper form of the hazard: a fix that changes WHICH ROWS EXIST is
harder to sweep for than one that changes values, because the recomputation looks
like a correction rather than a different question.

Located the fix (5744f37, 2026-08-29 14:01) and enumerated docs quoting
keyframe-derived numbers that have not been touched since. One real hit:
structures/ui-group-start-time.md, a page about group START TIMES, written -- in
its own words -- "under the shifted time reading" and referring to the glows'
"untimed first keyframe".

Durations survive. The glow is visible ~0..45 (45 units) and the logo ~15..210
(195 units), exactly what its table already used; the "~0" it hedged with is now
a real timed 0.

The argument did not. It read "every glow declares the same times 15, 30, 45 ...
both families start at 15". Post-fix both start at 0, with times 0,15,30,45 and
0,15,30,190,194,206,210. Corrected in place with the original sentence quoted so
the change is visible.

The conclusion is unchanged and slightly stronger: on one clock the glow is
visible over 0..45 and the logo over 15..210, an overlap of 30 of the glow's 45
units, where the capture shows no overlap at all (glows frames 94-115, logos
116-211). A shared clock origin was contradicted before and is contradicted by a
wider margin now, because both groups demonstrably begin at the same declared
instant.

Of the three figures the port reports having quoted from me, the splash dwell
spans were already corrected today and the black-gap and cold-boot intervals are
capture-derived, so the fix does not reach them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:54:11 +00:00
sylph-decoder
22846bf30e re: finish the --help audit -- a stale percentage and a missing noun, both shipped
The METHOD entry I wrote an hour ago says to read your tool's own --help as if a
stranger wrote it. I had done that for ONE of sixteen leaf commands, which is the
"a rule written down is not a rule applied" failure this corpus already records
twice. Finished it across the whole surface.

One survivor, and it fails in two ways at once. `screen render --settle` said a
narrow window means the bundle never settles, "(42 % of them, mostly loop*
fragments)".

MISSING NOUN: inside `screen render`, "them" reads as the builds you would render.
The 42 % is over composable bundles -- a different and much larger set including
~1 700 two-element fragments a user of that flag never renders. ui-settle-time.md
states its population precisely; the help inherited the number without it.

STALE: recomputed under the corrected reader, the composable figure is 862/2211 =
39 %, not 731/1758 = 42 %. The POPULATION GREW BY 453, which is the keyframe
record-layout fix's signature -- it times a group's final pose, so bundles that
previously showed one timed keyframe now show two and qualify. Third consequence
of that fix not being swept, after fade_quads.py and screen-transitions.md's
0.87-4.08 s fade-in.

And the share a --settle user actually faces is 38 %: 185 of 491 screen builds.

Corrected in the help text with all three numbers and their populations, and in
ui-settle-time.md, whose three-row table is marked pre-fix and superseded rather
than edited in place. Verified by artifact -- the tool's --help output is quoted,
not merely recompiled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:45:43 +00:00
sylph-decoder
0d1e0ae8b7 re: my own CLI shipped an unmeasured recommendation -- "Prefer --settle" withdrawn
sylpheed-port reported hedging a predicate in DECISIONS.md while stating the
unhedged version in their tool's header, and named it as the same delivery gap
they had fixed once elsewhere and not generalised. Checked this side for the same
shape and found it.

`sylpheed-cli screen render --at` told every user that the resting pose "is wrong
twice over" and to "Prefer `--settle`". That recommendation was never measured.
What the corpus actually records: scored against a live capture of the JP title,
settle gives RMSE 40.210 and rest 41.690 -- a margin of 1.48 against that
instrument's own noise floor of 1.2, which is not decisive -- and --settle has its
own failure mode, 25.5 % of elements mid-ramp at their screen's settle instant.
So neither is established as better, and the interface has been telling people
otherwise while the hedge lived only in docs/re/.

Corrected in the help text itself, on both flags, with the numbers rather than a
softer adjective. Verified by artifact: the tool's --help output is quoted in the
commit's own test, not merely recompiled.

METHOD: hedging in the write-up does not protect the claim you ship in the tool.
Docs are where a claim is reasoned; the tool is where it is believed. Read your
own --help as if a stranger wrote it and check every confident sentence against
what the corpus establishes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:38:42 +00:00
sylph-decoder
82b20bc51d re: test the port's black-backdrop predicate disc-wide -- exact locally, rare globally
sylpheed-port proposed that a screen declaring a full-screen .prm at t=0 with
fade == 0xff000000 is standalone, and one without it is composited: 12/4 across
their sixteen exported screens, every exception independently known to be
composited. They asked for it against archives they do not have. That is my lane.

CONTROL: the predicate reproduces their split exactly. GP_TITLE's sixteen bundles
give 12 with and 4 without, the four without being entries 0, 1, 2, 3 --
build_00, build_01, press_start, press_start_jp -- and the element names match
(pteff00.prm, palogo_eff0.prm, pgloading_eff00.prm). Independent derivation from
the disc, not a re-run of their tool.

DISC-WIDE it is rare: 76 of 965 screen builds, 7.9 %. GP_STAGE_CLEAR 4/4,
GP_SYSTEM 2/2 and GP_TUTORIAL 2/2 are all-yes; GP_HANGAR_ARSENAL is 0 of 390, and
GP_READY_ROOM, GP_OPTIONS, GP_PAUSE_MENU and GP_GAMEOVER are all zero.

So it is not a general standalone/composited test. GP_OPTIONS and GP_PAUSE_MENU
are screens a player plainly sees as screens and declare no backdrop; read as
"composited" the rule would make 92 % of the game's screens composited, which the
archives do not support. What it appears to separate is narrower: screens that
BEGIN FROM BLACK from everything else. A pause menu over gameplay, a hangar over a
3D scene and a plate over a title all lack a backdrop without being the same kind
of thing -- the negative class is heterogeneous, which is what a two-way rule
cannot express.

For the port: exact within GP_TITLE, so --black for those twelve is justified from
the file rather than assumed; do not carry it into the four archives they have yet
to export, where in three of them it classifies every screen alike.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:36:10 +00:00
sylph-decoder
a1af583725 re: verify the splash's opaque-black backdrop, and the noun amendment
sylpheed-port found the fifth member of our error family on their own side: their
"visible" test counted any element with alpha > 0, which includes palogo_eff0.
Verified from the disc rather than accepted --

  entry 10  [0] palogo_eff0.prm  1 kf  t=0  fade=0xff000000  scale=100x100  pos=(0,0)
  entry 11  same

Alpha 255 over RGB 000000: full-screen opaque black, drawn from t=0 and showing
nothing. So "any element drawn" reports these screens visible from t=0 while the
frame is black -- "visible" read as "drawn".

Worth having on its own: this verifies from the disc the premise behind
`screen render --black`, which its own help states as "what the game composites
over on a screen carrying its own background". On the splash builds that
background is DECLARED, not assumed.

METHOD gains their amendment, which is the sharpest formulation either of us
reached this week: all five instances are a failure of a NOUN, not of a number.
Extent, bounding box, duration, span, visible. The number was always correct FOR
SOMETHING; what went missing was which thing. Every other check in that file
tests whether a number is right, and not one tests whether it is a number of the
thing you think.

Also teaches fade_quads.py to address a PAK ENTRY directly (`e10`) rather than
only a build ordinal. The splashes are entries 10/11 and are not screen builds,
so no ordinal addresses them -- and writing `e10` states which index space is
meant, which is the standing lesson of build-ordinal-vs-entry.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:30:37 +00:00
sylph-decoder
2dfc20bc0f re: WITHDRAW the 8.5 % dwell systematic -- I measured one element, not the screen
sylpheed-port said the port plays the full group (255 and 210 units) rather than
my 240/195, and they are right for a reason sharper than either of us first had.
The _eff elements ramp alpha 0 -> 255 over t=0..15 while the main logo is still
fully transparent:

  palogo_sqex.t32      0:a=0  15:a=0    30:a=255  ... 255:a=0
  palogo_sqex_eff.t32  0:a=0  15:a=255  30:a=212  45:a=0

So the SCREEN is visible from within t=0..15 and its visible span is the full
group. My "240 units visible" was ONE ELEMENT's visible span, computed while
another element of the same build was already on screen -- which is exactly the
error class I was writing up when I made it.

Recomputed against the screen: publisher 1.011/1.083/1.028, developer
1.002/1.001/0.962, mean 1.0146 with one measurement BELOW unity, against my
1.085 with none below. That is not a clock at 54 u/s. The systematic is gone and
Q1 stands unqualified.

The consequence was wrong too: "a port playing 240 units at 60 shows the splash
0.42 s less" -- it plays 255, so the gap is 0.174 s, and on the developer splash
the port runs longer than my mean. No direction to correct in.

What survives weakly: against the full group the publisher runs long in all three
boots while the developer sits at unity. Three boots per screen is thin and it is
not a systematic.

METHOD: state the number, and state what it is a number OF. Four instances of
this family now -- pivot anchor as extent, centre track as bounding box, cycle
length as motion duration, one element's visible span as the screen's -- and two
of the four arose because the PUBLISHER of the number never said what it spanned.
The reader reasoned correctly from the only definition available each time.
Publishing a quantity's extent in the same breath is cheaper than every check in
that file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:28:00 +00:00
sylph-decoder
c354ee615d re: the splash dwells run ~8.5 % long, six for six -- a qualification on Q1
sylpheed-port reported verify-dwell at 4.28 s / 3.58 s and called it agreement
with my three cold boots. Checked the arithmetic instead of the impression, and
it is not agreement with the DISC.

  publisher  240 u = 4.000 s at Q1's 60 u/s   measured 4.297/4.604/4.370  mean 4.424
  developer  195 u = 3.250 s                  measured 3.508/3.503/3.366  mean 3.459

All six ratios exceed 1 -- 1.074, 1.151, 1.093, 1.079, 1.078, 1.036, mean 1.085 --
implying 54.3 and 56.4 units/s. The port's own two numbers imply 56.1 and 54.5.
Four estimates, none at 60.

The obvious explanation fails: a detector triggering early and late would lengthen
the interval, but the declared span IS 15->255 and outside it the alpha is 0, so
there is nothing on screen to trigger on. An 8.5 % overshoot is 20 units, ten
rendered frames, which no threshold can manufacture from a blank screen.

Recorded as an open qualification on Q1 rather than a correction: three boots per
screen is thin, and Q1 was measured on a different quantity. It is also NOT the
same discrepancy as the sweep leaf's, which runs ~50 % slow rather than 8.5 %.

For the port: the dwells remain decoded and should still not be authored, but a
port playing 240 units at exactly 60 u/s shows the publisher splash for 0.42 s
less than the game does.

METHOD gains the reusable half of the (A) result, which the port named: a probe
whose observation window is shorter than the effect reports a CLEAN NEGATIVE.
(A) takes 4-6 s; a script that presses and looks 0.5 s later concludes the press
was dropped, with nothing in its log to say otherwise. Check the window against
the latency before believing a null, and sample repeatedly when the latency is
unknown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:23:56 +00:00
sylph-decoder
9a80ed6bd2 re: (A) on a settled boot title DOES reach the menu -- the withdrawal explained
Clearing my own debt: I withdrew navigation.md's "boot title accepts a single A"
counter-example as confounded by three concurrent emulators and never re-ran it,
which left the claim unsupported rather than settled.

Clean trial: exactly one emulator verified by count, gated on the plate pulse
(glyph in [500,2500] held 12 samples) so the press lands on the BOOT title rather
than the attract loop's, delivery confirmed at [file-pad] keystroke vk=5800
down/up. Glyph after the press is 0 at +2 s and +4 s -- the transition -- then 327
steady from +6 s through +39 s.

327 is a proxy and reading a proxy is the habit this corpus keeps cataloguing, so
the screen was checked with which_title_screen.py instead: main_menu at RMSE
19.91 and 20.08 with margin ~10, inside the 9.9-11.7 band its control establishes
on four known captures. The before frame gives the "neither" signature at margin
0.10, correctly, since the title is neither main_menu nor extras.

So the count is 3 of 3, the latency is 4-6 s -- which is why a script that
presses and looks 0.5 s later concludes the press was dropped -- and the two
earlier failures were the confound, not the game.

Refutation attempted: sylpheed-port's leaf segment rates. Derived independently
from the disc and they SURVIVE exactly -- pteff03 +4.0000 then +4.0000 then a
hold, pteff03a -4.0667 then -4.0625 then a hold. So their inversion stands: my
linearity gate fails on the leaf whose declared track is perfectly straight.

And records the third structural consequence of main being stale, which they
raised: HANDOFF.md is the delivery contract and it lives on an unmerged branch,
so their checkout contains none of this week's entries. Findings written into the
contract reach them only through messages -- the channel the protocol says does
not count as delivery. Writing it in the contract is necessary and not sufficient
when the contract lives where the other party cannot see it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:17:41 +00:00
sylph-decoder
0fdce00273 re: close the sweep-leaf thread -- deliver it to HANDOFF, and record why one
check counted more than the others

An answer not reachable from HANDOFF is not delivered, and this thread lived in
messages and docs/re/. Delivering it: the leaves ARE drawn and free-run on a
settled title, so a settled screen is not a static screen; the leaves are
identical on entries 4, 5 and 7; how the game advances them is undecodable with
reach, four models each refuted by a measurement; and keyframe_units_per_second
should stay put because the port's 1.87x table has an input now known to be wrong
rather than merely unpinned.

METHOD gains the lesson sylpheed-port named, which outlives the thread. Almost
every cross-check here runs disc -> exporter -> export against disc -> our reader:
two paths that agree because they read the same bytes with the same
understanding, and that agree anyway when the understanding is wrong. That is how
this corpus produced a build-ordinal error where everything still validated, a
two-era comparison with the same binary on both sides, and a rate confirmation
that was a prediction 20 % low meeting a measurement 50 % high. The chain that
counts ends at the ORACLE, and the single instance this week was the leaves'
rotation: +30 / -45 from the file predicting AABB heights of 1135.3 and 1301.1
against 1134 and 1303 in the draw stream. Before quoting an agreement, ask where
the two paths diverge -- if it is after the fact in question they are one witness
wearing two coats.

Also records that a refuted model is a result: four refutations, each with the
measurement that closed it, is firmer than any one of them fitting would have
been, because the failure this corpus keeps hitting is a model that fits for the
wrong reason and nobody checks.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:10:22 +00:00
sylph-decoder
2298abe33e re: the leaf's clock is undecodable with reach -- and the rotation is confirmed
Four models for how the game advances the sweep leaf, four refutations.

Frame-locked predicts px/frame unchanged under --framerate_limit; measured
-4.348 -> -2.032. Wall-clock predicts px/frame LARGER at a lower limit; it got
smaller. sylpheed-port's alternative -- that my samples might be at a fixed
wall-clock rate while guest time slows, which would reproduce the direction --
checked rather than assumed: every capture reports 150 frames spanning 1..149, so
the capture is indexed by guest VdSwap submissions. And per UI-drawing frame,
which matters because at limit 15 only 99 of 150 frames carry draws against 131
at default, gives -5.773 vs -3.687, ratio 1.57, not invariant either.

Three measures of one slowdown -- 3.58x on the boot, 2.14x per submitted frame,
1.57x per appearance -- and no two agree. The clock is none of the four and the
absolute rate stays unpinned. Recorded as undecodable with the reach stated.

Two things the same data does establish.

The rotation is confirmed FROM THE ORACLE. The port's export carries rotation_deg
+30 on pteff03 and -45 on pteff03a, read from the file. The AABB height of a
rotated quad predicts from the declared scale alone: 400x1080 at +30deg -> 1135.3
against 1134 observed (0.12 %), and 400x1440 at -45deg -> 1301.1 against 1303
(0.15 %). Two angles, two scales, both under 0.2 %.

Which makes their inversion real. Height 1134 IS pteff03 -- the leaf whose
declared track is perfectly linear at +4.0000 px/unit across both segments -- and
that is the strip my sign-change gate FAILS. Height 1303 is pteff03a, the
slightly non-uniform one, and it passes. The curvature is in the strip whose
source is exactly straight, so it is not in the disc: it is in the measurement or
in how the game advances the record.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:07:16 +00:00
sylph-decoder
1538c3e333 re: the leaf is NOT frame-locked -- and a residual gate disqualifies half my fits
The frame-rate test sylpheed-port and I agreed was the only clean route left.
Same strips, same screen, --framerate_limit=15 against the default. The limit
demonstrably took effect: the title settled at 862 s against 241 s.

First, a gate this work should have had from the start. A slope is only a rate if
its residual is random, so count sign changes in the residual:

  default   1299x1303  -4.348  rms 3.33  43/111  OK
             883x1134  +4.284  rms 3.08  21/76   SYSTEMATIC
             890x1134  +4.284  rms 3.19  15/54   SYSTEMATIC
  limit 15  1299x1303  -2.032  rms 1.51  44/83   OK
             883x1134  +2.003  rms 1.12  36/61   OK
             890x1134  +1.999  rms 0.74  12/37   SYSTEMATIC

So one of the two strips I quoted as "agreeing to three significant figures"
FAILS the linearity gate at default fps: that agreement was between a rate and a
slope through a curve. The port had already caveated the claim for a different
reason; this weakens it further from my own side.

The result, on the one group passing the gate at both settings: -4.348 px/frame
at default against -2.032 at limit 15, a ratio of 2.14.

THE LEAF IS NOT FRAME-LOCKED. A fixed number of units per submitted frame
predicts px/frame unchanged; it changed by 2.14x. Dead.

A simple wall-clock model is dead too, in the other direction: fewer frames per
second means more wall time per frame, so a time-driven leaf should move MORE
px/frame at a lower limit. It moved LESS. Neither model fits and I have no third.

Reach: the effective frame rate was NOT measured. The timing instrument I added
polls for the capture log, which is created when the capture is ARMED rather than
when it finishes, so it reported 0.728 s and is void. The 3.6x boot slowdown says
the limit took effect, not that fps went 28 -> 15. The RATIO is measured; the
absolute rate still is not.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 17:03:15 +00:00
sylph-decoder
10b0dbe5c4 re: three routes to remove the fps caveat, all closed -- 1.07 stands on one capture
sylpheed-port's caveat on my 1.07 units/frame: two strips agreeing to three
significant figures constrains the strips to each other, not the absolute rate,
because both ratios come from one capture under one fps assumption. They are
right and I could not remove it. Recording the three attempts and why each fails,
since a closed route is worth as much as an open one.

Route 1, compare the leaf to a TOP-LEVEL clock in the same capture so fps cancels:
not available. On a settled title nothing top-level moves -- that is what settled
means -- and every varying quad in the capture is a leaf. The plate looked like a
candidate (538x76, clean ~56-frame pulse) but build 2's ptbtn00 is a one-shot fade
at t=0,214,236,238,244; the repeating pulse comes from its own nested .rat.

Route 2, fit the same strips in the transition captures, which DO carry a
top-level clock (the fade quad, 8 declared units at 2.0 units/frame). The strips
are present but the fits are not measurements: rms residuals of 26.70 and 16.75 px
against 147 px of travel, versus 3.59 px against 627 px in titledraw2. Scatter,
not a line. The apparent disagreement between captures is a NON-measurement, and
quoting 1.94 or 3.57 as a second sample would have repeated the 6-7 px/frame
eyeball error one message after withdrawing it.

Route 3, read fps from the emulator's own log: not printed.

So 1.07 rules out a per-record quirk and does not pin the absolute rate. The test
that would is measuring the same strips at a deliberately different emulator frame
rate -- unchanged px/frame means frame-locked, scaling with 1/fps means wall time.
Not run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:39:50 +00:00
sylph-decoder
dd7edd5e38 re: withdraw "the sweep rate matches the disc" -- two errors that cancelled
sylpheed-port corrected the disc figure I compared against: the leaf's final
segment HOLDS, so a cycle length is not a motion duration. Verified from the
disc rather than accepted -- pteff03 moves over t=0..540 of a 600-unit cycle
(4.000 px/unit, not 3.600) and pteff03a over 0..630 of 720 (4.063, not 3.556).

Checking that sent me back to my own measurement, which was worse. "6-7
px/frame" came from eyeballing deltas between consecutive APPEARANCES in a
capture that skips frames, so a delta of 7 often spans two frames. A
least-squares fit of x against frame over all 132/112 points gives +4.287 and
-4.348 px/frame, with rms residuals of 3.6 and 3.3 px.

So the confirmation I reported was a prediction 20 % too low meeting a
measurement 50 % too high. Neither number was right and the agreement was an
artefact of both being wrong -- which is the most dangerous form of agreement in
this corpus, because nothing about it looked suspicious.

The corrected numbers say something larger than the claim they replace. Measured
against declared: 4.287/4.000 = 1.072 units per frame, and 4.348/4.063 = 1.070.
Two independent strips with different cycle lengths and different declared rates
agree to three significant figures. Q1 establishes 2 units per RENDERED frame for
top-level elements. So either a nested leaf record advances at about half the
top-level rate, or Q1's factor does not apply to nested records. Measured, not
explained, and flagged as deserving its own iteration because Q1 is load-bearing.

One untested candidate recorded: 1 unit per 1/30 s of game time against the
~28.5 fps this corpus measures for the idle title gives 1.053, close to 1.07.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:35:09 +00:00
sylph-decoder
d80519e0c3 re: the game DOES draw the sweep leaves at rest -- my own hypothesis refuted
Last iteration I hypothesised that the game might not draw pteff03/pteff03a on a
settled title, which would have explained three things at once: the flat --at
plateau, the 0.32 between-session in-box term, and part of the ~40 residual. The
oracle says no.

A draw capture of the settled EN title -- gated on the plate pulse, fired at
325.3 s, with exactly ONE emulator verified by count -- shows two quads taller
than the 720 px screen present in every one of 132 frames and sweeping in
OPPOSITE directions:

  strip A  h=1134  ROT  x -109 -> +518   step +6..7 px/frame
  strip B  h=1303  ROT  x +486 -> -154   step -6..7 px/frame

The rate matches the disc: the declared x track is -639..1521 = 2160 px over a
600-unit cycle = 3.6 px/unit, and at 2 units per rendered frame that predicts 7.2
px/frame against 6-7 measured. Both quads are flagged ROT, which is why their
axis-aligned bounding boxes are ~885 and ~1300 px wide where the declared quad is
400 -- consistent with rotation living in leaf records and with `screen render`
being axis-aligned only.

So the leaves ARE drawn and DO free-run on a settled title. My hypothesis is
refuted and sylpheed-port's reading of their `title` curve -- sweep present in a
title capture -- is confirmed by the oracle rather than by a render.

What this does NOT settle is the tension that prompted it. Both strips cross the
adjudication box in x and cover it in y, so two JP captures at different phases
should differ there, and they differ by 0.32. Two candidates, neither tested: the
two JP shutters happened to fall at similar phases (a ~1 % coincidence for a
600-unit cycle), or build 7's denser logo stack -- the katakana plus the
crystalline burst that jp-title-at-rest.txt records as absent from the English
title -- occludes the sweep inside that box. A draw capture of the JP title
distinguishes them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:31:03 +00:00
sylph-decoder
4c92f54439 re: make the one-emulator rule enforceable instead of remembered
The withdrawal last iteration was caused by `rm -f /tmp/xenia-canary.lock` --
the obvious way past a lock orphaned by kill -9, which also disables the guard
for every later launch. Three instances ended up live at once, sharing
/tmp/xenia_pad.txt and display :98, and silently confounded an input experiment.

Care is not a fix, so this is tooling. ensure_single_emulator.sh counts live
instances, stops them (plain kill, then -9, each with a bounded wait), verifies
ZERO, and only then removes the lock -- refusing loudly if any remain. The lock
is never removed before the condition it guards against is verified absent.

FOUR scripts did the bare `rm -f`, and only two were mine from today:
menu_loop_session.sh, title_draw_capture.sh, poke_control.sh and
resume_reliability.sh. So the footgun was corpus-wide rather than introduced
this session. All four now route through the guard.

The guard is controlled rather than assumed: run against a deliberately started
live instance it reports "1 instance(s) live -- stopping them", ends at 0 with
the lock cleared, and exits 0. A guard that only ever passes on an already-clean
slate would prove nothing.

It also kills by process NAME. `pkill -f xenia_canary` matches the shell running
it -- that has now cost this corpus three commands, one of them a cleanup that
died halfway and left the very instances it was meant to remove.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:23:59 +00:00
sylph-decoder
969b816aad re: WITHDRAW the (A)-press finding -- three emulators were live at once
While chasing the draw-stream question I found THREE xenia instances running
simultaneously (started 15:39, 15:44, 16:12), which violates the "one emulator at
a time" hard rule and confounds the finding I recorded last iteration.

All three read the same /tmp/xenia_pad.txt and share display :98. A press written
to that file is delivered to EVERY instance, while `screenshot` grabs whichever
window is topmost -- not necessarily the one that acted on it. So "(A) was
delivered and the screen did not change" may simply be two different emulators,
and the keystroke-level confirmation proves only that SOME instance received it.
The navigation.md entry claiming the boot title's "2 of 2" is no longer 2 of 2 is
withdrawn as unsupported, pending a clean re-run.

The cause was mine. run-canary's lockfile is the IMPLEMENTATION of the one-at-a-
time rule; a kill -9 orphans it, and the obvious unblock -- rm -f the lock --
also disables the guard for every later launch. I did that more than once today.

METHOD gains two entries. A lockfile is the rule, not an obstacle to it: clear a
stale lock only after confirming zero live instances, and COUNT them rather than
trusting a kill landed, because a plain kill is asynchronous and a -9 on a stuck
process can take seconds. When a guard blocks you, the question is whether the
condition it guards against is present, not how to remove the guard.

And a third instance of pgrep -f matching the shell that runs it -- this time it
killed a cleanup command halfway through, leaving the emulators alive and the
lock in place. Already recorded for wait-loops; promoted to "reach for -C first".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:20:24 +00:00
sylph-decoder
21de7841da re: the crop is not why the box is robust -- and it questions "the leaf free-runs"
sylpheed-port could not transfer the masking rule to their screens and inferred a
precondition: my free-running element is a localised plate I can crop around,
theirs is a wide sweep they cannot. Tested against my own screen, that is wrong.
The JP title carries the SAME sweep -- the leaves are identical on entries 4, 5
and 7, which I established last iteration -- and it crosses the box:

  two renders of build 7 on the settled plateau, t=135 vs t=240
    whole frame  RMSE 12.135   95 791 px
    in the box   RMSE 11.923   57 981 px      <- the sweep IS inside the box
    differences span y 70..674, x 128..1140; the box is y 54..476, x 389..776

So the crop did not exclude the mover, and the in-box between-session term of
0.3215 has no explanation in the crop. Which leaves a tension worth stating:

  two RENDERS one plateau-phase apart differ by 11.9 inside the box;
  two CAPTURES of that screen from different sessions differ by 0.32 there;
  and the --at sweep of renders against a capture is flat to 1.2 across
  t=135..240, despite those renders differing from each other by 11.9.

A metric cannot be insensitive to an 11.9 change unless what changed is largely
absent from what it is compared against.

Hypothesis, recorded as untested: the game may not draw these leaves on the
settled title at all, while our renderer poses them wherever --at says. That
would explain the flat plateau, the tiny between-session term and part of the ~40
residual together. It would also mean the port's "the leaf free-runs in the game
too" is not established by their evidence -- their two minima come from two
DIFFERENT screens, which can differ for reasons other than phase, whereas my two
captures are of the same screen and barely differ where the sweep would be.

Not claiming the leaves are invisible; that needs a draw-stream check for
pteff03/pteff03a on a settled title, which is one run. What is established is
narrower and enough to stop the inference.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:09:55 +00:00
sylph-decoder
3da57ee515 re: measure the capture-phase term -- 4.6 whole-frame, 0.32 in-box
sylpheed-port overturned their own phase-0 result using the identical-leaves fact
I gave them: the same leaf minimises at phase 240 against a title capture and 0
against a main_menu capture, so the best-matching phase is a property of when the
shutter fell rather than of the game's rest state. A continuously sweeping
element has no canonical rest phase. They warned that any whole-frame score
against a single capture carries a phase term of ~1.0 RMSE.

Measured on my own two JP sessions, which certainly differ in sweep phase
(44 025 px differ in the band the leaf crosses):

  whole frame                4.566
  sweep band x721..1241      4.088
  the adjudication box       0.3215

Their ~1.0 understates it for this screen: a whole-frame score against one
capture of the JP title carries ~4.6. Theirs is the leaf-phase component isolated
in a renderer; mine is everything that varies between sessions -- the plate pulse
alone contributes ~2.8, measured separately on the EN peak/trough pair -- and
includes theirs.

My margins are unaffected and now for a measured reason rather than an assumed
one. The era margin of 16.72 sits against an in-box term of 0.32, and
settle-vs-rest at 1.48 is 4.6x that term while remaining non-decisive against the
render-axis plateau of 1.2, exactly as stated.

Scoring the 388x423 box rather than the frame drops the between-session term from
4.566 to 0.3215, a factor of 14, because the sweep contributes at x 721..1241 and
the box is mostly clear of it. That was NOT why I cropped -- the crop was to stop
a local difference being diluted across 92 % of an identical frame -- so the
robustness is luck. The rule it earns: score inside a region that excludes the
free-running elements, and measure the residual term there rather than estimating
it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:04:12 +00:00
sylph-decoder
2145691586 re: verify the sweep leaves' full extent -- port's table confirmed, plus a new fact
Attempted to refute sylpheed-port's leaf table by measuring it against the disc.
It SURVIVES to the digit: ptloop01 -> pteff03, cycle span 600, x track
-639..1521, scale (100, 600); ptloop02 -> pteff03a, span 720, x -839..1721,
scale (100, 800).

The existing ptloop_leaf_sweep_at.rs samples only t=340..540 -- a window chosen
to compare two competing fits -- so it could never have shown the extent. That
gap is what let my "ptloop01/02 do not free-run" claim stand: measured over the
parent's 200x90 pivot rect, which a leaf travelling -639..1521 is almost never
inside. ptloop_leaf_extent.rs sweeps the whole cycle instead.

New fact neither of us had: the leaves are IDENTICAL on entries 4, 5 AND 7 --
the title, the main menu and the JP title. Same leaf names, spans, x tracks,
scales and parent rest position. So the menu declares exactly the same sweep as
the title, and the still-open menu question is about the game's behaviour rather
than a different declaration.

The quad is 400 px wide at scale_x 100 % -- not widened -- and scale_y 600/800 %
makes it 1080/1440 px tall, taller than the screen. A full-height strip crossing
the frame and going off both sides, which is why a phase-to-phase diff covers the
union of two positions and looks frame-wide.

And my own "centre running x~921->1041" was a 30-unit window of a 600-unit cycle
whose centre spans -439..1721. A sub-range is not an extent -- the same caution
as a pivot not being a bounding box, one level up, and I made both errors within
a day.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:01:13 +00:00
sylph-decoder
cce20b83ca re: WITHDRAW "ptloop01/02 do not free-run" -- I measured a pivot, not an extent
sylpheed-port noted that build 5's ptloop parent can be static while the leaf
record animates, and asked me to check it against my table. My own corpus
refutes my claim outright.

ptloop-leaf-sweep-positions.txt -- written earlier in this same corpus -- records
ptloop01.rat's nested record at loop length 600, whose leaf pteff03.t32 sweeps a
400 px-wide quad with its centre running x~921->1041 over t=340..370. The
parent's declared rect is (441,270) 200x90. The leaf draws 300 px outside it: the
parent rect is a PIVOT ANCHOR, not the drawn extent.

Checked against the two JP captures: my measured rect differs by 0 px -- and so
does the whole dead region y 270..450 x 480..960 around it -- while the band the
sweep actually occupies (x 721..1241) differs by 44 025 px. The zero was measured
where nothing happens.

So the port's reading is right and now confirmed from the disc: parent static,
leaf animates, and the two nested records cycle at DIFFERENT lengths, 600 and
720. My "single static keyframe" described the parent only. The era adjudication
is unaffected -- its box overlaps the sweep band only at x 721..776, which shows
no between-session differences.

The menu-loop question is still unsettled after a second attempt, and the second
attempt's failure REFUTES my diagnosis of the first. menu_loop_probe.py gated on
the plate pulse (glyph in [500,2500] held 12 samples), fired at t=484.5 s with
glyph 1723 -- a verified settled BOOT title, not the attract one -- pressed A,
and the press was delivered ([file-pad] keystroke vk=5800 down/up, 8 RE-INPUT
lines). Twenty seconds later all five frames still classified as the title
(rmse ~67-70, margins 0.06-0.16, the "neither" signature; screen_id says title).
So "the attract title accepts nothing" does not explain attempt 1, and the
corpus's "the boot title accepts a single A, 2 of 2 runs" is no longer 2 of 2.

METHOD: a declared rect can be an anchor, not an extent -- confirm an element
draws in a region before diffing that region to ask whether it moves.
navigation.md: confirm the screen changed, do not infer it from a delivered
press.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 15:55:31 +00:00
sylph-decoder
5a49511952 re: ptloop01/02 do not free-run on the settled title -- and the menu is not settled
sylpheed-port found ptloop01/02 free-running in their renderer on the menu path,
pinned them, and was explicit that pinning picks one pose rather than the game's:
"a capture question, not a harness one". It is, and it lands in my lane.

On the title it is now answered. Those leaves rest at (441,270) 200x90, INSIDE
the box the ptlogo_eff3 era adjudication uses, and across my two JP captures from
different sessions they are byte-identical: 0 of 18 000 px, max |d| 0, against a
whole-frame contrast of 116 492 px differing. So they are static at rest, and the
in-box between-session noise of 0.32 is not theirs -- the 645 differing pixels
all lie in a 30-row band at y 99..128, nowhere near the loop rect. That also
closes the reach caveat on the EN->JP noise transfer.

The MENU is a different bundle and is not settled. Build 5 declares the same rect
with a single static keyframe, and that is where their row drifted.
menu_loop_rest.sh was written to capture five settled menu frames and diff the
rect; it did not complete. The run reached a title at t=146 s and (A) did not
take across six attempts -- the documented intermittency where the attract loop's
title accepts nothing, unlike the boot title. Recorded rather than re-rolled.

Two committed main-menu captures cannot substitute: they differ across 57 % of
the surface (different geometries and capture paths), so the 88 % differing on
the loop rect measures the mismatch, not the loops. The control fails and the
comparison is void.

navigation.md gains the trap that cost this iteration a run: kill -9 on xenia
orphans /tmp/xenia-canary.lock, the next run-canary refuses to STDERR where a
polling script never looks, and a probe then sampled a dead display for 484 s
reporting `other` every 4 s -- because screen_id.py on an empty screen returns
`other` and "not the title yet" is indistinguishable from "there is no emulator".
Kill plainly so it clears its own lock, and assert the emulator is alive before
entering any wait loop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 15:43:29 +00:00
sylph-decoder
281a058aca re: a second JP capture closes the transfer -- and corrects my own noise claim
Last turn I transferred the EN title's capture noise to the JP box and flagged
the gap: build 7 carries ptloop01/02.rat which may animate inside that region
where the EN plate does not, and the era adjudication rests on a single capture.
Took a second, independent capture from a fresh boot in a separate session
(jp_title_session.sh -- sets ja, captures, always restores en; verified back at
language=1).

Within-run stability reproduces: 0 of 138 600 px in the ROI across four
comparisons, with 47k-73k px moving whole-frame as the contrast control.

BETWEEN SESSIONS, inside the box the adjudication uses: 645 of 164 124 px
differ, RMSE 0.3215, against 116 492 px whole-frame -- genuinely different
sessions. And the verdict reproduces to three decimals: stale 58.412 -> 58.413,
fixed 41.690 -> 41.692, margin 16.722 -> 16.721.

The shape is the useful part: capture noise moves both candidates together, so it
nearly cancels in a MARGIN. Absolute scores moved 0.001-0.002 while the margin
moved 0.001 against an in-box noise of 0.32. A margin between two renders scored
on one capture is far more robust than either score is.

CORRECTION to a claim I made earlier today and sent to the port: I said the
settle-vs-rest negative was STRENGTHENED because 1.48 sits below the whole-frame
capture spread of 2.8. Wrong comparison -- the measurement lives in the box, and
in-box between-session noise is 0.32, so 1.48 is well above it. The negative
rests on the render axis alone (1.2, ratio 1.2x), exactly as first stated. I
reached for a number that was to hand rather than the one that applies, which is
the same family as the errors we have both been cataloguing.

METHOD gains: match the noise floor to the quantity, including which noise
applies; and sylpheed-port's point that an instrument which rounds away the thing
being verified cannot verify it (they called a harness reproducible from an RMSE
printed to two decimals when the residual was 0.0565).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 15:24:56 +00:00
sylph-decoder
f16338bc88 re: measure the CAPTURE-axis noise floor -- 0 in-box, and the era result survives
sylpheed-port found their main_menu row drifting 13.25-13.30 across runs on a
free-running spin clock, and made the general point that a margin only means
something against the noise it sits on. My --at plateau measures the RENDER axis;
it says nothing about how much the score moves between two CAPTURES of the same
screen, which is what a single JP grab is exposed to.

Measured from two independent captures of the settled EN title at different
phases of its free-running plate pulse, scored against one render:

  whole frame     peak 31.302  trough 28.463   spread 2.839
  inside the box  peak 21.230  trough 21.230   spread 0.000

The zero carries its control: the two captures differ by 83 496 px whole-frame
(max |d| 174), so they are genuinely different grabs, and by 0 inside the box --
the screen's free-running element is the plate, which lies outside the logo
region the adjudication uses.

Margins re-stated: stale-vs-fixed 16.7 is 14x the render noise and >=5.9x the
whole-frame capture noise, so the era result survives on both axes. And the
settle-vs-rest negative is STRONGER than first stated: 1.5 is not merely inside
the render plateau's 1.2 flatness, it is below the whole-frame capture spread of
2.8 as well.

Reach recorded: this transfers the EN title's capture noise to the JP title's
box, and build 7 carries ptloop01/02.rat which may animate inside that region
where the EN plate does not. A second JP capture would settle it and has not been
taken.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 15:17:22 +00:00
sylph-decoder
ee5ed2cfd2 re: count the in-range fallbacks -- and the control that failed is the answer
sylpheed-port pointed out that classifying defaults "by inspection" is exactly
the method that cannot see an in-range fallback, and that correction applies to
my own sweep from an hour ago: I waved 64 sites through by reading them.

Counted instead, disc-wide over 965 builds and 24 811 keyframes:
  ui_layout.rs:1681  untimed poses (would fabricate t=0):        0
  ui_layout.rs:1010  pose_at queries 168 264, None (reads a=0):  0

Two zeroes, which is the result this corpus now distrusts most, so the detector
was made to prove it can see a hit: ask pose_at for a time no build declares.
The control FAILED -- 10 906 out-of-range queries, 0 None -- so the detector was
blind and the :1010 zero measured nothing.

The failure is the finding. pose_at is TOTAL: reading the source, its only None
path is an `if ks.is_empty() { return None }` guard, and disc-wide there are 0
elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is unreachable
BY CONSTRUCTION, which is stronger than "0 in this corpus" -- and it was
established by the control failing rather than by the count passing. Without the
control this corpus would have recorded a true conclusion resting on a
meaningless number.

:1681 stands differently: 0 of 24 811, and time really is Option<u32> with the
stale reader demonstrably producing None (its screen info prints a trailing -),
so the state is representable and a detector would see it. :973 is not a hazard
-- guarded two lines later by `if tmax == 0 { return false; }`, where reading is
sufficient because the guard is the proof.

METHOD gains both: a zero is worth nothing until the detector is shown able to
report non-zero; and the habit under several of this week's errors, which is
reading a PROXY for the thing when the thing itself is one command away -- a line
count for an era, a type name's spelling for its default, an ordinal for an
entry, a fallback's text for its firing rate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 15:15:42 +00:00
sylph-decoder
593ce46069 re: sweep my own crates for fallbacks that fabricate a quantity
The mirror of sylpheed-port's sweep after their exit_ramp_units catch, where a
refuted 24.0 survived in a `get(..., 24.0)` fallback because the authored entry
had been deleted as progress and the deletion was a no-op.

112 fallback sites across sylpheed-formats and sylpheed-cli. 64 supply 0, false,
empty or Default -- sentinels asserting nothing. Of the 48 remaining most are
pass-through or an extent. Positive control: the filter found media.rs:314
unwrap_or(anchor), the voice-region start fallback landed earlier this session,
so the detector finds a known case rather than only reporting absence. The
mesh.rs cluster (1.0, 0.85, 0.5, 0.70, 0.45) is env-var tunables with defaults
documented in xbg7-mesh.md.

ui_layout.rs, the crate the port pins, has 8 sites; 6 sentinel or pass-through
and 2 that could fabricate a quantity. Both fabricate a value that is
LEGITIMATE, which is worse than the port's conspicuous 24.0:

  :695  unwrap_or((DESIGN_W, DESIGN_H)) -- 1280x720, which is what every real
        screen states, so no parser output can distinguish read from invented.
        MEASURED: it fires 0 times in 965 builds disc-wide, so design_w/design_h
        is read and the port can rely on it.

  :1681 kf.time.unwrap_or(0) in the serialiser -- 0 is a real keyframe time
        (pose 0's time IS 0). Unreachable today under the corrected record
        layout, the same status as their exit_ramp_units branch, but a
        fabricated 0 would be indistinguishable from a real one.

The measuring instrument failed its own control first: a version reading EVERY
RATC child reported all 965 builds stating a non-standard design size
(GP_TUTORIAL 12x3), where `screen list` prints 1280x720 for every one -- a T8aD
sprite header read at +0x18 is garbage that passes the range test. Filtered to
the .rat records, it reproduces screen list exactly.

METHOD: a fallback default is an authored value no reader can see, and the
dangerous ones are IN-RANGE -- the only way to know is to count how often they
fire, which no parser output reveals.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 15:06:15 +00:00
sylph-decoder
c7237edc9b re: an uncontrolled capture instant, and why the ptlogo_eff3 result survives it
sylpheed-port's harness grabbed main_menu at t=9.00 in one session and t=8.00 in
the next. One keyframe unit apart, mid-build-in, is 70 % of the picture, and it
read as "the change broke two screens" -- a real measurement of the wrong thing.
The instant was stable WITHIN a session and drifted BETWEEN them, so every cheap
reproducibility check said deterministic. Their flags are their harness's, not
sylpheed-cli's (checked: `screen` has only list/info/render), so the tool defect
is not in my crate -- but the hazard generalises to every live capture here.

It would void this iteration's ptlogo_eff3 adjudication if the JP capture had
been taken at an arbitrary moment. It was not, and for two independent reasons
recorded rather than assumed: the grab was gated on the plate pulse, the title's
own settled signature, with the gate and a contrast control written beside the
capture in jp-title-at-rest.txt; and the --at sweep shows the capture on a
plateau flat to 1.2 RMSE across 105 units against edges at 78, where a capture
caught mid-build would give a sharp minimum. The sweep was run for a noise scale
and answers this too -- which is luck, so METHOD now names both defences.

METHOD: pin a capture's instant explicitly, and do not infer stability from
repeat runs inside one session. Gate the grab on a settled signal prospectively,
and sweep --at retrospectively -- a broad flat minimum with sharp edges means at
rest, a sharp minimum means the instant is load-bearing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:57:55 +00:00
sylph-decoder
0c2910636a re: audit my own era comparison against the shared-target-dir trap -- it holds
sylpheed-port found that a shared CARGO_TARGET_DIR across two source trees
serves one binary to both: cargo fingerprints per source path, so building tree B
into a directory last written by tree A prints "Finished" in 0.15 s and changes
nothing. Their harness scored against a decoder from an unnamed tree for hours,
and it HAPPENED to be the correct era -- agreeing by luck, which is worse than
disagreeing because nothing prompts the check.

My own era comparison could have died the same way, so I audited it rather than
assuming it was fine: the two binaries have different md5s (7516bdac vs
8370e0e9), they were built into SEPARATE target dirs, and the era control still
distinguishes them live -- `rest t=70 [12 70 80 -]` against `rest t=12
[0 12 70 80]`. The result in ui-resting-pose.md stands, now with the evidence
that it stands.

Also raises main-is-the-stale-era.md from hygiene to a defect anyone can build.
Two things landed since it was written: the corrected association is now
confirmed against the running game (RMSE 41.69 vs 58.41 on a live title_jp
capture, a margin ~14x the noise floor), and the port confirmed their published
branch carries the stale ui_layout.rs, md5-identical to main's. So every
published ref except this branch ships the decoder the game disagrees with, and
nothing in a build warns you. Merging is a human's call; the page records the
cost of not making it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:53:41 +00:00
sylph-decoder
84cf98477f re: the record-layout fix is confirmed against the GAME, and settle-vs-rest is not
The era test left one element responsible for all 74 507 differing pixels on
title_jp -- ptlogo_eff3.t32, the corpus's named plateau-less rest() discriminator
-- with two candidate rest poses, (108,72) stale and (98,42) fixed. There is a
capture of that exact screen, so the oracle can choose.

Scored over the 388x423 box where the two renders differ, so the result is not
diluted by the ~92 % of the frame that is identical:

  stale era  rest (108,72)   RMSE 58.412
  fixed era  rest  (98,42)   RMSE 41.690   <- the game agrees with the fixed era
  fixed era  --settle t=213  RMSE 40.210

Until now the keyframe record-layout fix rested on internal consistency: 0 of
1 042 multi-segment alpha ramps constant-rate under the old reading against 857
of 1 540 under the new. Strong, but not a measurement of the game. It now has
one, on the single screen where the two readings change pixels.

Three controls, all run first. Alignment found by sweeping the vertical offset
rather than assuming it -- 45 gives 32.41 against 56.37 and 53.08 either side, a
sharp minimum at the known game-surface offset. The scoring box discriminates:
the same box against a different screen's capture gives 98-103 against 40-58
here. And --black changes nothing (58.412/41.690 either way) because every pixel
in that box is covered by an element -- recorded because the flag's help says a
framebuffer capture must be compared against a black canvas, and here it happens
not to matter.

Sweeping the screen's own timeline with --at gives the noise scale: the capture
sits on a plateau from t~135 to t~240, flat to 1.2 RMSE across 105 units, rising
sharply outside (78 at t=0 and t=270). So the stale-vs-fixed margin of 16.7 is
~14x that flatness and decisive, while the settle-vs-rest margin of 1.5 is INSIDE
it and is not. This capture separates the eras and cannot separate the policies;
the settle-instant proposal stays unadopted.

Refutation attempted: sylpheed-port's adjudication that their shipped pose is
closer to the game than their reference. It SURVIVES, independently and by a
different metric, in the same direction.

Also concedes that my "your branch is the stale era" reasoning was invalid -- I
inferred era from a line count, which is the error they named -- while recording
that the conclusion holds for the ref I could see: origin/auto/port-p6-audio's
ui_layout.rs is md5-identical to origin/main's.

METHOD: two things that should differ producing identical output is a broken
experiment until proven otherwise, and a zero is its most dangerous form. Four
instances now. Verify the inputs differ before believing the outputs match, and
do not infer that difference from a proxy -- line count is not era.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:48:30 +00:00
sylph-decoder
82ce9dbaaa re: the decoder eras DO change pixels -- 7 of 16 bundles, and title_jp is one
The reach test I deferred twice. sylpheed-port tested three screens across the
stale and fixed ui_layout.rs eras, found 0 differing pixels, and concluded the
eras explain nothing. Built both eras from source and rendered EVERY composable
GP_TITLE bundle through each.

7 of 16 differ. Entries 0-6, 8 and 9 are byte-identical -- which includes title
(4), main_menu (5) and extras (6), so the port's result reproduces for the
screens they picked. Entry 7 (title_jp) differs by 74 507 px, RMSE 12.409; the
two loading bundles by 49 771 px, RMSE 10.078; the four splashes by 23-33k px at
RMSE 0.94-1.78.

So "the eras explain nothing" is true for three screens and false for the
archive. It is specifically false for title_jp, which is one of the two rows
their check-all now allows BY NAME with the reason "rest-pose sparkles". Their
measurement of that screen was 0 and mine is 74 507; recorded with exact flags as
a disagreement for them to check, not adjudicated. Noted that their branch's
ui_layout.rs is the stale one (20 ins / 488 del against the pin), so a binary
built from their workspace HEAD is the stale era.

Two controls, both run first. The binaries genuinely embody the eras: build 5's
pteff00.prm reads `rest t=70 [12 70 80 -]` stale against `rest t=12 [0 12 70 80]`
fixed. And the renderer is deterministic: same binary, same flags, twice, 0
differing pixels on entries 7 and 12 -- without which every number is noise.

Mechanism on entry 7 is a single element, ptlogo_eff3.t32, rest (108,72) ->
(98,42). That is the element MISSION.md and ui-resting-pose.md already name as
THE plateau-less rest() discriminator, so the era difference on the JP title is
our existing open question surfacing rather than a new one.

And a trap: entries 10-15 differ by up to 49 771 px with NO rest position change.
The rest selection moves to a keyframe at the same (x,y) with a different scale
and alpha. My first extraction compared only the rest (x,y) column and would have
reported a difference with no cause. A pose is position and scale and alpha.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:42:29 +00:00
sylph-decoder
e803930e88 re: the black gap between screens is NOT a load -- measured, three legs
sylpheed-port's BLOCKED ask #2. The gap was the one quantity in the transition
with no rule: measured at 0, 3 and 2 frames across three transitions, and I had
proposed it might be a load, which would make it emulator- and storage-dependent
and unauthorable.

Leg 1, bundle size runs the wrong way. If the gap were the incoming bundle
arriving, the biggest bundle would gap longest. Build 4 is 12 278 666 B and gaps
ZERO frames; build 5 is 6 977 437 B and gaps 3 and 2.

Leg 2, ran title->menu a second time from cold. The outgoing ramp is
byte-identical (63, 127, 191, 255) and the gap is 3 frames in BOTH runs.

Leg 3, and the two runs are not a null comparison -- which is the objection leg 2
invites. The captures refute it themselves: press-to-first-change differs by ~12
frames between them (~25 against ~10). Something in this transition really is
cache-sensitive and moved by 0.4 s, while the gap did not move at all. The
control comes from inside the measurement rather than from an assumption that
conditions differed.

So the gap is deterministic to the frame and not a load. It is also not constant
across transitions (0, 3, 2, 3) and not in the fade group -- the port reports 866
keyframes across 16 screens with 0 untimed. A deterministic game quantity with no
rule found; black_hold_units stays 0, and "not a load" must not become a reason
to author a constant.

The load proposal in screen-transitions.md is marked refuted rather than deleted.

Also fills in docs/game/navigation.md, which the standing brief asks me to keep
and which I had not touched while measuring four transitions: a player-side
section on what a screen change looks like, and three scripting traps -- that
`pkill -f xenia_canary` kills the shell that ran it (cost a launch today, and the
same trap is already in METHOD for pgrep), that screen_id.py reports `menu`
during the attract loop, and that it cannot tell EXTRAS from the main menu.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:28:00 +00:00
sylph-decoder
6afe0c4ab8 re: main is 171 commits behind and carries the STALE keyframe reader
Went to refute sylpheed-port's finding that their check-all allowance ("the pin
is not on main, so this compares two decoder eras") explained nothing, by
extending its reach past three screens. Found the premise is understated.

  git rev-list --left-right --count origin/main...HEAD  ->  0  171

main has nothing we lack; we are 171 commits ahead of it. Its tip is dated
2026-08-29, the pin tag is not an ancestor of it, and its ui_layout.rs still
reads "Keyframe time, or None for the group's last frame" -- the pre-fix
association that takes a pose's time from the NEXT record and leaves a group's
final pose untimed. That is the exact bug that left fade_quads.py stale and made
screen-transitions.md publish a 0.87-4.08 s fade-in for a 0.20-0.27 s ramp.

So "sync with main first" is currently backwards: main is the stale era, and
`git merge origin/main` is a no-op from any topic branch -- it says "Already up
to date" every iteration, which reads as "I am current" and means "main has
nothing". Do not pin to main.

The port's measurement stands: across their three screens the two eras render
identically, which is consistent with the association fix moving TIMES and not
pixels -- same signature as the .tbm and stale-sylpheed-cli findings.

Not settled: whether the eras render identically beyond three screens (the
disc-wide build-and-compare is not done), and why 171 commits are unmerged,
which is a human's call.

Also adds the METHOD entry the port offered: an allowance is a claim and it
decays; allow by NAME, never by COUNT, because a count cannot notice that a
different row started failing while the total held steady.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:18:30 +00:00
sylph-decoder
589d23e44a re: (B) from EXTRAS DOES go black -- "(B) has no black interval" refuted
sylpheed-port's BLOCKED.md ask #1. They declined to suppress their uniform
black_hold on the cancel path because (B) menu->title was one transition. The
test says they were right.

EXTRAS -> main menu, also via (B): the outgoing quad ramps frames 34-38 (5
frames, exactly build 6's declared 10 units), then frames 39 AND 40 are
completely empty -- 3 draws, zero textured, a harder black than either earlier
capture -- then the incoming menu's quad decays 41-45. So (B) does not imply a
cross-fade; menu->title is the outlier of three, and the generalisation I was one
step from publishing is false.

The screen was verified, not assumed. screen_id.py cannot separate EXTRAS from
the main menu, so which_title_screen.py checked the armed frame: extras 18.58 vs
main_menu 29.85, margin 11.27, inside the 9.9-11.7 band its control sets on four
known captures.

Three transitions now agree on one thing and disagree on another:

  outgoing ramp = the declared final ramp, THREE FOR THREE, against three
  different declared values (10u/5f, 8u/4f, 10u/5f), and exactly linear where
  nothing overlaps it. Authorable from the file.

  black gap = none / 3 frames / 2 frames. Not a per-button property, not a
  per-direction property, not a constant. black_hold_units should not be
  authored as one.

Build 5's incoming ramp is confirmed at 12 units by its RATE rather than its
count: the count came out 5 against a predicted 6 in both runs -- reproducible,
so not noise -- but capture 3's steps are -21, -42, -43, -42, i.e. 255/6 per
frame after a half-step start. Capture 2's decay does not fit that and is
unexplained.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 14:15:58 +00:00
sylph-decoder
2a1ecc1c63 re: a menu/EXTRAS discriminator that failed its control, and the fix
sylpheed-port's BLOCKED.md ask #1 -- does (B) from EXTRAS also show no black
interval, or is "(B) has no black" one screen pair -- needs the harness to know
it is on EXTRAS. screen_id.py cannot tell: both are dark blue GP_TITLE screens
and it reports `menu` for either.

which_title_screen.py correlates a grab against our build 5 / build 6 renders.
First version FAILED its control: it called live-main-menu.png "extras" and
live-extras.png "main_menu", both backwards, margins under 1.1 on RMSE ~33.
Cause: it applied the y=45 game-surface offset unconditionally, but only a full
1280x720 display frame has the menu bar -- a 1279x675 grab IS the surface, and
two of the three reference captures are surface-sized. Offset made conditional;
the control now passes 4/4 with margins 9.9-11.7 against ~18 within-class.

The tool is a navigation aid for driving the emulator and says so: it identifies
a screen by agreeing with our own renders, so nothing measured may rest on it.

Also records the METHOD entry sylpheed-port offered from their own wedged check
script: an absence of output is not a status. They reported "still running, two
lines, both ok" for three iterations while the first attempt had died silently
under its own timeout with block-buffered output -- zero information, reported
as patience. An orphan from an older form of the same script was found running
after 9.5 hours. Line-buffer and bound long jobs, and check the artifact rather
than the exit code: the artifact reached its correct duration while the process
never returned.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 13:59:47 +00:00
sylph-decoder
aa4ffafbc5 re: the decaying quad is the INCOMING screen -- and (A) and (B) are different shapes
Last iteration left an unidentified full-screen untextured quad decaying
255->15 during a menu->title transition, which build 5's declaration does not
account for. Hypothesis: it is the INCOMING screen's own pteff00, which opens at
a255 and clears. 8 frames matching build 4's declared 16 units is a FIT, so the
test was a transition whose incoming screen declares something else: title->menu
brings in build 5, 0->12 = 12 units = 6 frames. Prediction recorded before the
run.

Measured: menu->title decay 8 frames (incoming build 4, declared 8), title->menu
decay 5 frames (incoming build 5, declared 6). Different incoming screen,
different decay, in the predicted direction. The second is one frame short of
prediction, inside the documented +-1.

The tell that clinches it: a screen contributes TWO primitives, pteff00 at 255
and pteff02 at 64. The settled menu's untextured set is [64]; at frame 34 it
becomes [64, 255, 64] -- build 4's opening pair, which no single element
explains.

Bonus, and it closes the alpha puzzle: in capture 2 the outgoing quad ramps with
no other untextured quad present -- 63, 127, 191, 255, steps of exactly 64, four
frames, against build 4's declared 261->269 = 8 units = 4 frames. Exact and
exactly linear. Capture 1's 102/127/255 was a composite of two overlapping
quads, as sylpheed-port proposed.

The thing neither of us predicted: the two directions are not the same shape.
(A) title->menu is SEQUENTIAL with a real black interval of 5 frames (~10 units,
against the port's authored 9). (B) menu->title is a CROSS-FADE with no black
interval at all -- the incoming title starts drawing at frame 34, before the
outgoing menu's quad begins ramping at 40. Authoring one hold for both directions
inserts black that (B) does not have.

Also fixed: fade_pair.py's automatic rising/decaying classifier worked on capture
1 and produced nonsense on capture 2, where the title has no full-screen
primitive at rest and the heuristic latched onto a transient. It now prints and
does not decide.

Refutation attempted: sylpheed-port's structural prediction of a 6-frame decay
for an incoming menu. Measured 5. Survives as direction, one frame short as
duration; recorded as both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 13:51:48 +00:00
sylph-decoder
d8b71cfb08 re: withdraw "the fade-out overlaps the content" -- it is a gap, and the port was right
sylpheed-port read the lead off the disc independently: content fade-outs start
at ptmsg 58, pteff10/pteff12/ptbtn05 60, against the quad's ramp at 70. That
reproduces my measured six-frame lead exactly (12 units = 6 frames) but has
content FINISHING two units before the quad starts, where I had published
overlap.

Checked which draws I had been watching. The content sprites are TEXTURED: they
fade over frames 34-37 and are gone by 39, and the black quad appears at 40 --
a one-frame gap, which is their two units. What overlaps the quad is a
different, UNTEXTURED full-screen quad decaying 255->...->15 across frames
34-41. It is unidentified: build 5 declares only pteff00.prm and a
single-keyframe pteff02.prm, neither of which is that decay. Recorded as an
open observation, not named from one capture.

So the shape is sequence, not overlap.

Also flagged, against my own interest: their "18 vs 19, one unit apart" compares
different intervals (content-start->black vs ramp-start->next screen), and the
capture's frame axis is not phase-locked to the file's unit axis -- the two
plausible alignments differ by two frames with nothing here to distinguish them.
So that agreement holds at one alignment and is not a confirmation. The quad's
alphas (102/127/255) also do not sit on a linear ramp across t=70->80, which is
unexplained.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 13:40:42 +00:00
sylph-decoder
4bcb35cef7 re: the transition is overlap, not ramp-then-hold -- and the fade-in was 5x wrong
screen-transitions.md carried a 14-unit "black hold" that the page itself
flagged as arithmetic rather than measurement. Measured it against the running
game; the guess was wrong, and finding the instrument to measure it turned up a
second, larger error in the same page.

1. fade_quads.py was STALE. It read each pose's time from blk+36 -- the next
record's time word -- the association the keyframe record-layout fix retired in
the crate. sylpheed-cli was rebuilt at the time; the Python helper was never
swept with it. Signature: it cannot time a group's last pose, so it printed a
trailing `t=-`. Fixed, controlled against the rebuilt `screen info` ([0 12 70
80] for build 5's pteff00.prm).

2. Through it, the page labelled the quad's CLEAR-hold as its fade-in and
published 0.87 s / 0.97 s / 4.08 s for a ramp that is 0.20 s / 0.20 s / 0.27 s.
A port pacing its menu fade-in off that would run it 5x too slow.

3. The measurement. fade_decompose.sh boots to the main menu, arms the UI draw
capture there, then presses (B), so one 260-frame window holds the whole screen
change. The fade quad is identified rather than guessed: a .prm carries no
tex[base=] and paints last, so it is the last full-screen untextured quad of a
frame. Control first -- the quad's ramp is decoded at 10 units = 5 frames, and
measures 4 submitted-frame steps with one unlogged frame in the span.

Result: content elements begin fading at frame 34; the black quad first appears
at 40 and is opaque by 43; the menu's last frame is 45; frame 46 has 6 draws
against 12. So the ~14 extra units are the content's own fade-outs OVERLAPPING
the quad's ramp, not a hold after it, and the inter-screen black is one frame.

Refutation attempted: sylpheed-port's entries 13/14 twins. Re-derived off the
disc -- 3.06 / 4.33 / 47.91, identical to two decimals. Recorded as confirming
their addressing and arithmetic, NOT as independent support: same renderer,
same disc, which is their own rule.

Reach: one transition, one run; the frame axis has gaps (232 headers over frames
3..260), so every span is +-1 frame.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 13:35:56 +00:00
sylph-decoder
c364cde476 re: sweep the disc for the ordinal foot-gun -- GP_TITLE was the mildest case
Last iteration I retracted three claims because `--build 10/11` on GP_TITLE are
entries 12/15, and named the untested remainder in my own report: how much else
in the corpus used a build ordinal as an entry index. This is that sweep.

`screen --build N` indexes a predicate-filtered list, so every rejected entry
shifts every later ordinal. Disc-wide: 21 of 24 build-bearing archives diverge,
18 of them at ordinal 0 -- `--build 0` is entry 108 in each GP_MAIN_GAME_*2D,
24/26 in GP_HANGAR_ARSENAL/GP_READY_ROOM. GP_TITLE is the ONLY archive whose
first ten ordinals are the identity, which is the sole reason 207 of the
corpus's 226 build citations are safe. Second foot-gun: `--all` swaps the
predicate and renumbers 18 archives, so `--build N` and `--build N --all` are
not the same object.

The instrument failed its control first. A version using parse_build as the
predicate reported GP_TITLE as 16 builds, ordinal == entry throughout -- it
would have certified the exact bug it was built to find. The shipped version
uses the same predicates screen_builds() uses and reproduces `screen list` on
GP_TITLE exactly.

Audited all 226 citations. One real defect: a five-row table in
ui-keyframe-time-unit.md headed "declared element (build 11)" spans builds 10
and 11 -- palogo_sqex is in 10. All five placements re-verified and correct, so
the linear-ramp measurement is untouched; only the label was wrong. Fixed with a
per-row bundle column. GP_DIALOG --build 0 and GP_DEBRIEFING_PILOTLOG --build 10
re-run and reproduce.

Refutation attempted: sylpheed-port's corrected mid-ramp test rests on
ptlogo_all_eff holding a=127 from t=112 to t=246. Their quote is exact and it is
a plateau. The refutation fails; their correction stands.

METHOD already carried the rule I broke, and ui-splash-addressing already said
the splashes need --all. The failure was not missing knowledge -- it was
addressing a bundle by index without grepping for the index first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 13:20:41 +00:00
sylph-decoder
f102cf9209 handoff+method: land the ordinal retraction where the claims live
Marks the two void splash rows in the capture-comparison data file, withdraws the
three claims in HANDOFF, and corrects the METHOD entry -- whose 'a gradient across
buckets is not a mechanism' near-miss was itself resolved by a counter-example
taken with the wrong index.

General form recorded: an index that silently means something else produces
well-formed output for the wrong object, and this project has now been bitten
twice from opposite directions with 'everything still validates' both times.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:59:58 +00:00
sylph-decoder
3356343cad re: RETRACT the splash settle windows -- --build takes an ORDINAL, not an entry
The port recomputed the publisher splash's widest keyframe-free gap as 190 units
against my 8 and said one reading must be wrong. Mine was, and the library was
never wrong -- only my invocation.

From the file: entry 10's union of times is [0,15,30,45,235,239,251,255], widest
gap 190, and settle_window() returns Some((45,235)). Entry 11 gives 145. Both
match the port exactly.

The cause is that screen render --build N takes a BUILD ORDINAL. screen list says
[10] entry 12 and [11] entry 15; the splashes are entries 10 and 11 and are not
screen builds at all, so my --build 10/11 rendered the LOADING screens. This is
the foot-gun HANDOFF already documents, which the port caught months ago in the
mirror direction.

Three retractions:

1. 'Width does not predict quality' -- withdrawn. It rested entirely on the
   splashes being width 8 while winning 75x. They are the widest of the five, so
   width and mid-ramp are perfectly confounded across every screen either of us
   has measured and the width hypothesis is NOT refuted.

2. 'My filter excluded the splashes' -- withdrawn; at 190 and 145 they were never
   near the 10-unit cutoff. The other half stands: it admitted the 10-19 bucket,
   the worst at 45.1 %.

3. The splash rows of settle-vs-rest-against-captures -- void. They scored
   loading-screen renders against splash captures. I discarded them for a railed
   gamma fit; the real reason is that they were the wrong screens, and the railing
   was that mismatch surfacing where my instrument could report it.

Surviving: the title row (ordinal 4 = entry 4) and the disc-wide censuses, which
iterate pak entries directly and never touch the ordinal path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:59:29 +00:00
sylph-decoder
ca41b81377 method: a borrowed threshold still has to be checked against the cases it decides
The under-10-units filter was documented and reasonable and wrong both ways: it
admitted the 10-19 bucket, the worst at 45.1 % mid-ramp, and excluded the two
splashes at width 8, the strongest evidence for the proposal it was serving. One
--settle invocation per screen would have shown this in seconds.

Plus the near-miss: the bucket gradient made 'narrow window means bad settle
pose' look obvious, and it is refuted by two screens inside the excluded band
that win by 75x and 33x. A gradient across buckets is not a mechanism.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:45:59 +00:00
sylph-decoder
9d32852724 re: census the settle pose's own failure mode -- and refute the obvious explanation
The port found ptmsg, the main menu's footer, at alpha 127.5 at that screen's
settle instant. Verified: build 5's window is [44,56] = 12 units and
screen render --settle already prints 'narrow -- this bundle may never settle'.

Disc-wide, elements caught mid-ramp at their screen's settle instant: 25.5 %
overall, 40.9 % on windows under 10 units, 45.1 % on 10-19, falling to 11.7 % and
15.0 % on wide ones.

The obvious reading of that table -- narrow window means the settle pose is bad --
is REFUTED by the screens that motivated the proposal, and I nearly published it.
The two splashes have an 8-unit window, narrower than the main menu's 12, and the
settle pose beats rest() there by 75x and 33x. Width does not predict quality.

The predictor is the port's own statement: the settle pose wins decisively where
rest() lands on a transient's peak, and loses slightly where rest() is already
sound and an element arrives after the window closes.

And my own rest_vs_settle filter was wrong in both directions: dropping bundles
under 10 units admitted the 10-19 bucket, the worst at 45.1 %, and excluded both
splashes at width 8 -- the strongest evidence FOR the proposal. A threshold taken
from a documented rule of thumb and applied without checking which screens it
admitted and which it threw away.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:45:33 +00:00
sylph-decoder
54254a86e1 method: correct 'cannot adjudicate against the incumbent' -- it needed a discriminator
The entry said a candidate-vs-incumbent comparison is the wrong shape of
experiment. Too strong. Two iterations later the same comparison adjudicated with
no new oracle, once a structural property was added that says which side is wrong
per disagreement -- does the chosen run contain the settle instant. Control 3072
of 3072; disagreements attributed 1036 of 1036.

Corrected rule: a bare comparison cannot adjudicate because a disagreement is
symmetric; it becomes decisive the moment a property breaks the symmetry per
case. Reach for an oracle when no such property exists, not as the first move.

With the tell that I had one available and did not look: I recorded the residual
as 'ambiguous by construction' and moved on TWICE without asking what would make
it un-ambiguous.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:38:44 +00:00
sylph-decoder
642341b12b re: rest_plateau() picks the wrong plateau -- and it is the whole residual
rest_plateau() selects the LONGEST run of identical adjacent poses, which need
not be the run covering the screen's settle instant. rest_vs_settle left a 21.9 %
disagreement that I recorded as ambiguous by construction. It is not.

  CONTROL  exactly one plateau, covering the settle instant:
           3 072 / 3 072 agree (100.0 %)
  TEST     more than one plateau, at least one covering:
           1 622 elements, agree on 586 (36.1 %)
           of the 1 036 disagreements, rest() landed on a run NOT covering the
           settle instant: 1 036 -- all of them, no exceptions

Both poses are genuinely held in these cases -- they are plateau cases, not
transients -- so this is rest() returning a pose the screen has ALREADY LEFT by
the time it settles.

This corrects my own METHOD entry of two iterations ago, which said a candidate
cannot be adjudicated against the incumbent it replaces. Too strong. The bare
comparison cannot; the comparison plus a structural property that independently
says which side is wrong in each disagreement can. What I lacked was not an
oracle but a discriminator.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:38:18 +00:00
sylph-decoder
b37eb4a5bc handoff: settle_time() itself beats rest() on the one screen that adjudicates
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:30:23 +00:00
sylph-decoder
10f469cbed re: settle_time() itself beats rest() against the game -- on the one screen that adjudicates
Closes the gap the port named: it ran my proposal against captures 3/3 in favour,
but tested ITS OWN settled pose rather than UiBuild::settle_time().

Geometry established first, because my first attempt got it wrong: a 1280x720
render meets a 1279x675 capture by CROP, not scale -- crop rows 0..675 gives RMSE
14.07 against 68.89 resized and 79.61 for the 45-row crop. The 45-row offset
holds for a full display frame; these captures are already the game surface.

Gamma fitted per pose so neither candidate can win on the fit:

  title      settle  g=0.84  RMSE  8.17  15.28 % >8
  title      rest    g=1.04  RMSE 20.92  70.84 % >8

The two splashes DO NOT ADJUDICATE and are not counted: their gamma fit rails at
the edge of the search range, still railing when widened to 0.30..3.00, so the
photometric model is wrong for them -- and with gamma railed their margins
collapse to 1.16x and 1.06x.

title adjudicates at an interior gamma and does so decisively, 4.6x on differing
area and 2.6x on RMSE. So the IMPLEMENTATION and not merely the direction is
supported.

Absolute agreement is poor -- the port's settled title row is 0.21 % where mine
is 15.28 % -- so the ordering is what this table carries, not the values. The
port's three-screen result remains the stronger evidence.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:30:07 +00:00
sylph-decoder
3aa47f77a7 method: a candidate cannot be adjudicated against the incumbent it replaces
Plus the two companions: any statistic keyed on where an element's visibility
ends is near information-free here (87.8 % end at a=0 from the screen's exit
ramp, which bit both agents within an hour), and the port's mirror -- my
threshold-free 'nothing is held on this path' criterion is correct on the
fallback path and fails outright on the plateau path, so a cleaner definition
that fails a control is worse than an ugly one that passes.

HANDOFF carries the proposal with its evidence, its failed control, and an
explicit refusal to change rest() in a crate the port pins on the strength of
something I cannot validate from my own side.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:23:10 +00:00
sylph-decoder
0c9224fbbc re: propose settle-instant posing -- and my control cannot validate it
The proposal: pose every element at the SCREEN's settle instant rather than
asking each element for its own resting pose. On the 2 249 fallback elements in
settling bundles the visible-pose rate falls 73.6 % -> 34.7 %.

But the control fails twice. Naive, over every plateau element: 46.6 %. That one
was misspecified and I caught it by asking what the number means physically --
rest() finds *a* held pose and many elements hold one during the build-in then
move on, so it answers a different question and disagreement proves nothing.
Restricted to elements HOLDING ACROSS the settle instant: 78.1 %, still not a
pass.

And the residual is ambiguous by construction: rest_plateau() picks one plateau,
so an element with two whose settle instant falls in the other will disagree --
and there pose_at(settle) is RIGHT. The control cannot separate 'the candidate is
wrong' from 'the incumbent is wrong'.

Recorded as the general point: comparing a candidate to the incumbent cannot
adjudicate when the incumbent is the thing under suspicion. It is the wrong shape
of experiment, not a tuning problem.

What does adjudicate is the oracle and it is the port's measurement, not mine --
publisher splash against a committed capture, settle-instant pose RMSE 2.17 /
0.01 % differing against --pose=rest 9.05 / 0.75 %. My numbers describe the
proposal's effect; they do not establish it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:22:44 +00:00
sylph-decoder
e988f6e090 handoff: correct the fallback number to 1457, and record the failed correction
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:13:57 +00:00
sylph-decoder
c89e4da723 re: my own 1697 audited -- and the first correction failed its control
Applying the port's physical-story rule to my own number. '1 697 fallback fires
return a visible pose' was published as if it were a defect count; it is not, since
an element that genuinely ends visible should rest visible.

The first correction split the 1 697 by whether the element's LAST keyframe is
visible: 347 correct, 1 350 transient peaks. Plausible, arithmetic fine, and
WRONG -- 12 278 of 13 991 elements (87.8 %) end at alpha 0 because a screen's exit
ramp drives everything to zero, so the split carries almost no information. The
1 350 is not published.

What survives needs no such split: the fallback runs only when no two adjacent
poses are equal, i.e. only when no pose is held, so every pose it can return is
un-held by construction -- and 1 457 of the 2 305 times it returns the element's
MAXIMUM alpha, the brightest un-held pose.

I ran that control only because the port had just been bitten by the same exit
ramp, its census calling ptmsg -- the main menu's permanent footer -- 'a 2-unit
flash'. Without its message the 1 350 would have shipped.

METHOD gains the sharpened form: the physical-story test catches confident FALSE
claims, not just nulls. A wrong number usually still has a story, just an absurd
one. Plus the tell that its fix was right -- re-keyed on the screen's span, the
false positives fell out on their own, and a definition that stops needing
hand-maintained exceptions is usually the correct one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 12:13:46 +00:00
sylph-decoder
ef851fec92 method: say what the number means physically and see whether the story survives
From the port, and a better generalisation than mine. I had been filing my
failures under 'an external quantity caught it', which prescribes finding an
anchor; anchors are not always available. The port's title_jp error had none --
every control passed because the metric was fine and the error was which frame it
scored. What caught it was asking why rest produced that light, which exposed a
4-unit sparkle whose rest.t is its own peak.

So: state what the number means physically and see whether the story survives
contact with the data. A wrong frame yields a number with no physical story
behind it, which is detectable from the inside. It subsumes the null-as-result
cases too.

And a control does not test this: a control proves the INSTRUMENT and says
nothing about the SAMPLE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:55:10 +00:00
sylph-decoder
ad9cd948c6 re: the port's two extra elements are PLATEAU cases -- refutation succeeds, and its point gets bigger
The port listed palogo_gamearts_eff and palogo_seta_eff among GP_TITLE's four
visible dwell-fallback fires; this census listed only palogo_sqex_eff and
palogo_anima_eff. Checked, and the census is right: gamearts_eff and seta_eff
hold a=255 at identical x, y and scale from t=15 to t=30, which is a plateau at
pair index 1, so rest_plateau() handles them and t=15 is the CORRECT answer. They
are not fallback cases.

The distinction is not cosmetic -- a plateau is a pose the element genuinely
holds, and only the dwell fallback is the unsound path.

But the refutation makes the port's underlying point STRONGER. Its rest pose for
those two really is the flash's peak, reached by the SOUND path. So 'a rest
render is not a frame to score against a capture' does not follow from the
fallback being unsound: a plateau can itself be the held peak of a transient. The
rule covers both paths, and the fallback census understates the exposure rather
than bounding it.

Also records the port's oracle number for the rule -- publisher splash against
the committed capture, timeline RMSE 2.17 / 0.01 % differing against --pose=rest
9.05 / 0.75 %, 75x the differing area.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:54:43 +00:00
sylph-decoder
28b06f9a31 handoff: rest is not a settled pose -- 1697 of 2305 fallback fires return a visible pose
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:50:25 +00:00
sylph-decoder
cae2f7596e re: the rest() fallback -- its example dissolved, the question got bigger
ui-resting-pose.md built its dwell-fallback section on GP_TITLE build 7's
ptlogo_eff3.t32, listing keyframes [46, 61, 103, -] -- the STALE PARSER's output.
Corrected they are [0, 46, 61, 103], the longest gap moves from 61->103 to 0->46,
and BOTH ends of the new longest gap are a=0. The element no longer selects a
visible pose under either indexing, and build 7 renders byte-identical under the
corrected and legacy readings (0 px differ). MISSION lists this element as the one
case a Japanese capture was needed to discriminate; it is not.

But losing an example is not closing a question, so: disc-wide census. The
fallback fires on 2 305 of 13 991 elements and returns a VISIBLE pose in 1 697 of
them -- 74 %.

GP_TITLE is 5 fires, 4 visible, and all four are on the SPLASH screens:
palogo_sqex_eff and palogo_anima_eff, each [0:a0 15:a255 30:a212 45:a0], a flash
peaking at 15 and dead by 45 where the fallback returns t=30 a=212.

Independently converged on from the other side: the port, working from the JP
capture and knowing nothing of this census, found ptlogo_back2eff1's rest.t at the
peak of its own 4-unit sparkle with six staggered across the logo, so --pose=rest
fires every sparkle at once -- a frame the game never shows.

Consequence recorded as a rule: a render posed at rest is a legitimate common
reference for comparing two DECODERS and is not a frame to score against a
capture of the game.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:50:07 +00:00
sylph-decoder
3b52240d83 handoff: the JP title at rest is captured, with its rest demonstrated
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:37:54 +00:00
sylph-decoder
279a33846e re: the Japanese title at rest -- the capture MISSION has wanted since 2026-08-29
Asked for by the port: its title_jp row drifted, localized to a 350x396 block at
(405,74) -- the logo stack -- and with no JP capture in the corpus it could say
the renderers moved apart but not which one moved.

Three earlier attempts failed to reach the interactive title in either locale.
The reason is now known and was never the locale: A at the title needs a
signed-in profile, and no run had one.

Locale set through canary's own persisted XConfig and restored afterwards,
verified back at language=1. INDEPENDENT confirmation it took: the XMA probe
logged a different voice-context set from every English run (ja 1112064 /
1150976 / 1177600 against en 1294336 / 1118208 / 1171456), so the switch reached
the guest rather than being a menu-language cosmetic.

'At rest' is demonstrated rather than assumed. Five frames ~1.5 s apart after the
plate pulse says the screen has settled: the port's ROI is byte-identical across
all of them, max |delta| 0 over 138 600 px, while the WHOLE FRAME moves 39 584 to
71 927 px -- the plate pulse and sweeps. That contrast is the control: the
instrument can see motion and the ROI still shows none.

The capture shows what the English title does not -- the katakana subtitle, and a
crystalline burst behind the wordmark, the ptlogo3a/b/c + ptlogo_back2eff* stack
that this corpus records as transparent at rest in English. Exactly the region
the port's drift is localized to.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:37:35 +00:00
sylph-decoder
8ad87012fb handoff: the fade ramp is 10 units decoded, and screen info was stale
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:22:59 +00:00
sylph-decoder
83b7316065 re: the CLI binary was STALE -- screen info's keyframe times were the old parser's
The copy of sylpheed-cli in this container was built 2026-08-29 12:38, before the
keyframe-record-layout fix. The old parser shifted every time by one slot and
could not time a group's final pose, printing a trailing '-':

  stale  pteff00.prm  4 kf  rest t=70  [12:0,0 70:0,0 80:0,0 -:0,0]
  fresh  pteff00.prm  4 kf  rest t=12  [ 0:0,0 12:0,0 70:0,0 80:0,0]

Both outputs are well-formed and neither announces its age.

That refutes the premise of screen-transitions.md's 2026-08-29 section, which
argued from 'there is exactly one untimed keyframe, and every element has it'.
There is no untimed keyframe, so the question it answered -- is 0.4 s the missing
duration of that keyframe -- has lost its subject. The ratio test in the same
section is untouched.

And it decodes the number the port asked about: pteff00.prm's final ramp is
70 -> 80 = 10 units, about 0.167 s, not the ~24 this page authored. I tried to
refute the port's 10 against the bytes and could not.

So the measured ~0.4 s is NOT the ramp alone -- 24 units measured against 10
decoded. That the remaining ~14 units are exactly the black hold is arithmetic
that fits (0.233 s, inside this corpus's own 0.17-0.23 s plateau) and is NOT a
measurement; the decomposition stays open.

CONTAINER-NOTES gains the trap. Renders are byte-identical across the two
binaries (max per-channel difference 0 on GP_TUTORIAL build 0), so element
identity, pivots, keyframe counts and screen render output are unaffected -- it
is the times that move.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:22:43 +00:00
sylph-decoder
951b9a4c80 handoff: Q5's two weak clauses are measured -- both stampable now
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:18:42 +00:00
sylph-decoder
1eee838f30 re: three empty evidence cells filled in one run -- auto-repeat, B on a settled title, plate redraw
1. NO AUTO-REPEAT. A 2.0 s held DOWN moves the cursor exactly once. The counter
   passes its control first: a single 0.12 s tap gives exactly 1 spike and the
   hold gives 1, with the move spike at 0.0202-0.0220 against a 0.0003-0.0038
   noise floor. The port had flagged that the hedge 'at the durations tried' was
   carrying the claim, and it was -- nothing recorded a HELD direction.

2. B ON THE SETTLED TITLE DOES NOTHING. Twenty seconds after a
   delivery-confirmed B the screen is still the title with PRESS (A) BUTTON up,
   read off a capture that names itself. This is the run the previous attempt
   could not be: it waited for the plate pulse, the title's own settled
   signature, instead of pressing during the build-in.

3. THE PLATE IS RE-DRAWN after B from the menu -- pressed at 351.2 s, pulse
   detected at 358.5 s. That was the other unevidenced half of the B-on-menu row.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:18:18 +00:00
sylph-decoder
7a63501bc1 handoff: split Q5's bundled 'measured' -- a label is as strong as its weakest cell
The port's authored/flow.json stamped title/on_cancel_why = 'MEASURED, HANDOFF
Q5' for a clause whose evidence cell in the source table reads 'none'. It did not
invent that: HANDOFF's Q5 row opened with one **measured** covering six clauses of
different strength, and HANDOFF is the document it authors against.

Split per clause. Measured: initial focus varies; up/down move one item per press
and wrap both ends; left/right do nothing; B on a submenu restores focus 4/4; B on
the main menu goes to the title in <= 0.4 s with no loading screen. NOT measured,
evidence cell empty: 'no auto-repeat at the durations tried', and 'B on the title
-> nothing'. Both marked do-not-stamp.

Also splits the source table's own up/down row, which bundled 'one item per press'
(indirectly but soundly evidenced by the 4-press wrap count) with 'no auto-repeat'
(nothing behind it, and the hedge was carrying the claim).

METHOD entry: the failure is in summarising, not at either endpoint. The source
table was honest and the consumer cited its source; flattening six claims into one
adjective created a provenance nothing supports. A strength label is not
distributive.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:11:08 +00:00
sylph-decoder
c3b66c4b91 handoff: on_cancel from the main menu is measured
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:06:32 +00:00
sylph-decoder
78cb1d4e9b re: B on the main menu goes to the TITLE -- measured, filling an empty evidence cell
menu-navigation-semantics.md had this row at yellow with an EMPTY evidence cell,
and it is what the port still authors as on_cancel.

Delivery-confirmed via [RE-INPUT] (B is kXInputPadB = 0x5801), change detected
rather than timed. B delivered at 331.2 s; the glyph leaves 327 by 331.6 and
73.5 % of pixels differ. Both captures name themselves: PROJECT SYLPHEED with the
(C)2006,2007 SQUARE ENIX line.

Three things measured:
  * B on the main menu goes to the title;
  * latency <= 0.4 s at a 4 Hz sample rate, where the corpus previously had this
    as 'not measured (a backlogged probe void)';
  * NO loading screen in between -- the disc carries four pgloading_* bundles and
    none appears on this path.

What the run CANNOT say, recorded in the table rather than glossed: 'B on the
title -> nothing' is still unevidenced. The second B was delivered during the
title's build-in, so the glyph 0 -> 154 change after it is the build-in
completing, not a response. A run that answers that row must wait for the title
to settle before pressing.

The 're-draws PRESS A after a beat' half of the first row is also still
unevidenced -- the run ended with the plate absent.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 11:06:18 +00:00
sylph-decoder
dc0b84c87f handoff+index: a .tbm draws, and screen render omits it silently
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:53:57 +00:00
sylph-decoder
ddc2a8e36b re: a .tbm DRAWS -- the TUTORIAL screen captured, and the 'inert' reading refuted
Closes the open second reading in ui-forced-backdrop.md: that a .tbm contributes
no pixels, leaving 24 of its 62 deciding verdicts harmless rather than correct.

The TUTORIAL screen was reached and captured. It carries a full-screen blue
circuit/hex background. GP_TUTORIAL build 0's element 0 is pubase.tbm with pivot
(640,360) -- 1280x720, the only full-screen TEXTURED element in the bundle; the
one other full-screen element is pueff00.prm, an untextured primitive the colour
census puts at pure black. Our render of the same build is the identical layout
on pure black, 6.0-6.4 % inked against the game's 99.7 %. The only difference is
the background and the only thing it can be is the .tbm.

So the 24 .tbm verdicts are correct rather than harmless, and they are
load-bearing in the full sense. Reach: one .tbm observed; the class question is
settled, the ten other families are not individually seen.

Also: screen render is wrong on every screen carrying a .tbm -- it drops the
background silently, with no diagnostic.

And the identification is worth its own METHOD entry. Two statistical identifiers
were built. Masked correlation FAILED its control, picking EXTRAS over the known
main menu by 0.004 because the shared background dominates. A high-passed variant
PASSED by 1.28x, which is not a margin that licenses identifying an unknown, so it
was not used. The screen says TUTORIAL across the top. Ask whether the artefact
already states the answer before building a matcher.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:53:34 +00:00
sylph-decoder
77e54e95a5 re: a submenu is REACHED -- and correlation cannot identify it
Third attempt at the .tbm question. All three fixes from the previous page were
applied and all three were needed: hold A for 0.5 s, confirm delivery from
[RE-INPUT] rather than from the pad, and detect the screen change instead of
timing it. Title at 288.6 s, both presses delivered on attempt 1, submenu at
303.4 s with 87.1 % of pixels changed.

The capture is 99.7 % inked and uniform top to bottom -- a full-screen
background. Our renderer gives 1.9-3.0 % for all 19 GP_SAVE_LOAD builds,
6.0-6.4 % for GP_TUTORIAL, 78.4 % for GP_SYSTEM 0/1. So two of the three
archives render essentially nothing where the game draws a full screen.

But WHICH screen was captured is not established, and the reason is worth more
than the run: correlation cannot discriminate when the candidate renders are
near-blank. All 19 GP_SAVE_LOAD builds score -0.004..-0.010 -- a ranking with no
information. A matching statistic is useless against a hypothesis that predicts
an empty image, which is exactly the hypothesis under test.

Focus could not be read either: the two labelled menu captures fit at 2.52 and
2.48 mean absolute difference, 1.6 % apart. That is a SECOND statistic failing on
the focus problem after the per-row brightness one, so it is an open item rather
than an oversight.

Kept regardless: the game surface sits at y=45 in the 1280x720 display frame,
fitting the committed 1279x675 captures to 2.5 mean absolute difference. That is
the alignment the earlier cross-geometry comparison got wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:49:48 +00:00
sylph-decoder
ac1b76ee39 re: run 'grep the corpus for the claim' on this corpus -- four still standing
Applying my own METHOD entry one iteration after writing it found four refuted
statements still asserted unmarked where a reader lands:

  * envelope correlation 'has no resolving power' -- in three places including
    HANDOFF. The port controlled the same estimator on a single track and got
    r=1.0000 at zero offset; the saturation needs CONCURRENT streams sharing
    timing. I agreed to this in a message and never landed it.
  * '8 of 10 three-chunk regions' -- still asserted in HANDOFF in a different
    section from its own correction.
  * 'r9 is a wild pointer, never a guest address' -- still asserted inside the
    kept-for-the-record section.
  * the ALSA channel permutation, stated without scope, when a later capture
    measured the identity and labelling from it put the silent channel on the
    wrong name.

All four marked in place, striking the sentence and pointing forward.

Two lessons added: a 'kept for the record' section still asserts, so labelling
the heading is not enough; and naming a refuted claim keeps it greppable, so the
audit returns its own corrections as hits and every hit needs reading.

The first item is the one worth admitting: I acknowledged that correction in a
message, wrote the entry about corrections that never land, and then did not land
my own for a full iteration.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:35:27 +00:00
sylph-decoder
e882900f85 method: 'it did nothing' and 'it never happened' look identical from outside
An A press produced no screen change; the obvious reading was that the button did
nothing. The log said the press was never delivered -- two file-pad vk=5800 lines
across the whole run is ONE press -- because it was issued 0.8 s after a screen
appeared, while the guest was loading and not polling.

The pad driver reports what it emitted, so a script checking its own output sees
success either way. Confirm the receiving side.

Generalised: when an action produces no observable effect, the first hypothesis
is that the action did not occur, not that it had no effect. The corpus has paid
for this twice -- here, and in the sign-in swallow where thousands of delivered
keystrokes were discarded inside the emulator and looked exactly like a dead pad.

Companion to the control entries: a control proves the instrument reads
correctly; a delivery check proves the experiment happened at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:31:12 +00:00
sylph-decoder
bbc167425f re: the .tbm submenu is not reached -- and the second tap was never delivered
Two runs, neither answering whether a .tbm draws pixels.

Run 1 TIMED the title->menu transition and was still on the title 8 s later
(glyph 714, the plate's pulse trough), so the second tap did the transition and
the 'submenu' capture is the menu. Void.

Run 2 DETECTED the menu instead -- glyph 327, matching live-main-menu.png
exactly -- tapped 0.8 s later, and 12 s after that was still on the menu. The
log says why: 2 file-pad vk=5800 lines, i.e. ONE press, and one RE-INPUT
delivery. The second tap was never delivered, with zero swallow lines so it is
not the sign-in path. A 0.12 s press issued while the guest is still loading a
screen is missed outright.

So 'the press did nothing' and 'there was no press' look identical from the
screen, and only the log separates them.

Worth more than the run: this is the third time in one iteration that timing was
used where detection was required -- the title->menu wait, the menu->submenu
wait, and the press itself. Each fix is the same substitution, and each was
written only after the timed version had produced a confident wrong answer.

Also records that no focus detector is needed for this question, since every
main-menu destination except EXTRAS carries a .tbm decider.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:30:49 +00:00
sylph-decoder
12159be61f re: land the loop-point correction where the claim actually lives
The port found its exporter still shipping 'no loop-point field has been
identified anywhere' in the field manifest.json concatenates, days after the
correction existed in other fields. Auditing this corpus the same way found the
same failure here: the refuted sentence was still standing untouched in
bgm-two-stems.md -- where anyone looking up BGM behaviour arrives -- and in
HANDOFF.md, the one page the port is told to read. My correction had gone into a
NEW page only.

Both fixed in place, each naming the refutation rather than quietly deleting the
old claim, and each carrying the measured window [9.44, 71.31] s at 61.87 s.

METHOD entry: writing a correction down is not landing it. Grep the corpus for
the CLAIM, not for the file you were working in. Plus the port's trap in doing
that audit -- a replacement that quotes the refuted sentence in order to name it
will match a substring search from inside the paragraph saying it is false.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:20:04 +00:00
sylph-decoder
e1f2a7f714 re: the menu loop starts at 9.44 s -- measured, and the fix was scheduling
Tailing the log from BEFORE the music starts cut the unsampled backlog from 616
samples spanning offsets 32..2,559,033 to 125 spanning 32..515,239, so the first
pass is sampled like any later cycle. Offsets below loop_start play exactly once,
which is why the previous run could not measure them.

Wraps at 96.46 / 158.33 / 220.21 s, gaps 61.87 / 61.87, both contexts together.

Two derivations, neither converting bits to seconds:
  (a) time to read_offset crossing loop_start, plus a 1.33 s head correction at a
      rate measured on 748 timestamped samples of that same stretch
  (b) first pass (offset 32 -> loop_end) minus the cycle
Both give 9.44 s on both contexts -- four numbers, one value.

So the loop region is [9.44, 71.31] s of an 87.744 s wave, cycling every 61.87 s.
The first 9.44 s is an intro played once; the last 16.4 s, the fade-out
bgm-two-stems.md documents, is never played at all.

The decoder reads ahead of playback, but both endpoints are read_offset events so
the lead cancels in the difference. One boot, one bank.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:13:14 +00:00
sylph-decoder
10df64e7d0 method: a control easier than the measurement bounds nothing
My locator validated on slices cut from the wave itself -- found exactly, control
passed perfectly -- and the measurement was still ten seconds wrong, because
matching an exact copy is a different problem from matching a real capture and
music with repeated sections is where a locator aliases. Its clean +5.00 s
stepping showed self-consistency, which is also what an aliased lock looks like.

Paired with the port's mirror image the same day: an awk that read 0 for every
span produced a perfectly structured result agreeing with the hypothesis under
test, and its tell was that the CONFIRMING rows were impossible too.

Both point the same way: the tell is in the rows that agree with you. Checking
the disconfirming half harder is the intuitive discipline and it is the wrong
half.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:04:18 +00:00
sylph-decoder
d949a2216f re: the menu loop WATCHED -- three wraps, 61.81 s, and my placement is refuted
Settles the conflict by timing the loop instead of converting it. A tailing probe
stamps read_offset with the wall clock as each log line arrives, so the period
needs no bits-to-time step -- the step already shown to be invalid.

Three wraps, each exactly loop_end -> loop_start, and BOTH CONTEXTS WRAP AT THE
SAME INSTANT all three times. That is the property two stems of one performance
must have and the one the linear conversion could not deliver (62.34 vs 63.29 s
would drift a second per cycle).

Cycle 61.56 and 62.06 s, mean 61.81, against the audio autocorrelation's 61.93 --
0.2 % apart from instruments sharing nothing.

Linearity refuted a second time and internally: the fitted rate over 10..60 s is
341 394 bits/s while the cycle covers 22 034 741 bits in 61.81 s = 356 491
bits/s, 4.4 % apart inside one stream.

My own audio locator's PLACEMENT is refuted. loop_start at 3.6 M bits is 11.6 %
of the stream by any reading, ~10.1 s at the cycle's own mean rate, against the
0.25 s that page reported -- for the reason already suspected, that its control
matched slices cut from the wave itself and never tested the aliasing the real
problem has. The length was right and the span was wrong.

Still not measured: loop_start in seconds. Offsets below it play exactly once and
this trace stamped that whole stretch at t=0.002, swallowing the log backlog in
one read, because it started after the music. The fix is to start the trace
before tapping into the menu -- one line, not done.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 10:03:52 +00:00
sylph-decoder
cf6be709ab re: the loop IS a runtime XMA field -- and reading it contradicts my audio measurement
No Canary patch was needed: UpdateLoopStatus already logs loop_start/loop_end,
they just need the Apu category (--log_mask=13 --log_level=3).

Decoded, from the menu, 8734 records all after BGM_103's contexts appear:
  ctx0 (wave 3876864)  loop_start 3605682  loop_end 25640423  loop_count 255
  ctx1 (wave 3930112)  loop_start 3539158  loop_end 26216351  loop_count 255
The movie's three ADV streams log NO loop records -- they do not loop.

Semantics visible in the trajectory: read_offset runs from 32 upward and 20 % of
samples sit below loop_start, so the stream plays from the beginning and
loop_start is where it returns AFTER loop_end. No wrap was observed -- the 45 s
hold ended with read_offset at 17 M against a loop_end of 25.6 M.

Two registered predictions REFUTED. loop_start is not ~0 but 11.6 % in. And a
linear bits-to-seconds conversion is invalid: it gives 62.34 s and 63.29 s for
two stems that must play sample-synchronously, which is impossible, so the data
refutes the assumption on its own.

That leaves a conflict I am not resolving: the field implies a cycle of roughly
[10 s, 72 s]; my audio tracking reported offsets 0.25..57.18 s. Recorded as
contested, with the likely weak link named as mine -- that locator's control used
slices cut from the wave itself, exact copies, which is an easier problem than
matching a real capture, and a control easier than the measurement does not bound
its error.

The port is told to change nothing: its trimmed 61.93 s loop is verified in its
own output, and the length survives better than the placement.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:52:13 +00:00
sylph-decoder
5f386111ad re: count the voice-region population properly -- 25 three-chunk, and 17 of them were broken
Pays the debt from the truncated audit. The census prints population, coverage
and skips in the same output, and ends with an explicit END line, so a cut-short
run cannot be read as a complete one.

  POPULATION 104 movies; COVERAGE 95 resolved, 9 unresolved, 0 unreadable
  70 one-chunk regions, 25 three-chunk regions

The port's 25 was right; my '8 of 10' was not a count.

Cross-referenced against the fix's own sweep, which also ran to completion
(78 + 17 + 9 = 104): all 17 changed regions are three-chunk, none is one-chunk,
and 8 three-chunk regions were never affected -- which the 1.5 MB cap predicts,
since a region only trips the filter if its span exceeds it.

So 'the defect is specific to the multichannel regions' survives with complete
populations on both sides, while 'all three-chunk regions were broken' does not.
The original 8-of-10 was wrong in its denominator and coincidentally shares a
digit with the 8 that are unaffected, which is the kind of resemblance that
carries a dead number into a later document.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:46:08 +00:00
sylph-decoder
45a21f0d33 method: a sound instrument, a correct number, and the wrong sentence around it
Named by the port after hitting it twice in a fortnight -- a real 3.4 s seam
written up as the cost of a missing loop point when our own loop produced it, and
a real r=0.998 correlation written up as a duplicate when it was a
start-truncated simultaneous stream.

Distinct from everything else in this file, which is about broken or misspecified
instruments. Controls test whether a measurement is faithful and say nothing
about the clause that follows it. The defences that work are naming the
alternative explanation so it can be rejected, and noticing when a measurement
taken in OUR output is being used to make a claim about THE GAME.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:40:39 +00:00
sylph-decoder
fa832fad1e re: the menu BGM loops at 61.93 s, and the game never reaches the fade
240 s parked on the main menu, reached by using the XMA probe log as the screen
oracle instead of video -- the route the previous iteration wrote down. Menu in
26.8 s against never-in-378 s for the video rig, guest at 0.92x, capture at
0.08 % silence against the recipe page's own best of 0.31 %. BGM_103's contexts
verify the screen and no ADV context appears afterwards, so the attract loop
never took over.

Three results, two instruments.

NO SEAM: zero runs >= 0.3 s below median-18 dB in 232 s. The port's 3.4 s
near-silence is a property of its authored loop, not of the game.

NOT THE WAVE LENGTH: autocorrelation r at 87.750 s is -0.009 on four independent
windows; the top lag is 61.909 s with a 2x harmonic. Estimator controls recover
87.750 and 60.000 exactly.

61.93 s, INDEPENDENTLY: locating 30 s slices of the capture inside the decoded
summed waves shows playback advancing exactly +5.00 s per 5 s and wrapping at
61.93, from three wraps. Control: slices cut from the wave itself at 10/45/70 s
are found at 10.00/45.00/70.00. Two points mis-lock where the slice straddles a
wrap and they carry the two lowest scores in the table.

Offsets span 0.25..57.18 s of an 87.744 s wave, so the loop is [~0, 61.93) and
the final ~25.8 s is never played -- exactly where bgm-two-stems.md found the
fade-out and trailing silence. The game loops before the fade, which is why
there is no seam.

Also corrects my own '8 of 10 three-chunk regions start mid-stream'. The port
counts 25 three-chunk regions; it is right that both numbers cannot describe the
same set. My audit run was CUT SHORT -- the committed file ends mid-list with no
summary line -- so that was a ratio over an unknown fraction of the population,
and the claim that the defect is specific to multichannel regions is now
unsupported. The ADV verification and the fix's own sweep are unaffected; that
sweep ran to completion and printed its totals.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:34:42 +00:00
sylph-decoder
57035a700b handoff: the menu BGM loop is attempted and not captured; the route left
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:22:01 +00:00
sylph-decoder
4ce639c63d re: the menu BGM loop is NOT captured -- and the rig that cannot take it
Recorded per 'do not improvise around a blocker'. The question is what the game
does at BGM_103's loop seam, where the corpus has 'not a seamless loop, no
loop-point field found, so the menu loop is authored' and the port measures a
3.4 s near-silent seam.

Audio needs the ALSA tee; detecting the title needs video, so --gpu=null was
unavailable. Measured twice: the guest runs at ~0.20x real time (76.5 s of audio
in 378 s of wall clock) and the title is not reached in 300 s even after tapping
A to skip the movie, with the tee's slave ending in a broken pipe and Xenia in
underrun recovery. Not a crash -- rss 701 MB with 9.5 GB free, and the 'Killed'
line is this harness's own cleanup.

REFUTED along the way: CONTAINER-NOTES says --gpu=null runs here die at ~70 s.
The intro-audio capture ran 148.02 s under --gpu=null and ended on its probe's
timer with the emulator alive and the whole ADV movie decoded. More than twice
the quoted lifetime. That note had been the reason not to use --gpu=null for
anything long, which is exactly what a clean audio capture needs.

The route left, written down rather than attempted: use the XMA probe log as the
screen oracle instead of video. Sitting on the main menu decodes exactly BGM_103's
two waves, so their byte_sizes appearing IS the menu -- which is better
provenance for an audio question than a screenshot anyway.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:21:47 +00:00
sylph-decoder
3392982e58 method: over-warning is what makes the next real warning unreadable
From the port, after two rounds of its 'known incomplete' banner firing wrongly
-- once with a message true only for ADV, once claiming a gap over 93.694 s of
exact zeroes. Both errors were in the cautious direction, which feels like the
safe mistake and therefore goes unexamined longer than a false all-clear would;
the cost is deferred onto the one occasion the warning is true. A warning needs
the same scrutiny as an assertion, starting with what it keys on.

Also records S00A's kept count moving 1 -> 2 after the voice-region fix, on an
asset the fix was not derived from and with the prediction preceding the
observation -- at the strength it actually has. A different ASSET is evidence
about generality; a different IMPLEMENTATION is what would make it independent,
and only one of those was present.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 09:11:10 +00:00
sylph-decoder
dbb12036c1 method: an internal check cannot catch a bug that makes the input smaller
The voice-region truncation survived every test because there was nothing to
catch: the region parsed, the chunks decoded, the durations were self-consistent.
A missing third of a stream is smaller VALID output, and no check written against
our own output distinguishes that from correct output. What caught it was a
number from outside -- the running decoder's byte_sizes not fitting the region.

So: prefer at least one test per decoder pinned to something we did not produce,
and say so in the test, because the obvious maintenance of such a test is to
re-baseline it against current output, which deletes the only thing it was for.

Plus the port's corollary: it was checkable only because the identifier happened
to be a byte count. Index a handed-over result by a quantity the recipient can
test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:56:14 +00:00
sylph-decoder
3dbfa320ae formats: drop the 1.5 MB cap that truncated 17 voice regions' first stream
The cause, and the fix, with a disc-wide check.

resolve_movie_voice_region picks start = the predecessor cue's trailer, then
filtered it with 'end - s < 1_500_000' -- 'only within one bank'. ADV's
predecessor sits 3 618 816 B before end, so the filter rejected it and start fell
back to anchor, which is a TOC offset and not a stream boundary. That explains
the shape of the defect exactly: it strikes regions larger than 1.5 MB, which is
why the three-stream multichannel regions are hit and single-stream ones never
are. 17 of 95 resolving movies took the fallback.

ADV's predecessor trailer at 433 425 776 plus 17 040 B of descriptor and padding
is 433 442 816 -- the -238-packet start measured against the decoder, to the byte.

Dropping the cap: unchanged 78, fixed cleanly 17, changed in any other way ZERO.
In all 17 the only difference is a larger first chunk with every later chunk
byte-identical, which is what a corrected start looks like and what pulling in a
neighbouring asset does not.

Regression test pinned to the RUNNING DECODER's byte_sizes rather than to this
crate's own output. That is the point of it: every internal check passed happily
while a third of a stream was missing, so only an external number could have
caught this class of bug.

sylpheed-formats: 136 tests pass, 0 fail (the one still running at commit time is
an unrelated long mesh test).

Exact clips for the other 16 are not independently verified -- the sweep is
strong but ADV is the only one with a decoder measurement behind it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:55:47 +00:00
sylph-decoder
fb6095ae3a handoff: tell the port its refusal found a decoder defect, and what is safe to use
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:41:38 +00:00
sylph-decoder
3e8235ddbd re: resolve_movie_voice_region starts INSIDE the first stream, 8 of 10 multichannel regions
Found because the port refused to apply my stream assignment and did the
arithmetic instead: the running decoder's three ADV contexts sum to 3 584 000 B
against a resolved region of 3 114 352 -- 15 % too small to hold them. Two spans,
one wrong, and it was the disc side.

The gap is 238 packets exactly (487 424 B), which is what a start offset looks
like; ctx0 declares 632 packets and the resolver's leading chunk has 394.

Verified against the decoder's own byte_sizes, which cannot be fitted to: at
-238 packets to_xma_riffs yields [1294336, 1118208, 1171456], all three exactly.
It is a real boundary and not the end of a sweep -- at -300 the previous asset's
chunks appear while the three ADV sizes stay stable.

Disc-wide: 24 of 24 single-chunk regions start at a boundary; 8 of 10 three-chunk
regions start mid-stream. The defect is specific to the multichannel case.

The audit's per-movie number is an UPPER BOUND, not the clip -- its stopping rule
is the chunk count changing, and to_xma_riffs absorbs a few packets of the
previous asset first (243 reported for ADV against a true 238). Only ADV has
external ground truth.

Consequence: in those 8 movies the leading chunk is a truncated first stream, not
a spurious artefact, and anything measured on it was measured on a fragment --
including this corpus's own chunk-0 level, though the assignment survives because
its ratio test was chosen to be immune to the clipping.

The resolver is NOT patched. Why the predecessor cue's trailer lands 238 packets
into the next asset is unanswered, and a fix guessed from one movie would be
worse than a documented defect.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:41:22 +00:00
sylph-decoder
8c71520ab8 re: which ADV stream sits where -- settled by level, not by waveform
Completes ask #4. The three chunks were dumped from the resolved voice region
and decoded; the assignment is ctx0 -> FL/FR, ctx1 -> FC with LFE silent,
ctx2 -> BL/BR.

Two instruments failed first and both look like results, so both are recorded.
Envelope correlation with a per-pair lag search returns 0.86-0.95 for EVERY
chunk against EVERY channel, because all six residual channels share the
dialogue's activity timing -- that is an instrument with no resolving power, not
a finding. Sample-level correlation returns about zero, because the chunks do
not start with the movie and the XMA decode's framing offset is unknown.

Level settles it under the same 0.600 gain the bed uses: each stream lands
within 0.5 dB of exactly one residual pair and misses the others by 4-6 dB. The
ratio test is immune to chunk 0 being a clipped tail of ctx0 -- chunk0 - chunk2
is +5.88 dB against FL - BL at +6.18 dB, agreeing to 0.30 dB, where a swap would
be wrong by 11.76 dB.

Structural confirmation: chunk 1 is the only chunk with a digitally silent
channel and LFE is the only output channel with an empty residual (-115.73
dBFS), one to one; and the internal L/R correlations track the residual pairs'
(0.932 vs 0.918, 0.962 vs 0.929).

Worth having on its own: the same 0.600 scales both the movie bed and the voice,
so it is one mixer gain rather than two.

Reach: levels, not waveforms; one boot, one movie; and whether 0.600 is a fixed
constant or a volume setting is still unknown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:32:14 +00:00
sylph-decoder
59f5bf1b59 method: a rule learned from a burn generalises by resemblance, not by mechanism
From the port agent. This file already carries two divisor bugs of the same
shape -- a silent input in a divisor attenuating real signal -- and the lesson
taken from them was 'be suspicious of dividing by N'. Applied to the intro's
three streams it produced a unity sum that the port's own checker rejected at
+2.62 dBFS.

The precedent did not transfer because a BGM bank's two waves are stems of one
signal while the intro's three streams are positions in a field, whose downmix
weights sum to one whatever the assignment. Nothing in 'several streams, one
output' distinguishes those.

The general point: a rule extracted from a burn is indexed by what the burn
looked like rather than by why it happened, so it fires on the next thing with
the same silhouette while feeling well-earned. State the mechanism a past lesson
turned on and check that mechanism is present.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:29:01 +00:00
sylph-decoder
232ae0fa9c re: ask #4 answered -- the intro is a 5.1 WMAPro bed at 0.600 plus three streams
ADV.wmv carries ONE audio stream and it is wmapro 5.1, not XMA. Any framing of
the intro's audio as only 'which of three voice streams to ship' was missing the
bed.

Aligned the 148 s capture against that track (envelope r 0.769 against a median
of -0.001, refined to +224 samples, r 0.900) and solved
capture = g x movie + residual per channel.

The gain is 0.600 on every channel -- a uniform -4.44 dB, a mixer setting rather
than a fit artefact. LFE reproduces to -115.73 dBFS, 72 dB down, which is what
rules out codec difference as the explanation for the other residuals. FC is the
exception: the movie explains NOTHING of it (-0.09 dB), and the movie's own FC is
91.6 % silent.

The residual is three signals, not one: a front pair (r 0.918), a rear pair
(r 0.929), and a centre whose partner LFE is empty. The FC residual spans 34 dB
across 100 ms frames -- bursty, not steady noise.

That CONFIRMS the corpus's 5.1 reading, which voice-three-streams-are-concurrent
recorded as not established, and it confirms the specific detail it offered: that
the mono-in-stereo stream is 'a centre paired with a silent LFE'. Measured from
the output with no access to the stream contents.

Also corrects my own census page: it labelled channels with the ALSA permutation
[0,1,4,5,2,3] from the recipe page, which does NOT apply to this capture. The
6x6 matrix was computed assuming no order, every row's max falls on a distinct
movie channel, and the answer is the identity -- so the census's 'BR is 82 %
silent' was really LFE, reconciling with the movie's own 80.64 % silent LFE.

Reach: one boot, one movie; which XMA context is front/centre/rear is not
determined, only that the residual occupies those positions; and whether 0.600 is
a fixed constant or a volume setting is unknown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:19:03 +00:00
sylph-decoder
ef4ea8fe86 re: the boot intro's audio output -- five live channels, not a stereo mix
Groundwork for the port's ask #4; it does not settle #4.

Captured the game's own output over the boot intro following the ALSA file-tee
recipe exactly -- paced pulse slave, --gpu=null, both mutes off. 148.02 s, 6ch
float32 48 kHz, 0.15-0.16 % silence against the 0.31 % the recipe page records
for its own clean run.

Provenance is the XMA probe rather than a screenshot, which is the right evidence
for an audio question: ADV's three contexts appear byte-exact (1294336 /
1118208 / 1171456), then the documented BGM_102 pair.

Five of the six channels carry distinct content; BR is 82 % silent and 11-15 dB
down. No channel is a copy of another -- the largest pairwise correlation is 0.70
between FL and FR.

That rules out a stereo mix, so 'ship one stream' cannot be right and the port's
held-wrong value stays wrong. It does NOT establish that summing is right, and
the 6-channel count is Xenia's hardcoded kFrameChannelsDefault -- what is
evidence is that five of them differ, which a stereo guest cannot produce.

NOT settled and named as such: the stream-to-channel mapping. The
cross-correlation of each captured channel against each decoded ADV stream has
not been run. One boot, one movie, and --gpu=null means no video cross-check.

Raw is 170 MB and is not committed; sent over share to the port.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:13:50 +00:00
sylph-decoder
6f87ecc4db re: the pulse floor gets a second witness, and two METHOD entries
The port reproduced the floor exactly (159) once the predicate was named, and
counted an independent capture from a different session: 753 against this run's
714, a ratio of 4.7x against 4.6x. 'Never goes off' is no longer single-run.

Two METHOD entries.

A detector that can fire on a single frame will fire on the wrong one. The A/B's
first pair was void because the title detector tested one frame against a glyph
threshold and the intro movie throws sub-second green flashes of 1298..5433. The
presses were real and skipped the movie, so both legs returned a clean,
symmetric, meaningless result -- a void test that looks like it ran is worse than
one that errors. Same shape the corpus already recorded for screen_id.py calling
the SQUARE ENIX logo 'title'. Twice paid for. The rule is that a screen detector
matches a signature over time, and a broken run's own series is the cheapest
control for its replacement.

A demand for reproducibility can surface a defect that is not the one demanded.
The literal answer to 'your figures are unverifiable' was 'here is the
predicate', after which they verified exactly -- but writing the method down is
what exposed the cross-geometry floor comparison, which nobody was looking for.
And both sides were wrong at once: the challenger's counts were the wrong
measurement AND the published figure had a real flaw.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:07:51 +00:00
sylph-decoder
e0de5c6f22 re: the A-press A/B is run -- signed-in profile, no swallow, menu opens
The debt from two iterations ago. Two boots, same binary and ISO, one A tap
each, fired only after the plate's pulse had been seen for 12 consecutive
samples. ARGV recorded per leg, because the config dump provably cannot say.

  leg A  no profile flag        3811 swallow lines and climbing
  leg B  --logged_profile_...   0 swallow lines, final glyph 327 = MAIN MENU

327 is the documented main-menu glyph count, reproduced by this instrument's own
control, so leg B's press opened the menu. Capture committed.

Leg A demonstrates the SWALLOW, not the crash: I stopped it at ~2.3 M swallowed
calls because kernel tracing at log_level=3 was eating the 300 MB budget the
crash dumps need. The fault itself remains measured once, historically. One run
per leg.

A void pair came first and is recorded, because it is why the detector is what
it is. The first version fired on a single frame over a glyph threshold and hit
the INTRO MOVIE -- green flashes of 1298..5433 lasting under a second -- about
6 s before the title, in both legs. The presses were real (each skipped the rest
of the movie, which is Q9's behaviour) but the pair tested nothing. The fixed
detector requires 12 consecutive in-band samples, and was replayed against the
void runs' own series as its control: it declines the movie flash at 84.8/85.5 s
and fires at 93.9/94.7 s inside the sustained pulse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 08:05:43 +00:00
sylph-decoder
6072d216a8 re: name the region and the threshold -- and the floor was cross-geometry
The port agent could not reproduce this page's 159/714/1520 from the capture it
holds: counting green>150..200 over a plate box it got 3-5x at every threshold.
The page named neither the region nor the predicate.

Stated now: the whole 1280x720 frame, and is_title.py's three-channel predicate
(g>130 & g-r>45 & g-b>45), which is why it counts far fewer pixels than a bare
green>N. That reproduces 1520/714/159 exactly.

Writing the method down exposed a defect the prose had hidden. The 159 floor
came from live-title-build4-no-plate.png at 1279x675 -- the game surface --
while the pulse frames are 1280x720, the whole display. Different crops,
silently compared.

Replaced with a same-run, same-geometry floor that was in the series all along:
154, flat for ~2 s immediately before the plate ramps in. So 'it never goes off'
now rests on one run in one geometry, at 714 against 154, which is where it
should have rested from the start. The port's independent ratio of 1:10.4-10.9
brackets this page's 1:9.6 and is the part robust to how anyone counts.

Two METHOD entries: a pixel figure needs its region and its predicate, and a
comparison between two counts needs them to share a geometry; and the port's
observation that a fix which overshoots leaves no symptom until a third change
needs the part it disabled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:59:00 +00:00
sylph-decoder
b6f0cf3fb2 re: RETRACT -- a Canary config dump is the FILE, not the run
Refuted my own evidence with a direct test. The A-press fault page cited the
faulting run's dumped logged_profile_slot_0_xuid = "" as proof no profile was
signed in. Xenia prints its config dump BEFORE applying command-line overrides:
in a run launched with --apu=sdl --hid=file --mute=true --log_mask=13, the dump
says apu="any", hid="any", mute=false, log_mask=0. Four for four.

So the dump is a statement about xenia-canary.config.toml and nothing else, and
this page cannot know the faulting run's profile state. Anything in the corpus
citing a config dump as evidence of what a run did is making the same mistake;
to know a run's settings, record its argv.

Survives: the mechanism (swallow -> unbounded pump -> failed allocation ->
fault), which rests on the [RE-INPUT] counter and the crash dump's registers;
and canary-scripted-input-traps.md section 3's measured sign-in-dialog claim,
which has a capture behind it.

Also records the port's base-plus-glow mechanism for the plate, which explains
why the pulse floor is 714 rather than the plate-absent 159 -- ptbtn00's fade at
t=244 is an exit ramp so the base holds at 255 while the screen is held, and
ptbtn00f's 0->80->0 glow draws over it. Marked as agreeing with the measurement,
not confirming it: their renderer is not an oracle. It does rule out a glow-only
plate, which could not produce a non-zero floor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:52:14 +00:00
sylph-decoder
3c004845fa re: the PRESS A plate PULSES -- measured, and it keeps an authored entry
Answers the port's ask #1, which it had flagged as the only one of its four
that could delete an authored entry rather than confirm one. It confirms one.

Held at the title with no input, the plate oscillates continuously: two windows
in one boot, 58 s and 57 s, ~23 cycles each, no decay. Periods 2.530 and 2.540 s
by upward mid-crossings -- 0.4 % apart.

It never goes off. The plate-absent floor is 159 green pixels, measured on the
committed live-title-build4-no-plate.png; the pulse bottoms at 714, 4.5x that.
So the port's 'flash and nothing after', reasoned from ptbtn00 expiring at
t=244, is wrong on the boot's end state -- ptbtn00f's 120-unit cycle is what
runs.

Instrument controls were run before it was pointed at anything unknown: the
glyph counter reproduces the documented 753 on live-title-press-a.png and 327 on
live-main-menu.png exactly.

Two estimators, and only one replicates. Mid-crossings agree across the two
windows to 0.4 %; a single-sinusoid least-squares fit does not (2.553 vs 2.413),
because the waveform is fast-rise/slow-decay rather than sinusoidal -- its own r2
of 0.468 and 0.228 is the tell. Both were controlled on synthetic sinusoids at
2.24/2.55/3.10 s laid on the ACTUAL timestamps and recovered every one exactly,
so neither is broken; one is misspecified. Recorded as such.

The wall-clock is 13 % longer than the corpus's earlier 2.24 s mean. Same
declared 120 units, different emulator pacing (x1.27 here against x1.12), so
this corroborates 'author the units' rather than disturbing it.

Reach stated: one boot; does not distinguish the boot title from an attract-loop
title; and the glyph count is a thresholded pixel count, so 714/1520 is not an
alpha ratio and no duty cycle can be read off it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:37:49 +00:00
sylph-decoder
ec06c50bf6 method: the mirror trap -- two records that drift, and a weakened control
Two corrections from the port agent, both of which make earlier claims smaller.

1. Its 'reproduces your published centres to half a pixel' was model against
   model. This corpus's 981/478 are the model's output at t=355, not the
   capture's; the capture measured 992.0/467.2, the 11.5 px residual the page
   declines to fit. So that control shows two implementations of one model
   agreeing, not the model matching the oracle. Neither of us applied the
   correlated-instrument test to that sentence at the time.

   The discriminator survives: it asks whether two captures are the same frame,
   and the model is monotone in t at ~4 px/unit, so a 42-unit gap cannot come
   out of one frame however wrong the absolute times are. Recorded as such.

2. Running my 'grep for the symptom' audit against its own tree, the port found
   the opposite failure: a control recorded in BOTH a tool table and a document,
   drifted to 53.3 % and 53.2 %, with the evidence file gone so neither can be
   re-measured. One hard-to-find record announces itself as missing; two
   disagreeing records announce nothing, which is worse.

   So the rule is not 'write it down twice' -- one record in docs/re/,
   everything else cites it, and any number that must appear twice is generated
   rather than typed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:26:27 +00:00
sylph-decoder
8dfa0ebac5 re: the A-press dialog is the SIGN-IN dialog -- and the corpus already knew
Answers the open half of the A-press diagnosis, and most of the answer was
already in the tree.

The faulting runs booted with logged_profile_slot_0_xuid = "" -- their own
config dump -- while a profile existed (Found 1 Profiles). With nobody signed
in, A takes the state-0 branch of sub_821D03A0 and calls XamShowSigninUI(1,1);
Canary raises its Sign In dialog with a no-op close handler and nothing in an
unattended run dismisses it. 85 instructions verified against the image, 0
mismatches; the state-3 branch is XamShowDeviceSelectorUI, already ruled out by
storage_selection_dialog = false.

The correlation runs through the tooling: boot_menu.sh passes the profile flag
and Q4/Q5 pressed all five buttons; frame_clock.sh, which produced the faulting
run, does not.

So there is no blocker -- boot with boot_menu.sh. Flagged as retrodicted rather
than A/B tested, since I have not myself booted both ways and pressed A.

The uncomfortable half: canary-scripted-input-traps.md section 3 already named
the sign-in dialog WITH a committed capture, and boot_menu.sh's header already
carried the mechanism and the 8.4 million figure. The fault page searched for
the cause it had hypothesised and never searched for its own symptom. Added to
METHOD.md, along with the more expensive lesson -- a measurement whose only
record is a script comment is invisible to the document that needs it.

What this session did add is the join: that the known blackout is what drives an
unbounded guest queue into a failed 128 MB allocation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:21:18 +00:00
sylph-decoder
15d9037774 re: the sweep discriminator resolves -- 294.9 against a predicted 295
The port ran the check and returned 294.9. Different frames; both measurements
stand. Its renderer also reproduces this page's published t=355 centres to half
a pixel on both quads, which is the control that makes the 295 worth anything,
and it confirms the 600/720 cycles from its own export rather than from the
header word.

Worth recording as method: the observable and the value were specified before
the port computed anything, so it produced the number without knowing whether
295 was the pass or the fail. Neither agent checked its own instrument with its
own instrument.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:18:11 +00:00
sylph-decoder
59f3ac6846 re: ask #2 -- t=357.7 came from a GPU draw capture, and a sweep cannot date a frame
The port asked whether the refined sweep fit t=357.7 was measured against
live-title-build4-no-plate.png, because if so one of us is 42 units out.

It was not. 357.7 was solved against title-draw-capture-vertex-colours.log, a
GPU per-draw capture of the submitted vertex buffer -- four observables at once,
two quad centres and two vertex alphas. No framebuffer, no PNG.

The gap is not a fitting error either. Posing the leaves directly, t=400 misses
the captured quads by +169.0 and -172.2 px. Probe control: it reproduces the
page's published t=355 centres, 981 and 478, exactly.

Refutation attempted and FAILED: I expected the port's fit to be minimised by
the quad leaving the screen -- 'best fit' meaning 'draws least', the same shape
as the .tbm control that could not fail. At t=400 quad B is fully on screen and
quad A is 319 of 400 px. Their number is fitting something present and it
survives.

The real reason the two must differ is better than 'different frames'. The
sweeps are nested records on a free-running loop and their cycles differ -- 600
and 720, read from the record header +0x08 -- while the top-level clock stops at
settle. So two captures of the same settled title share a screen time and not a
sweep phase, by construction.

Consequence for the port: a sweep position does not date a frame; it gives a
phase on a 600- or 720-unit loop. And 357.7 is a joint fit over both leaves
while the port's ~400 poses one, so the two are not comparable in kind -- the
phases coincide only every LCM 3 600 units.

Discriminator handed to the port rather than taken: if its ~400 is pteff03 and
the frame is in the first cycle, pteff03a must be at centre 295 in that same
frame. The fit is against its renderer, so it owns the check.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:15:45 +00:00
sylph-decoder
bec7f02c0a re: not ONE of the 80 forced instances has a file-read key
The port agent pointed out that forced_backdrop_necessity.rs collapsed
sprite_layer_key (a u16 read from the T8aD header, decoded) with
implied_layer_key (this crate's table of positions MEASURED in the running
game), and that 'has its own key' therefore reads as file-backed when it is
not. Splitting them is stronger than either of us stated:

    read from the T8aD header:   0
    implied (measured):         14   10x pfbase.tbm, 4x palogo_eff0.prm
    nothing at all:             66   62 decided, 4 inert

Zero. There is no instance on the disc where a forced element also carries a
file-read layer key, so this rule has never been checked against a decoded
field -- there is no case where both can speak. That is what a keyless-element
fallback necessarily looks like, but it removes a check a reader would assume
exists.

Also corrects something I said to the port and had wrong. 'None of the 18 is
evidence for the rule in any direction' conflated two questions. Whether the
rule changes the composite: no, the sort already had the key. Whether the rule
gets the RIGHT answer: yes, and the 14 implied keys are measured positions, so
this is the rule agreeing with the oracle -- its only external corroboration,
and there are 14 instances of it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:11:12 +00:00
sylph-decoder
f8abb56bc4 re: reconcile the two ink counts -- we agree at >1 and not at >0
The port agent produced a genuine second witness for the pixel-cost claim: it
re-checked GP_TITLE entry 12 in Godot, which shares no code with compose,
swapping only paint_order. 59 530 px ink with the rule, exactly 0 without it.
The strong form -- the screen ceasing to exist, not merely changing a lot --
now has two real renderers behind it on that entry.

Its figures did not match ours, so I counted the same composite every way:

    RGB > 0    ours 49 771   Godot 59 530    16 %  apart
    RGB > 1    ours 48 043   Godot 48 368    0.68 % apart

The entire disagreement lives in pixels whose value is exactly 1. That is a
1-LSB sampling artefact between two samplers, not a different set of inked
pixels. So '>0' is not a portable ink convention between renderers on a
mostly-dark frame and '>1' is; any future cross-renderer ink figure should say
which it used.

Also worth recording: our 49 771 was never a threshold figure. It is exact RGBA
inequality between the two paint orders, which over a black backdrop coincides
with ink>0 -- so it belongs against the port's 59 530, not its 48 368. Matching
it to the 48 368 would have made the two renderers look like they agreed for
the wrong reason.

The without-the-rule column is 0 at every threshold here too, matching Godot:
the strong form is not threshold-sensitive in either renderer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:07:21 +00:00
sylph-decoder
aa9b7ef340 re: the forced-backdrop rule's pixel cost -- 38 screens go black without it
Follows the necessity census. 'The order moves' is a property of the sort; the
tie-break work already found reorders costing zero pixels, so the picture
moving is a separate claim. Rendered each of the 62 deciding builds twice and
diffed.

  38 .prm deciders: changed_px == ink_px in ALL 38. Without the rule the
                    primitive sorts last, paints over everything, and the
                    screen composites to pure black. The port's original
                    contradiction argument, measured on 38 builds across seven
                    archives instead of argued on two.
  24 .tbm deciders: zero -- and that is MY INSTRUMENT, not a finding.

The control asked whether the composite had ink; it always does. The question
was whether the reordered ELEMENT has ink, and compose draws no pixels at all
for a .tbm. So those 24 zeros measure our renderer's blindness by construction.
tie_break_pixel_cost.rs already had the per-element ink_mask this needed.
Reported rather than quietly patched: a control that cannot fail is the shape
this corpus keeps paying for.

Also corrects two things the port agent caught:

  - 'Two renderers, same answer' was true of the six GP_TITLE instances and not
    of the other 74. The port's re-run of my probe is my code executed twice;
    its independent leg was removing its own exporter post-pass, which covers
    GP_TITLE only. The disc-wide 62 has one witness and the page now says so.
  - forced_backdrop_necessity.rs defaulted to GP_TITLE with no argument, so a
    bare run printed 6 instances in the same format as 80. It now walks every
    dat/*.pak and reports the archive count.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:04:05 +00:00
sylph-decoder
304ce9efaa re: forced_backdrop DECIDES 62 of its 80 instances, not 6
The port agent raised that every check this corpus ran on the rule measured
its STABILITY -- that no verdict moved -- and never its NECESSITY. It is
right, and the distinction is load-bearing.

New probe: recompute derived_paint_order with the forced_backdrop fallback
removed and diff the orders, over every dat/*.pak.

  80 forced instances = 62 the rule DECIDES + 18 it merely AGREES with.

The 80 reproduces the page's own census exactly, which is the check that the
probe sees the same set. Every one of the 62 deciders is keyless; no keyed
element is ever moved.

Of the 18 that agree, 14 have their own key -- and that includes the
palogo_eff0.prm 'control', whose implied key is 0x00000000 and would sort it
first regardless. So that agreement is the rule reproducing our crate, not the
game confirming the rule. The port saw this before I did. The remaining 4 are
keyless but inert: every element on those two builds is forced, so the
tie-break gives the same order either way.

Confirms the port's GP_TITLE finding from the other side: entries 10/11/13/14
unchanged without the rule, entries 12/15 decided by it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 06:53:16 +00:00
sylph-decoder
e94e203a71 re: the A-press fault is SOLVED -- Xenia swallows input, the guest pump is unbounded
The 326 MB log from the failing run was still on disk, so this needed no
emulator time at all.

Mechanism: Xenia's XamInputGetKeystrokeEx returns X_ERROR_SUCCESS with a zeroed
keystroke on every call while a XAM dialog is up (xam_input.cc:197, upstream
Canary). The game's keystroke pump -- sub_82457038, read out of the image -- is
an unbounded 'while (GetKeystrokeEx() == SUCCESS) queue.push_back()'. It queued
8 388 608 empty keystrokes, grew its vector to 64 MB, asked for 128 MB, got a
failed allocation back unchecked, and copied off the top of the guest stack.

Two independent instruments agree to within 7: the Canary counter's last report
before the crash says 8 388 601 swallowed calls; the crash dump's r29 says the
vector held 8 388 608. The reporting granularity is 600.

Retracts this page's own 'r9 is a wild pointer above 4 GB'. Xenia prints
si_addr, a host address; the guest is mapped at 0x100000000, so the fault
address is guest 0x701D0000 -- which is exactly r9 in the register dump.

Also refutes nothing of the port's, but answers its ask #3: the two press-a
captures are different frames (40.84 % of the band's pixels differ at the
best alignment, which has a sharp minimum), so its 0.301 % is not an
instrument floor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 06:44:49 +00:00
sylph-decoder
6d7bc87b0f re: diagnose the A-press fault -- a wild pointer, and a third failure mode
The blocker on all menu-side dynamic RE in this container, measured over four
runs and traced to an instruction.

A single A press on the title produces a Xenia CRASH DUMP with PC 0x824578A0 and
"Access Violation: write at 0x00000001701D0000", repeating 32 356 times and
writing 326 MB of register dump in about ten seconds. Four A runs faulted; four
no-input runs in the same sessions completed.

REFUTED, my own hypothesis: it is not an unimplemented instruction. The config
carries break_on_unimplemented_instructions = true and Xenia's own message reads
"to skip, disable break_on_unimplemented_instructions", so the flag looked like
the fix. Booting with it false faults identically, and no "Unimplemented instr"
line is ever logged on stdout or stderr in any run -- and since that path emits
its XELOGE BEFORE the guarded DebugBreak, the absence rules the mechanism out
rather than leaving it open. The dump comes from Emulator::ExceptionCallback, a
genuine guest exception.

The instruction, read from the image rather than the database: b0c90000 is
sth r6, 0(r9), the first of four halfword stores at offsets 0/2/4/6 through r9
inside a bne- loop -- code filling an array of 8-byte records with four u16
fields each. So r9 is a wild pointer, and 0x1701D0000 is above 4 GB, outside the
guest's 32-bit address space entirely: not a null dereference and not a small
overrun, but a base that was never a guest address. The database agrees on the
containing function, sub_82457780 at +0x120.

It is a THIRD failure mode. Not the cache-flush crash at 0x82307128, and not the
loader stall documented in canary-scripted-input-traps.md, which logs ZERO crash
dumps. Unlike the stall it reproduced 4 of 4, so that page's "retry whole boots"
does not obviously apply. It does not explain how Q4 and Q5 pressed A
successfully; what differs between those runs and these has not been found.

frame_clock.sh's 300 MB guard killed the run as designed -- the session log's
"EMULATOR GONE at 56s" is the guard, not the crash.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 22:17:45 +00:00
sylph-decoder
159778faf1 formats: test backdrop coverage per instant, and record where the .tbm hunt reached
Two things, neither of which moves a verdict.

The port pointed out that rejecting on DECLARED size replaces one error with its
mirror: an element scaled ABOVE 100% could cover the screen from a smaller
declared size, and my guard would silently exclude it. Checked against the disc
first: across 921 keyless elements, ZERO cover the screen only via scale, so the
mirror case does not occur here. Adopted anyway, because the construction does
not need that to stay true -- coverage is now tested per instant against the
scaled size, alongside the opacity test, since both animate on the same ramp.
80 forced instances before and after, split 42 .prm / 38 .tbm, unchanged.

Second: an attempt to upgrade the 38 .tbm verdicts from inferred to decoded by
finding the texture and measuring its alpha coverage. It cannot be located. Not
in its bundle (no RATC record, no sprite-table entry, for any of the 13 names);
not a file (no .tbm anywhere on the disc); not a pak entry (its archive's hashed
TOC contains none of the name, its uppercase form, its stem, .t32/.tga/.xpr
variants, or ui\\ and tex\\ prefixes, across four archives); and not visible in
our composite, since compose skips an element with no resolvable sprite, so we
draw no pixels for a .tbm at all -- and no committed capture covers a screen
that has one.

So a second reading survives and is recorded rather than excluded: a .tbm may
contribute no pixels, in which case its paint position is INERT rather than
correct. That leaves the 38 harmless instead of right -- a different claim with
the same consequence. Distinguishing them needs a capture of GP_SAVE_LOAD,
GP_BUNK or GP_DEBRIEFING_PILOTLOG, all behind the A fault.

One upgrade: pfbase.tbm's first position is MEASURED, not inferred -- it is
element 0 of the save/load frame and the order read off the running game starts
[0, 1, 2, ...]. Twelve of the thirteen .tbm names still rest on the rule.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 22:04:31 +00:00
sylph-decoder
29c99e1b3e re: primitive blend mode -- undecodable with reach, and no longer a risk
Looked in four places. The bundle has no field: a primitive has no RATC child at
all and the declaration words are constant across every element of three measured
screens -- the two grounds ui-prm-primitives.md already used to refute a
bundle-side LAYER key, and they apply identically to blend.

The colour census: every full-screen *eff00* primitive on the disc carries pure
black at its various alphas, and the only non-black primitive anywhere is
pbafc.prm, RGB 00e8e0 cyan.

The occlusion constraint cannot reach that one. pbafc.prm looked alarming at a
declared 844x600 and alpha ff; it is a small moving glint. It strobes between
alpha 255 and 124 every 2 units, travels from x=178 to x=291, and is scaled
2%x3%, so it draws about 17x18 pixels. At that size it occludes essentially
nothing.

The oracle is unavailable: GP_READY_ROOM is a recorded no-go and gameplay needs
the A press that faults the guest in this container.

But the consequence closes even though the question does not. For a BLACK quad
-- which is every primitive forced_backdrop touches -- the hypotheses differ only
in whether it hides what is beneath. Drawn first it is correct under both; drawn
last it is correct only under additive. So the rule's verdict is robust to the
open question, and the port's original "layerless sorts last" was wrong under
alpha-over and merely pointless under additive. This is explicitly NOT evidence
for alpha-over.

The investigation also found forced_backdrop judging coverage from the pivot
alone, ignoring scale -- pbafc.prm is the disc's own proof that a nominally
844x600 element can draw at 2%. Checked before changing anything: all 80 forced
instances are at scale 100% on every opaque instant, so no verdict moved. The
guard now requires scale >= 100 at the instants it counts as opaque. Defensive,
not a fix. 4 + 13 disc tests green either side.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:58:25 +00:00
sylph-decoder
1f6e07598e re: the primitive colour census -- and it refutes 38 of my own 80 forced verdicts
A disc-wide census of the ARGB that keyless elements carry.

Every full-screen *eff00* PRIMITIVE is pure black at its various alphas
(ff000000, 7f000000, 40000000, b2000000, cc000000, d4000000, 00000000). Black at
alpha a over content is exactly an alpha-over dim or fade, and an additive black
quad would be a no-op nobody would author -- so this narrows the open blend
question a long way. The only non-black primitive on the disc is pbafc.prm, RGB
00e8e0 cyan at alphas up to ff, and it is 844x600, NOT full-screen, so it sits
outside forced_backdrop's geometry guard. It is now the sole additive candidate.

The census also refutes my own argument for nearly half its verdicts. Of the 80
forced-first instances only 42 are .prm; 38 are .tbm carrying fade ffffffff. A
SOLID white quad at alpha 255 painted first would make the screen white, and no
screen is white -- so a .tbm is a white modulation on a texture, and element
alpha does not establish its coverage.

That is the .t32 error one file extension further out. I guarded that with
el.sprite.is_some(), which fixed the symptom and not the cause: an element's
alpha is not its texture's opacity, and only an untextured primitive makes the
two the same fact.

So 42 verdicts stay decoded and 38 drop to inferred -- still almost certainly
right, since all are named *base*, all are full-screen, and pfbase.tbm's first
position is measured in the running game, but that is a name-and-role argument
which this page elsewhere calls the weaker kind.

The code is deliberately unchanged. Restricting forced_backdrop to .prm would
send eleven screens' backgrounds back to u32::MAX -- last -- which is the
blank-screen bug the rule was written to fix. Downgrading the status is honest;
reverting the position would be wrong. The 42/38 split is pinned by a test so
anyone tightening the rule sees what it costs.

Separately, on the port's black_hold_units ask: four more no-input boots yielded
one usable log, which armed late and missed the publisher splash, so the sample
is still two runs spanning 3 and 4 frames. Their 6.5-9.2 range stands. And a
reason it may not be resolvable this way: the draw log DROPS frame numbers -- in
the 3-frame run, frames 121 and 124 are absent entirely, so "frames with no
sprite" and "span of frame numbers" are different quantities.

Their statistical correction is taken: at n=3 the sample SD (3.893) is the
estimator, not the population SD (3.179), making my run 1.88 sigma from the
corpus mean rather than 2.31.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:51:06 +00:00
sylph-decoder
7a5f7b886a re: downgrade -- the drift explains the 4.1% in sign, not magnitude
The port refuted the stronger half of the last claim and was right. I wrote that
the units/frame drift explained the publisher splash's 4.1% error against its
declared dwell. It explains the sign only.

Their test verified exactly here: the publisher/developer dwell ratio is 1.2143
declared, 1.2784 as the corpus's three cold boots measure it, and 1.3678 as this
container's drift predicts -- so the drift's direction is right and real evidence,
but its magnitude is about 2.4x too strong.

One refinement, because the means are being compared more finely than n=3
supports: the corpus's three boots individually give excesses of +0.89%, +8.24%
and +6.79%, a spread of 7.3 percentage points -- WIDER than the 5.30 pp gap under
test -- and boot 1's ratio (1.2251) is essentially the declared 1.2143. This run
sits 2.3 sigma above their mean: suggestive, not established.

Not closable without a frame log from the corpus's instrument, which was
screenshot timing and has none. An attempt to give this side an n of 3 failed on
tooling and is recorded: ARM=early loses its F10 about 40% of the time -- two of
five runs logged "ARMED EARLY" and produced no draw log at all, with nothing in
the session log distinguishing them.

Also fences the 33% drift against a misreading the port flagged: it is
PRESENTATION pacing and cannot reach keyframe_units_per_second = 60, which is the
game's logical rate, decoded under Q1, and which a renderer converts through at
its own frame rate.

And records a cross-check neither side went looking for: the batch counts are 1
and 2 on the publisher against 3 and 6 on the developer, and the port reports a
count restricted to SPRITE-BEARING elements reproduces that exactly from the
export -- so palogo_eff0, the layerless forced backdrop, is not in the batched
draw, confirmed from the file. Two instruments that disagreed about that element
in every previous iteration now agree on which one it is.

New tool splash_boundaries.py carries the corrected counting method.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:40:23 +00:00
sylph-decoder
6c8ab5db94 re: withdraw the splash frame boundaries -- count the batch, not the logged quads
The port refuted the boundaries in boot-splash-dwells-are-declared.md by
arithmetic: the two splash spans gave 2.237 and 2.414 units/frame, 7.9% apart on
one boot of one guest, which must be one number. They proposed the spans were
anchored on different elements.

The log says the cause is worse. The developer splash batches SIX quads into one
draw (indices=24) and the log dumps only the first two. While the three glows are
alive they occupy that prefix, so the three wordmarks are invisible to the log
until the glows stop being submitted at t=45. "Developer wordmarks first drawn at
frame 140" was the logging prefix shifting, not the game -- and the same defect
explains why palogo_anima never appeared at all.

The fix costs nothing: indices/4 is how many quads the draw actually holds, and
the 8-vertex cap cannot touch it. Its transitions land exactly where the declared
count of elements with alpha>0 changes, giving free calibration points:

  publisher   1->2 quads at frame 5.5 (t=15), 2->1 at 22.5 (t=45), ends 119.5 (t=255)
  developer   3->6 quads at frame 126.5 (t=15), 6->3 at 139.5 (t=45), ends 209.5 (t=210)

That yields 1.765 and 2.165 units/frame on the publisher, 2.308 and 2.357 on the
developer -- the developer's two independent segments agreeing to 2%, and the rate
rising 33% across the run. One cause for both the port's 7.9% inconsistency and
this page's open 4.1% publisher error, exactly as they predicted: the publisher
splash runs during the first seconds, where the rate is furthest from its later
value. It also means no single units-per-frame figure describes a run here, which
is the dwell-is-emulator-paced conclusion from a third direction.

The declared dwells (255 and 210 units) and the corpus's three-cold-boot
confirmation are untouched -- neither uses this draw log.

METHOD.md gains the general form: when an instrument truncates, the surviving
sample is not random, it is the first N, and what falls in the first N is itself a
moving function of the thing being measured. A truncated view looks like a
complete view of a smaller set.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:34:51 +00:00
sylph-decoder
acaacc36e0 re: the boot splash dwells are declared -- and wall clock is the wrong unit
The port asked for two wall-clock timestamps across the boot splashes. Measured,
and the measurement's own result is that timestamps are not the invariant.

The dwells are the bundles' own declared timelines: publisher t=0..255 = 4.250 s
at 60 units/s, developer t=0..210 = 3.500 s. The corpus's independent screenshot
timing over three cold boots gives 4.30/4.60/4.37 and 3.51/3.50/3.37 -- the
developer agreeing to 1.1%, two of its three runs to 0.3%.

A fresh no-input boot with a frame->wall-clock map puts the same two dwells at
5.10-5.61 s and 3.83-4.30 s, 15-20% longer than both the declared values and the
corpus's runs, on the same disc and the same declared timeline. So the
wall-clock dwell is an emulator-pacing artefact that varies run to run, and a
port authoring seconds is authoring one run's pacing.

Boundaries from the draw stream, read per quad: publisher glow frame 1, wordmark
6-119, three frames with NO sprite drawn, developer glows 123, wordmarks
140-209, intro video 216. The 3-frame gap replicates the earlier 4-frame
measurement within the +-1 both are quantised to.

New tool frame_clock.sh, and its limitation found by its own control: it
resolves to one BUFFER FLUSH, not one frame. The capture writes through a C++
ofstream, so tail sees the log in bursts -- 69 of 125 samples showed no advance
and the rest jumped 7-15 frames. Naive interpolation inside a burst made the
apparent rate swing between 0.0164 and 0.0316 s/frame, which is the flush and
not the guest. Frames 119 and 123 fall in one burst, so the inter-splash gap is
not separable by this clock at all. Everything is quoted as brackets and the
point estimates were withdrawn before being reported.

palogo_anima never appears in the log and is NOT reported as undrawn: the
developer bundle batches 7 elements into one draw and only the first two quads
are logged. That is the trap that produced the eff3 false negative, so it is
named rather than claimed.

Also records the port's correction: ptcopyright has 105 instants with alpha >= 1
(t=139..243) against 105.89 units of span; I had quoted the rounded span.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:29:06 +00:00
sylph-decoder
78328c5022 re: the top-level clock freezes at the settle point -- closing the 114-vs-120 gap
Measured in the title draw capture, re-read with the per-quad parser.

GP_TITLE build 4 declares t = 0..269, about 120 presented frames at this run's
pacing. The title dwell lasted ~1100. ptcopyright declares alpha >= 1 for 106
units (t=138..244) and is drawn for 1050 frames; ptlogo1 declares an exit at
t=264 and is drawn for 1095. Both vanish within three frames of the dwell
ending.

So the top-level clock advances through the build-in, stops inside the settle
window [160,236], and holds. The exit ramp is not played on a timer -- it plays
when something makes the screen leave. That is ui-settle-time.md's decode seen
from the other side and observed in the running game rather than inferred from
the file. A nested record keeps looping on its own clock throughout.

This closes the 114-vs-120 gap, and it was my arithmetic rather than a
discrepancy in the decode. The 2.231 units/frame was regressed over BUILD-IN
events -- the only stretch in which the top-level clock advances -- and applied
to a period measured over the settled dwell, where that clock is frozen and
only the plate's own record is running. Two different clocks. The declared 120
was never in doubt from the calibration-free dark-fraction test.

The 51.158-frame period is now confirmed by a second independent estimator:
autocorrelation returns lag 51 with clean harmonics at 102 and 154. Its FIRST
version failed its control, returning 48 for a period known to be 51.158,
because it indexed by sample position where the log's frame numbers have gaps.
Recorded, because the failure is the reason the second version can be trusted.

Not settled: the sweeps' period. The same validated estimator disagrees between
two dwells of one screen -- 515 vs 452 frames for the same family -- and a 14%
disagreement within one screen is not a period. The +0x08 field cannot settle
it either, since ptloop01/ptloop02 have zero slack.

Blocker recorded in CONTAINER-NOTES: a single A press on the title faults the
guest. Three menu-capture attempts, two ending in register dumps of 223 MB and
519 MB, against three no-input runs in the same session that all completed. And
a guest fault writes an UNBOUNDED register dump to stdout on a filesystem at
91%, so any scripted button press needs a size guard.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:21:27 +00:00
sylph-decoder
cf91ad1dcc re: the forced-backdrop span -- 256 vs 211 is a bundle mismatch, and the hold
decides 55% of verdicts

The port implemented the forced-backdrop rule and reported a discrepancy:
palogo_eff0.prm at 256 opaque instants against this corpus's 211.

There is no discrepancy. palogo_eff0.prm appears on BOTH splashes -- the
publisher (entries 10, 13) runs to t=255, giving 256 instants; the developer
(11, 14) runs to t=210, giving 211. Same definition, different bundle. The page
now names the entries so it cannot recur.

The definition, stated: the span is 0..=max keyframe time over every element in
the build, and an element HOLDS its final pose past its own last keyframe --
which is what pose_at does, and which is decoded rather than assumed (a group
holds at its last keyframe rather than looping; the declared +0x08 never falls
short of the last keyframe, the slack being that hold).

The port's instinct that the hold was load-bearing was right. Over the 130
keyless full-screen primitives with an opaque interval:

  * span = the header's declared +0x08          ->  0 verdicts change
  * span = the primitive's own last keyframe    -> 72 change
  * elements GONE after their last keyframe     -> 72 change

So the hold decides 55% of verdicts -- and dropping it is REFUTED by a measured
order. palogo_eff0.prm is a single keyframe at t=0: without the hold it is
opaque for one instant, no other element is up yet, and the rule calls it free,
against a game measured painting it first. Pinned by a new test that spells out
the counterfactual rather than importing it.

The verdicts that matter are convention-independent: pgloading_eff00.prm is
FIRST under all four conventions and pteff00.prm FREE under all four. And the
header length is interchangeable with the elements' maximum -- zero
disagreements disc-wide.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:14:58 +00:00
sylph-decoder
cfcda5501c formats: a keyless primitive that would hide the screen is forced to paint first
Partly closes ui-prm-primitives.md's standing blocker, "where an UNMEASURED
primitive paints". Raised by the port: build_12/build_15 composite to solid
black at every instant of their declared life, because pgloading_eff00.prm -- a
full-screen opaque quad -- sorts last.

The rule is a constraint read off the file, not a preference: an element that
covers the screen and is fully opaque at some instant cannot paint above
anything visible at that instant. Where the elements visible during its opaque
span are ALL of them, its position is forced to first.

pgloading_eff00.prm is opaque for 39 instants and all 9 other elements are
visible inside that span -> forced first, 4/4 instances.

Two controls, both measured orders from the running game, and the rule has to
survive both:

  * palogo_eff0.prm is measured painting FIRST -- opaque 211 instants, forced
    below 6 of 6. It is NAMED like an overlay, so a name-based rule sorts it
    wrong against a measured order. Occlusion gets it right.
  * pteff00.prm is measured painting LAST -- opaque for 2 instants at its
    screen's entry and exit, forced below only 3 of 23, so the constraint
    permits it on top where it belongs.

Disc-wide: 80 instances forced first, 50 constrained but not forced, 0
unconstrained. The split runs almost exactly along the names -- every *base* is
forced, every *eff00* is not -- with three families crossing it, which is
exactly why the name is not the rule.

It also explains 36 builds the corpus had recorded as "coming out one colour"
with no cause: pzeff00.prm is forced first in 32 of 32 instances, so they were
wiped by our own sort rather than by the game.

The rule's real limit was found by its own disc-wide test failing. Applied to
any element it claimed 22 .t32 SPRITES must sort first against their own layer
keys -- pneff01.t32 (key 0xd850, #8 of 13) and pbfriendly.t32 (0x9230, #17 of
49). A sprite's ELEMENT alpha says nothing about whether its TEXTURE covers the
screen, so forced_backdrop is now restricted to untextured primitives, which is
also the only case derived_paint_order consults it for.

Reach stated: assumes straight alpha-over (blend mode is still open, and an
additive quad at alpha 255 would not occlude); it is a lower bound, not an
ordering; and there is no new oracle measurement -- both controls are prior
ones, and a loading screen is not reachable from the title path.

3 new disc tests; the 13 paint-order tests are green, including
the_derived_order_matches_the_measured_ones_up_to_ties.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 21:02:17 +00:00
sylph-decoder
47faeaa7a9 re: RETRACT "the game never draws eff3" -- a batched draw merged two quads
The console draws all five title flashes. My claim that ptlogo_back2eff3 is
never drawn was an instrument artefact, and I had reported it to the port with
three alternative explanations "ruled out".

A GPU draw can batch several quads -- indices=4 is one, indices=8 two,
indices=24 six -- and the UI draw log dumps only the first 8 vertices. Taking
min/max over a line's whole vertex list merges quads into one box.

eff3 is batched with eff4, and because the wipe family is right-aligned, eff3
(788..1196) lies ENTIRELY INSIDE eff4 (447..1196). The union is exactly eff4's
own extent, so the merged box matched eff4 to 1 px, eff3 vanished, and nothing
looked wrong.

Parsed per quad, all five fire in both title entries in the declared stagger:
eff1 130-131, eff2 133, eff3 133-134, eff4 133-135, eff/eff5 134+, back2 136+;
and 5953-5955 / 5955-5957 / 5957-5958 / 5957-5959 / 5958+ / 5962+ in entry 2.
Frames 133 and 134 are t=60.1 and 62.3, inside eff3's declared t in (58,64).

Also retracts "the developer splash is one composited quad" -- the same bug,
which the port refuted by arithmetic first (a 259-tall box cannot contain three
logos spanning y 164..585). It draws three logos and three glows as separate
quads in one indices=24 call; the 525x259 was gamearts_eff merged with
seta_eff. The 9-unit black hold is unaffected: those glows are the developer
splash's first draw.

The three "ruled out" explanations were all aimed at the wrong failure. In
particular the invisible-draw check counted draws with NO geometry line, when
the hiding place was draws with PARTIAL geometry. Refuting three wrong
hypotheses is not evidence for a fourth, and a list of failure modes written by
whoever built the instrument is the least likely to contain its blind spot.
Recorded in METHOD.md, along with the tell that was present and explained away:
a merged box carries the first quad's colour, which made one element's alpha
read 255/127/254 on consecutive frames.

New tool: tools/re-capture/quads_per_frame.py parses vertices in groups of four
and warns when the logged quad count falls short of indices/4.

Also guards a double-A-tap in ui_draw_capture.sh: the movie branch ignored that
TARGET=menu had already tapped, so a run tapped A on the title at t=23s and
again at t=27s on the transition; the guest faulted and Xenia dumped registers
to stdout until the file reached 519 MB.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 20:49:27 +00:00
sylph-decoder
1a2f4fdc2d re: the boot splash black gap is ~9 units, measured in draws not luminance
The port found its boot had no black frame between the publisher and developer
splashes and authored 12 units by analogy with the menus' transition quad. On
the boot path that analogy has nothing behind it -- palogo_eff0.prm is a single
static keyframe, so the splash bundles declare no fade quad.

I had agreed with the dismissal that hid the defect: told the residual was
0.03 s against a bound built from two measured ranges plus jitter slack, I said
it said more about the bound than the game. The real gap was 0.2 s.

Measured in the draw stream, which separates true black from a fade tail where
luminance cannot: palogo_sqex is drawn to frame 125 at alpha 7, frames 126-129
submit NO sprite quad at all, and the developer fades in at frame 130 from
alpha 34. Four presented frames, the only such run in the sequence.

Converted with the disc as its own clock rather than a frame rate -- this run
presented at 13.1 fps against 28 elsewhere -- palogo_sqex declares alpha >= 1
for 239.8 units and is drawn in 105 frames, giving 2.284 units per presented
frame, which the title capture independently corroborates at 2.231. So the gap
is ~9.1 units (0.152 s), against the 12 authored; +-1 frame is 6.9-11.4. And
the true black is SHORTER, since both boundary frames still carry picture.

Second finding: the developer splash is ONE composited 525x259 quad at the
bounding box of its three declared logos, none of whose individual sizes is
ever submitted. That is why an earlier pass reported "developer splash: 0
frames".

Declaration sites ruled out: the splash bundles (no fade quad) and the
top-level +0x08 (a family constant, 300/60, slack 12-226 units). The
executable is NOT looked at and is named as the next place rather than
claimed.

Also answers the port's sweep question: +0x08 canNOT settle it, because
ptloop01/ptloop02 have zero slack and a zero-slack record cannot distinguish
"loops" from "runs once and stops". The oracle settles it for the TITLE -- the
sweep oscillates over its whole range and resets hard to the same start, once
in dwell 1 and twice in dwell 2, so it does not park. The MENU is unmeasured
and stays open.

Tooling: GRACE and NOTAP knobs for ui_draw_capture.sh. The script taps A on
"the screen changed a lot", which is also true of a fading splash -- a first
run tapped through the publisher and the developer never appeared. The
instrument was perturbing what it measured.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 20:36:15 +00:00
sylph-decoder
69bc4cd1cd re: the game never draws ptlogo_back2eff3 -- reproduced, with three explanations
ruled out

Last iteration I recorded eff3's absence as unexplained after withdrawing a bad
explanation for it. The previous capture survived on disk with 6907 frames, and
the attract loop returns to the title, so it contains a SECOND build-in at
frames 5942..7025. eff3 is absent there too.

Three alternative explanations tested and failed:

  * sampling phase -- eff3 is non-zero for t in (58,64), SIX units, against a
    2.23-unit step. A window wider than the step cannot be missed; frames 133
    (t=60.1) and 134 (t=62.3) sit inside it and draw eff2 and eff4 instead.
  * a draw the log cannot see -- exactly 2 draws per frame carry no geometry,
    on all 932 settled title frames, always the same full-screen-triangle
    shader, and present on frames where no wipe element is active.
  * a bad position guess -- dropping position entirely, ZERO quads anywhere on
    screen in either build-in window have a width within +-30 of 408. The width
    spectrum jumps straight from 262 to 748.

Draw counts across both entries: eff1 4, eff2 3, eff3 0, eff4 6, against ~5
expected each. The four are a right-aligned wipe (938+258, 788+408, 447+749,
64+1133, all ending at x~1196) -- a left-growing reveal in four widths, of
which the game draws three.

Why is NOT established: nothing in eff3's element record differs from its
neighbours. Classified measured, not decoded, and the port is told that
dropping eff3 means authoring a behaviour I cannot derive from the file.

Two further corrections, both to my own earlier claims:

  * "frame 107 is the title composited once" was an over-read. It binds NO
    texture and only 4 of its 27 draws log geometry. The second title entry
    has no such frame.
  * the two build-ins are NOT frame-identical. I had that from a coincidentally
    aligned pair of rows; aligned properly only 4 of 46 frames match. They are
    the same animation at different sampling phases -- which is precisely what
    makes the eff3 result robust.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 20:19:04 +00:00
sylph-decoder
311bd16ad8 re: withdraw the eff3 explanation and the flash advice; add a calibration-free
test that refutes 105

Two claims shipped this morning are withdrawn, and the port had already acted
on one of them.

WITHDRAWN 1: "eff3 was never drawn because a 2-unit flash peak is sub-frame."
eff3's alpha is non-zero for t in (58,64), and the capture's frames 133 and 134
sit at t = 60.0 and 62.2 -- squarely inside that window, with eff2 and eff4
both drawn in the same frames. It should have been submitted and was not. The
absence is real and UNEXPLAINED; it is not sampling phase.

WITHDRAWN 2: "a port drawing all five flashes shows more sweep than the
console". No evidence behind it. The port checked against its own renderer and
found it draws them sequentially at their declared times, never more than two
at once -- which is exactly what frames 131-135 show the game doing. The
pile-up worth warning about was the rest() bug, now fixed.

Kept, at the port's request: a frame-by-frame comparison of the build-in WILL
disagree about which flash lands in which frame -- 2 units per submitted frame
against this run's 2.231 units per presented frame -- and neither side is
wrong. Without that stated, the discrepancy reads as a port defect.

Added, and stronger than the argument it replaces: a calibration-free test of
105 vs 120. The glow's draw is omitted when its alpha reaches zero, and the
smallest alpha actually submitted across 807 drawn frames is 1, so the culling
threshold is read off the data rather than assumed. Measured dark fraction
17.7% (173 of 980 settled frames); a 120-unit cycle with its declared 15-unit
hold predicts 14.4%; a 105-unit cycle predicts 2.2%. 105 is out by 8x and
would need a threshold of alpha 11 out of a peak of 80, while the capture
contains submitted draws at alpha 1..12. No frame rate, no pacing factor, no
wall clock.

Also recorded: a regression of five build-in events against their declared
times (residuals <=0.9 frames) recovers t=0 at frame 106.1 when the composite
spike, not in the fit, is frame 107 -- and that same slope makes the glow's
period imply a 114-unit cycle against a declared 120, which is unexplained.
And the vertex-alpha identity holds for the glow but does NOT generalise:
eff4 reads 255/127/254 on consecutive frames.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 20:03:48 +00:00
sylph-decoder
d98c8214cc re: the title's build-in measured in the guest's draw stream -- the flashes are real
The settle-time decode was confirmed only against a SETTLED frame, which shows
the end state is right and says nothing about whether the five flashes ever
happen. This runs the oracle: a draw capture armed before the title exists,
so the window contains the frames in which the screen is built.

The flashes fire in a six-frame window and are absent from all 155 other
sampled frames. `ptlogo_back2eff1` is drawn in exactly two frames at t = 54.0
against a decoded peak of t54-56; `ptlogo1` first appears at t = 42.2 against
a decoded t42. Units-per-frame was taken from the GLOW's period alone, a
different element, so the timings are not circular. The two holders are
continuous from frame 134.

The plate glow's quad carries a per-vertex colour whose alpha IS the element's
fade alpha, so the ramp is read straight out of the guest: observed range
0..80 against a decoded peak of 80, exact and unfitted; period 51.158
presented frames over 20 cycle starts. Fitting the decoded ramp gives RMS
13.16 alpha levels against 38.18 for the same ramp REVERSED -- if the shape
carried no information those would be equal, so the asymmetry is real and
correctly directed. Further controls: symmetric triangle 15.73, flat 31.13.

`ptlogo_back2eff3` was never drawn, and that is expected rather than a miss: a
2-unit flash peak is 0.85 of a presented frame, so catching one is a matter of
phase. A port drawing all five every time shows more sweep than the console.

METHOD.md gains the trap this cost: a 2D draw's identity is its vertex
geometry, not its bound texture. These sprites sample shared pages, and
matching texture dimensions produced a false negative (no flash is ever drawn)
and a false positive (the intro movie's 640x360 YUV planes read as `ptbase2`)
in the same pass.

Also records the top-level restriction on the settle window, which the port
raised and which is verified here: top-level [160,236] width 76, including the
`ptloop` leaves [269,540] width 271 -- an instant past the end of every
top-level element's timeline.

Evidence committed as a derived per-frame series, not the 7 MB raw log.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:56:34 +00:00
sylph-decoder
4c74e579a0 re: 210 focus records pulse, not 2 -- and 8 of them fail in a way that looks right
The port censused focus-record alpha over its own export -- 34 elements, 2
varying, both `ptbtn00f` -- and concluded there is nothing to fix. That is
correct and correctly scoped. This asks the same question of the whole disc.

1 130 focus records, 2 664 timed elements, 210 with a varying alpha. 202 have
`rest()` returning the PEAK, the `ui-settle-time` pathology. By pak:
PILOTLOG 116, MOVIE_THEATER 54, HANGAR_ARSENAL 30, LEADERBOARD 8, GP_TITLE 2.

So the port's 2 is right because GP_TITLE has 2. The scope was load-bearing
and was not stated as a limit -- "only 2 have a varying alpha" reads as a fact
about the format and is a fact about one pak. The pathology is concentrated in
exactly the screens a wider port reaches next.

The 8 LEADERBOARD ones are the worse mode. `py_ranking_btn01f` swings
255->127->255 with no two adjacent keyframes equal, so `rest()` falls through
to its longest-dwell rule and returns 244 -- neither the peak nor the trough.
A glow stuck at its peak is visibly wrong; one stuck at 244 of a 127..255
range looks entirely plausible and nothing reports it.

Verified rather than asserted: two hits dumped keyframe by keyframe, and a
control on `ptbtn01f`, which is genuinely constant across its cycle and is
correctly NOT flagged. `py_ranking_btn01f` also confirms the loop-length
decode independently -- its ramp ends at t=90 inside a declared 120-unit
cycle, holding bright for 30 units.

Reach stated: 210 is a floor. Focus records are matched by the `Xf.rat` name
rule, and elements with constant alpha but varying scale, rotation or
position have the same problem and are not counted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:45:17 +00:00
sylph-decoder
d4a08ad194 re: a nested record's +0x08 is its loop length -- the plate's period is 120, not 105
Answers the question the port agent asked: does the `PRESS A` plate's pulse
group loop from its start, or hold at alpha 0 between cycles? It holds.

A nested record is itself a RATC bundle with its own header, and that header's
`+0x08` is the loop length -- the same field ui_header_time_disc already tests
as an animation length at the top level. Its 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 between pulses. The five
main-menu focus records fill their 120 exactly, which is what shows the slack
belongs to this 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, and 0 declare less. That last row is the
falsifier -- a cycle cannot restart before its own last pose -- and it never
fires; the 7.7% is what keeps the reading from being an unfalsifiable
relabelling of the keyframes.

Falsification against the running game, using a pacing factor measured
INDEPENDENTLY on the main menu's focus ring (declared 120 units, measured
2.177 s, factor 1.0885): to reach the corpus's four measurements of the plate
pulse (2.12/2.19/2.34/2.31 s), a 105-unit period needs a factor of 1.211-1.337,
which EXCLUDES the ring's; a 120-unit period needs 1.060-1.170, which CONTAINS
it. Predicted 2.177 s against a measured 2.12-2.34. The two elements are in
different bundles and were measured in separate runs; the only thing tying
them together is that both declare 120.

So the port should stop shipping 105. Its 123-vs-129 ambiguity straddled the
right answer without containing it, and 129 only fitted because it was
105 + the exit_ramp_units constant it has since correctly deleted.

Reach is stated: this says where a cycle ends, not which records cycle, and
the TOP-level +0x08 is a different field left untouched -- every GP_TITLE
entry declares 300 while its elements end at 244-269.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:40:23 +00:00
sylph-decoder
7b5a4aa041 re: the paint-order tie-break costs one pixel, on one screen we do not ship
Closes the open half of Q3. `ui-paint-order-derived-check.md` bounded WHERE a
wrong tie-break could show -- overlapping same-key pairs -- and said outright
that nobody had measured how many change a pixel.

At the instant the player sees, the answer is: at most 1 px at max channel
difference 1, on the JAPANESE title only (`ptlogo2` x `ptlogo_tm`, 5 px of
shared ink). Exactly 0 px on all five port screens.

The earlier 24-pair bound was counted at `rest()`, and 10 of the title's 11
overlapping tied pairs are between `ptlogo_back2eff1`..`eff5` -- the five
transient flashes from the settle-time finding, transparent on the settled
screen. A tie between two invisible elements cannot cost a pixel.

Not a knife-edge. Sweeping every keyframe time and every midpoint between
keyframe times, the live-pair count is flat across the ENTIRE settle window:
1 on the EN title, 2 on the JP title, 0 on all four loading bundles -- whose
tie is live only at t17..t33, during the build-in, which matters because
their settle windows are narrow enough to deserve little trust otherwise.

Controls: every entry reporting zero also swaps an overlapping DIFFERENT-key
pair, which must and does move pixels (25 310 / 268 698 / ~765 000 px). Zeros
are explained by shared-ink counts rather than asserted -- the `ptframe` pairs
overlap by bounding box and share 0 px of ink. Entries 0/1/12/15 have NO live
control and their zeros rest on keyframe data rather than a render; recorded
as the weaker claim it is.

Refutation attempt on the corpus's "24 overlapping pairs": it SURVIVES as a
rest-pose count -- an independent recount reproduces entry 7's 16 exactly.
What is overturned is its interpretation as the risk surface.

`tie_break_pixel_cost` gains a settle-time case and an alpha/scale filter on
its rect test; `tie_cost_over_time` is new. Also strips 611 bytes of captured
cargo warnings from the head of the committed tie census.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:35:29 +00:00
sylph-decoder
38b80302b7 re: the title's light arc is five transient flashes, not a tone or rotation error
Records the settle-time decode, and corrects two claims it overturns.

docs/re/structures/ui-settle-time.md is the finding: a settled screen is one
instant every element is posed at, the disc names it (the midpoint of the
longest keyframe-free interval), and the title's arc closes from 33.22 to
11.79 with the clipped-pixel count landing on the console's 1459 within 0.5%.
Includes the disc-wide reach -- only 30% of bundles have a window wide enough
to trust -- and a three-way figure.

Withdrawn in ui-rotation-implemented.md:

  * "Flat. No minimum." was not a property of rotation. `at` posed LEAVES ONLY,
    so the scan moved the light sweeps and never touched the top-level flashes.
  * "our renderer does not draw ptlogo1/ptlogo2 at all" is wrong. Both are
    drawn; the four elements the diagnostic named are kind-0x4 ghosts sharing
    their template's name. Hiding the real ones makes the error WORSE by
    +5.20 and +7.47.
  * Its 10.92 baseline is not reproducible -- 14.07 at its own pre-change tag
    and 14.07 today -- so the "1.7% better" verdict rests on an unrecorded
    recipe. Flagged in title-residual-tone-vs-geometry.md too.

METHOD.md gains two traps: a shared CARGO_TARGET_DIR makes a `git worktree`
build silently replace the binary you run next (it cost three renders here,
caught only because a missing flag was a hard error rather than a wrong
number); and an aggregate computed per-element is not a state of the system.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:29:12 +00:00
sylph-decoder
d0735d2c25 formats: a settled screen is one instant, not one hold per element
`Element::rest()` picks each element's last hold keyframe independently of
every other element, so a composite built from it is not the screen at any
moment in time -- it is a per-element maximum. For a transient that is
exactly wrong: a two-frame flash's last hold IS the flash peak, so it burns
forever.

GP_TITLE build 4 is the case. `ptlogo_back2eff1`..`eff5` are five staggered
two-frame flashes -- one light sweep drawn as five frames, all extinguished
by t110 -- that `rest()` draws simultaneously and permanently. Five stacked
white glows saturate the light arc behind the logo.

The disc names the right instant: the midpoint of the longest interval
containing no keyframe of any element. `UiBuild::settle_time()` and
`settle_window()`; `screen render --settle` applies it and prints the window,
whose width is how much the midpoint is worth.

Predicted t=198 from [160,236] BEFORE scoring. Against the console capture,
the arc band goes 33.22 -> 11.79 and pixels at the clipping level 8581 ->
1452, where the console has 1459 -- an unfitted statistic. Whole frame
14.07 -> 12.06. Controls at t=100 and t=358 are far worse, and a hand-picked
visibility list reaches the identical numbers.

`ComposeOptions::at` now poses every element rather than leaves only, which
is why the earlier rotation pose scan was flat: it moved the sweeps and never
touched the top-level flashes. `at = None` is byte-identical (cmp), the
pre-rotation tag renders identically at rest, and the 13 paint-order tests
plus the keyframe/focus/opt-link disc tests are green.

Also fixes the diagnostic that caused a wrong finding to be sent to the port
agent: `not drawn` listed bare names, and a kind-0x4 ghost carries its
template's name, so four ghosts printed as `ptlogo1.t32`/`ptlogo2.t32` and
read as "the logo is missing". It now prints index, name and reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:28:27 +00:00
sylph-decoder
37af2055e3 formats: a scale-0 leaf must not claim the draw and blank its parent
Found by inspection while the disc tests ran. The leaf branch set its
something-was-drawn flag unconditionally after calling blit, but blit returns
early on a zero scale -- collapsed to nothing, not unset. So a scale-0 leaf would
have been counted as drawn, its parent skipped, and the element blanked outright.

pgloading_loop5 s leaf is scale (0,0), so this was live on all four loading
screens, and scale-0 is one of the failures this corpus is already named for.
Fixed by skipping a zero-scale leaf pose before it can claim the draw; the
loading builds render afterwards at 4.0 percent non-black.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 19:04:03 +00:00
sylph-decoder
81f42f9041 formats: teach the renderer to rotate (Option A) -- and report that it does not close the title
The human chose Option A: teach sylpheed-formats own renderer to draw
rotation_deg so it and the port stay comparable and verify-screen keeps meaning
someone is wrong.

Three pieces, because rotation alone does nothing on the title. blit gains a
rotated path that draws by inverse mapping over the rotated bounding box, turning
about the pivot, whose absolute position is invariant under scale; zero rotation
keeps the original forward-mapped path byte for byte so non-rotating screens
cannot regress. compose draws a nested .rat leaf when the leaf carries geometry
the parent does not, which is the sweeps case, but not as a blanket rule since a
button s leaf duplicates its parent. And --at poses leaves at a keyframe time,
because the sweeps hold off-screen at x=1521 so a resting composite omits them.

A trap found the hard way: posing EVERYTHING at one global time is wrong, because
a top-level group s final keyframes are its exit ramp and rest() deliberately
stops before them. Posing the title at t=358 walked every parent into its exit
and drove the disagreement from 10.92 to 61.74. So at poses leaves only.

Controls: 0 and 360 degrees byte-identical to the unrotated path, 90 degrees
swaps a 10x4 to 4x10, area conserved within 15 percent, centroid stays on the
pivot. 116 lib tests pass, main_menu unchanged at 9.26.

And the verification did not show what it was meant to, which is reported rather
than buried: scanning the pose time against the title capture gives 10.73 to
11.17 against a 10.92 baseline -- flat, no minimum, best 1.7 percent. The
whole-frame mean is dominated by the tone curve, and the renderer still does not
draw ptlogo1/ptlogo2 at all, which is a far larger spatial gap than two
translucent sweeps. So rotation is correct in isolation and no screen regressed,
but whether it closes the port s 1.81 percent is not established here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:59:26 +00:00
sylph-decoder
21a2c649e6 notes: build-reborn points at a source root that does not exist either
Found while checking what "Reborn" names. build-reborn line 15 is
SRC="${PROJECT_DIR:-/work}/Syplheed-Reborn" -- transposed letters -- and no such
directory exists; the workspace is at /work itself. It fails immediately with
cd: /work/Syplheed-Reborn: No such file or directory, so the documented way to
run the disc-gated tests is broken in this container.

Records the direct alternative, setting SYLPHEED_DISC by hand, which is what this
session has actually been doing.

This is the second wrapper here pointing at a source root that does not exist --
build-canary has the same defect and blocks the audio tap. Worth checking a
wrapper s SRC before trusting that a green or a failure came from your own code.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:47:35 +00:00
sylph-decoder
ce5505872b handoff: deliver the tone-versus-geometry split on the title
The rotation decision needs a size, not just a direction. A per-level LUT fitted
on a screen is the most general tone model possible, so whatever it cannot close
is by construction spatial. Self-fitted, it closes 70.3 percent on the main menu
-- the positive control, where the port measures 0.06 percent so geometry is
right -- and only 32.0 percent on the title. At most a third of the title s
disagreement is tone; at least two thirds is geometry.

Also warns the port off a global tone correction: the curve does not transfer.
Fitted on the title and applied to the menu it closes 29.7 percent; the other way
round it makes the title 24 percent worse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:45:30 +00:00
sylph-decoder
f2a74efe2d re: at least two thirds of the title s disagreement is geometry, not tone
Separates two confounded effects so the pending rotation decision has a number:
how much would drawing the rotation actually buy.

A per-level lookup table fitted on a screen is the most general tone model there
is -- every render level mapped to whatever capture level minimises the error,
no functional form assumed -- so whatever such a LUT cannot close is by
construction not a per-level effect. Fitting on the screen itself therefore gives
an upper bound on the tone share and a lower bound on the geometry share.

Positive control: on the main menu, where the port measures 0.06 percent of
pixels differing so geometry is essentially right, a self-fitted LUT closes
70.3 percent, from 9.26 to 2.75. The instrument can collapse a tone-dominated
residual.

Result: on the title the same self-fitted LUT closes only 32.0 percent, from
10.92 to 7.42. So at most a third of the title s disagreement is tone and at
least two thirds is spatial -- content in the wrong place, which is where the
rotation lives. The fitted LUT is generous to tone, so the geometry share is if
anything larger.

Also refutes the idea of a single transferable tone curve. Fitted on the title
and applied to the menu it closes 29.7 percent; fitted on the menu and applied to
the title it makes things 24 percent WORSE. A curve fitted on a dark flat screen
is unconstrained at the bright end -- the menu s populated range is levels 5 to
204 with few bright pixels -- and extrapolating it onto the title s planet and
wordmark actively harms. That extends the existing refutation of the single
exponent: even a full per-level LUT fails to transfer, so a consumer must not
carry a global tone correction.

Reach: two screens, one capture each, and the title pairing is the same screen
but not the same instant, so the ratio is what is claimed rather than the
absolute level. Our render draws the sweeps parent record only, so the geometry
share includes both the missing rotation and the missing leaf placement -- both
closed by the same decision.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:45:15 +00:00
sylph-decoder
1f9609c37f re: the keyframe block s +4 and +8 are angles used almost always as a 180 flip
Narrows a standing unexplained pair without claiming to decode it, and states
precisely why it cannot be closed in this container.

Census over every UI pak on the disc -- 2859 builds, 90347 keyframes, parents and
nested leaves. +4 has 12 distinct values and +8 has 11, against 157 for the
decoded rotation at +12. Per sprite-instance across 14241 of them, with +12 as a
control because it is known to hold a real angle: +4 takes more than two distinct
values on 7 instances, +8 on 99, and +12 on 396. So +4 is in practice a two-state
field whose state is 180 -- and for a screen-plane sprite a 180 degree rotation
about an in-plane axis is a mirror.

But they are not booleans. GP_TITLE entry 7 s ptlogo3a runs +4 = -72, -18, -4, -1
against +12 = -14, -4, -1, 0: the two decay to zero together with +4 roughly four
to five times +12 at each keyframe. That is a coupled two-axis settle and the
strongest support the disc offers for the three-axis reading. So the readings
reconcile -- the field is an angle whose overwhelmingly common use is the 180
degree special case.

The reach is the important half. All six non-zero +4/+8 keyframes in GP_TITLE are
in entry 7, the Japanese title, which has no oracle capture and which MISSION
scopes out as localisation beyond English. The five English screens that do have
captures carry +4 = +8 = 0 on every keyframe, so they never exercise the fields.
The paks that use them heavily, GP_READY_ROOM at 4686 and GP_DIALOG at 1058, are
also out of scope and GP_READY_ROOM is a recorded no-go. So this is untestable
against every oracle the project holds rather than merely unfinished.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:30:29 +00:00
sylph-decoder
258e1e63f7 method: an insensitive observable fails twice, and the second way sends you hunting
The port checked my pivot claim rather than taking it and found the nuance: the
sprite is odd-width, 399, so its true centre is 199.5 against a declared pivot of
200. Half a pixel, far inside the 0.70 and 0.48 px agreement, so it changes
nothing -- but "the pivot IS the centre" is the kind of sentence somebody leans on
for a sub-pixel claim later, so the page now says it is the centre rounded up.

And records the general form of the two bugs this exchange produced, which share
one cause. First, a leaf-composition rule was checked against alpha, which moves
about 0.3 levels per keyframe unit, so a one-keyframe association error barely
shifted it and the rule looked confirmed -- while the same span moved x by
1560 px. Second, fitting t from that same alpha manufactured an 11.5 px position
residual that did not exist and sent the consumer hunting a pivot rule to explain
it, because one byte of alpha quantisation is worth 1.5 to 1.9 keyframe units.

Solve on the fastest-moving field and check the slow one, never the reverse. The
second failure is the more expensive: failing to falsify leaves you falsely
reassured, but inventing a residual sends you looking for a mechanism.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:25:52 +00:00
sylph-decoder
f15c3f516d re: the 11.5 px residual was the alpha-only fit s resolution, and it closes
Left open earlier as do-not-fit. Closed by adding observables rather than tuning
a parameter.

The draw s vertex buffer carries positions and colours at the same instant, so
all four quantities must agree on one t. Solving independently: quad A x gives
357.88, quad B x 357.58, quad A alpha 355.75, quad B alpha 354.09. The alphas are
about 50x less precise per unit of time because alpha is a byte changing by only
0.27 to 0.33 levels per keyframe unit, so a single level of quantisation is worth
1.5 to 1.9 units, which at 4 px per unit is 6 to 8 px of sweep. The 11.5 px was
that.

At the position-derived t = 357.7 every observable lands: centres within 0.70 and
0.48 px, both alphas inside one level, and the parent alpha is 0 throughout. And
there is no pivot correction to find -- the leaf pivot is (200,90) against a
399x180 sprite, so the pivot is the sprite centre and rotation displaces it by
nothing.

The methodological point is the one this exchange started with, inverted. Earlier
a rule looked confirmed because it was checked against alpha, the insensitive
field. Here the same insensitivity manufactured an apparent 11.5 px error. The
insensitive quantity does not merely fail to falsify, it invents residuals. Solve
on the fastest-moving field and check the slow one, never the reverse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:23:28 +00:00
sylph-decoder
a1adb17d35 re: 125 percent is not the only odd scale, and ptlogo_eff2 is a pop not a steady state
Refutes a DECISIONS claim and decodes the element the port withheld on my say-so.

The claim that title_jp s ptlogo_eff2 at 125 percent is the single drawn element
in the whole export at a scale that is not a whole multiple of 100 percent rested
on a census of PARENTS only. Opening the 45 leaves as well finds thirteen
distinct non-whole-multiple scales -- 75, 96, 99, 101, 103, 112, 125, 150, 204x208,
210x220, 250, and the 75x100 / 96x100 / 99x100 pairs -- with 125 among the rarest
at two occurrences. ptlogo1 and ptlogo2 carry 101/103/112 on the ENGLISH title
too, so it is not a Japanese-build peculiarity. The claim s real content was "the
only one the port draws", which is about the export s element set rather than the
disc.

And ptlogo_eff2 is decoded. The 125 percent lasts 57 units, about 0.95 s -- a
scale-0 to 125 to scale-0 flash between t=50 and t=107, a transient rather than a
steady state, which is why it looked anomalous in a census of resting poses. The
leaf draws at 100 percent as two superimposed copies of the same sprite at alpha
160 and 80, each rotating a full 360 degrees over 960 units: a slow double-layered
spin, 16 s per revolution.

This is exactly the case the ptloop rule could not separate. There the parent had
expired so leaf-wins and parent-ignored were indistinguishable; here the parent
carries real geometry including a scale that reaches zero twice. If parent scale
gates the leaf the spin is a 0.95 s flash; if the leaf runs on its own timeline it
spins for 16 s. Nothing on the disc chooses between them, and title_jp has no
oracle capture, so it is undecodable in this container -- the port is right to
withhold it, and the Japanese-locale capture MISSION has parked would settle it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:16:20 +00:00
sylph-decoder
5da1a837fa re: the port s leaf x = -324 is the OLD keyframe association, not a geometry gap
They implemented the leaf rule and reported the leaf top-left at x about -324 at
t=355, off-screen left, against 781 here, and asked how a rotated 600-percent
quad s declared pos relates to its drawn centre. It is not a geometry question.

Their stated pairing is t=150 at x=-639, t=540 at x=-39. On the disc the poses
-639 / -39 / 1521 carry times 0 / 150 / 540. Their pairing gives each pose the
NEXT pose s time -- exactly the association ui-keyframe-record-layout.md refuted
and HANDOFF carries a red banner about. Feeding their pairing into the same
interpolation reproduces -324 to the digit.

With the corrected association t=355 gives top-left 781 and centre 980.5 for the
399-wide sprite, against 992.0 measured off the capture.

So the leaf path still carries the pre-fix association although the top-level
parser was corrected: a leaf is parse_build on a sub-slice, so anything reading
leaves through a separate path can still be shifted.

And the reason it looked confirmed is worth keeping: alpha at t=355 sits inside a
long segment where a one-keyframe shift barely moves it, while x sweeps 1560 px
over the same span. The rule matched on the insensitive quantity and was wrong on
the sensitive one -- check a new interpretation against the fastest-moving field,
not the one that happens to agree.

The residual 11.5 px between 980.5 and 992.0 is left open rather than fitted; a
rotation about a declared pivot rather than the centre would displace by roughly
that much and nothing here measures it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:11:10 +00:00
sylph-decoder
14a7897c8f handoff: deliver the leaf-versus-parent alpha rule
The port asked for the composition rule and declined to guess it, which was the
right call. Delivered on the page they read: draw the leaf on its own timeline,
do not multiply the parent s alpha in, with the refutation stated -- multiplying
predicts zero at the observed time and the sweeps would be invisible.

Keeps the two limits that matter to a consumer. It is not a universal precedence
rule: here the parent is a container with no sprite, while for a button the leaf
duplicates the parent and the parent wins, so the discriminator is which record
carries the geometry. And because every observation has parent alpha zero, leaf
wins is not separated from parent ignored because it draws nothing.

Also flags their title_jp ptlogo_eff2 lead as untested by me, with the reason it
is worth checking: if its two-element leaf carries the geometry the same way, the
125 percent scale may be the parent s.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:03:38 +00:00
sylph-decoder
2f1c561d76 re: a nested .rat leaf animates on its own timeline; parent alpha does not multiply
Answers the port s question, which they refused to guess at: they emit both a
parent record and its nested leaf, each with an alpha ramp over a different
span, and would not draw the leaf without the composition rule.

The per-draw capture records vertex colours, and on the title s ptloop draw they
are C3FFFFFF and B6FFFFFF -- alpha 195 and 182, not 255 -- so the composed alpha
is observable.

Fitting ONLY the two alphas against the two leaf ramps gives one consistent time,
t = 355, where leaf A is 194.8 against an observed 195 and leaf B is 182.2
against 182. The parent has expired there: it returns to 0 at t=250 and a group
holds at its last keyframe. So leaf times parent over 255 predicts zero for both
quads and the sweeps would be invisible. They are drawn.

The position check was predicted rather than fitted: nothing about x entered the
fit, and the same t=355 places the quad centres at 981 and 478 against 992.0 and
467.2 measured off the capture -- within about 11 px on 400-px quads travelling
1560 and 1950 px. Four quantities from two differently-shaped ramps agree on one
time.

The rule: a leaf carrying geometry animates on its own timeline and the parent s
alpha does not gate it. For these records the parent is a container with no
sprite.

Reach stated: one draw, one capture, one element pair, and specifically the case
where the parent carries no geometry. The opposite case is already recorded --
for a button a base record s leaf duplicates the parent and the parent wins -- so
the discriminator is which record carries the geometry, not a fixed precedence.
And because every observation here has parent alpha 0, "the leaf wins" is not
separated from "the parent is ignored because it draws nothing"; a capture during
t=100 to 238 would separate them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 18:03:19 +00:00
sylph-decoder
5a4428ec67 handoff: the port s title residual is the rotated ptloop quads, not a blend mode
The port asked whether a blend field exists and whether _eff layers draw
additively, naming it as their largest remaining oracle gap. Both answers are no
and the cause is already decoded.

Additive blending is refuted specifically: T8aD +0x04 bit 0x02 as an additive
selector was tested and every measure worsens against the capture. The export
carries no blend field because none has been found -- the per-draw capture
records primitive type, index count, shader hashes, texture bindings and vertex
attribute 0, but no RB_BLENDCONTROL, and reading real blend state needs a Canary
change that is blocked here.

One of their three eliminations is overturned. They ruled out the ptloop sweeps
as 399x180 at (441,270) with keyframes holding position constant -- that is the
unscaled, unrotated geometry. Measured off a GPU draw capture, the live title
submits two rotated quads: ptloop01 at 400x1076 rotated +30.26 degrees centred
(992,359), and ptloop02 at 400x1444 rotated -45.28 degrees centred (467,360),
the scales being 600 and 800 percent. Two quads at x about 467 and 992, leaning
opposite ways, is exactly their signature of darker centre-left and brighter
right nearly cancelling. Our own renderer shows the same residual from the same
cause, tiles running -38.6 then +33.8 across the band, so it is a shared decode
gap rather than a defect in their compositor.

The rotation itself is decoded: keyframe block +12, degrees, clockwise-positive,
confirmed against a framebuffer capture. So their biggest oracle gap and the
rotation question they raised for the human are the same item.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:56:16 +00:00
sylph-decoder
3bd1a61ea9 re: S00A is unreachable here -- the new-game path crashes on a cache it cannot build
Drive 4 worked. With focus detected and the detector validated live against a
known transition (NEW GAME, down, LOAD GAME -- CONTROL PASSED), the drive
navigated and pressed through, and every step confirms against a committed
capture: main menu +0.999, newgame-difficulty +0.999, newgame-selectdata-crash
+0.997. Then the guest throws, PC 0x82307128 times 349, and no S00A voice stream
ever decodes.

It is on the new-game path rather than the boot: the log order is ADV attract,
then BGM_103 menu music, then the throw. So it is not the ~100 s boot throw that
title-crash-stl-tree.md documents.

That page attributes the throw to an incomplete on-disc cache and Q4 s note cites
it for this crash. The attribution survives, but not through the container the
page names. aab216c3 is complete here at 7 files. The line immediately before the
exception resolves \1b556564\9\00c8dcd, and 1b556564 holds exactly one file plus
a stray 1b556564900c8dcd.tmp -- precisely the page s run C, partially rebuilt,
which throws. So the new-game path builds a different cache container from the
title path and that one is incomplete.

The page s remedy does not transfer. It restores a previously complete cache, and
no complete 1b556564 has ever existed here: the game crashes while building it,
leaving the .tmp, so the cache cannot complete and re-running does not escape it.
Its own run B shows a fully cold cache throws as well, so deleting does not help.

Consequence recorded: the centre-channel voice result stays resting on ADV alone,
because the corroborating asset is behind a crash that is outside menu-port scope.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:52:36 +00:00
sylph-decoder
c5fe6a460c re: initial focus is TUTORIAL x3 / NEW GAME x3, and never anything else
Two more data points for the Q5 instability, from today s drives. A run that
pressed A with no d-pad movement ended in a tutorial mission, correlating +0.960
with the committed capture, so that boot opened on TUTORIAL. A later boot read
NEW GAME from a focus detector on the first menu frame.

Six boots on the same harness now: TUTORIAL three times, NEW GAME three times,
and no other item ever observed. The distribution is not uniform over the five
buttons -- only these two occur -- which is a real constraint on whatever selects
initial focus and something an explanation will have to account for.

Also records in METHOD a bug that cost a seven-minute driven boot: a value was
clamped for readability BEFORE the comparison that used it. A focus detector
printed a degenerate margin, so it was capped at 999; the cap ran before the
vote-sorting step, two different votes compared equal, the stable sort kept the
wrong one, and a correct NEW GAME became an out-of-range index and a refusal. The
measurement was right throughout -- a cosmetic fix changed a decision. Clamp at
the point of display, never upstream of a comparison.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:42:03 +00:00
sylph-decoder
8b4dcccb67 handoff: BGM_103 as the menu music now has a runtime leg
The port asked for this to have its own line rather than sitting inside a drive
report, and they are right -- it is a third independent confirmation of a claim
that the port authors from.

The claim rested on GamePart_Title s sub_821C5580 playing cue 1103 (static code)
and on the bank s two declared wave sizes matching what an XMA probe saw (disc
census). On a driven boot, BGM_103 s two waves were handed to the XMA decoder at
the moment the main menu appeared -- observed being decoded on arrival at the
screen, rather than inferred from a table or matched by size afterwards.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:33:29 +00:00
sylph-decoder
b7930e6616 re: the S00A drive failed -- initial menu focus was TUTORIAL, not NEW GAME
Reported as a route finding rather than retried silently, because the cause is a
defect in shared harness tooling that will bite the next drive.

Drive 1 sat 396 s reporting other with two spurious menu hits while the guest was
healthy and decoding audio throughout. screen_id.py thresholds on green and only
returns title once the PRESS A plate has faded in, so it cannot see the
plate-less build-4 title this corpus documents. It also calls difficulty-screen a
menu. Both reproduce on committed frames, and newgame_path.sh, nav_probe.sh and
boot_menu.sh all gate on it.

Drive 2, with a classifier controlled 6/6, reached title_plate at t=398 s and
drove on -- into a TUTORIAL MISSION. The screen 60 s after the last A correlates
+0.960 with the committed tutorial-mission-reached-then-crash.png, and no S00A
voice stream ever decoded. newgame_path.sh s header assumes NEW GAME is the first
item so no d-pad movement is needed; that contradicts this corpus s own Q5
result, where four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME.

Incidental corroboration: BGM_103 s two waves decoded on reaching the menu, an
independent runtime confirmation of the menu-music claim that HANDOFF rests on
static code and a disc census.

What is needed is a focus DETECTOR, and wrap-around means counting presses cannot
substitute -- up from the first item goes to the last. I do not have one: a
per-row brightness statistic failed its control, picking NEW GAME on the capture
whose filename says OPTIONS.

Also records a refutation attempt on the port s focus identification that FAILED.
Differencing the two captures and binning by row appeared to show NEW GAME and
EXTRAS changing, contradicting them. That was my error -- I placed row bands as
rest_y plus or minus 24, treating the resting position as a band centre. The
offset-independent check settles it: the changed bands are 254.9 design-y apart
against a button pitch of 80, so the two focused buttons are 3 apart and not 4 --
NEW GAME to OPTIONS. Their identification stands.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:27:22 +00:00
sylph-decoder
2a7ac9f859 re: the tone curve s single exponent is refuted above render 40
Raised by the port and independently reproduced here before being adopted, since
adopting their claims unchecked has misfired twice this session.

Binning matched pixels by render level rather than fitting a scalar, the implied
exponent falls monotonically and crosses 1.0:

  render          16     23     31     39     47     64
  port  (all)   1.26   1.18   1.10   1.03   0.93   0.85
  mine  (flat)  1.303  1.347  1.128  0.912  0.935  1.003

Below the crossing the capture is darker than the render, which is what the page
measured; above it the capture is brighter. A single exponent cannot express a
curve that crosses unity, so the model is valid only in the darks -- which is
exactly the reach the page already stated. The reach line was not a hedge, it was
the finding.

Where the two disagree is recorded and not resolved: the crossing is about 44 by
their binning and 35 to 40 by mine, and the darks read 1.18-1.26 theirs,
1.30-1.35 mine, 1.49 for the page s original patch fit. Three estimators on three
populations, all agreeing on direction and on gamma above 1 in the darks.

A confound in my own reproduction is stated rather than left implicit: whole-image
correlation is only 0.594 because the committed capture and the default render
differ in focus state, which the port measured as 74.1 percent of differing
pixels. My bins include that mismatch, so they are not a clean second opinion.
And a 1280x720 render against a 1279x675 capture needs a resample, which is why
the fit is restricted to flat-neighbourhood pixels.

METHOD gains the general form: a stated reach is a boundary rather than a hedge,
and the fix was printing the curve instead of a scalar, because a scalar hides
its own domain.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:20:41 +00:00
sylph-decoder
fbe4ba5526 method: screen_id.py cannot see a plate-less title, and calls DIFFICULTY a menu
Both reproduce on committed reference frames, so this is a defect in a shared
harness tool rather than a one-run anomaly:

  live-title-build4-no-plate.png -> other   (should be title)
  live-title-press-a.png         -> title
  difficulty-screen.png          -> menu    (is not the main menu)

It thresholds on green -- 0.0009 with the PRESS A plate against 0.0002 without --
so it only recognises a title once the plate has faded in. This corpus s own
finding is that the boot title shows build 4 FIRST, plate-less, for about 2.25 s,
which means any harness waiting for `title` from it can sit through a visible
title and report nothing. That is what happened on an S00A drive here: 396 s of
`other` with two spurious `menu` hits, on a run whose audio proved the guest was
healthy throughout. newgame_path.sh, nav_probe.sh and boot_menu.sh all gate on
it.

The zncc-against-committed-frames classifier used for the settle-time screen log
has neither defect, controlling 6/6 with both movie frames and difficulty-screen
as negatives -- but only at a 0.85 threshold. At 0.60 it also called
difficulty-screen a menu at 0.632, so the threshold is doing real work and has to
be controlled rather than chosen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:14:03 +00:00
sylph-decoder
a13dd42c2d re: stripping additive padding is exact -- controlled, and only one side needs it
The page recorded the substituted-versus-additive distinction as unverified, with
the port controlling it. It passes.

A real music and SFX bed of 137.37 s, itself carrying 454 genuine zero runs --
which is what makes it an honest control -- had 1149 holes inserted at 8.37
gaps/s to +9.9 percent length, matching the measured ALSA profile, then stripped:

  original vs itself (ceiling)   r 1.000  lag 0.0 s  margin +0.141
  padded vs original             r 0.436  lag -12.2  margin +0.006
  stripped vs original           r 1.000  lag  0.0   margin +0.142

Two things beyond the yes. It runs the inference forwards: padding at this
profile puts correlation squarely in the known-absent regime on a file whose
contents are controlled, so the earlier captures were unusable for the reason
claimed rather than for some other one -- until now that was reasoning backwards
from a failure to a cause. And only one side needs stripping, since the stripped
capture matches the UNSTRIPPED source at the ceiling, so a capture needs no
preprocessing before being handed over and there is no shared step to get out of
sync on.

The danger is recorded as the part to repeat: stripping removes genuine silence
too and cannot tell the two apart, so it is exact on additive ALSA padding and
vandalism on a PulseAudio monitor capture where the silence replaced real audio.
Running it on the wrong artefact would look like it worked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:05:37 +00:00
sylph-decoder
9e66d6a82c handoff: deliver the centre-channel result and the S00A capture that is not taken
Records the port s measurement on the page they read, because it closes the last
open question and my own pages carried the hypothesis it settles. Keeps all
three limits as they stated them, including that streams 2 and 3 are
indistinguishable to the instrument so no selection rule is vindicated, and that
the one-of-three-streams warning stands with its character changed rather than
its colour.

Also names the capture that would strengthen it most and says plainly that I have
not taken it: S00A rather than a longer ADV, why it is structurally different,
and what it costs -- a driven rendered run, so no --gpu=null and the additive
padding comes with it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:01:44 +00:00
sylph-decoder
5fb64f3d31 re: the voice dialogue is in the CENTRE channel -- measured, not inferred
The 5.1 reading of a voice cue s three concurrent streams was recorded here as a
hypothesis with counter-evidence attached. It is now answered, by the port
fitting the disc s decoded streams against a clean capture of the game s own
6-channel output, with the instrument controlled first (known-present margin
+0.248, known-absent +0.005).

Speech-band margins put streams 2 and 3 at +0.305 and +0.307 on FC, r = 0.989,
above the known-present control, while stream 1 sits in the noise on every
channel. The low band mirrors it exactly: the movie bed at 0.76 to 0.84 on the
four corners against 0.32 on FC. Dialogue in the centre, bed in the corners.

The hypothesis was right for a reason the file could never have supplied.
ChannelMask reads 0x0002 on all three streams, so the header is not merely
unhelpful, it is actively misleading -- refusing to call it 5.1 from the header
was correct, and the oracle answered what the header could not.

Three limits recorded as the measurer stated them: streams 2 and 3 are
indistinguishable to this instrument, so no rule for choosing between them is
vindicated; the one-of-three-streams warning stands, since nothing says what
streams 1 and 3 contribute; and the reach is 59.7 s of a 137 s movie, one run,
one asset.

Also records the capture that would strengthen it most and why it is not taken:
S00A rather than a longer ADV, because its second full-length stream is digital
silence where ADV s is a 0.60x copy, so a structurally different movie would
agree. Reaching it needs a driven rendered run -- S00A starts about 4.5 s after A
on the save slot -- so it cannot use --gpu=null and will carry the additive
padding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 17:01:26 +00:00
sylph-decoder
6f25a6a0d0 re: substituted silence destroys information, additive padding does not
The distinction is the port s and it is sharper than the framing this page had.

PulseAudio s monitor SUBSTITUTES: audio that existed is replaced by silence to
keep the wall clock, so information is destroyed and deleting the holes only
compresses time unevenly. Xenia s padding is ADDITIVE: the silence is inserted
between samples the guest emitted, so nothing is lost and every real sample is
present and in order.

So stripping all-channel-zero runs from an ALSA-tee capture is exact rather than
a repair, which means even the 0.70x rendered capture at 9.98 percent padding is
usable for correlation, where none of the PulseAudio-monitor captures ever were
however they were tuned. Recorded as unverified: the port is controlling it by
padding a known source to match and checking the stripped result correlates back.

Consequence for check-capture recorded too: its silence and gap-rate rule was
built when only damage existed and cannot distinguish genuine emulator padding
from capture damage, so a FAIL on an ALSA-tee capture is a statement about the
recording path rather than the file s usability.

Also promotes the runaway guard to a first-class CONTAINER-NOTES entry at the
port s request -- 7.34 GB in 50 seconds at about 250x real time is not a
footnote -- and adds --gpu=null there, which is what takes the guest from 0.70x
to 0.96x and stops the padding, with its two caveats: no video for provenance,
and runs die at about 70 s with PM4_DRAW_INDX failures.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:56:32 +00:00
sylph-decoder
4f77ab26d7 re: --gpu=null gives a clean audio capture -- 0.31 percent silence, 0.01 gaps/s
The residual padding in the ALSA tee was the guest running at 0.70x real time,
and the dominant load is llvmpipe software rendering -- which an audio capture
does not need at all.

  PulseAudio monitor, xenia default             39.3 percent silence  30.5 gaps/s
  ALSA tee to paced slave, rendered              9.98 percent silence  8.37 gaps/s
  ALSA tee to paced slave, --gpu=null            0.31 percent silence  0.01 gaps/s

One gap in 67.7 s. Six distinct channels, no duplicates, sensible peaks. For
scale the port s genuine music bed control measures 1.1 percent silence at 3.3
gaps/s, so this capture is cleaner than their known-good reference.

Control that the run is still comparable: ADV s three XMA contexts appear in the
--gpu=null log, so the movie s voice is decoding exactly as in a rendered boot.
That is also better provenance for an audio question than screenshots were, since
it evidences the thing being recorded rather than what was on screen.

Records the full working recipe. Caveat: --gpu=null means no video, so
screen-based provenance is unavailable and it is only appropriate when the
question is about audio.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:52:51 +00:00
sylph-decoder
eaa578421f notes: point the container page at the working audio-capture route
The entry already warned that run-canary is silent twice over, but stopped
there -- and fixing only the mutes still yields an unfaithful capture, because a
PulseAudio null sink s monitor is wall-clocked and invents silence when the
client is late. Adds the pointer to the ALSA file-tee page, with the two things
a reader needs before starting: the slave must pace or the tee free-runs at about
250x real time, and a size guard is not optional.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:51:14 +00:00
sylph-decoder
371cd0d610 re: the ALSA tee measured on Canary -- faithful now, but the guest still pads
150 s boot with --apu=alsa --mute=false, tee in front of the paced pulse slave.

  PulseAudio monitor, default 5.3 ms   39.3 percent silence   30.5 gaps/s
  PulseAudio monitor, 200 ms           15.6 percent silence    3.5 gaps/s
  PulseAudio monitor, 500 ms           50.1 percent silence    1.3 gaps/s
  ALSA tee to paced pulse slave         9.98 percent silence   8.37 gaps/s

106.2 s captured over about 151 s of wall clock, i.e. 0.70x real time: the file
is SHORT rather than gap-riddled, which is the intended trade. Six distinct
channels, no duplicates, sensible peaks.

A format trap worth recording: xenia s ALSA driver is SND_PCM_FORMAT_FLOAT_LE and
its log confirms 6 channels, so the raw tee is float32 and not s16. Reading it as
s16 yields a plausible-looking file whose giveaway is peaks alternating exactly
-0.00 / -4.82 across channels -- the two halves of each float landing in
alternate channels. I measured it wrongly that way first.

The residual 10 percent silence is not removed, but its meaning has changed. It
is no longer invented by PulseAudio s monitor; the tee records exactly what Xenia
wrote, and Xenia wrote silence, because its writer thread pads whenever the guest
has not filled the ring. So the capture is faithful -- every sample in it is a
sample the emulator emitted -- while the emulator is still padding, because the
guest runs at about 0.7x real time here. No capture method can remove that.

So this is a 3.9x improvement in silence and a change of attribution, not a clean
capture. At 9.98 percent and 8.37 gaps/s it sits right on the port s fail bar,
and should not be treated as an oracle without saying which side of the line it
fell on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:49:17 +00:00
sylph-decoder
3d5b5bae13 re: capture audio through an ALSA file tee, not a PulseAudio monitor
The human identified that both agents were fighting the wrong subsystem, and
testing it here confirms the diagnosis and finds the limit.

A PulseAudio null sink s MONITOR is sampled on a wall clock: when the client is
late PulseAudio does not wait, it emits silence to keep its own timeline. So the
39.3 percent silence in the take-2 capture was never audio that went missing, it
was silence PulseAudio invented -- which is why PULSE_LATENCY_MSEC gave a
non-monotonic curve and never won. The instrument was wrong, not mistuned.

ALSA s file plugin has no clock; it tees exactly what the client writes, so a
slow producer yields a shorter file rather than a gap-riddled one. Control with
six distinct tones: 12.000 s against a 12.000 s source, 0.00 percent silence,
zero gaps, no duplicate channels. Channel order comes out as ALSA s
FL FR BL BR FC LFE rather than WAV s FL FR FC LFE BL BR -- deterministic and
invertible, not data loss.

Three configuration traps recorded in the order they bite: ALSA_CONFIG_PATH
replaces the whole config so the stock one must be included; but WITH that
include a pcm.!default override silently does not take, in either the inline or
the alias form, so the slave must be declared with an inline plugin type and no
include; and a pipe to head SIGPIPEs the producer before it writes, which looks
exactly like a broken config.

And the limit the proposer honestly flagged, now measured: a bare file tee is not
enough for Xenia, because its ALSA writer thread pads silence whenever the ring
buffer is empty (alsa_audio_driver.cc:359). Against a device that never blocks it
free-ran at about 250x real time -- 7.34 GB, 12746 s of nominal audio, in 50 s of
wall clock, nearly all driver-generated silence. Killed and deleted; it would
have filled the disk.

The configuration that satisfies both constraints is a tee in FRONT of a paced
slave: type file with slave.pcm { type pulse }. The file plugin captures what the
client writes and the slave supplies the clock, so the wall-clock silence
insertion happens downstream of the capture point. Control through that exact
config: 12.000 s, 0.00 percent silence, zero gaps.

Consequences for verification: short file becomes the failure mode, so a capture
check needs an expected-duration test alongside silence and gap rate, and a
runaway guard is not optional.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:47:31 +00:00
sylph-decoder
e8afbc8632 re: the buffer/dropout relationship is not monotonic, and a gap-rate bar misses it
Extends the latency finding with a third point, and it changes the advice.

  xenia default (~5.3 ms)   347.5 s   39.3 percent silence   30.5 gaps/s   3.94 ms median
  PULSE_LATENCY_MSEC=200     88.0 s   15.6 percent silence    3.5 gaps/s  37.33 ms median
  PULSE_LATENCY_MSEC=500     87.9 s   50.1 percent silence    1.3 gaps/s 346.67 ms median

200 ms is 2.5x better than the default; 500 ms is worse than either. Raising the
buffer keeps cutting the gap RATE while total silence bottoms out at 200 ms and
then doubles, because an over-large buffer starves in a few enormous holes rather
than many small ones.

That is also a warning about the metric. The port s check-capture bar is 20
gaps/s, derived from sound controls -- starved 32.9, genuine music bed 3.3, voice
track 0.03. The 500 ms file scores 1.3 gaps/s, better than a real music bed,
while being 50 percent silence: a gap-rate test alone would pass the worst
capture of the three. It needs a total-silence companion. Same shape as the
defect that made a per-channel level table useless -- one number that cannot see
the failure mode next door.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:35:46 +00:00
sylph-decoder
b56d0e1fb6 re: the capture dropouts are largely a client-buffer size, not the guest running slow
Withdraws my conclusion that the monitor-sink capture route cannot be fixed by
configuration, and with it the claim that only an in-emulator tap would work.

The container has no audio hardware -- no /proc/asound/cards, no /dev/snd, no
asound.conf -- so PulseAudio s stock default.pa module-always-sink supplies a
null sink, whose whole purpose is to exist when there is no device. A null sink
has no hardware clock: it is timer-driven, and anything the client fails to write
in time becomes silence in the monitor. That much was right.

What was wrong was inferring from it that the holes mean the guest runs below
real time. The alternative was never tested: xenia asks SDL for channel_samples_
= 256, which is 5.33 ms at 6 channels, and daemon.conf here is stock with no
fragment tuning. PULSE_LATENCY_MSEC overrides what SDL s PulseAudio backend
requests.

Measured, same title and sink and parec invocation:

  xenia default (~5.3 ms)   347.5 s   39.3 percent silence   30.5 gaps/s
  PULSE_LATENCY_MSEC=200     88.0 s   15.6 percent silence    3.5 gaps/s

An 8.7x reduction from one environment variable. Against the port s controls --
starved 32.9 gaps/s, genuine music bed 3.3, voice track 0.03, bar at 20 -- the
default is squarely starved and 200 ms lands at the level of real content.

Not yet a clean bill of health: the runs are not like-for-like at 88 s against
347 s, and the short one covers the splash logos where silence is real. What is
established is direction and scale. The consequence that matters is that the
capture route should be retried at raised latency before anyone spends a session
on a Canary rebuild.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:34:34 +00:00
sylph-decoder
55cdcac61b handoff: tell the port the settle-time numbers carry an unmeasured real-time factor
The pulse-period argument for trusting the settle-time run is withdrawn, and the
port authors from those numbers so it belongs on the page they read. The plate
delay survives because it agrees with three independent prior readings; the menu
build-in and B-to-title are anchored by nothing, so a few per cent of emulator
slowdown sits inside them undetected. That is a second, independent reason to
treat those two as provisional beyond their being one-run figures.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:28:23 +00:00
sylph-decoder
02a99bc3e9 re: withdraw the pulse-period argument, and the shared WAV declares itself empty
Two corrections to my own recent work, both prompted by the port checking it.

First, the settle-time page argued the plate delay discrepancy was an instrument
artefact on two legs, and one of them is withdrawn. It said the plate pulse
period acts as an internal clock for presentation rate and measured 2.369 s
against the corpus s 2.3. That estimate rests on ONE interval between two
distinct troughs at a 125 ms sample interval -- uncertainty 0.177 s or 6.7
percent -- and trough-picking on a noisy plateau is fragile enough that
re-running it gives 2.628 s, because an adjacent local minimum had been counted
as a separate trough. Against the corpus s 2.24 that is +17.3 percent, about two
sigma. So the pulse period does not show the run at normal speed; it is too weak
to show anything, and cannot resolve a real-time factor below about 7 percent.

The conclusion survives on the other leg, which is the sound one: the
content-measured 2.247 s agrees with three independent prior readings
(2.13 / 2.132 / 2.138), and both its landmarks are sharp content transitions
rather than a trough on a plateau. A 17 percent slowdown would have put it at
2.49 s.

What that leaves open matters because the port authors from these numbers: the
run carries an unmeasured real-time factor under about 7 percent. The plate delay
is anchored by agreement with prior runs; the menu build-in and B-to-title are
anchored by nothing, so that is a second reason to treat them as provisional.

Second, the shared capture is worse than truncated: parec writes the WAV header
with zero sizes and patches them on clean exit, so the mid-write copy has RIFF
size 8 and data size 0 against 183 MB of actual bytes. Python s wave module
refuses to open it; ffmpeg and ffprobe recover by scanning and report a plausible
duration, which is exactly why it went unnoticed -- the lenient reader hid it.

Also corrects the attribution of the starvation numbers: 39.3 percent and
16680453 frames were measured on the finished local recording, not on the shared
artefact. The port measured the shared copy and got 35.6 percent and 15289876
frames, with burst and gap medians agreeing to 0.1 ms. The diagnosis is
unaffected but a number must say which artefact it came from.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:28:09 +00:00
sylph-decoder
5938d3b1fc notes: build-canary points at a source root that does not exist here
Recorded as a blocker rather than worked around, because it changes what the
next session can plan.

The faithful-capture route is an internal tap at SDLAudioDriver::SubmitFrame,
which receives exactly frame_size_ bytes of the guest s own frame in guest order
with no wall clock in the loop. A cvar-gated WAV writer there would record what
the guest PRODUCED rather than what a device CONSUMED, so it would be gap-free
however slowly the emulator runs -- which is precisely the defect that made both
ADV captures unusable.

The change is small. The build is not. build-canary builds
${PROJECT_DIR:-/work}/xenia-canary, which does not exist in this container; the
source is at /canary. The warm 235 MB tree at /sylph-home/re/canary-build is
configured with CMAKE_HOME_DIRECTORY=/work/xenia-canary, also missing, and its
build-Release.ninja carries no per-file rules -- it re-runs CMake first, and that
reconfigure fails on the absent root. So any Canary change is a full reconfigure
against /canary plus a full compile, at SYLPH_JOBS=4 on a box sitting at about
700 MB free with a documented history of full-parallel builds OOM-killing the
host.

Not attempted: that is a whole session s risk for one probe, and the next session
should decide with the cost in front of it rather than discover it halfway
through.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:22:13 +00:00
sylph-decoder
3a5f215179 re: withdraw a wrong explanation of the BGM_001 duration gap
I wrote that BGM_001 s declared 173.821 s disagreed with a decoded 167.663 s,
and explained the gap as declared covering the encoded stream including trailing
silence while decoded is where the audio stops. The port decoded it fully: the
bank yields 173.809 s of PCM. There is no disagreement -- 167.663 s is where the
music fades out, measured from the audio, and the stream continues silent to its
declared end inside that same decode.

So the declared-rate method is better than this page claimed, and is now
cross-checked on three banks against independent decodes: BGM_103 87.750 vs
87.744, BGM_102 37.487 vs 37.482, BGM_001 173.821 vs 173.809 -- agreement 5 to
12 ms.

The conclusion survives unchanged and is the useful half: trust it for lengths,
not for musical boundaries. A declared length includes whatever silence the
encode carries, so it is not a loop point.

Also records in METHOD a defect shape the port hit three times in one pipeline,
each invisible to every check except a level: normalising by how many inputs
there are rather than how many carry signal. A silent chunk in a voice sum, a
silent channel in a mono fold, and a silent sub-wave -- the 10240-byte bank
header wrapped to 10300 B -- counted as a third stem in a music sum, which put
every real stem at 1/3 instead of 1/2 and cost 3.52 dB on all menu music for two
iterations. This corpus s census said two waves and the exporter s divisor said
three; the count that disagrees with a census is the one that is wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:20:49 +00:00
sylph-decoder
c05c8e1719 re: take 2 is also unusable -- the sink is starved, 39.3 percent digital silence
The port could not find the movie bed or the cutscene voice in take 2 either,
this time with a correlator they had rebuilt and calibrated in both directions
after retracting the first one. Their negative stands. They named two readings:
the capture path is still losing the guest s mix, or the guest is not emitting
these sources -- and flagged the second as landing on them hard, because if the
game never plays the .wmv s WMA track the port s intro audio has been wrong
since P4.

It is the first, and take 2 says so on its face:

  digital silence on all six channels   6557892 / 16680453 = 39.3 percent
  non-silent runs   10595, median 13.60 ms, longest 1.19 s
  silent runs       10596, median 3.94 ms
  burst+gap period  about 17.5 ms, 57 Hz, duty cycle 60.7 percent

The recording is chopped into 13 ms fragments separated by 4 ms holes, ten
thousand times over -- a starved sink, PulseAudio filling underruns with silence.
That destroys envelope correlation by construction, since the envelope is
dominated by a 57 Hz chop unrelated to the content. The file s strongest
periodicity is 5.2 s rather than BGM_102 s 37.487 s loop; the estimator was
controlled first, recovering a synthetic 37.487 s loop as 37.480 and scoring
non-repeating noise at 0.019.

So the port s alarming hypothesis is NOT supported. Nothing here says the game
fails to play the movie s audio; it says this capture cannot answer either way.

A monitor sink cannot fix it: parec reads a monitor that advances at wall clock
and substitutes silence, so every moment the emulator runs below real time is a
hole and the timebase is warped non-uniformly. The route that would work is an
internal tap at SDLAudioDriver::SubmitFrame, which sees every frame the guest
produces in guest order with no wall clock -- same shape as xma_param_probe,
additive and default-off. Not attempted this iteration.

Also corrects a provenance number I got wrong: I told the port take 2 was 253.3 s
when the shared file is 318.5 and the full recording 349. I read ffprobe while
the recorder was still writing and copied the file before it finished, so the
shared artefact is itself a truncation. Corrected provenance: movie 10-251, title
262-318, back to movie at 329 -- meaning the file includes the title screen,
contrary to what I told them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:19:46 +00:00
sylph-decoder
b07f8984e3 handoff: deliver the BGM_102 identification and the header-derived durations
States the identification, the caution that it does NOT establish which screen
BGM_102 belongs to, and the one thing the port can use today: BGM durations from
the corrected XMA1 PsuedoBytesPerSec with no decoder. Flags that those durations
include trailing silence -- BGM_001 reads 173.821 declared against 167.663
decoded, a gap matching the 6.15 s of silence this page already records -- so a
menu loop point must use the decoded figure.

Also records that a refutation attempt on this page s own BGM_103 wave sizes
failed: both match the disc exactly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:16:34 +00:00
sylph-decoder
05d278173d re: the two unexplained XMA streams are BGM_102, and BGM_103 s sizes survive
Closes the open question left by the take-2 audio capture, where the probe
logged five streams on one boot when only ADV s three were accounted for.

Both unexplained sizes are whole packet counts, 562 and 620. Searching every
inter-descriptor span of the voice stream and every sound.pak entry large enough
finds zero hits in the voice stream and ONE entry carrying both -- hash
9799c546, which candidate enumeration recovers as BGM_102.slb, two streams of
1150976 and 1269760 B. One entry holding both sizes is the two-stem shape rather
than two coincidental matches. So the boot s five streams were ADV s three voice
streams plus one music bank s two stems, and nothing is unaccounted for.

What it does not establish is which screen it belongs to. The window ran from
launch to t=253 s with the title arriving at 262, so BGM_102 was decoded
somewhere inside a launch-to-just-before-title window -- but the probe fires on
first decode and its lines carry a thread id rather than a timestamp, so a title
BGM decoded moments before the title appears is equally consistent with the
evidence. Cue 1103 is already the main menu, which makes 1102 as the title at
least suggestive. The settling experiment is written down and not done.

Refutation attempt on HANDOFF s BGM_103 wave sizes: exact match on both
(3876864 / 3930112). The claim survives unchanged.

Also a third route to two-stems-of-identical-duration, from the XMA1 header
alone now that PsuedoBytesPerSec is read correctly: BGM_102 37.487/37.487,
BGM_103 87.750/87.749, BGM_001 173.821/173.821. The one apparent disagreement
resolves in the corpus s favour -- BGM_001 reads 173.821 here against the port s
decoded 167.663, a gap of 6.158 s, and HANDOFF already records 6.15 s of trailing
silence after its fade-out. Declared duration covers the encoded stream including
that silence.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:16:13 +00:00
sylph-decoder
b047788d37 re: the capture recipe that passes, and a five-stream observation it turned up
Take 2 of the ADV audio capture verified with the port s independent
tools/port/check-capture -- six distinct channel MD5s, PASS -- run before
sharing and deliberately using their tool rather than the hand that made the
file.

Records the recipe: sink channel_map set equal to Canary s own stream map and
the same map passed to parec, so PulseAudio does no remapping; both of
run-canary s mutes off; recorder started before the emulator so WAV t=0 precedes
process launch; and a screenshot every ~11 s keyed to the recording s own clock.

That last pair is what makes it self-checking, and both were the port s asks.
Classified against the committed references, this run reads movie/other for
t=10..251 and then title_noplate at t=262 (r=+0.998) and title_plate at 277/289
-- so the 253 s of audio sits wholly inside the movie with the title arriving
just after. A miss is now diagnosable instead of ambiguous, which is the whole
difference from take 1.

Still the full mix: movie WMA bed plus voice, nothing at this boundary separates
them.

Also records something unexplained that the run turned up: the probe logged FIVE
distinct XMA byte_size values, not three -- ADV s 1294336 / 1118208 / 1171456
plus 1150976 and 1269760. The extra pair belongs to some other cue, is not
BGM_103 s two waves, and a pair is the shape bgm-two-stems documents for music
banks. Untested.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:10:28 +00:00
sylph-decoder
930ab1016d re: a per-channel level check is blind to remap corruption, by construction
The port made this point while building a checker for the channel-map trap, and
it refutes a sentence in my own write-up.

In the known-bad control all six channels report a peak of -18.063656 dB,
identical to six decimals, while the file contains three duplicate pairs. Equal
tone amplitudes make the peak table uniform however the channels are permuted or
duplicated; on real content the peaks simply differ from one another, which looks
equally healthy. The table is uninformative either way.

So "the WAV has plausible per-channel levels" was not weak evidence that a
capture was sound, it was none, and this page implied otherwise. The per-channel
peak table is the natural thing to eyeball after a capture and it cannot see this
failure at all. What detects it is hashing each channel.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:08:10 +00:00
sylph-decoder
e2c599fa72 re: a 6-channel capture scrambles and duplicates channels unless the maps match
The ADV audio capture I shared with the port is withdrawn as evidence. They
could not match it against anything -- the movie bed, any of the three voice
streams, BGM_103, S00A -- with best-vs-runner-up margins of 0.001 to 0.016
everywhere, and they controlled that three ways before saying so. They also
noticed capture channels 3 and 6 were byte-identical.

That duplicate pair reproduces without the emulator, and it is my capture chain.
Six channels each carrying a different tone, played to the null sink and
recorded from its monitor with the same parec invocation:

  sink map NOT matching the client (the original setup)
    expected  400  800  200 1600 3200 6400
    captured  400 3200  200  800  800  200     ch2 == ch5 byte-identical

  sink map made identical to Canary s stream map, and passed to parec too
    captured  400  800  200 1600 3200 6400     no duplicates -- CONTROL PASSED

PulseAudio remaps when the maps differ, and a 6-channel remap silently drops
channels and duplicates others. No error, no warning; the WAV has the right
length, channel count and plausible per-channel levels.

Withdrawn with it: "all six channels carry signal", and the observation that
non-zero surround and LFE weakly supported the 5.1 reading of a voice cue s
three streams. The port said a duplicated channel is not an independent one and
they were right before this control existed.

Unaffected: the three-XMA-context concurrency result, which is read from the
emulator s own log rather than the audio path, on two independent boots.

The control needed no emulator, no disc and thirty seconds. It was not run, an
artefact was published, and the person who found the defect was the one who
could not see the instrument.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 16:04:52 +00:00
sylph-decoder
105a1f65e4 notes: run-canary is silent TWICE over, and the 6-channel stream is a red herring
Completes an entry committed an hour ago that was incomplete, which is worse
than absent because it looked authoritative. Fixing SDL_AUDIODRIVER alone still
records silence: run-canary also passes --mute=true on its own command line
(line 98). With the driver fixed and the mute left alone, Canary attaches a
healthy 6-channel stream, holds it at 100 percent volume, reports Corked: no,
and emits nothing. Both layers have to go, and "$@" is last so --mute=false on
the caller s side wins.

Also records that parec defaults to stereo/44.1 kHz and will resample a
6-channel monitor without saying so -- the first successful-looking capture came
back 2ch 44100 from a 6ch sink.

And a red herring I nearly published as a finding. pactl shows Canary s stream
as float32le 6ch 48000Hz with a full 5.1 channel map, which reads as the guest
requesting 5.1 and would have been strong support for the hypothesis that a
voice cue s three streams are 5.1 channel pairs. It is not evidence about the
game at all: AudioDriver::kFrameChannelsDefault is a hardcoded 6, and the code
path actually used, SDLAudioSystem::CreateDriver(index, semaphore, &driver),
constructs SDLAudioDriver(semaphore) taking every default. The format is
Xenia s; only the content of those six channels is the guest s.

That is the same failure this corpus recorded in METHOD earlier today -- the
specific observation and the general rule reading identically -- caught this
time before it was written down rather than after.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:56:24 +00:00
sylph-decoder
a8a828644a notes: run-canary is silent by default, which records perfect silence
Both of these cost time in one session and both are the kind that look like
success.

run-canary line 82 is SDL_AUDIODRIVER=${SDL_AUDIODRIVER:-dummy}, and its own
header explains why: --apu=nop stalls the guest in the intro movie, so the SDL
driver against a dummy device is what lets the title advance. But the comment s
premise -- "there is no PulseAudio here" -- stopped being true when
tools/audio-capture landed, since that starts a daemon on demand. So a capture
through the null sink records pure silence, of the right length, behind a run
that looks perfectly healthy. The override is
PULSE_SINK=cap SDL_AUDIODRIVER=pulseaudio run-canary, and the live check is
pactl list sink-inputs: empty means Canary never attached and the sink sits at
IDLE. audio-capture s own -inf peak warning is the backstop, but it only fires
after the whole run.

Separately, pkill -f and pgrep -f match the caller s OWN command line. Hit twice
here: pkill -9 -f adv_audio_cap.sh killed the shell running it, and an
until ! pgrep -f "probe.py --run" loop never exited because the loop s own
command line contained the pattern -- which looks exactly like the job hanging.
Kill by process name with ps -o pid= -C instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:52:05 +00:00
sylph-decoder
4362ea21b7 handoff: deliver the concurrent-streams refutation to the page the port reads
The finding landed in docs/re/ in the previous commit; an answer not reachable
from HANDOFF is not delivered. States plainly that "take one stream" was mine,
that the port implemented it, and that it is withdrawn -- together with the
caution that summing is not thereby right, because an equal-gain 1/n sum of
channel pairs is not a downmix and the port s measured 6.02 dB loss was real.
Neither rule is established, so the manifest should say the value is authored.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:49:32 +00:00
sylph-decoder
062e17bf34 re: the three streams of a voice cue are decoded CONCURRENTLY, not alternatives
Refutes a framing of mine that two documents and the port s exporter were built
on, so it is a new page rather than an edit.

voice-region-leading-chunk.md read a long cue s three streams as three
presentations of one take, and from that came the instruction "take one stream,
do not sum", which the port implemented. The open question was which
presentation the game plays.

It has no answer. Booted with --xma_param_probe=true, the cvar whose own comment
says it is keyed to reveal which sub-wave of a movie s .slb the game actually
decodes. The guest opens three XMA contexts and decodes all three concurrently:

  ctx=0  packets=632  byte_size=1294336  ch=2  48000   ADV stream 1
  ctx=1  packets=546  byte_size=1118208  ch=2  48000   ADV stream 2
  ctx=2  packets=572  byte_size=1171456  ch=2  48000   ADV stream 3

Byte-exact against the three streams payloads taken independently off the disc
(RIFF size minus 60). Only these three contexts appear in the run.

So a consumer that picks one discards two thirds of what the game mixes. Both
"three presentations of one take" and "take one stream" are withdrawn -- and the
previous behaviour is not thereby right either, because an equal-gain 1/n sum of
channel pairs is not a downmix and the port s measured 6.02 dB loss was real.
Neither rule is established; a consumer is authoring.

Three concurrent stereo streams is six channels and N stereo streams is how XMA
carries multichannel on the 360, which would also explain the 1-or-3-never-2
span census. Recorded as a hypothesis, not a result: all three fmt chunks
declare ChannelMask 0x0002 identically, which is not what distinct channel roles
should look like.

Everything byte-level survives: the leading chunk being stream 1 clipped by our
own guard, the 70 + 8 + 17 decomposition, the bank-header discriminator.

Reach: one cue, one boot. That 28 cues are 3-stream is decoded; that all three
decode concurrently is measured on ADV alone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:48:35 +00:00
sylph-decoder
a98a66190e formats: XMA1 is not a WAVEFORMATEX -- audio info was reading three wrong fields
parse_riff_wave read every fmt chunk as a WAVEFORMATEX. XMA1 (tag 0x0165) is
not one, so audio info reported the disc s movie voices as 16 channels,
4310 Hz, 2-bit: 16 is wBitsPerSample read as a channel count and 4310 is
wEncodeOptions (0x10d6) read as a sample rate. This misled me earlier in the
session and I recorded it as a limitation before finding the cause.

XMA1 carries XMAWAVEFORMAT followed by one XMASTREAMFORMAT per stream. The
reader now branches on the tag and reads bits at +2, PsuedoBytesPerSec at +12,
SampleRate at +16 and Channels at +29. The same three files now report 2
channels, 48000 Hz, 16-bit.

The consequence worth having: this crate has no XMA decoder, and
data_bytes / PsuedoBytesPerSec is the only route to a duration. Checked against
durations decoded independently by the port:

  ADV presentation 1   137.34 s declared   137.324 s decoded   +0.012 percent
  ADV presentation 2   137.33 s declared   137.324 s decoded   +0.004 percent
  S00A presentation 1   93.71 s declared    93.694 s decoded   +0.017 percent

So the corpus can now get XMA1 durations off the disc without a decoder, which
is a capability I had written down as absent. It is a declared rate rather than
a measurement of the samples, and the CLI labels it as such.

Regression test pins the real on-disc header bytes and asserts the duration
against the independently decoded 137.324 s. 115 lib tests and 3 media disc
tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:42:52 +00:00
sylph-decoder
9f34829776 method: the specific observation and the general rule read identically
Five corrections across two agents in two days share one shape, and it is worth
naming as a family rather than fixing one at a time. None was carelessness about
the measurement -- every underlying observation was true of the asset actually
looked at. The failure is reaching for the general form in the same breath as the
specific one, where the two are indistinguishable on the page and the general one
is what the next reader uses.

Three were the port s and two were mine, and the entry names both sides:

  the two chunks are two stems of one performance -- true of a music bank,
    written as a fact about voice, where one of the two is digital silence
  the extra bytes are a duplicated channel, not fidelity -- true of ADV, and the
    size ratio it implies runs 0.0778 to 2.9163 across the disc
  everything the sequencer paces off rest.t is late -- true of the title, and
    false of the screens actually checked
  a three-stream cue is a movie cue -- mine, and BIRD_224 is neither
  take the highest-rate, highest-gain stream -- mine, and on ADV those two
    criteria select different streams

The counter is the same every time: run the census before writing the rule.
Where the census cannot be run, write the specific sentence and say it is
specific.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:40:11 +00:00
sylph-decoder
b82f75979e re: the dual-mono explanation for the extra stream bytes does not generalise
The port chose a voice presentation on the argument that ADV chunk 1 is
mono-in-stereo and chunk 2 is dual-mono, so chunk 2 s extra bytes encode a
duplicated channel rather than fidelity -- which would explain its higher
declared PsuedoBytesPerSec without appealing to encode quality.

Their ADV channel measurement stands. The generalisation does not. If stream 3
were systematically the same take with its channel duplicated, its size ratio to
stream 2 would be tight across the 28 three-stream cues. Measured:

  min 0.0778 (S00A, the silent one)
  median 1.2565
  max 2.9163 (S06A)
  sd 0.5057
  within 15 percent of 1.0: 12 of 28

A 37x spread is not a duplicated channel, and the declared rates scatter with
them -- S06A is 5661 against 16513 B/s. Whatever distinguishes the three streams
varies per cue rather than being a fixed channel-configuration triple.

This does not touch the port s decision, which is to take the loudest
presentation: that is a per-asset content measurement, not a structural rule, so
a scattering ratio cannot undermine it. It touches the explanation, which should
not harden into a fact about the format.

Two curiosities recorded: S12B s three streams are byte-size identical at 14396
each, and BIRD_224 is 3-stream while being a non-movie cue, so the shape is not
exclusive to cutscenes.

Also narrows the settle-time page s own generalisation. The port measured its
boot the way this corpus measured the game and found the sequencer NOT late --
its 0.6 s discrepancy was arrival-to-arrival timestamps compared against visible
spans, the plate-delay trap in a second place. So what is supported is that
rest.t is the wrong landmark for the TITLE, not that everything paced off it is
late. And the offered re-take of the one-run menu figures is recorded as
declined, with the reason, rather than left looking unfinished.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:37:46 +00:00
sylph-decoder
63573d2b50 re: settle_time measured -- the title is drawn at 2 s, not at rest.t s 4.18
The port s boot sequencer paces every screen off rest.t, which is the last hold
keyframe rather than when a screen arrives. Measured on one cold boot: the
container had no Xenia storage root at all, so this is a fresh profile with no
shader cache, the slowest case.

  title build-in (first ink -> art fully drawn)   0.23 s
  title settled -> PRESS A plate on              2.247 s   (disc declares 120 units)
  plate pulse period                            ~2.37 s
  main menu build-in                             0.531 s
  B -> title                                     0.482 s
  A -> menu                                      3.763 s   DO NOT AUTHOR, see below

The title s rest.t is 251 units = 4.183 s and its art is finished at about 2 s,
so a sequencer pacing off rest.t holds it roughly twice as long as the game does.

Instrument controlled before the run: 9/9 on the content classifier including
the movie-frame and difficulty-screen negatives, 4/4 on the plate detector; the
run sampled 7.99 fps against a requested 8 with an independent one-shot grab
cross-checking every 20 s.

Records a refutation attempt of mine that FAILED. The probe s own marks gave a
plate delay of 3.203 s against the corpus s 2.13 s, which on a cold-cache boot
looked like a real effect. It was the instrument: the plate pulse period is an
internal clock for presentation rate and measures 2.369 s here against the
corpus s 2.3, so the run is not slowed, and re-measuring from content gives
2.247 s. The probe s title_static mark fires during the crossfade out of the
attract movie, before the wordmark has drawn -- glyph was still 0 when it fired.

Also a third independent reproduction of the A-path load stall: 13 frames,
1.53 s, surface mean 26.631 against the earlier 14/1.53 and 12/1.39 at 26.626.
This boot had no shader cache, so it is not a warm-cache artefact. Noted that
the earlier pair agreed to six decimals and mine agrees to three.

Reach: one run. The menu build-in and B->title rest on it alone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:21:49 +00:00
sylph-decoder
6011512334 method: the plate glyph counter false-positives on the attract movie by 13x
Found while controlling the timing probe before a settle_time run, not by
reasoning about it.

title_timing_probe.py s plate detector thresholds a green-glyph pixel count at
400, and its control checks two committed movie frames that both score 0. A real
boot disagrees: in one 100 s attract window, 17 frames scored at or above 400
and the peak was 5393. The attract movie has green content in the plate region.

The probe is not wrong -- its state machine refuses to look at the glyph until
the content classifier has already labelled the frame title_noplate or
title_plate, so the false positives never reach the drive. But it is safe
because of that gate, not because the threshold discriminates, and the
distinction matters for anyone reusing glyph() on its own.

Recorded with the general form: a two-frame control over a three-and-a-half
minute movie is not a control over that movie.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:17:08 +00:00
sylph-decoder
cf3b60180e re: withdraw a stream-selection recommendation that contradicted itself
The port implemented "take the highest-rate stream" and reported that on ADV it
selects the QUIETER presentation -- chunk 2, 1171516 B at -8.3 dBFS, over
chunk 1, 1118268 B at 0.0. They were right to flag it rather than accept it.

My sentence was "the highest-rate, highest-gain one is chunk 1". Those two
criteria do not select the same stream and the sentence should never have joined
them; the parenthetical named chunk 1 while the rule named chunk 2. Withdrawn.

What the header does decode, read off the bytes: the fmt chunk is a 32-byte
XMAWAVEFORMAT, little-endian, and +0x20 is a declared PsuedoBytesPerSec -- 8142
and 8530 on ADV s two presentations, agreeing with the computed rates to 0.02
percent, with 48000 Hz at +0x24. So the rate is decoded rather than inferred.

What it does not decode: wEncodeOptions (0x10d6), channel count and channel mask
are byte-identical across the presentations. Nothing in the header ranks them,
so stream selection stays an authored choice and the port must know it is
authoring. Settleable in one emulator run -- a capture of the intro with the
dialogue audible says which level the game plays -- and not yet done.

Also records that sylpheed-cli audio info is misaligned for XMA1: its "16
channels / 4310 Hz / 2-bit" is wBitsPerSample, wEncodeOptions and the channel
fields read at the wrong offsets.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:13:20 +00:00
sylph-decoder
3f945808d6 re: a long voice cue is three presentations of one take, and our guard clips the first
Closes the last open question on the voice regions: why one cue s byte span
decodes to ~2.6x the movie s length.

The port measured, with controls including a cross-movie negative, that a
region s leading chunk is the TAIL of the full-length chunk that follows it --
r = 0.998 at a lag that puts it flush against that chunk s end, residual 16.7 dB
down over 84.5 s. They withdrew their own earlier 0.768, which came from a
search that scored best on the boundary of its own lag range.

Checked it here by an independent route that needs no decoder. If the leading
chunk is the tail of a full-length first stream, the whole leading stream should
be one complete take of chunk 1 s duration. For ADV: 504464 + 808304 = 1312768 B
at chunk 0 s byte rate of 9559.7 B/s is 137.323 s, against chunk 1 s measured
137.324 s. One millisecond over 137 seconds, from byte rates rather than from
envelope correlation.

And the byte structure settles the shape disc-wide. Counting stream starts inside
every inter-descriptor span: 258 hold exactly 1 stream, 28 hold exactly 3, and
nothing holds 2 or any other number. All 20 spans over 1.5 MB are 3-stream. The
95 movie regions decompose 70 + 8 + 17, and the 8 are independently the same 8
the first census found as bank-header-with-3-chunks.

So 359 s = 84.55 + 137.32 + 137.32: three presentations of one take, the first
clipped by resolve_movie_voice_region s own 1.5 MB guard.

Consequences recorded for the port: dropping the leading chunk is removing a
duplicate rather than truncating, so the hedge is lifted; but summing chunk 1
and chunk 2 is wrong, because they are the same take at different gain, not two
stems. Take one stream.

Also flags a coincidence I nearly built on: the 504464 B constant is structural,
not proportional -- ADV s proportional prediction lands within 8 bytes of it and
S00A s is 4305 B out.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:09:40 +00:00
sylph-decoder
432fb7450b re: the voice region s leading chunk is the movie s OWN dialogue, and a guard puts it there
My own leading hypothesis -- that the leading chunk is an in-mission VOICE_D_*
line -- is refuted, on the route the port suggested: widen the enumeration past
the 95 manifest-bound movies and the byte-span test settles it without anyone
listening.

Scanning the stream for every trailer descriptor (the (id, 0x11) pair whose id
repeats at +0x800) gives the complete cue partition, mission lines included:
287 descriptors in a 116.2 MB window, all 287 carrying an id the 4280-name
registry names. Every one of the 17 leading spans is bracketed by
desc(N-1)..desc(N) where desc(N) is that movie s OWN cue id. Zero mission lines.

The mechanism is a guard in our own resolver. resolve_movie_voice_region takes
the predecessor trailer as the region start, guards it with
end - start < 1_500_000, and falls back to the .slb TOC anchor when that fails.
Cues with a true span over the guard: 17, of which 17 are stream-opening. Cues
under it: 78, of which 0. Perfect discrimination both ways. The anchor sits a
constant 504464 B after the true predecessor trailer on all 17, which is
unexplained.

Not established, and stated as such: this does NOT mean the export truncates N
seconds. The port s decode already has ADV s region at 359 s against a 137 s
movie, so it over-covers and the byte-to-time mapping is not linear. No XMA1
decoder in this container to check.

Also withdraws a claim this page had adopted from the port -- that chunks 1 and
2 are two stems of one performance. The port refuted its own claim by decoding:
S00A chunk 2 is digital silence, ADV chunk 2 is 0.60x chunk 1 with the residual
26.8 dB down. Equal duration was a shape match and Q10 s music census should not
have been carried across to voice on it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 15:03:58 +00:00
sylph-decoder
de2fe4a110 re: the voice-region third chunk is a different structure from the BGM one
The port hit a 2+1 chunk signature on a resolved movie-voice region and asked
whether the bank-header explanation that closed HANDOFF Q10 also covers it,
rather than assuming it. It does not, and the discriminator is mechanical.

Disc-wide over the 95 English movie-voice regions the manifest binds:

  78 open with a bank header -- bank_header_len fires, 10240 B = 5 packets
     exactly, every time. That is the BGM case.
  17 open with a leading headerless stream -- bank_header_len is None, and all
     17 have length congruent to 1392 mod 2048, the disc s own derived data
     offset. No other residue occurs.
   0 begin at a RIFF.

Counting chunks does not discriminate: 8 bank-header regions also yield three
chunks. slb.rs already predicted this in its own doc comment -- the header
signature has "zero false positives on the 7993 mid-bank windows, where the
leading region IS real" -- and a voice region is a mid-bank window by
construction.

Also tested the obvious defence of dropping the leading chunk, that it is the
predecessor cue s audio: 0 of 17 leading spans lie inside any other resolved
region, 0.0 percent on every one. The test finds overlaps where they exist (16
overlapping pairs among the regions, 60 exactly-adjacent boundaries, 73 of 78
bank-header regions starting where another ends), so the zero is not the
instrument.

Left open, with reach: the census covers movie-voice regions only, and the same
stream carries the in-mission VOICE_D_* cues, which are not enumerated -- the
leading bytes plausibly belong to one of those. Could not be settled by
listening: no XMA1 decoder in this container, and sylpheed-cli audio info
reports these chunks as 16 channels / 4310 Hz / 2-bit, which is visibly wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 14:56:17 +00:00
sylph-decoder
3e7a258a9a re: a cross-reference kept recommending a route the cited page had killed
`menu-navigation-semantics.md` advertised "the cheap way to finish this":
read 0x828A690C as a live screen id and 0x828F38AC as the cursor, under
--gpu=null with no screenshots. `menu-state-in-memory.md` withdrew exactly that
identity ON THE SAME DAY it was published -- three back presses send the
"cursor" 36 -> 38 -> 40 -> 41, and a cursor returns when you go back. They are
monotonic counters; the cross-run agreement is the same key sequence producing
the same count.

The recommendation stood for three days after the page it cited had killed it,
and either document would have been believed on its own. Marked withdrawn where
it was recommended, with what the words ARE still good for (did the game react?)
and the consequence: a measured button->GamePart-id binding stays unfinished
because no screen enum has been located.

Also delivers Q4 to HANDOFF in the shape the port asked for -- exactly one
main-menu button opens a GP_TITLE entry (EXTRAS -> entry 6/9); the other four
leave the archive. That was measured on 2026-08-28 and was reachable only from
docs/re/, which the protocol counts as undelivered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 14:51:15 +00:00
sylph-decoder
b40f18eeb6 re: a refutation attempt that failed -- EXTRAS really is a three-button screen
The port reported GP_TITLE entries 6/9 as a three-button submenu. This page and
HANDOFF call 6/9 EXTRAS and never recorded a button count, and 18 elements
looked like too many for three buttons, so I challenged it -- from the count,
without listing the elements.

Wrong. `screen info --all --build 6` shows ptbtn11/12/13 among fifteen frame,
title, background and effect layers, and entry 9 is identical. Both things are
true: 6/9 are EXTRAS (our composite correlates +0.944 whole-frame with the
committed live-extras.png) and EXTRAS is a three-button screen. The port
established the button count; the corpus did not have it.

Recorded per the adversarial duty, which is worth nothing if only the successful
challenges get written down. The retraction has gone to the port as well.

Also checked in the same pass, and it constrains Q2: entries 5 and 8 have
identical element lists and identical button placements, as do 6 and 9. The
EN/JP difference lives in the baked sprite pixels, so no layout field will ever
separate the members of either pair -- that needs the sprite images or a
capture, and the "English is the first half of the data segment" rule stays a
heuristic rather than something a field will replace.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 14:48:46 +00:00
sylph-decoder
fb0755d190 handoff: say which index space a build number is in -- 10/11 meant two different screens
The port challenged HANDOFF's loading-screen row and was right. The Q2 row said
"0/1 and 10/11 are the LOADING screen"; the dated section above it says
"entries 0, 1, 12, 15". Both are true, in different index spaces, and the page
did not say which.

Verified against the bytes rather than the table:

  screen list       GP_TITLE.pak -> 12 builds, ordinals 0..11
  screen list --all GP_TITLE.pak -> 16 builds, ordinals 0..15

Only under --all does the ordinal equal the pak entry. Without it ordinal 10 is
entry 12 and ordinal 11 is entry 15. `screen info --all --build 10` shows
palogo_sqex; --build 11 shows palogo_gamearts / seta / anima; 12 and 15 show
pgloading_*. So in ENTRY space 10/11 are the publisher and developer splashes,
which is exactly the screen the wrong reading would have renamed.

It would have validated silently: the port's screen_names.json is keyed by
entry. Q2 row corrected to entry space and marked; the trap is in METHOD under
"Mechanics that have bitten", with the rule that a number leaving this
repository says "entry N", never "build N".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 14:47:30 +00:00
sylph-decoder
884822ebe3 re: the paint-order tie-break costs the port zero pixels, not 24 pairs
The census bounded WHERE a wrong tie-break could show and said outright that
nobody had measured how many of those pairs change a pixel. Measured.

`compose_with_order` renders a bundle in a caller-supplied order; the new
example renders each screen twice, once derived and once with one tied pair
swapped, and diffs. Same-key elements are contiguous under a stable sort on
(key, i), so a swap paints nothing else in between.

Controlled per entry: swapping an OVERLAPPING pair with DIFFERENT keys moves
36 305 to 771 479 px (max delta 254). Where no such pair is drawn the output
says so rather than reporting an uninterpretable zero.

* EXTRAS (entries 6/9) and the main menu (5/8): 0 px. The tied ptframe pairs
  ink ~3 600 px each and share NONE of them -- the 102x132 rect overlap was an
  artefact of approximating an element as pivot x 2. Blend-independent.
* Across all 31 drawable overlapping tied pairs in GP_TITLE, the largest change
  any of them makes to any channel is 3/255.
* Withdrawn: "a wrong tie-break can be wrong by a whole layer". That rested on
  ptlogo_back2eff5 geometrically containing two other glows. Rendered, the swap
  moves 6 390 px by max delta 2. Containment is not occlusion when the container
  is a near-transparent glow, and nobody had rendered it before asserting it.

Reach: this measures our compositor's sensitivity to order, not the game's. The
zero-shared-ink results hold under any per-pixel blend; the delta<=3 figures
assume ours.

13 disc-gated ui_paint_order_disc tests and 114 lib tests pass unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
2026-08-29 14:47:19 +00:00
sylph-decoder
a0eb509cec Merge remote-tracking branch 'origin/main' into auto/no-disc-and-menu-captures 2026-08-29 14:34:10 +00:00
sylph-decoder
6c05b72099 re: the paint-order tie-break costs 24 overlapping pairs, not one element
The port challenged HANDOFF's "costs one element's blend on one screen" with a
census of 105 elements sharing a layer key across 12 of 16 screens. The two
numbers count different things -- elements vs overlapping pairs -- so it is not
the contradiction it looked like, but the objection stands and the line was
wrong.

paint_order_audit already reports overlapping ties per entry, and over all 16
GP_TITLE entries: 5 use a measured order and carry no tie risk; of the 11 that
fall back to the derived order, 7 have overlapping ties, 24 pairs in total. The
Japanese title (entry 7) alone has 16, because it is the twin of the one build
whose measured order exists and has none of its own.

Overlap bounds where a wrong tie-break COULD show, not what it costs; nobody has
measured how many of the 24 change a pixel, and the port is right about that too.

The rule itself is unaffected: the layer key is still decoded and the derived
order still reproduces every measured order exactly except the title's eight
tied pairs.

Census committed at docs/re/data/paint-order-ties-gp_title.txt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzY
2026-08-29 14:17:40 +00:00
sylph-decoder
406517cc68 handoff: address the loading bundles by pak entry, not by is_build ordinal
The port caught this before writing a name: over the twelve bundles is_build
accepts, ordinals 10/11 are entries 12/15, while ENTRIES 10/11 are the two
splash bundles. A key written from an ordinal names the publisher wordmark as a
loading screen and still validates. Restated in entry space throughout.
2026-08-29 14:15:50 +00:00
sylph-decoder
fe49c70da1 re: the boot shows the publisher first -- the TSV that says otherwise attached late
The port flagged docs/re/data/boot-timeline-2026-08-29.tsv, whose label column
runs splash_dev before splash_pub, as a possible boot-order bug in its tree.

Three cold boots, t=0 at launch, no pad input, and the frames looked at rather
than only correlated: SQUARE ENIX 3.05-7.34 / 1.18-5.78 / 1.19-5.56 s, then a
~0.25 s black hold, then GAME ARTS/SETA/studio anima. Publisher first, 3/3.

The TSV is not wrong about any frame; its t=0 is ~7.7 s into the guest's boot,
so the publisher splash had been and gone before the stream opened. The tell is
in the file: its first twelve rows are byte-identical to four decimals -- one
held frame sampled twelve times -- and those exact numbers reappear in my run 1
at 8.42-10.94 s.

Second trap, new: ADV.wmv opens with its own SQUARE ENIX card, bloomed and below
centre, scoring 0.59-0.75 against live-splash-publisher.png. The classifier
fires splash_pub twice per boot and the second one is a movie frame. The real
splash holds perfectly still and scores 0.93-0.94.

And the dwells are DECODED, not measured: the publisher declares 240 units
(4.000 s) and the developer 195 (3.250 s), against measured 4.30/4.60/4.37 and
3.51/3.50/3.37. Measured over declared is 1.085 on average across six spans --
a 30 Hz timeline at 27.6 fps, which is the presentation rate this corpus has
measured independently three times. The port authors nothing here.

Instrument control run first: 11/11 content, 4/4 plate, the two splash
references rejecting each other at 0.035.

docs/re/boot-order-and-splash-dwell.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzY
2026-08-29 14:15:28 +00:00
sylph-decoder
d71a74f938 re: index and cross-references for the record layout and the loading screens 2026-08-29 14:06:10 +00:00
sylph-decoder
2e04e24ce9 handoff: the keyframe record layout, and the loading screens are named 2026-08-29 14:05:19 +00:00
sylph-decoder
3e4864b7fa re: the DELTASABER plates are the loading screen, and the pak is packed EN-then-JP 2026-08-29 14:04:42 +00:00
sylph-decoder
43f61a8d93 re: the splash timing table was already reading the corrected pairing 2026-08-29 14:04:04 +00:00
sylph-decoder
5744f379b2 formats: a keyframe's time comes before its pose, and none of them was missing
The placement region is `frames` records of `{u32 time; 36-byte pose}` after an
8-byte header, so the time word PRECEDES the pose it belongs to. Our parser's
40-byte window opened at the pose, four bytes into the record, and then read the
word at its `+36` as that pose's time -- which is the NEXT pose's. Every pose
field was right; only the time association slipped by one.

Two things the corpus has carried for weeks are that off-by-one and nothing
else: "a group's data stops 4 bytes short of its final block's time slot", and
"the last keyframe carries no time". The group is not short (8 + frames*40 is
exact) and no time is missing -- the first pose's time is the lead-in word at
`header + 8` that `parse_placements` skipped without asking what it was.

Disc-wide, 33 archives, 13 991 groups, each test with a control:

  A  lead-in prepended to the shifted times is non-decreasing  13991/13991
  B  a non-zero lead-in is strictly below the next time         5058/5058
     control (another group's lead-in, same bundle)            70.9%
  C  multi-segment alpha ramp at a constant rate, corrected    857/1540
     the same, under the old reading                             0/1042

C is the one that cannot be argued with: interpolation between keyframes is
linear, and under the old reading not one multi-keyframe ramp on the disc comes
out at a constant rate.

Adoption is free on every static composite, which is what the corpus previously
declined it over. `SYLPHEED_KF_TIME_SHIFT=1` moved GP_TITLE build 7 by 13.1% of
its pixels because it left pose 0 untimed; with the lead-in restored, all 12
GP_TITLE builds render byte-identically, and across 217 builds in six archives
only two elements pick a different rest pose -- both times between two poses
that are equally invisible.

`SYLPHEED_KF_TIME_SHIFT` is gone; `SYLPHEED_KF_TIME_LEGACY=1` restores the old
reading for A/B work.

ui_header_time_disc needed one line: 546 bundles whose every group is a single
static pose now report max_time = 0 where they previously reported no time at
all. Excluding them, the result it guards strengthened -- the bound holds over
2 859 bundles instead of 2 313, still with zero violations.

Not established: the executable's own parser. Reach is written down.

docs/re/ui-keyframe-record-layout.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzY
2026-08-29 14:01:39 +00:00
sylph-decoder
b7104c6668 Merge remote-tracking branch 'origin/main' into auto/no-disc-and-menu-captures 2026-08-29 13:24:03 +00:00
sylph-decoder
aafd7c1b6f Merge remote-tracking branch 'origin/main' into auto/no-disc-and-menu-captures 2026-08-29 13:18:09 +00:00
sylph-decoder
14fced07b6 re: I cannot measure this emulator's clock -- and that answers the port's 2%
The port put two of my pages against each other: settle->plate 2.135 s and one
focus-ring revolution 2.177 s, both a declared 120 units during a static hold,
2% apart against a 6 ms run-to-run agreement. Fair challenge.

The resolution is that the question assumes a stable wall clock. Same interval,
same container, same day: 2.138, 2.132, and 2.549 s -- a 19% swing, caused by
adding --log_ui_draws=true. The 2% is a fifth of that. The two pages were never
in conflict about the game; they are three readings of one declared quantity
through a clock that moves. What settles the quantity is the disc.

Wall clock cannot separate the hypotheses, so I tried to measure frames instead.
Both instruments are recorded as failures rather than published as numbers:

  * Canary's own [UI-CAP] counter -- the one that produced the corpus's 28.5 fps
    -- costs a third of the frame rate. 300 frames in 16.567 s = 18.11 fps on a
    screen that gives ~28 without it. That reclassifies 28.5 as a load-dependent
    lower bound; it does not overturn it.
  * A distinct-frame counter over the spinning ring FAILED its decisive control:
    15.88 fps against the game's own 17.59 in the same window, 10% low, so the
    ring does not change on every presented frame. Its static control also read
    2.63 instead of ~0. Dead, not tuneable, per METHOD.md.

The rule that follows, and it applies to everything I hand the port: a measured
interval landing near a round number of declared units almost certainly IS that
number of units. Ship the units.

Also recovered here, because the same question needed it: the static PPC route.
Four tools open /work/xenia-rs/sylpheed.db and nothing in this repository builds
it -- no disassembler, no PPC decoder, and default.xex is encrypted (zero
plaintext "GamePart"). Xenia decompresses the image at load, so dump_image.py
reads it out of guest memory and validates it against the corpus's own landmarks:
the 29-entry GamePart id table at 0x820A1630 and the Xbox 360 D3D runtime
strings. String search and table dumps work again; instruction-level work does
not, and the present interval I wanted is an immediate, not a string.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 13:16:02 +00:00
sylph-decoder
f24304248c re: the plate delay was on the disc all along -- my instruction is refuted
The port caught this with arithmetic off the disc, and it was right: build 2 has
a keyframe group of its own, so "when build 4 has settled, wait 2.13 s, then
composite build 2" puts the plate at settle + 2.13 + 3.97 s. Confirmed build 2's
group here independently of their message: `ptbtn00.t32` reaches a=255 at t=238.

The reconciliation needs no free parameter. Both builds run on ONE clock, started
together, and the premise that fails is `rest.t`:

  rest.t is NOT when a screen settles. It is the last HOLD keyframe before the
  exit. ptlogo1 rests at t=251 and stops moving at t=42.

The title's visible build-in ends at t=118, where pteff01, pteff02.prm and
ptlogoall_eff end their ramps together. 238 - 118 = 120 units = 2.000 s, against
a measured 2.138 and 2.132. So the interval the two runs agreed on to 6 ms was a
DECLARED one and I handed over a wall-clock reading of it.

That reading is 6.7% long, and the corpus already knew why: 120 units in 2.135 s
is the game presenting at 28.06 / 28.14 fps against a nominal 30, and the idle
title was independently measured at 28.5 fps before these runs. Corroborated from
inside the same two runs -- first pixels -> settle is 1.643 s and 2.131 s, a 30%
spread, while settle -> plate is 2.138 and 2.132. Frames are dropped during the
build-in, not during the hold, which a change in the game's own timing could not
do.

So the port authors nothing here. What is unchanged: ScreenView still has to draw
two builds at once and the boot's end state is still not plate-free.

Not settled, and said so on the page: which reading of the keyframe times is
right (it moves the plate by 2 units and I cannot separate them from these
traces), and my settle landmark to better than +/-5 units.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 12:43:41 +00:00
sylph-decoder
f34d24941d formats: a music bank's third sub-wave was its own header
The port hit `sound_bank_riffs("BGM_103.slb")` returning three against a census
that says two, and refused to guess which to drop. It was our reader.

`to_xma_riffs`'s hybrid branch derives a leading packet stream's start as
`first_riff % XMA1_PACKET`. That is right only when the bank header is smaller
than one 2048-byte packet -- true of the voice banks the branch was written for
(1392/1468/1600/1728), false of a music bank, whose header is exactly five
packets. The modulus returned 0 and the whole 10 240-byte header was emitted as
sub-wave 0.

The header states its own length, so the guard needs no threshold: BE u32 0x800
at +0x18 with the bank id repeated at +0x00 and +0x20, header length in blocks at
+0x24. Disc-wide over sound.pak's 9 519 entries, 28 match at offset 0 -- every
music bank, ids 1001-1023 and 1101-1105 -- and on 28/28 the declared header ends
EXACTLY at the first RIFF. Zero have a gap, so a header and a leading packet
stream never coexist here; zero false positives among the other 9 491.

Controlled rather than argued: decoding the emitted region through the same
chain, on the same bank, in the same run gives 0.009 s of PCM where the bank's
real wave 0 gives 87.744 s against a declared 87.75. The region is also 99.1%
zero bytes. And the oracle had already said two -- the XMA probe at the main menu
saw exactly two streams, at BGM_103's two declared wave sizes.

BGM_106-109 are deliberately NOT in the 28: their entries start mid-bank, so they
have no header at offset 0 and their leading region is real audio. The
VOICE_D_453 recovery is untouched and its tests still pass, 10/10 green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 12:30:16 +00:00
sylph-decoder
5fcc89be55 re: the PRESS-A plate arrives 2.13 s after the title settles, measured twice
The one number the port said decides a structural question on its side: whether
`ScreenView` has to draw two builds at once. It does. The boot title shows
build 4 alone, and 2.13 s after build 4 stops animating it composites build 2
over it. Two independent boots agree to 6 ms (2.138 / 2.132), which is under one
sample interval.

Measure from SETTLED, not from first pixels. "First drawn -> plate" is 3.78 s in
one run and 4.26 s in the other, because the build-in animation itself ran 1.64 s
and 2.13 s -- that spread is the emulator's frame pacing, and it is exactly the
kind of number that looks like a measurement.

Ruled out before believing it: that the plate was pulsing all along, too dim for
a thresholded glyph counter. The counter reads EXACTLY 154 -- the committed
no-plate title's own value -- for every frame of a plateau nearly one full pulse
period long, with zero variation, and the surface mean is flat to +/-0.03 across
it. A cycling overlay moves both.

Also settled, and also not:

  * the black hold between two screens is 0.14-0.30 s, which brackets the port's
    authored 0.17-0.23 s and the file's declared 12 units. Their constant stands.
  * the (A)->menu latency is STILL not available, and now the reason is known.
    Both runs freeze one frame for ~1.4 s at surface mean 26.626 -- agreeing
    between runs to six decimals, and reproduced in run 2 with stream restarts
    disabled, so it is not the capture path. It is a guest load stall: the (B)
    path, which loads nothing, has no freeze at all. Any figure from it would be
    an emulator load time.

Refutation attempt, recorded whether or not it survived: navigation.md's "the
title is not input-ready for about ten seconds, and even then (A) registers
roughly half the time". At 7.29 s and 7.28 s after the title settled, (A) was
accepted first press in both runs, as was (B) on the menu. n=2 only makes "half
the time" unlikely (p ~ 0.25); it contradicts the ten seconds outright.

And the standing red banner is withdrawn: the interactive title IS reachable in
this container, twice, with no pad input, in ~3.5 minutes. Why it changed is NOT
established -- this container came up with no Xenia storage root at all, so run 1
created a profile -- and that is written as a correlation for the next session to
test rather than as a cause.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 12:15:22 +00:00
sylph-decoder
3ee1a25f47 tools: a title timing probe that costs 8.7 ms a frame, not 1503
The four durations withdrawn yesterday were produced by a classifier costing
1503 ms/frame draining an 8 fps x11grab at 0.64 fps -- a backlog, which
preserves ordering and destroys durations. This is the instrument for retaking
them.

What makes it cheap: every committed capture aligns at exactly dy=0 dx=0
(five-screens-acceptance), so the +/-8 px offset search screen_match does at
full resolution is 25 ZNCCs buying nothing on this path. Decimate 4x, do one
ZNCC per reference. Measured 8.7 ms per frame including the glyph count -- 173x.

Controls, run before the measurement and not after it:
  * 9/9 content controls, including the two committed movie frames that are the
    class this oracle exists to reject;
  * 4/4 on the plate detector itself, which is a threshold on the green-glyph
    counter and so needs its own control (no-plate title 159, plate title 753,
    movie frames 0).

And three things learned from run 1, folded back in:
  * do NOT restart the stream once the measurement is under way. Run 1's restart
    landed 0.25 s after the (A) press and its stale frames straddled exactly the
    interval being timed;
  * press INLINE, not through pad.py's subprocess -- an interpreter start plus
    the 0.25 s hold sat between the press and the timestamp;
  * count the longest run of byte-identical surface means and report it. That is
    the freeze signature, and it is how run 2 showed the 26.626 hold is the
    guest rather than the capture path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 12:15:06 +00:00
sylph-decoder
dd4f30a79f tools: fade_quads could not run -- two pre-monorepo paths
`screen-transitions.md` cites `fade_quads.py` as the command behind its decoded
fade ramp, and the command had been dead since the monorepo migration: it read
regn_decode.py from /work/Syplheed-Reborn and defaulted its pak to
/work/sylph_extract, neither of which exists. Resolve the helper beside the
script and default the pak under $SYLPHEED_DISC, the way run-canary and
sylpheed-cli already do.

A cited command that no longer runs is a citation nobody can check.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 12:15:06 +00:00
sylph-decoder
06c32a0fd4 Merge remote-tracking branch 'origin/main' into auto/no-disc-and-menu-captures 2026-08-29 11:53:43 +00:00
sylph-decoder
7a4a74f8d7 re: the main menu has no idle self-return -- and four of my own durations were a backlog
Two results and one retraction, all from the same session.

REFUTED: 'an ~8-10 s idle returns to the title' does not apply to the main menu.
Held untouched it stayed put for >= 60 s, correlation never leaving
0.9245-0.9249. That timer is real but belongs to the TITLE. It was the only
reason 'B leaves the main menu' was classed as authored, so Q5's B rule is
upgraded to measured-ordering: B is delivered (canary logs vk=5801) and is the
only input in >= 100 s before the return.

The PRESS (A) plate: the boot title presents build 4 WITHOUT the plate first --
green-glyph 154, against 159 on the committed no-plate capture and 753/977/1493
on plate titles -- and the plate arrives after. That is the port's third option.

RETRACTED: four durations taken the same day. classify_array costs 1503 ms per
frame; running it per frame against an 8 fps x11grab drained the pipe at
0.64 fps, so every classified frame was stale and increasingly so. It
manufactured 'plate 24.66 s after the title art', 'B->title 15.58 s', 'B->title
25.60 s' and 'A->menu 20.26 s'. The tell: a transition, a press and a fade do
not share a duration, and the two B figures GREW across a longer run.

A backlog preserves ordering and destroys durations, which is why the sequence
results above stand and every timing does not. The ring's period is unaffected
and that was checked, not assumed -- ring_period ran at 15.03 fps against a
requested 15.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KNR5Y79D1T4bBr6gJQaWFP
2026-08-29 11:50:46 +00:00
sylph-decoder
724e06b134 re: the main menu's focus ring spins continuously -- period 2.18 s, measured
Answers the port's ask: ptbtneff01 is ANIMATED while a button is focused, not
drawn once and held. The existing page said 'the ring SPINS' from one frame at a
large angle, which is equally consistent with a static draw at a fixed angle.

No angle is quoted anywhere. The 360-bin angular estimator written for this
FAILED its own control -- a synthetic 30 deg came back as 0 deg (peak 0.596)
while 90/180/270 came back exactly -- so it was not used. What settles it needs
no angle: total annulus brightness is conserved to 0.4 % while individual
angular bins swing by 24, i.e. brightness moving AROUND the ring, which excludes
a pulse. The temporal-std map is a clean annulus, falling to ~1 both inside and
outside the stroke, which excludes positional jitter.

Period from the profile's autocorrelation: eight evenly spaced peaks, mean
2.177 s over nine revolutions. Even spacing is the internal check a drifting
instrument cannot pass. That is 120 units = 60 frames = 2.00 s at a true 30 Hz.

Also measured, same run: the ring is the ONLY moving thing on the settled main
menu -- temporal std is exactly 0.000 on every unfocused button, the labels and
the footer. And the ring's centre, located from the std map at game
(520.7, 339.7), matches the declared leaf offset's prediction of (521, 340).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KNR5Y79D1T4bBr6gJQaWFP
2026-08-29 11:50:32 +00:00
sylph-decoder
e2d2dd34f0 tools: a screen oracle that matches CONTENT, with movie frames as its controls
The statistics oracle (green/white/mean) cannot reject the class it exists to
reject. A frame of ADV.wmv with a bright green laser reads green 0.0018 /
white 0.086 / mean (53,67,76) -- the title's numbers -- and a probe built on it
tapped (A) into the movie, then waited 120 s for a menu that was never coming.

screen_match correlates against committed captures instead. Controls run before
it was ever used live: 8/8, and the negatives are COMMITTED movie frames rather
than scratch grabs -- an earlier list pointed at two scratch files and a later
run of the same probe overwrote one, failing the control for the wrong reason.

Two paths, both controlled. The exact path costs 1503 ms/frame, which is fine
offline and catastrophic in a live loop; fast=True decimates 4x for 38-75 ms and
agrees with the exact path to +/-0.005 on all eight.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KNR5Y79D1T4bBr6gJQaWFP
2026-08-29 11:50:18 +00:00
sylph-decoder
9f34e6f7b6 re: withdraw the no-disc banner -- the disc is mounted, and both instruments that said otherwise were blind to it
The container was replaced at 11:07:38 UTC, 25 minutes after 3db09a3 wrote
"the decoder container has no disc". /disc is a real read-only bind mount
(device 2050 against /'s 92), 6.2 GB, 74 entries under dat/, and
`sylpheed-cli screen list` returns 12 GP_TITLE builds.

The reusable half is the instruments. `find / -xdev` cannot cross into a bind
mount on another device, so its "no ISO, no default.xex, no GP_TITLE.pak"
is what it returns whether or not the disc is there. `sylph-doctor` only ever
looks under /work and never consults $SYLPHEED_DISC, so it still reports
"no ISO" against a disc that works. Two instruments, one blind spot, read as
corroboration.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KNR5Y79D1T4bBr6gJQaWFP
2026-08-29 11:12:36 +00:00
sylph-decoder
c88f5e87a9 game: fill in the player's-eye navigation map from the committed oracle frames
Sections 1 to 3 were almost entirely open questions. Everything a capture in
docs/re/captures/ actually shows is now written down from the chair: what is on
each screen, what the cursor does, and what each footer offers.

Boot: the publisher plate is SQUARE ENIX, the developer plate is GAME ARTS /
SETA / studio anima, both still pictures the game draws rather than video, then
the cinematic -- one A skips it, 57 s to the title against 193 s without.

Main menu: the five labels and where each goes, the wrap rule, and the caveat
that initial focus varied across four boots. Carries the footer warning from the
measurement in the same push.

Submenus: NEW GAME's DIFFICULTY and SELECT DATA; LOAD GAME's slot carousel,
Details panel and its five-button footer; the six tutorial lessons in two
groups; OPTIONS' four categories; EXTRAS' three items; and MISSION SELECT with
the locked-list explanation for the cursor that would not move.

What stays open is marked open, and it is now the residue no capture answers
rather than the residue nobody looked at.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013UxPvE5cz7zekXBKi7Xw2r
2026-08-29 10:43:12 +00:00
sylph-decoder
6f4b4d8b4c re: two menu facts re-measured from the committed captures, no disc needed
Refutation attempt, per the adversarial duty. Target: this page's own row "B on
the main menu goes to the title". Chosen because it is one of only two Q5 rows
with an empty evidence cell, and because it is the only exit from the main menu,
so the port will build on it.

Whole-frame colour test for the pad-glyph discs. The main menu carries ZERO
red-B pixels anywhere in the frame, on two independent captures, while the same
unchanged detector finds 514 on EXTRAS and 518 on DIFFICULTY. The control passes
twice: the A glyph reads 438/438/440/438 across all four screens, so it is one
asset at one size and a B of that family could not have slipped under a
threshold. The main menu's legend is "Select / OK"; every submenu adds "Back".

The claim SURVIVES -- a legend is not behaviour, and an absent glyph cannot
refute an observed press -- but it is downgraded to amber. The observation is
uncited and single, it is now the only Q5 row the game's own text contradicts,
and there is a named confound: the title-side screens auto-return after ~8-10 s
idle, which looks exactly like what was described. Reading 0x828A690C while
pressing B would separate them in one run; that run needs a disc this container
does not have.

Second finding, same method. MISSION SELECT's "sixteen d-pad presses never left
Stage 01" was a LOCKED stage list, not a broken one. The labels have three
brightnesses, not two -- locked 104, unlocked 183, focused 254 -- and the
all-story-unlocked capture is the control that separates the lower two while
holding row 1 at an identical 254. On that save the cursor reaches Stage16 at the
bottom of a scrolled list. The list is 16 long and shows 8 at a time.

Regenerator committed beside the finding; it reads only files already in git.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013UxPvE5cz7zekXBKi7Xw2r
2026-08-29 10:43:01 +00:00
sylph-decoder
3db09a3806 re: the decoder container has no disc -- root-caused to the volume migration
find / -xdev turns up no ISO, no default.xex and no GP_TITLE.pak; /exchange is
empty; SYLPHEED_DISC is unset; sylph-doctor agrees. Everything else in the
container is healthy -- xenia_canary is built, :98 is up, screenshot works,
Vulkan enumerates. There is simply no game to boot.

The cause is in the launcher. Before c58196b, sylph-agent bind-mounted the
human's working tree at /work, and the ISO and sylph_extract/ live in that tree,
so the disc arrived incidentally with the repository mount. c58196b replaced
that with `-v sylpheed-decoder-repo:/work` -- correct for the collision class it
was written for -- and nothing was added to replace the disc. sylph-decoder
still forwards SYLPH_ISO, but as a bare environment variable naming a host path
that does not exist inside the container. sylph-port mounts the disc explicitly,
so the one container that owns the disc and the oracle is the one without them.

This shuts the oracle, every sylpheed-cli call that names a pak, the disc-gated
tests, and -- because the XEX is on the disc -- the static PPC route too. It
does not touch the committed corpus, which is what this iteration worked from.

A second, smaller casualty of the same migration: no git identity is configured
anywhere, so the first commit in a fresh container fails outright. Both are
recorded with their fixes; neither is worked around, since the launcher runs on
the host and this container cannot restart itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013UxPvE5cz7zekXBKi7Xw2r
2026-08-29 10:42:47 +00:00
1184 changed files with 242264 additions and 7382 deletions

29
.cargo/config.toml Normal file
View File

@@ -0,0 +1,29 @@
# getrandom 0.3 refuses to build for wasm32-unknown-unknown unless it is told
# which backend to use. The target has no OS entropy source, so the crate will
# not guess: it wants the `wasm_js` backend named explicitly, AND the matching
# feature enabled on the crate itself. Its own error is unusually clear that one
# without the other is not enough:
#
# error: The wasm32-unknown-unknown targets are not supported by default; you
# may need to enable the "wasm_js" configuration flag. Note that enabling the
# `wasm_js` feature flag alone is insufficient.
#
# This is the cfg half. The feature half is a wasm32-only dependency in
# crates/sylpheed-viewer/Cargo.toml — that is the only crate reaching getrandom
# here, transitively through `ahash`.
#
# Scoped to the wasm target, so native builds are untouched. Note that a
# RUSTFLAGS environment variable, if one is ever set, replaces this rather than
# adding to it.
#
# The second cfg is bevy_egui's. Its web clipboard support calls web-sys APIs
# that are still gated behind an unstable flag, and it refuses to build without
# it rather than silently dropping the feature:
#
# error: bevy_egui uses unstable APIs to support clipboard on web.
#
[target.wasm32-unknown-unknown]
rustflags = [
'--cfg', 'getrandom_backend="wasm_js"',
'--cfg', 'web_sys_unstable_apis',
]

View File

@@ -31,6 +31,24 @@ env:
# So: one job, on the machine that exists, building for the machine that exists.
# If a second architecture is ever wanted here it needs a second RUNNER, not a
# second matrix row.
#
# ── The toolchain is PINNED, in three places, deliberately ───────────────────
#
# All three jobs used `dtolnay/rust-toolchain@stable`, which resolves to whatever
# stable is on the day the job runs. A lint gate that floats is not a gate: the
# same tree goes green or red depending on the date, and this repo has already
# produced a disagreement between two people reading the same commit (#15).
# `collapsible_else_if` is the example — `warn` on 1.92.0, `allow`-by-default
# pedantic on 1.98.1, so a clean local run and a red CI run were both correct.
#
# `1.98.1` is the version run 206 resolved, and `docker/ci/Dockerfile` pins the
# same one, so `docker/ci/run cargo clippy …` on a desktop is a true stand-in for
# this workflow rather than an approximation of it.
#
# To bump: change all three `dtolnay/rust-toolchain@` refs here AND the `FROM
# rust:<version>-bookworm` in `docker/ci/Dockerfile` in one commit, so the two
# can never drift apart silently. A bump is a change to the gate and belongs in
# its own PR, where the new lints it turns on are the diff.
jobs:
# ── Native build, on the one runner there is ────────────────────────────────
@@ -42,7 +60,17 @@ jobs:
- uses: actions/checkout@v4
- name: Install Rust toolchain
uses: dtolnay/rust-toolchain@stable
# Pinned — see the toolchain note at the top of this file.
#
# This action installs a MINIMAL profile: rustc, cargo, rust-std and no
# more. Components have to be named. Without this line the Clippy step
# below dies on "'cargo-clippy' is not installed for the toolchain
# 'stable-aarch64-unknown-linux-gnu'" — which is not a lint result, it
# is the step never having run. The `fmt` job below always got this
# right; this one never did.
uses: dtolnay/rust-toolchain@1.98.1
with:
components: clippy
- name: Cache Cargo registry and build
uses: Swatinem/rust-cache@v2
@@ -69,6 +97,31 @@ jobs:
- name: Run tests
run: cargo test --workspace
# The tally above cannot tell you what it verified. `cargo test` reports
# the same count whether the disc corpus was exercised or entirely
# absent -- a gated suite that skips still counts as passed, and the
# `ignored` column is a static count of `#[ignore]` attributes that cannot
# move at runtime. Issue #16. This prints what the run ACTUALLY had, from
# a file, because a passing test's stdout is captured and would be
# invisible in exactly this log.
- name: Report which corpora the tests actually had
if: always()
run: cat target/sylpheed-corpus-report.txt || echo "(no corpus report produced -- did corpus_report run?)"
# This step has never once executed on this codebase: the toolchain above
# shipped without the component, so every run died on "not installed"
# before clippy saw a line of source. Its result was never pass or fail,
# only unmeasured. With the component installed it becomes a real check,
# and the first honest thing it will report is that the workspace is not
# clean — the build already emits ~13 plain rustc warnings (unused
# imports, unused variables, needless `mut`, dead fields) that
# `-D warnings` promotes to errors, before clippy's own lints are counted.
#
# Left gating on purpose. A red check that measures something is worth
# more than a green one that measures nothing, and the alternative —
# `continue-on-error`, or dropping `-D warnings` — cannot tell "debt not
# yet paid" from "debt paid", which is the shape PROTOCOL.md forbids.
# The debt is scoped in #13, as the rustfmt debt is in #12.
- name: Clippy
run: cargo clippy --workspace -- -D warnings
@@ -81,7 +134,7 @@ jobs:
- uses: actions/checkout@v4
- name: Install Rust toolchain + WASM target
uses: dtolnay/rust-toolchain@stable
uses: dtolnay/rust-toolchain@1.98.1
with:
targets: wasm32-unknown-unknown
@@ -89,7 +142,16 @@ jobs:
uses: Swatinem/rust-cache@v2
- name: Install Trunk
uses: jetli/trunk-action@v0.5.0
# v0.5.0 selects the download by PLATFORM ONLY and never consults the
# architecture -- `case 'linux': arch = 'x86_64-unknown-linux-gnu'` --
# so on this aarch64 runner it fetches an x86_64 binary. v0.5.1 adds
# `process.arch` with 'x64' -> 'x86_64', 'arm64' -> 'aarch64' and
# core.setFailed otherwise, so a wrong arch now fails loudly instead of
# silently. It also moves the download host thedodd/trunk ->
# trunk-rs/trunk (trunk moved repositories; v0.5.0 still points at the
# old one), and swaps io.mv for io.cp, which is what avoids EXDEV on a
# self-hosted runner whose /tmp is a separate filesystem -- ours.
uses: jetli/trunk-action@v0.5.1
- name: Check WASM compile
run: >
@@ -101,11 +163,17 @@ jobs:
- name: Build WASM release with Trunk
run: trunk build --release
- name: Upload WASM dist artifact
uses: actions/upload-artifact@v4
with:
name: web-dist
path: dist/
# No artifact upload. actions/upload-artifact@v4 hard-refuses on Gitea --
# Gitea presents as GHES and @actions/artifact v2+ aborts there
# (go-gitea/gitea#31256, #36024). Nothing consumes `web-dist`: it had
# exactly one reference in this repository, the line that produced it,
# and there is no download-artifact and no second workflow. The job's
# purpose -- proving the web build compiles -- is met by the step above.
# Add it back when something consumes the bundle, and decide then between
# actions/upload-artifact@v3 (the GHES guidance names v3.2.2 / the
# -node20 tag, so check the runner's node first) and the Gitea-specific
# christopherHX/gitea-upload-artifact@v4, which is a third-party
# dependency and therefore a decision, not a swap.
# ── Format check ─────────────────────────────────────────────────────────────
fmt:
@@ -113,7 +181,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
- uses: dtolnay/rust-toolchain@1.98.1
with:
components: rustfmt
- run: cargo fmt --all -- --check

7
.gitignore vendored
View File

@@ -18,6 +18,13 @@ Thumbs.db
# Local dev overrides
.env
# The static-analysis database `tools/zq.py` reads by default. A build artefact
# of several hundred MB (`sylph-xexdb dis ... --db sylpheed.db`), and zq.py
# now tells people to put it exactly here -- so it must never be committable.
# One `git add -A` would otherwise put it in public history for good.
/sylpheed.db
/sylpheed.db.wal
# Trunk build output
dist/
__pycache__/

788
Cargo.lock generated

File diff suppressed because it is too large Load Diff

View File

@@ -4,6 +4,9 @@ members = [
"crates/sylpheed-viewer",
"crates/sylpheed-cli",
"crates/sylpheed-export",
"crates/sylpheed-xex",
"crates/sylpheed-ppc",
"crates/sylpheed-xexdb",
]
resolver = "2"

21
LICENSE Normal file
View File

@@ -0,0 +1,21 @@
MIT License
Copyright (c) 2026 Fabian
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

View File

@@ -38,7 +38,6 @@ use anyhow::{Context, Result};
use clap::{Parser, Subcommand};
use colored::*;
use indicatif::{ProgressBar, ProgressStyle};
use tracing::info;
use sylpheed_formats::vfs::{identify_format, GameAssets};
use sylpheed_formats::{IdxdObject, PakArchive};
@@ -195,6 +194,36 @@ enum ScreenCommands {
/// `--build`**, which is why it is a flag and not the default.
#[arg(long)]
all: bool,
/// Pose every element at this KEYFRAME TIME instead of at its resting
/// pose (60 units = 1 second). The resting pose is each element's last
/// *hold* keyframe, picked independently of every other element, so it is
/// not the screen at any one moment: it omits anything still moving (the
/// title's light sweeps hold off the right edge) and freezes a transient
/// at its PEAK (the title's five two-frame flashes burn forever).
/// ⚠️ This help used to end "Prefer `--settle`". That is WITHDRAWN and was
/// never measured: scored against a live capture of the JP title, settle
/// gives RMSE 40.210 and rest 41.690 — a margin of 1.48 against that
/// instrument's own noise floor of 1.2, which is NOT decisive. `--settle`
/// also has its own failure mode (25.5 % of elements are mid-ramp at their
/// screen's settle instant). Neither is established as better; pick by what
/// you are measuring. See `docs/re/structures/ui-resting-pose.md`.
#[arg(long, conflicts_with = "settle")]
at: Option<u32>,
/// Pose every element at the instant the screen is SETTLED, derived from
/// the disc: the midpoint of the longest interval containing no keyframe
/// of any element. Prints the window it used, whose width is how much the
/// midpoint is worth — a narrow one means the bundle never settles.
/// ⚠️ That is **38 % of the screen builds this command renders** (185 of
/// 491 carrying two or more keyframe times) and 39 % of the wider set
/// `--all` admits (862 of 2 211), mostly `loop*` fragments. This help used
/// to say "42 % of them" without saying of WHAT: 42 % was 731/1 758 over
/// composable bundles, computed before the keyframe record-layout fix,
/// which times a group's final pose and so admits ~450 bundles that
/// previously had only one timed keyframe. ⚠️ NOT established as better
/// than the resting pose — see the note on `--at`. See
/// `docs/re/structures/ui-settle-time.md`.
#[arg(long)]
settle: bool,
},
}
@@ -306,7 +335,7 @@ async fn main() -> Result<()> {
tracing_subscriber::fmt()
.with_env_filter(
tracing_subscriber::EnvFilter::from_default_env()
.add_directive("sylpheed=info".parse().unwrap())
.add_directive("sylpheed=info".parse().unwrap()),
)
.init();
@@ -314,24 +343,33 @@ async fn main() -> Result<()> {
match cli.command {
Commands::Extract { iso, output } => cmd_extract(&iso, &output).await,
Commands::List { iso, filter } => cmd_list(&iso, filter).await,
Commands::List { iso, filter } => cmd_list(&iso, filter).await,
Commands::Sniff { dir, unknown_only } => cmd_sniff(&dir, unknown_only),
Commands::Texture { cmd } => match cmd {
TextureCommands::Info { file } => cmd_texture_info(&file),
TextureCommands::Info { file } => cmd_texture_info(&file),
TextureCommands::Export { file, output } => cmd_texture_export(&file, &output),
},
Commands::Mesh { cmd } => match cmd {
MeshCommands::Info { file } => cmd_mesh_info(&file),
MeshCommands::Render { file, output, size, yaw, pitch, dist, row, only } => {
cmd_mesh_render(&file, &output, size, yaw, pitch, dist, row, only)
}
MeshCommands::Render {
file,
output,
size,
yaw,
pitch,
dist,
row,
only,
} => cmd_mesh_render(&file, &output, size, yaw, pitch, dist, row, only),
},
Commands::Pak { cmd } => match cmd {
PakCommands::List { pak, idxd_only } => cmd_pak_list(&pak, idxd_only),
PakCommands::Dump { pak, hash } => cmd_pak_dump(&pak, &hash),
PakCommands::Textures { pak, output, verbose } => {
cmd_pak_textures(&pak, &output, verbose)
}
PakCommands::List { pak, idxd_only } => cmd_pak_list(&pak, idxd_only),
PakCommands::Dump { pak, hash } => cmd_pak_dump(&pak, &hash),
PakCommands::Textures {
pak,
output,
verbose,
} => cmd_pak_textures(&pak, &output, verbose),
},
Commands::Audio { cmd } => match cmd {
AudioCommands::Info { file } => cmd_audio_info(&file),
@@ -353,8 +391,10 @@ async fn main() -> Result<()> {
black,
all,
primitives,
at,
settle,
} => cmd_screen_render(
&pak, &output, build, focus, animated, black, all, primitives,
&pak, &output, build, focus, animated, black, all, primitives, at, settle,
),
},
Commands::Save { cmd } => match cmd {
@@ -482,7 +522,9 @@ fn cmd_screen_info(pak: &Path, want: Option<usize>, geometry: bool, all: bool) -
"{:<3} {:<30} {:>7} {:>8} {:>12} {:>4} {rest}",
el.index,
el.name,
el.parent.map(|p| p.to_string()).unwrap_or_else(|| "-".into()),
el.parent
.map(|p| p.to_string())
.unwrap_or_else(|| "-".into()),
format!("{:#x}", el.kind),
format!("({},{})", el.pivot_x, el.pivot_y),
el.keyframes.len(),
@@ -572,6 +614,11 @@ fn print_geometry(b: &sylpheed_formats::ui_layout::UiBuild, bytes: &[u8]) {
}
}
// 8 parameters against a threshold of 7 — a plain function, unlike the Bevy
// systems in the viewer, so this one is real if mild. Left as-is because the
// arguments are the CLI flags this subcommand takes; grouping them into a
// struct is a change to the command surface, not a lint fix.
#[allow(clippy::too_many_arguments)]
fn cmd_screen_render(
pak: &Path,
output: &Path,
@@ -581,12 +628,42 @@ fn cmd_screen_render(
black: bool,
all: bool,
primitives: bool,
at: Option<u32>,
settle: bool,
) -> Result<()> {
use sylpheed_formats::ui_layout::{self, ComposeOptions};
let builds = screen_builds(pak, all)?;
let idx = pick_build(&builds, want)?;
let bytes = &builds[idx].1;
let b = ui_layout::parse_build(bytes).context("build did not parse")?;
let at = if settle {
match (b.settle_window(), b.settle_time()) {
(Some((lo, hi)), Some(t)) => {
// Report the width, not just the answer. A 4-unit window and a
// 190-unit one give the same kind of number and mean entirely
// different things.
println!(
"settle window [{lo}, {hi}] = {} units ({:.2} s) -> posing at t={t}{}",
hi - lo,
(hi - lo) as f64 / 60.0,
if hi - lo < 30 {
" ⚠️ narrow — this bundle may never settle"
} else {
""
}
);
Some(t)
}
_ => {
println!(
"no settle window (fewer than two distinct keyframe times) — using rest()"
);
None
}
}
} else {
at
};
let screen = ui_layout::compose(
&b,
bytes,
@@ -599,6 +676,7 @@ fn cmd_screen_render(
ComposeOptions::default().backdrop
},
include_primitives: primitives,
at,
},
None,
);
@@ -619,16 +697,40 @@ fn cmd_screen_render(
screen.height
);
if !screen.missing.is_empty() {
println!(" sprites that did not resolve/decode: {:?}", screen.missing);
println!(
" sprites that did not resolve/decode: {:?}",
screen.missing
);
}
let undrawn: Vec<&str> = b
// 🔴 Report the INDEX, the KIND and WHY, not just the name. A kind-`0x4`
// ghost instance carries its template's name, so a bare name list shows
// `ptlogo1.t32` twice and reads as "the logo is missing" when what is
// skipped is two motion-trail ghosts sitting at alpha 0 off-screen. That
// misreading cost this project a wrong finding sent to another agent.
let undrawn: Vec<String> = b
.elements
.iter()
.filter(|e| !screen.drawn.contains(&e.index))
.map(|e| e.name.as_str())
.map(|e| {
let why = if e.name.ends_with(".prm") {
"untextured primitive, needs --primitives"
} else if e.name.ends_with(".rat") {
"animation, needs --animated"
} else if e.kind == 0x4 {
"kind 0x4 ghost instance"
} else if e.rest().map(|k| k.fade >> 24) == Some(0) {
"transparent at its pose"
} else {
"no reason established"
};
format!("[{}] {} ({why})", e.index, e.name)
})
.collect();
if !undrawn.is_empty() {
println!(" not drawn ({}): {undrawn:?}", undrawn.len());
println!(" not drawn ({}):", undrawn.len());
for u in &undrawn {
println!(" {u}");
}
}
Ok(())
}
@@ -636,9 +738,7 @@ fn cmd_screen_render(
// ── save file ────────────────────────────────────────────────────────────────
fn cmd_save_info(file: &Path, all: bool) -> Result<()> {
use sylpheed_formats::savegame::{
self, Confidence, DevelopState, FieldKind, GHAD_LAYOUT,
};
use sylpheed_formats::savegame::{self, Confidence, DevelopState, FieldKind, GHAD_LAYOUT};
let raw = std::fs::read(file).context("read save")?;
let save = savegame::parse(&raw).map_err(|e| anyhow::anyhow!("{e}"))?;
@@ -688,7 +788,11 @@ fn cmd_save_info(file: &Path, all: bool) -> Result<()> {
" {} +{:<3} {:<14} {}",
mark(f.confidence),
f.offset,
if f.name.is_empty() { "(unnamed)" } else { f.name },
if f.name.is_empty() {
"(unnamed)"
} else {
f.name
},
value
);
if all && !f.note.is_empty() {
@@ -697,7 +801,10 @@ fn cmd_save_info(file: &Path, all: bool) -> Result<()> {
}
let dev = save.develop_state();
let owned = dev.iter().filter(|d| **d == DevelopState::Developed).count();
let owned = dev
.iter()
.filter(|d| **d == DevelopState::Developed)
.count();
let ready = dev
.iter()
.filter(|d| **d == DevelopState::Developable)
@@ -741,16 +848,36 @@ fn cmd_audio_info(file: &Path) -> Result<()> {
println!("{} {}", "Audio:".green().bold(), file.display());
println!(" Codec : {}", info.codec.label().yellow());
let opt = |v: Option<String>| v.unwrap_or_else(|| "".dimmed().to_string());
println!(" Channels : {}", opt(info.channels.map(|c| c.to_string())));
println!(" Sample rate: {}", opt(info.sample_rate.map(|r| format!("{r} Hz"))));
println!(" Bit depth : {}", opt(info.bits_per_sample.map(|b| format!("{b}-bit"))));
println!(
" Channels : {}",
opt(info.channels.map(|c| c.to_string()))
);
println!(
" Sample rate: {}",
opt(info.sample_rate.map(|r| format!("{r} Hz")))
);
println!(
" Bit depth : {}",
opt(info.bits_per_sample.map(|b| format!("{b}-bit")))
);
if let Some(b) = info.avg_bytes_per_sec {
println!(" Byte rate : {} B/s (declared)", b.to_string().yellow());
}
if let Some(d) = info.duration_secs {
println!(" Duration : {d:.2} s");
let how = if info.codec == sylpheed_formats::AudioCodec::Xma {
" (from the declared byte rate, not decoded)"
} else {
""
};
println!(" Duration : {d:.2} s{how}");
}
if let Some(p) = info.xma_packets {
println!(" XMA packets: {} (2048 B each)", p.to_string().yellow());
}
println!(" Size : {} bytes", info.size_bytes.to_string().yellow());
println!(
" Size : {} bytes",
info.size_bytes.to_string().yellow()
);
if info.codec.needs_decoder() {
println!(
" {} decode not supported (needs an XMA2 decoder + the sound-bank descriptor)",
@@ -783,7 +910,7 @@ async fn cmd_extract(iso_path: &Path, output_dir: &Path) -> Result<()> {
ProgressStyle::default_bar()
.template("{spinner:.cyan} [{bar:40.cyan/blue}] {pos}/{len} {msg}")
.unwrap()
.progress_chars("█▉▊▋▌▍▎▏ ")
.progress_chars("█▉▊▋▌▍▎▏ "),
);
let stats = reader.extract_all(output_dir).await?;
@@ -812,7 +939,11 @@ async fn cmd_extract(iso_path: &Path, output_dir: &Path) -> Result<()> {
// ── list ───────────────────────────────────────────────────────────────────
async fn cmd_list(iso_path: &Path, filter: Option<String>) -> Result<()> {
println!("{} {}", "Listing".green().bold(), iso_path.display().to_string().cyan());
println!(
"{} {}",
"Listing".green().bold(),
iso_path.display().to_string().cyan()
);
let mut reader = sylpheed_formats::xiso::open_iso(iso_path).await?;
let files = reader.list_all_files().await?;
@@ -857,7 +988,9 @@ fn cmd_sniff(dir: &Path, unknown_only: bool) -> Result<()> {
let mut counts: std::collections::HashMap<&str, usize> = std::collections::HashMap::new();
for file in &files {
let Ok(bytes) = assets.read(file) else { continue; };
let Ok(bytes) = assets.read(file) else {
continue;
};
let fmt = identify_format(&bytes);
let label = fmt.extension_hint();
*counts.entry(label).or_insert(0) += 1;
@@ -878,9 +1011,10 @@ fn cmd_sniff(dir: &Path, unknown_only: bool) -> Result<()> {
let hex_preview = if label == "bin" && bytes.len() >= 8 {
format!(
" {:02X} {:02X} {:02X} {:02X} {:02X} {:02X} {:02X} {:02X}",
bytes[0], bytes[1], bytes[2], bytes[3],
bytes[4], bytes[5], bytes[6], bytes[7]
).dimmed().to_string()
bytes[0], bytes[1], bytes[2], bytes[3], bytes[4], bytes[5], bytes[6], bytes[7]
)
.dimmed()
.to_string()
} else {
String::new()
};
@@ -892,13 +1026,9 @@ fn cmd_sniff(dir: &Path, unknown_only: bool) -> Result<()> {
println!();
println!("{}", "Format Summary:".bold());
let mut summary: Vec<_> = counts.into_iter().collect();
summary.sort_by(|a, b| b.1.cmp(&a.1));
summary.sort_by_key(|&(_, count)| std::cmp::Reverse(count));
for (fmt, count) in summary {
println!(
" {:>6} .{}",
count.to_string().yellow(),
fmt
);
println!(" {:>6} .{}", count.to_string().yellow(), fmt);
}
Ok(())
@@ -907,8 +1037,7 @@ fn cmd_sniff(dir: &Path, unknown_only: bool) -> Result<()> {
// ── texture info ──────────────────────────────────────────────────────────
fn cmd_texture_info(file: &Path) -> Result<()> {
let bytes = std::fs::read(file)
.with_context(|| format!("Cannot read {}", file.display()))?;
let bytes = std::fs::read(file).with_context(|| format!("Cannot read {}", file.display()))?;
use sylpheed_formats::texture::X360Texture;
let tex = X360Texture::from_xpr2(&bytes)
@@ -916,16 +1045,27 @@ fn cmd_texture_info(file: &Path) -> Result<()> {
let d = tex.format.desc();
println!("{} {}", "Texture:".green().bold(), file.display());
println!(" Resolution : {}×{}", tex.width.to_string().yellow(), tex.height.to_string().yellow());
println!(
" Resolution : {}×{}",
tex.width.to_string().yellow(),
tex.height.to_string().yellow()
);
println!(
" Format : {} ({:?}) · {} bpp, {}",
tex.format.gpu_name().yellow(),
tex.format,
d.bpp,
if d.compressed { "compressed" } else { "uncompressed" },
if d.compressed {
"compressed"
} else {
"uncompressed"
},
);
println!(" Mip levels : {}", tex.mip_levels);
println!(" Data size : {} bytes", tex.data.len().to_string().yellow());
println!(
" Data size : {} bytes",
tex.data.len().to_string().yellow()
);
Ok(())
}
@@ -933,13 +1073,12 @@ fn cmd_texture_info(file: &Path) -> Result<()> {
// ── texture export ────────────────────────────────────────────────────────
fn cmd_texture_export(file: &Path, output: &Path) -> Result<()> {
let bytes = std::fs::read(file)
.with_context(|| format!("Cannot read {}", file.display()))?;
let bytes = std::fs::read(file).with_context(|| format!("Cannot read {}", file.display()))?;
use sylpheed_formats::texture::X360Texture;
let tex = X360Texture::from_xpr2(&bytes)?;
let rgba = decode_to_rgba8(&tex)
.with_context(|| format!("decoding {:?} texture", tex.format))?;
let rgba =
decode_to_rgba8(&tex).with_context(|| format!("decoding {:?} texture", tex.format))?;
image::save_buffer(
output,
@@ -956,7 +1095,11 @@ fn cmd_texture_export(file: &Path, output: &Path) -> Result<()> {
tex.width,
tex.height,
tex.format,
if tex.is_cubemap { " (cubemap face 0)" } else { "" },
if tex.is_cubemap {
" (cubemap face 0)"
} else {
""
},
output.display().to_string().cyan(),
);
Ok(())
@@ -1034,7 +1177,7 @@ fn cmd_mesh_info(file: &Path) -> Result<()> {
let nv = sub.positions.len();
let mut referenced = vec![false; nv];
let (mut degen, mut oob, mut imax) = (0usize, 0usize, 0u32);
for tri in sub.indices.chunks_exact(3) {
for tri in sub.indices.as_chunks::<3>().0 {
let (a, b, c) = (tri[0], tri[1], tri[2]);
imax = imax.max(a).max(b).max(c);
if a == b || b == c || a == c {
@@ -1056,11 +1199,17 @@ fn cmd_mesh_info(file: &Path) -> Result<()> {
};
let mut maxedges: Vec<f32> = sub
.indices
.chunks_exact(3)
.as_chunks::<3>()
.0
.iter()
.map(|t| edge(t[0], t[1]).max(edge(t[1], t[2])).max(edge(t[0], t[2])))
.collect();
maxedges.sort_by(|a, b| a.partial_cmp(b).unwrap());
let median = maxedges.get(maxedges.len() / 2).copied().unwrap_or(1.0).max(1e-6);
let median = maxedges
.get(maxedges.len() / 2)
.copied()
.unwrap_or(1.0)
.max(1e-6);
let spanning = maxedges.iter().filter(|&&e| e > 6.0 * median).count();
println!(
" sub{si}: {nv} v, {} tris | degenerate {degen}, unref-verts {unref}, spanning>6×med {spanning}, idx_max {imax}/{}{}",
@@ -1180,10 +1329,16 @@ fn cmd_mesh_render(
(lo[2] + hi[2]) * 0.5,
];
let (scale, cell) = if multi {
let extent = (hi[0] - lo[0]).max(hi[1] - lo[1]).max(hi[2] - lo[2]).max(1e-3);
let extent = (hi[0] - lo[0])
.max(hi[1] - lo[1])
.max(hi[2] - lo[2])
.max(1e-3);
let col = i % cols;
let row = i / cols;
(CELL / extent, [col as f32 * grid_pitch, -(row as f32) * grid_pitch, 0.0])
(
CELL / extent,
[col as f32 * grid_pitch, -(row as f32) * grid_pitch, 0.0],
)
} else {
(1.0, [0.0, 0.0, 0.0])
};
@@ -1220,7 +1375,9 @@ fn cmd_mesh_render(
let med = {
let mut e: Vec<f32> = sub
.indices
.chunks_exact(3)
.as_chunks::<3>()
.0
.iter()
.filter(|t| (t[0] as usize) < n && (t[1] as usize) < n && (t[2] as usize) < n)
.map(|t| {
let d = |a: u32, b: u32| {
@@ -1247,14 +1404,16 @@ fn cmd_mesh_render(
};
for place in &mine {
let f = |i: usize| {
let p = place.map(|pl| pl.apply(sub.positions[i])).unwrap_or(sub.positions[i]);
let p = place
.map(|pl| pl.apply(sub.positions[i]))
.unwrap_or(sub.positions[i]);
[
(p[0] - center[0]) * scale * mirror[0] + cell[0],
(p[1] - center[1]) * scale * mirror[1] + cell[1],
(p[2] - center[2]) * scale * mirror[2] + cell[2],
]
};
for tri in sub.indices.chunks_exact(3) {
for tri in sub.indices.as_chunks::<3>().0 {
let (a, b, c) = (tri[0] as usize, tri[1] as usize, tri[2] as usize);
if a < n && b < n && c < n {
if span_only || span_hide {
@@ -1440,7 +1599,9 @@ fn decode_to_rgba8(tex: &sylpheed_formats::texture::X360Texture) -> Result<Vec<u
// [A,R,G,B] byte order (verified against the retail Acheron backdrop).
// Emit RGBA. X8 has no meaningful alpha.
let opaque = matches!(tex.format, F::X8R8G8B8);
for (px, out) in tex.data.chunks_exact(4).zip(rgba.chunks_exact_mut(4)) {
let src = tex.data.as_chunks::<4>().0;
let dst = rgba.as_chunks_mut::<4>().0;
for (px, out) in src.iter().zip(dst) {
out[0] = px[1]; // R
out[1] = px[2]; // G
out[2] = px[3]; // B
@@ -1636,8 +1797,10 @@ fn emit_t8ad(
}
match t8ad::parse(slice) {
Some(img) => {
let out =
output.join(format!("{hash:08x}_{stem}_{}x{}.png", img.width, img.height));
let out = output.join(format!(
"{hash:08x}_{stem}_{}x{}.png",
img.width, img.height
));
image::save_buffer(
&out,
&img.rgba,
@@ -1659,8 +1822,7 @@ fn cmd_pak_textures(pak: &Path, output: &Path, verbose: bool) -> Result<()> {
use sylpheed_formats::{lsta, ratc, t8ad};
let arc = PakArchive::open(pak).with_context(|| format!("opening {}", pak.display()))?;
std::fs::create_dir_all(output)
.with_context(|| format!("creating {}", output.display()))?;
std::fs::create_dir_all(output).with_context(|| format!("creating {}", output.display()))?;
println!(
"{} {}{}",
@@ -1690,12 +1852,12 @@ fn cmd_pak_textures(pak: &Path, output: &Path, verbose: bool) -> Result<()> {
let mut idx = 0usize;
while let Some(pos) = payload[off..]
.windows(4)
.position(|w| w == &t8ad::T8AD_MAGIC)
.position(|w| w == t8ad::T8AD_MAGIC)
{
let start = off + pos;
let next = payload[start + 4..]
.windows(4)
.position(|w| w == &t8ad::T8AD_MAGIC)
.position(|w| w == t8ad::T8AD_MAGIC)
.map(|p| start + 4 + p)
.unwrap_or(payload.len());
emit_t8ad(
@@ -1728,7 +1890,14 @@ fn cmd_pak_textures(pak: &Path, output: &Path, verbose: bool) -> Result<()> {
} else {
safe_name(&child.name)
};
emit_t8ad(&payload[child.offset..end], hash, &stem, output, verbose, &mut stats)?;
emit_t8ad(
&payload[child.offset..end],
hash,
&stem,
output,
verbose,
&mut stats,
)?;
}
}
continue;

View File

@@ -7,7 +7,8 @@ use std::process::Command;
use sylpheed_formats::media;
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let disc =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let src = media::DirectorySource::new(&disc);
for bank in ["BGM_103.slb", "BGM_102.slb", "BGM_001.slb"] {
match media::sound_bank_riffs(&src, bank) {
@@ -19,22 +20,42 @@ fn main() {
let w = std::env::temp_dir().join(format!("bk_{i}.wav"));
let _ = Command::new("ffmpeg")
.args(["-hide_banner", "-loglevel", "error", "-y", "-i"])
.arg(&p).arg(&w).output();
.arg(&p)
.arg(&w)
.output();
let out = Command::new("ffmpeg")
.args(["-hide_banner", "-v", "info", "-i"])
.arg(&w)
.args(["-af", "astats=measure_perchannel=none", "-f", "null", "-"])
.output().unwrap();
.output()
.unwrap();
let t = String::from_utf8_lossy(&out.stderr).into_owned();
let get = |k: &str| t.lines().find_map(|l| l.split_once(k).map(|x| x.1.trim().to_string()))
.unwrap_or_else(|| "?".into());
let get = |k: &str| {
t.lines()
.find_map(|l| l.split_once(k).map(|x| x.1.trim().to_string()))
.unwrap_or_else(|| "?".into())
};
let dur = Command::new("ffprobe")
.args(["-v","error","-show_entries","format=duration","-of","csv=p=0"])
.arg(&w).output().ok()
.args([
"-v",
"error",
"-show_entries",
"format=duration",
"-of",
"csv=p=0",
])
.arg(&w)
.output()
.ok()
.map(|o| String::from_utf8_lossy(&o.stdout).trim().to_string())
.unwrap_or_default();
println!(" sub-wave {i}: {:>9} B -> {:>10} s peak {:>10} rms {}",
r.len(), dur, get("Peak level dB:"), get("RMS level dB:"));
println!(
" sub-wave {i}: {:>9} B -> {:>10} s peak {:>10} rms {}",
r.len(),
dur,
get("Peak level dB:"),
get("RMS level dB:")
);
let _ = std::fs::remove_file(&p);
let _ = std::fs::remove_file(&w);
}

View File

@@ -18,19 +18,26 @@
use sylpheed_formats::media;
fn main() {
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let src = media::DirectorySource::new(&root);
const WANT: [usize; 2] = [3_876_864, 3_930_112];
let (mut found, mut matches) = (0usize, Vec::new());
for n in 0..=199u32 {
let name = format!("BGM_{n:03}.slb");
let Ok(riffs) = media::sound_bank_riffs(&src, &name) else { continue };
if riffs.is_empty() { continue }
let Ok(riffs) = media::sound_bank_riffs(&src, &name) else {
continue;
};
if riffs.is_empty() {
continue;
}
found += 1;
let sizes: Vec<usize> = riffs.iter().map(|r| r.len()).collect();
// Compare on the DATA payload the port sums, not on the RIFF wrapper:
// a wrapper differs by header bytes and would hide a real collision.
let near = sizes.iter().any(|s| WANT.iter().any(|w| s.abs_diff(*w) < 4096));
let near = sizes
.iter()
.any(|s| WANT.iter().any(|w| s.abs_diff(*w) < 4096));
if near {
matches.push((name.clone(), sizes.clone()));
}
@@ -39,7 +46,10 @@ fn main() {
for (n, s) in &matches {
println!(" {n:<14} wave sizes {s:?}");
}
println!("\n {} bank(s) carry a wave within 4 KiB of {WANT:?}", matches.len());
println!(
"\n {} bank(s) carry a wave within 4 KiB of {WANT:?}",
matches.len()
);
println!(" Exactly 1 means the census EXCLUDES alternatives and is a real third");
println!(" leg. More than 1 means the byte match does not distinguish BGM_103,");
println!(" and \"three legs\" is two. Zero means this reader cannot see the");

View File

@@ -16,27 +16,40 @@
//!
//! This prints what the differences actually look like, so the reading is judged
//! against the names rather than accepted as plausible.
use sylpheed_formats::{pak, ratc, ui_layout};
use std::collections::BTreeSet;
use sylpheed_formats::{pak, ratc, ui_layout};
fn main() {
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let ar = pak::PakArchive::open(format!("{root}/dat/GP_DIALOG.pak")).expect("GP_DIALOG.pak");
let sets: Vec<Option<BTreeSet<String>>> = ar.entries().iter().map(|e| {
let by = ar.read(e).ok()?;
if !ratc::is_ratc(&by) { return None }
let b = ui_layout::parse_build(&by)?;
Some(b.elements.iter().map(|el| el.name.clone()).collect())
}).collect();
let sets: Vec<Option<BTreeSet<String>>> = ar
.entries()
.iter()
.map(|e| {
let by = ar.read(e).ok()?;
if !ratc::is_ratc(&by) {
return None;
}
let b = ui_layout::parse_build(&by)?;
Some(b.elements.iter().map(|el| el.name.clone()).collect())
})
.collect();
let (mut same, mut diff, mut pairs) = (0usize, 0usize, 0usize);
let mut shown = 0;
for i in (0..sets.len().saturating_sub(1)).step_by(2) {
let (Some(a), Some(b)) = (&sets[i], &sets[i + 1]) else { continue };
let (Some(a), Some(b)) = (&sets[i], &sets[i + 1]) else {
continue;
};
pairs += 1;
if a == b {
same += 1;
println!(" entries {i:>3}/{:<3} IDENTICAL sets, {} element(s)", i + 1, a.len());
println!(
" entries {i:>3}/{:<3} IDENTICAL sets, {} element(s)",
i + 1,
a.len()
);
continue;
}
diff += 1;
@@ -49,19 +62,37 @@ fn main() {
if (10..=15).contains(&i) {
let sp = |x: &BTreeSet<String>| x.iter().filter(|n| n.ends_with(".t32")).count();
let stage = |x: &BTreeSet<String>| -> Vec<String> {
let mut v: Vec<String> = x.iter().filter_map(|n| n.strip_prefix("pzstg")
.and_then(|r| r.get(..2)).map(|s| s.to_string())).collect();
v.sort(); v.dedup(); v
let mut v: Vec<String> = x
.iter()
.filter_map(|n| {
n.strip_prefix("pzstg")
.and_then(|r| r.get(..2))
.map(|s| s.to_string())
})
.collect();
v.sort();
v.dedup();
v
};
println!(" entries {i:>3}/{:<3} stages {:?} vs {:?} sprites {} vs {}",
i + 1, stage(a), stage(b), sp(a), sp(b));
println!(
" entries {i:>3}/{:<3} stages {:?} vs {:?} sprites {} vs {}",
i + 1,
stage(a),
stage(b),
sp(a),
sp(b)
);
}
if shown < 3 {
shown += 1;
let only_a: Vec<_> = a.difference(b).cloned().collect();
let only_b: Vec<_> = b.difference(a).cloned().collect();
println!(" entries {i:>3}/{:<3} differ: {} only-in-first, {} only-in-second",
i + 1, only_a.len(), only_b.len());
println!(
" entries {i:>3}/{:<3} differ: {} only-in-first, {} only-in-second",
i + 1,
only_a.len(),
only_b.len()
);
println!(" first : {:?}", &only_a[..only_a.len().min(4)]);
println!(" second : {:?}", &only_b[..only_b.len().min(4)]);
}
@@ -71,12 +102,17 @@ fn main() {
// different dialogs and the whole adjacent-pairing premise is wrong -- which
// is a stronger statement than "the language reading is untested".
let btns = |s: &Option<BTreeSet<String>>| -> usize {
s.as_ref().map_or(0, |x| x.iter().filter(|n| n.contains("btn")).count())
s.as_ref()
.map_or(0, |x| x.iter().filter(|n| n.contains("btn")).count())
};
let mut mismatched = 0;
for i in (0..sets.len().saturating_sub(1)).step_by(2) {
if sets[i].is_none() || sets[i + 1].is_none() { continue }
if btns(&sets[i]) != btns(&sets[i + 1]) { mismatched += 1 }
if sets[i].is_none() || sets[i + 1].is_none() {
continue;
}
if btns(&sets[i]) != btns(&sets[i + 1]) {
mismatched += 1
}
}
println!("\n adjacent pairs whose BUTTON COUNTS differ: {mismatched}");
println!(" A language pair cannot. Every one of these is two different dialogs.");

View File

@@ -17,7 +17,8 @@
use sylpheed_formats::{pak, ratc, ui_layout};
fn main() {
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
// 🔴 WIDENED 2026-08-31 to every pak, to check the Decoder's rival search
// independently. They report zero four-button builds within 6 px of
// 259/329/399/469 anywhere on the disc, which turns "another dialog with
@@ -26,40 +27,66 @@ fn main() {
// with a different reader, because its whole content is an absence.
const WANT: [i32; 4] = [259, 329, 399, 469];
const TOL: i32 = 6;
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat")).expect("dat/")
.flatten().map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak")).collect();
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat"))
.expect("dat/")
.flatten()
.map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak"))
.collect();
paks.sort();
let (mut hits, mut scanned) = (0usize, 0usize);
for path in &paks {
let Ok(ar) = pak::PakArchive::open(path) else { continue };
let arch = path.file_name().unwrap().to_string_lossy().to_string();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) { continue }
let Some(b) = ui_layout::parse_build(&by) else { continue };
scanned += 1;
// Any button-shaped record, not just `pcbtn`: a rival need not share the
// naming convention, and restricting by name would answer a narrower
// question than the one asked.
let mut rows: Vec<(String, i32)> = b.elements.iter()
.filter(|el| el.name.contains("btn"))
.filter_map(|el| el.rest().map(|r| (el.name.clone(), r.y)))
.collect();
if rows.is_empty() { continue }
rows.sort_by(|a, b| a.1.cmp(&b.1));
let ys: Vec<i32> = rows.iter().map(|r| r.1).collect();
let gaps: Vec<i32> = ys.windows(2).map(|w| w[1] - w[0]).collect();
if rows.len() == 4 && ys.iter().zip(WANT.iter()).all(|(a, b)| (a - b).abs() <= TOL) {
hits += 1;
println!(" {arch} entry {i:>2} {} record(s): {}", rows.len(),
rows.iter().map(|r| r.0.as_str()).collect::<Vec<_>>().join(" "));
println!(" rows {ys:?} gaps {gaps:?}");
let Ok(ar) = pak::PakArchive::open(path) else {
continue;
};
let arch = path.file_name().unwrap().to_string_lossy().to_string();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
scanned += 1;
// Any button-shaped record, not just `pcbtn`: a rival need not share the
// naming convention, and restricting by name would answer a narrower
// question than the one asked.
let mut rows: Vec<(String, i32)> = b
.elements
.iter()
.filter(|el| el.name.contains("btn"))
.filter_map(|el| el.rest().map(|r| (el.name.clone(), r.y)))
.collect();
if rows.is_empty() {
continue;
}
rows.sort_by_key(|r| r.1);
let ys: Vec<i32> = rows.iter().map(|r| r.1).collect();
let gaps: Vec<i32> = ys.windows(2).map(|w| w[1] - w[0]).collect();
if rows.len() == 4
&& ys
.iter()
.zip(WANT.iter())
.all(|(a, b)| (a - b).abs() <= TOL)
{
hits += 1;
println!(
" {arch} entry {i:>2} {} record(s): {}",
rows.len(),
rows.iter()
.map(|r| r.0.as_str())
.collect::<Vec<_>>()
.join(" ")
);
println!(" rows {ys:?} gaps {gaps:?}");
}
}
}
}
println!("\n {scanned} build(s) scanned across {} pak(s); {hits} match the",
paks.len());
println!(
"\n {scanned} build(s) scanned across {} pak(s); {hits} match the",
paks.len()
);
println!(" DIFFICULTY row signature within +/-{TOL} px.");
println!(" Expected: exactly 2 -- the EN/JP pair. More means a RIVAL exists and");
println!(" the geometric identification is not unique; fewer means this reader");

View File

@@ -8,31 +8,49 @@
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let disc =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let ar = PakArchive::open(format!("{disc}/dat/GP_TITLE.pak")).expect("open");
let e = &ar.entries()[4]; // entry 4 = the English title
let bundle = ar.read(e).expect("read");
let b = ui_layout::parse_build(&bundle).expect("parse");
println!("build has {} elements, {} records", b.elements.len(), b.records.len());
println!(
"build has {} elements, {} records",
b.elements.len(),
b.records.len()
);
let mut names: Vec<&String> = b.records.keys().collect();
names.sort();
println!("records: {names:?}");
for el in &b.elements {
if !el.name.starts_with("ptloop") { continue; }
if !el.name.starts_with("ptloop") {
continue;
}
let r = el.rest();
println!("\nPARENT {} sprite={:?} -> rest scale {:?} rot {:?}", el.name, el.sprite,
r.map(|r| (r.scale_x, r.scale_y)), r.map(|r| r.rotation_deg));
println!(
"\nPARENT {} sprite={:?} -> rest scale {:?} rot {:?}",
el.name,
el.sprite,
r.map(|r| (r.scale_x, r.scale_y)),
r.map(|r| r.rotation_deg)
);
if let Some(&(off, size)) = b.records.get(&el.name) {
match ui_layout::parse_build(&bundle[off..off + size]) {
Some(leaf) => {
println!(" LEAF {} parses: {} element(s)", el.name, leaf.elements.len());
println!(
" LEAF {} parses: {} element(s)",
el.name,
leaf.elements.len()
);
for le in &leaf.elements {
let lr = le.rest();
println!(" {:<20} rest scale {:?} rot {:?} pos {:?}",
println!(
" {:<20} rest scale {:?} rot {:?} pos {:?}",
le.name,
lr.map(|r| (r.scale_x, r.scale_y)),
lr.map(|r| r.rotation_deg),
lr.map(|r| (r.x, r.y)));
lr.map(|r| (r.x, r.y))
);
for k in &le.keyframes {
println!(" t={:?} scale=({},{}) rot={} pos=({},{}) fade={:#010x} u4={} u8={}",
k.time, k.scale_x, k.scale_y, k.rotation_deg, k.x, k.y,

View File

@@ -26,15 +26,14 @@
//! and adds the one they could not run: the same two, restricted to the records
//! **this port actually animates**. A disc-wide 0.00 % violation rate says
//! nothing about my six screens if all six sit in the exceptional tail.
use sylpheed_formats::{pak, ratc, ui_layout};
use std::collections::BTreeMap;
use sylpheed_formats::{pak, ratc, ui_layout};
/// The records the port animates: the plate glow, the five menu focus records,
/// and the title's two sweeps. Named rather than pattern-matched, because the
/// point is to check the ones that are shipped, not the ones that match a glob.
const SHIPPED: &[&str] = &[
"ptbtn00f", "ptbtn01f", "ptbtn02f", "ptbtn03f", "ptbtn04f", "ptbtn05f",
"ptloop01", "ptloop02",
"ptbtn00f", "ptbtn01f", "ptbtn02f", "ptbtn03f", "ptbtn04f", "ptbtn05f", "ptloop01", "ptloop02",
];
/// Which header word to read as the loop length. `0x08` is the decoded one;
@@ -44,14 +43,19 @@ const SHIPPED: &[&str] = &[
static mut OFFSET: usize = 8;
fn main() {
let off: usize = std::env::args().find_map(|a| a.strip_prefix("--offset=")
.and_then(|v| v.parse().ok())).unwrap_or(8);
let off: usize = std::env::args()
.find_map(|a| a.strip_prefix("--offset=").and_then(|v| v.parse().ok()))
.unwrap_or(8);
unsafe { OFFSET = off };
println!(" reading the loop length at header +0x{off:02x}");
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat")).expect("dat/")
.flatten().map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak")).collect();
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat"))
.expect("dat/")
.flatten()
.map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak"))
.collect();
paks.sort();
let (mut total, mut exact, mut holds, mut violations) = (0usize, 0usize, 0usize, 0usize);
@@ -59,14 +63,24 @@ fn main() {
let mut shipped: BTreeMap<String, (i64, i64)> = BTreeMap::new();
for p in &paks {
let Ok(ar) = pak::PakArchive::open(p) else { continue };
let Ok(ar) = pak::PakArchive::open(p) else {
continue;
};
for e in ar.entries() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) { continue }
let Some(b) = ui_layout::parse_build(&by) else { continue };
if !ratc::is_ratc(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
for (rn, &(o, s)) in &b.records {
if o + off + 4 > by.len() || o + s > by.len() { continue }
if &by[o..o + 4] != b"RATC" { continue }
if o + off + 4 > by.len() || o + s > by.len() {
continue;
}
if &by[o..o + 4] != b"RATC" {
continue;
}
// 🔴 THE FALSIFIER IS RUN AT NEIGHBOURING OFFSETS TOO. The
// Decoder's struct-layout control showed that a homogeneous
// repeated table type-checks at every field boundary, so an
@@ -77,15 +91,28 @@ fn main() {
// "confirmation" without asking whether it discriminates the
// OFFSET or merely the file.
let len = u32::from_be_bytes(by[o + off..o + off + 4].try_into().unwrap()) as i64;
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else { continue };
let maxt = lb.elements.iter()
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else {
continue;
};
let maxt = lb
.elements
.iter()
.flat_map(|el| el.keyframes.iter().filter_map(|k| k.time))
.max().unwrap_or(0) as i64;
if maxt == 0 { continue } // static: declares no cycle at all
.max()
.unwrap_or(0) as i64;
if maxt == 0 {
continue;
} // static: declares no cycle at all
total += 1;
let slack = len - maxt;
*slack_hist.entry(slack).or_default() += 1;
if slack == 0 { exact += 1 } else if slack > 0 { holds += 1 } else { violations += 1 }
if slack == 0 {
exact += 1
} else if slack > 0 {
holds += 1
} else {
violations += 1
}
let stem = rn.trim_end_matches(".rat");
if SHIPPED.contains(&stem) {
shipped.entry(stem.to_string()).or_insert((len, maxt));
@@ -95,36 +122,68 @@ fn main() {
}
println!("disc-wide, records with timed keyframes: {total}");
println!(" +08 == max t (exact) : {exact:5} {:5.1} %", pc(exact, total));
println!(" +08 > max t (a hold) : {holds:5} {:5.1} %", pc(holds, total));
println!(" +08 < max t <- FALSIFIER : {violations:5} {:5.2} %", pc(violations, total));
println!(
" +08 == max t (exact) : {exact:5} {:5.1} %",
pc(exact, total)
);
println!(
" +08 > max t (a hold) : {holds:5} {:5.1} %",
pc(holds, total)
);
println!(
" +08 < max t <- FALSIFIER : {violations:5} {:5.2} %",
pc(violations, total)
);
println!("\nslack distribution, most common first:");
let mut h: Vec<_> = slack_hist.iter().collect();
h.sort_by_key(|&(_, n)| std::cmp::Reverse(*n));
for (k, n) in h.iter().take(8) { println!(" slack {k:>6} : {n}"); }
for (k, n) in h.iter().take(8) {
println!(" slack {k:>6} : {n}");
}
println!("\nthe records THIS PORT animates:");
println!(" {:<12} {:>6} {:>7} {:>7}", "record", "+0x08", "max t", "slack");
println!(
" {:<12} {:>6} {:>7} {:>7}",
"record", "+0x08", "max t", "slack"
);
let (mut ship_exact, mut ship_hold, mut ship_bad) = (0, 0, 0);
for (n, (len, maxt)) in &shipped {
let slack = len - maxt;
match slack { 0 => ship_exact += 1, s if s > 0 => ship_hold += 1, _ => ship_bad += 1 }
println!(" {n:<12} {len:>6} {maxt:>7} {slack:>7}{}",
if slack < 0 { " 🔴 FALSIFIED" } else { "" });
match slack {
0 => ship_exact += 1,
s if s > 0 => ship_hold += 1,
_ => ship_bad += 1,
}
println!(
" {n:<12} {len:>6} {maxt:>7} {slack:>7}{}",
if slack < 0 { " 🔴 FALSIFIED" } else { "" }
);
}
println!("\n shipped: {ship_exact} exact, {ship_hold} hold, {ship_bad} falsified");
if shipped.len() < SHIPPED.len() {
let missing: Vec<_> = SHIPPED.iter().filter(|s| !shipped.contains_key(**s)).collect();
let missing: Vec<_> = SHIPPED
.iter()
.filter(|s| !shipped.contains_key(**s))
.collect();
println!(" ⚠️ not found on the disc: {missing:?} -- a name the port ships and");
println!(" this control never checked is worse than a violation it found.");
}
println!("\n verdict: {}", if ship_bad > 0 {
"🔴 the reading fails on a record the port animates -- do NOT adopt"
} else if ship_hold == 0 {
"⚠️ every shipped record is exact, so this port cannot tell loop length\n from max keyframe time -- adopting 120 would change nothing here"
} else {
"✅ falsifier clean and the field is non-trivial ON THE SHIPPED SET"
});
println!(
"\n verdict: {}",
if ship_bad > 0 {
"🔴 the reading fails on a record the port animates -- do NOT adopt"
} else if ship_hold == 0 {
"⚠️ every shipped record is exact, so this port cannot tell loop length\n from max keyframe time -- adopting 120 would change nothing here"
} else {
"✅ falsifier clean and the field is non-trivial ON THE SHIPPED SET"
}
);
}
fn pc(n: usize, d: usize) -> f64 { if d == 0 { 0.0 } else { 100.0 * n as f64 / d as f64 } }
fn pc(n: usize, d: usize) -> f64 {
if d == 0 {
0.0
} else {
100.0 * n as f64 / d as f64
}
}

View File

@@ -11,30 +11,49 @@
use sylpheed_formats::{pak, ratc, ui_layout};
fn main() {
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat")).expect("dat/")
.flatten().map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak")).collect();
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat"))
.expect("dat/")
.flatten()
.map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak"))
.collect();
paks.sort();
let (mut records, mut in_bounds, mut magic, mut parsed, mut timed) = (0, 0, 0, 0, 0);
let (mut untimed, mut all_at_zero) = (0usize, 0usize);
for p in &paks {
let Ok(ar) = pak::PakArchive::open(p) else { continue };
let Ok(ar) = pak::PakArchive::open(p) else {
continue;
};
for e in ar.entries() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) { continue }
let Some(b) = ui_layout::parse_build(&by) else { continue };
for (_, &(o, s)) in &b.records {
if !ratc::is_ratc(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
for &(o, s) in b.records.values() {
records += 1;
if o + 12 > by.len() || o + s > by.len() { continue }
if o + 12 > by.len() || o + s > by.len() {
continue;
}
in_bounds += 1;
if &by[o..o + 4] != b"RATC" { continue }
if &by[o..o + 4] != b"RATC" {
continue;
}
magic += 1;
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else { continue };
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else {
continue;
};
parsed += 1;
let maxt = lb.elements.iter()
let maxt = lb
.elements
.iter()
.flat_map(|el| el.keyframes.iter().filter_map(|k| k.time))
.max().unwrap_or(0);
.max()
.unwrap_or(0);
// 🔴 `maxt == 0` merges two different populations, and the
// Decoder's cause -- `.max()` returning `Some(0)` -- is only one
// of them. A record with NO timed keyframe has no largest
@@ -43,10 +62,16 @@ fn main() {
// content. Both of us called all 1 530 "the question has no
// meaning"; that is true of one group and an assumption about
// the other.
let any_timed = lb.elements.iter()
let any_timed = lb
.elements
.iter()
.any(|el| el.keyframes.iter().any(|k| k.time.is_some()));
if maxt == 0 {
if any_timed { all_at_zero += 1 } else { untimed += 1 }
if any_timed {
all_at_zero += 1
} else {
untimed += 1
}
continue;
}
timed += 1;
@@ -55,8 +80,10 @@ fn main() {
}
println!(" records declared by parse_build : {records}");
println!(" within the entry's bounds : {in_bounds}");
println!(" carrying the RATC magic : {magic} <- {} dropped here",
in_bounds - magic);
println!(
" carrying the RATC magic : {magic} <- {} dropped here",
in_bounds - magic
);
println!(" parsing as a nested build : {parsed}");
println!(" with a largest keyframe time > 0: {timed}");
println!(" of the {} excluded:", untimed + all_at_zero);

View File

@@ -11,18 +11,31 @@
use sylpheed_formats::{pak, ratc, ui_layout};
fn main() {
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let ar = pak::PakArchive::open(format!("{root}/dat/GP_TITLE.pak")).expect("GP_TITLE.pak");
let (mut total, mut hits, mut multipose) = (0usize, 0usize, 0usize);
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) { continue }
let Some(b) = ui_layout::parse_build(&by) else { continue };
if !ratc::is_ratc(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
for (name, &(o, s)) in &b.records {
if o + 12 > by.len() || o + s > by.len() || &by[o..o + 4] != b"RATC" { continue }
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else { continue };
let maxt = lb.elements.iter()
.flat_map(|el| el.keyframes.iter().filter_map(|k| k.time)).max().unwrap_or(0);
if o + 12 > by.len() || o + s > by.len() || &by[o..o + 4] != b"RATC" {
continue;
}
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else {
continue;
};
let maxt = lb
.elements
.iter()
.flat_map(|el| el.keyframes.iter().filter_map(|k| k.time))
.max()
.unwrap_or(0);
let len = ui_layout::loop_length_units(&by[o..o + s]).unwrap_or(0);
total += 1;
if maxt == 0 && len > 0 {
@@ -31,10 +44,19 @@ fn main() {
// to move between. All-at-t=0 with a single keyframe per element
// is visually inert however it is played.
let kf: usize = lb.elements.iter().map(|el| el.keyframes.len()).sum();
let multi = lb.elements.iter().filter(|el| el.keyframes.len() > 1).count();
if multi > 0 { multipose += 1 }
println!(" entry {i:>2} {name:<16} {len}-unit cycle, {kf} keyframe(s) \
across {} element(s), {multi} with >1 pose", lb.elements.len());
let multi = lb
.elements
.iter()
.filter(|el| el.keyframes.len() > 1)
.count();
if multi > 0 {
multipose += 1
}
println!(
" entry {i:>2} {name:<16} {len}-unit cycle, {kf} keyframe(s) \
across {} element(s), {multi} with >1 pose",
lb.elements.len()
);
}
}
}

View File

@@ -7,7 +7,8 @@ use std::process::Command;
use sylpheed_formats::{media, slb::VoiceLang};
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
let disc =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let src = media::DirectorySource::new(&disc);
for movie in ["ADV", "S00A", "RT01A"] {
let Some((s, e)) = media::resolve_movie_voice_region(&src, movie, VoiceLang::English)
@@ -16,7 +17,11 @@ fn main() {
continue;
};
let riffs = media::voice_region_riffs(&src, s, e).expect("riffs");
println!("{movie}: region [{s}, {e}) = {} bytes, {} chunk(s)", e - s, riffs.len());
println!(
"{movie}: region [{s}, {e}) = {} bytes, {} chunk(s)",
e - s,
riffs.len()
);
for (i, r) in riffs.iter().enumerate() {
let p = std::env::temp_dir().join(format!("vc_{movie}_{i}.xma.wav"));
std::fs::write(&p, r).unwrap();
@@ -28,7 +33,14 @@ fn main() {
.arg(&w)
.output();
let out = Command::new("ffprobe")
.args(["-v", "error", "-show_entries", "format=duration", "-of", "csv=p=0"])
.args([
"-v",
"error",
"-show_entries",
"format=duration",
"-of",
"csv=p=0",
])
.arg(&w)
.output()
.unwrap();

View File

@@ -109,6 +109,8 @@ pub struct BgmSpec {
pub loop_start_s: Option<f64>,
#[serde(default)]
pub loop_end_s: Option<f64>,
// Deserialised to model the sidecar schema, not read in Rust.
#[allow(dead_code)]
#[serde(default)]
pub loop_end_why: Option<serde_json::Value>,
#[serde(default)]
@@ -167,10 +169,9 @@ pub fn load(authored: &Path) -> Result<Option<Config>> {
#[serde(default)]
voice: BTreeMap<String, serde_json::Value>,
}
let raw = std::fs::read_to_string(&path)
.with_context(|| format!("read {}", path.display()))?;
let file: File = serde_json::from_str(&raw)
.with_context(|| format!("parse {}", path.display()))?;
let raw = std::fs::read_to_string(&path).with_context(|| format!("read {}", path.display()))?;
let file: File =
serde_json::from_str(&raw).with_context(|| format!("parse {}", path.display()))?;
// `_` is the house convention for a prose block explaining the section it
// sits in -- see `authored/flow.json` and `authored/timing.json`. It is
@@ -209,9 +210,12 @@ pub fn load(authored: &Path) -> Result<Option<Config>> {
let size: usize = k
.parse()
.with_context(|| format!("authored/audio.json: voice.stream_weights key {k}"))?;
let w = v.get("weight").and_then(serde_json::Value::as_f64).with_context(|| {
format!("authored/audio.json: voice.stream_weights.{k} has no numeric weight")
})?;
let w = v
.get("weight")
.and_then(serde_json::Value::as_f64)
.with_context(|| {
format!("authored/audio.json: voice.stream_weights.{k} has no numeric weight")
})?;
stream_weights.insert(size, w);
}
}
@@ -280,8 +284,16 @@ fn run_ffmpeg(argv: &[String], out: &Path) -> Result<()> {
// temp name -- it is a hard failure before a byte is written: "Unable to
// choose an output format". `video.rs` already had this shape; this
// function was written from scratch and did not.
let stem = out.file_stem().unwrap_or_default().to_string_lossy().into_owned();
let ext = out.extension().unwrap_or_default().to_string_lossy().into_owned();
let stem = out
.file_stem()
.unwrap_or_default()
.to_string_lossy()
.into_owned();
let ext = out
.extension()
.unwrap_or_default()
.to_string_lossy()
.into_owned();
let partial = out.with_file_name(format!(".{stem}.partial.{ext}"));
let mut argv = argv.to_vec();
let last = argv.len() - 1;
@@ -326,8 +338,12 @@ fn measure(path: &Path) -> (Option<f32>, Option<f32>) {
.find_map(|l| l.split_once(KEY)?.1.trim().parse().ok());
let dur = Command::new("ffprobe")
.args([
"-v", "error", "-show_entries", "format=duration",
"-of", "csv=p=0",
"-v",
"error",
"-show_entries",
"format=duration",
"-of",
"csv=p=0",
])
.arg(path)
.output()
@@ -366,7 +382,12 @@ pub fn export_cues<S: DiscSource + ?Sized>(
// short read rather than returning a truncated stream, because a
// truncated XMA decodes to plausible-sounding garbage.
let riff = media::se_wave_riff(
source, &cue.bank, offset, cue.packets, cue.channels, cue.rate,
source,
&cue.bank,
offset,
cue.packets,
cue.channels,
cue.rate,
)
.map_err(anyhow::Error::msg)
.with_context(|| format!("assemble the {event} cue"))?;
@@ -374,9 +395,16 @@ pub fn export_cues<S: DiscSource + ?Sized>(
let staged = stage_riff(&dir, event, &riff)?;
let ogg = dir.join(format!("{event}.ogg"));
let argv: Vec<String> = [
"-hide_banner", "-loglevel", "error", "-y",
"-i", &staged.display().to_string(),
"-c:a", "libvorbis", "-q:a", VORBIS_Q,
"-hide_banner",
"-loglevel",
"error",
"-y",
"-i",
&staged.display().to_string(),
"-c:a",
"libvorbis",
"-q:a",
VORBIS_Q,
&ogg.display().to_string(),
]
.iter()
@@ -535,9 +563,15 @@ pub fn export_bgm<S: DiscSource + ?Sized>(
argv.push(format!("{end}"));
}
argv.extend(
["-c:a", "libvorbis", "-q:a", VORBIS_Q, &ogg.display().to_string()]
.iter()
.map(|s| s.to_string()),
[
"-c:a",
"libvorbis",
"-q:a",
VORBIS_Q,
&ogg.display().to_string(),
]
.iter()
.map(|s| s.to_string()),
);
let command = format!("ffmpeg {}", argv.join(" "));
run_ffmpeg(&argv, &ogg)?;
@@ -909,7 +943,10 @@ pub fn export_voice<S: DiscSource + ?Sized>(
// 238-packet late start was found. Applied positionally instead, the
// weights would have gone onto the wrong streams in silence.
let sizes: Vec<usize> = keep.iter().map(|&i| riffs[i].len() - RIFF_HEADER).collect();
let ws: Option<Vec<f64>> = sizes.iter().map(|s| stream_weights.get(s).copied()).collect();
let ws: Option<Vec<f64>> = sizes
.iter()
.map(|s| stream_weights.get(s).copied())
.collect();
match ws {
Some(w) if w.len() == staged.len() => {
// Weights sum to one, so the total is the movie's own and what
@@ -935,9 +972,15 @@ pub fn export_voice<S: DiscSource + ?Sized>(
argv.push("-map".into());
argv.push("[a]".into());
argv.extend(
["-c:a", "libvorbis", "-q:a", VORBIS_Q, &ogg.display().to_string()]
.iter()
.map(|s| s.to_string()),
[
"-c:a",
"libvorbis",
"-q:a",
VORBIS_Q,
&ogg.display().to_string(),
]
.iter()
.map(|s| s.to_string()),
);
let command = format!("ffmpeg {}", argv.join(" "));
run_ffmpeg(&argv, &ogg)?;
@@ -1037,8 +1080,14 @@ pub fn export_voice<S: DiscSource + ?Sized>(
fn probe_channels(path: &Path) -> Option<u8> {
let out = Command::new("ffprobe")
.args([
"-v", "error", "-select_streams", "a:0",
"-show_entries", "stream=channels", "-of", "csv=p=0",
"-v",
"error",
"-select_streams",
"a:0",
"-show_entries",
"stream=channels",
"-of",
"csv=p=0",
])
.arg(path)
.output()
@@ -1054,8 +1103,12 @@ fn probe_channels(path: &Path) -> Option<u8> {
pub fn probe_duration(path: &Path) -> Option<f32> {
let out = Command::new("ffprobe")
.args([
"-v", "error", "-show_entries", "format=duration",
"-of", "csv=p=0",
"-v",
"error",
"-show_entries",
"format=duration",
"-of",
"csv=p=0",
])
.arg(path)
.output()
@@ -1092,7 +1145,6 @@ fn decoded_chunk(riff: &Path) -> (f32, f32) {
out
}
/// Which channel indices of a decoded stream are not digitally silent.
///
/// `astats` reports per-channel blocks: a `Channel: N` line followed by that

View File

@@ -50,8 +50,9 @@ impl Ctx {
/// name. Anything else means a consumer has to guess, which is the whole thing
/// the format exists to prevent.
fn is_hex32(v: Option<&Value>) -> bool {
v.and_then(Value::as_str)
.is_some_and(|s| s.len() == 10 && s.starts_with("0x") && s[2..].chars().all(|c| c.is_ascii_hexdigit()))
v.and_then(Value::as_str).is_some_and(|s| {
s.len() == 10 && s.starts_with("0x") && s[2..].chars().all(|c| c.is_ascii_hexdigit())
})
}
fn check_pose(c: &mut Ctx, where_: &str, p: &Value) {
@@ -89,12 +90,17 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
// an invented one, so the provenance is mandatory and closed.
match v.get("name_source").and_then(Value::as_str) {
Some("authored") => {
if v.get("name_why").and_then(Value::as_str).is_none_or(str::is_empty) {
if v.get("name_why")
.and_then(Value::as_str)
.is_none_or(str::is_empty)
{
c.err("name_source is `authored` but there is no `name_why`");
}
}
Some("index") => {}
other => c.err(format!("name_source must be `authored` or `index`, got {other:?}")),
other => c.err(format!(
"name_source must be `authored` or `index`, got {other:?}"
)),
}
if let Some(s) = v.get("source") {
for key in ["archive", "entry", "build"] {
@@ -119,9 +125,22 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
let mut indices = Vec::new();
let mut buttons_by_y: Vec<(i64, String)> = Vec::new();
for (i, el) in elements.iter().enumerate() {
let id = el.get("id").and_then(Value::as_str).unwrap_or("<no id>").to_string();
let id = el
.get("id")
.and_then(Value::as_str)
.unwrap_or("<no id>")
.to_string();
let at = format!("element {i} ({id})");
for key in ["index", "id", "declared", "role", "kind_raw", "pivot", "layer_source", "keyframes"] {
for key in [
"index",
"id",
"declared",
"role",
"kind_raw",
"pivot",
"layer_source",
"keyframes",
] {
if el.get(key).is_none() {
c.err(format!("{at}: missing `{key}`"));
}
@@ -131,7 +150,9 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
continue;
};
if idx as usize != i {
c.err(format!("{at}: `index` {idx} does not match its position {i}"));
c.err(format!(
"{at}: `index` {idx} does not match its position {i}"
));
}
indices.push(idx as usize);
@@ -152,15 +173,21 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
match el.get("layer_source").and_then(Value::as_str) {
Some("sprite") | Some("implied") => {
if !is_hex32(el.get("layer")) {
c.err(format!("{at}: layer_source claims a key but `layer` is not one"));
c.err(format!(
"{at}: layer_source claims a key but `layer` is not one"
));
}
}
Some("none") => {
if el.get("layer").is_some() {
c.err(format!("{at}: layer_source `none` but a `layer` is present"));
c.err(format!(
"{at}: layer_source `none` but a `layer` is present"
));
}
}
other => c.err(format!("{at}: layer_source must be sprite/implied/none, got {other:?}")),
other => c.err(format!(
"{at}: layer_source must be sprite/implied/none, got {other:?}"
)),
}
for key in ["sprite", "focus_sprite"] {
@@ -169,7 +196,9 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
if !path.exists() {
c.err(format!("{at}: `{key}` points at {p}, which does not exist"));
} else if let Err(e) = image::open(&path) {
c.err(format!("{at}: `{key}` {p} does not decode as an image: {e}"));
c.err(format!(
"{at}: `{key}` {p} does not decode as an image: {e}"
));
}
}
}
@@ -177,7 +206,11 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
if let Some(r) = el.get("rest") {
check_pose(&mut c, &at, r);
if role == "button" {
if let Some(y) = r.get("pos").and_then(Value::as_array).and_then(|a| a[1].as_i64()) {
if let Some(y) = r
.get("pos")
.and_then(Value::as_array)
.and_then(|a| a[1].as_i64())
{
buttons_by_y.push((y, id.clone()));
}
}
@@ -214,7 +247,10 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
// either drops an element or draws one twice.
match v.get("paint_order").and_then(Value::as_array) {
Some(po) => {
let mut got: Vec<usize> = po.iter().filter_map(|x| x.as_u64().map(|v| v as usize)).collect();
let mut got: Vec<usize> = po
.iter()
.filter_map(|x| x.as_u64().map(|v| v as usize))
.collect();
if got.len() != po.len() {
c.err("`paint_order` holds a non-integer");
}
@@ -256,7 +292,10 @@ fn check_screen(root: &Path, rel: &str, errors: &mut Vec<String>) -> Result<()>
pub fn run(root: &Path) -> Result<usize> {
let manifest_path = root.join("manifest.json");
if !manifest_path.exists() {
bail!("{} has no manifest.json — is that an export tree?", root.display());
bail!(
"{} has no manifest.json — is that an export tree?",
root.display()
);
}
let m: Value = serde_json::from_str(&std::fs::read_to_string(&manifest_path)?)?;
let mut errors = Vec::new();
@@ -328,9 +367,13 @@ fn check_audio(root: &Path, m: &Value, errors: &mut Vec<String>) {
errors.push(format!("manifest.json: audio `{name}` has no `{key}`"));
}
}
let Some(file) = a.get("file").and_then(Value::as_str) else { continue };
let Some(file) = a.get("file").and_then(Value::as_str) else {
continue;
};
if !root.join(file).exists() {
errors.push(format!("manifest.json: lists audio {file}, which does not exist"));
errors.push(format!(
"manifest.json: lists audio {file}, which does not exist"
));
continue;
}
match a.get("peak_dbfs").and_then(Value::as_f64) {

View File

@@ -14,8 +14,8 @@
mod audio;
mod check;
mod video;
mod screen;
mod video;
use anyhow::{Context, Result};
use clap::Parser;
@@ -158,11 +158,13 @@ fn load_names(authored: &Path) -> Result<NameMap> {
#[derive(serde::Deserialize)]
struct File {
archives: NameMap,
// Deserialised to model the on-disc schema, not read in Rust.
// Removing it would silently change what this struct accepts.
#[allow(dead_code)]
#[serde(default)]
also_export: AlsoExport,
}
let raw = std::fs::read_to_string(&path)
.with_context(|| format!("read {}", path.display()))?;
let raw = std::fs::read_to_string(&path).with_context(|| format!("read {}", path.display()))?;
Ok(serde_json::from_str::<File>(&raw)
.with_context(|| format!("parse {}", path.display()))?
.archives)
@@ -170,8 +172,7 @@ fn load_names(authored: &Path) -> Result<NameMap> {
/// Extra pak entries to export that `is_build` does not accept, keyed by
/// archive. AUTHORED, and each carries its own `why`.
type AlsoExport =
std::collections::BTreeMap<String, std::collections::BTreeMap<String, NameEntry>>;
type AlsoExport = std::collections::BTreeMap<String, std::collections::BTreeMap<String, NameEntry>>;
fn load_also_export(authored: &Path) -> Result<AlsoExport> {
let path = authored.join("screen_names.json");
@@ -183,8 +184,7 @@ fn load_also_export(authored: &Path) -> Result<AlsoExport> {
#[serde(default)]
also_export: AlsoExport,
}
let raw = std::fs::read_to_string(&path)
.with_context(|| format!("read {}", path.display()))?;
let raw = std::fs::read_to_string(&path).with_context(|| format!("read {}", path.display()))?;
Ok(serde_json::from_str::<File>(&raw)
.with_context(|| format!("parse {}", path.display()))?
.also_export)
@@ -208,9 +208,10 @@ fn load_also_export(authored: &Path) -> Result<AlsoExport> {
/// exactly four bundles and all four are real screens, with zero fragments. In
/// another archive it would not be, which is why this is an allow-list and not
/// a widened predicate.
fn screen_builds(ar: &PakArchive, also: Option<&std::collections::BTreeMap<String, NameEntry>>)
-> Vec<(usize, Vec<u8>)>
{
fn screen_builds(
ar: &PakArchive,
also: Option<&std::collections::BTreeMap<String, NameEntry>>,
) -> Vec<(usize, Vec<u8>)> {
let mut out = Vec::new();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(bytes) = ar.read(e) else { continue };
@@ -231,7 +232,11 @@ fn main() -> Result<()> {
} => run_export(&disc, &out, &authored),
Cmd::Check { out } => {
let n = check::run(&out)?;
println!("{} screen(s) in {} validate against sylpheed.screen/3", n, out.display());
println!(
"{} screen(s) in {} validate against sylpheed.screen/3",
n,
out.display()
);
Ok(())
}
}
@@ -275,7 +280,7 @@ fn run_export(disc: &Path, out: &Path, authored_dir: &Path) -> Result<()> {
// `video/` that this run did not claim, so a movie that stops being exported
// still stops existing.
if out.exists() {
for entry in std::fs::read_dir(&out).context("clear the output tree")? {
for entry in std::fs::read_dir(out).context("clear the output tree")? {
let entry = entry?;
if entry.file_name() == "video" {
continue;
@@ -288,7 +293,7 @@ fn run_export(disc: &Path, out: &Path, authored_dir: &Path) -> Result<()> {
.with_context(|| format!("clear {}", entry.path().display()))?;
}
}
std::fs::create_dir_all(&out)?;
std::fs::create_dir_all(out)?;
let archive = "dat/GP_TITLE.pak";
let pak = disc.join(archive);
@@ -315,7 +320,7 @@ fn run_export(disc: &Path, out: &Path, authored_dir: &Path) -> Result<()> {
None => (format!("build_{entry:02}"), "index", None),
};
let ex = screen::export_build(
&out,
out,
archive,
*entry,
build_idx,
@@ -391,12 +396,7 @@ fn run_export(disc: &Path, out: &Path, authored_dir: &Path) -> Result<()> {
Some(cfg) => {
let source = media::DirectorySource::new(disc);
for a in audio::export_cues(&source, out, &cfg.se)? {
println!(
" se {:<8} -> {} ({})",
a.name,
a.file,
describe(&a)
);
println!(" se {:<8} -> {} ({})", a.name, a.file, describe(&a));
audio.push(ManifestAudio::from(a));
}
for (role, spec) in &cfg.bgm {
@@ -458,7 +458,10 @@ fn run_export(disc: &Path, out: &Path, authored_dir: &Path) -> Result<()> {
// there is no `authored/audio.json` -- the voice binding is decoded,
// so the dialogue exports either way and only the choice defaults.
let want = audio_cfg.as_ref().map(|c| c.voice).unwrap_or_default();
let weights = audio_cfg.as_ref().map(|c| c.stream_weights.clone()).unwrap_or_default();
let weights = audio_cfg
.as_ref()
.map(|c| c.stream_weights.clone())
.unwrap_or_default();
match audio::export_voice(&source, out, stem, *len, want, &weights)? {
Some(a) => {
// 🔴 A TOP-LEVEL WARNING, not just a `why` on the entry. The
@@ -514,7 +517,6 @@ fn run_export(disc: &Path, out: &Path, authored_dir: &Path) -> Result<()> {
Ok(())
}
impl From<audio::Exported> for ManifestAudio {
fn from(a: audio::Exported) -> Self {
ManifestAudio {
@@ -557,7 +559,6 @@ fn describe(a: &audio::Exported) -> String {
}
}
/// Delete anything in `video/` this run did not produce.
///
/// `video/` is the one directory the wholesale wipe spares, so that the

View File

@@ -416,7 +416,6 @@ pub fn export_build(
Ok(true)
}
/// The highlighted twin of a sprite name: `ptbtn01.t32` → `ptbtn01f.t32`.
fn highlight_name(sprite: &str) -> Option<String> {
let (stem, ext) = sprite.rsplit_once('.')?;
@@ -460,7 +459,9 @@ pub fn export_build(
written: &mut std::collections::BTreeMap<String, ()>,
missing: &mut Vec<String>|
-> Result<Option<Focus>> {
let Some(&(off, size)) = b.records.get(rec) else { return Ok(None) };
let Some(&(off, size)) = b.records.get(rec) else {
return Ok(None);
};
let Some(leaf) = ui_layout::parse_build(&bundle[off..off + size]) else {
return Ok(None);
};
@@ -468,8 +469,13 @@ pub fn export_build(
for fe in &leaf.elements {
let sp: &str = fe.sprite.as_deref().unwrap_or(&fe.name);
let mut fsprite = None;
if write_from(&sprite_dir, written, sp, &bundle[off..off + size], &leaf.sprites)?
|| write_from(&sprite_dir, written, sp, bundle, &b.sprites)?
if write_from(
&sprite_dir,
written,
sp,
&bundle[off..off + size],
&leaf.sprites,
)? || write_from(&sprite_dir, written, sp, bundle, &b.sprites)?
{
fsprite = Some(sprite_rel(sp));
} else if sp.ends_with(".t32") {
@@ -481,8 +487,11 @@ pub fn export_build(
declared: fe.name.clone(),
sprite: fsprite,
blend_additive: ui_layout::blend_additive_by_name(
&leaf, &bundle[off..off + size], sp)
.or_else(|| ui_layout::blend_additive_by_name(&b, bundle, sp)),
&leaf,
&bundle[off..off + size],
sp,
)
.or_else(|| ui_layout::blend_additive_by_name(&b, bundle, sp)),
pivot: [fe.pivot_x, fe.pivot_y],
rest: Rest {
pos: [r.x, r.y],
@@ -533,9 +542,13 @@ pub fn export_build(
// into the leaf slice) or in the parent's.
let sp: &str = fe.sprite.as_deref().unwrap_or(&fe.name);
let mut fsprite = None;
if write_from(&sprite_dir, &mut written, sp,
&bundle[off..off + size], &leaf.sprites)?
|| write_from(&sprite_dir, &mut written, sp, bundle, &b.sprites)?
if write_from(
&sprite_dir,
&mut written,
sp,
&bundle[off..off + size],
&leaf.sprites,
)? || write_from(&sprite_dir, &mut written, sp, bundle, &b.sprites)?
{
fsprite = Some(sprite_rel(sp));
} else if sp.ends_with(".t32") {
@@ -547,8 +560,11 @@ pub fn export_build(
declared: fe.name.clone(),
sprite: fsprite,
blend_additive: ui_layout::blend_additive_by_name(
&leaf, &bundle[off..off + size], sp)
.or_else(|| ui_layout::blend_additive_by_name(&b, bundle, sp)),
&leaf,
&bundle[off..off + size],
sp,
)
.or_else(|| ui_layout::blend_additive_by_name(&b, bundle, sp)),
pivot: [fe.pivot_x, fe.pivot_y],
rest: Rest {
pos: [r.x, r.y],
@@ -575,7 +591,9 @@ pub fn export_build(
if !fes.is_empty() {
focus = Some(Focus {
record: rec,
loop_length_units: ui_layout::loop_length_units(&bundle[off..off + size]),
loop_length_units: ui_layout::loop_length_units(
&bundle[off..off + size],
),
elements: fes,
});
}
@@ -704,7 +722,6 @@ pub fn export_build(
})
}
/// The longest interval containing no keyframe time, over TOP-LEVEL elements.
///
/// See [`Screen::settle_window`] for why this is the settled instant and why
@@ -750,12 +767,12 @@ fn settle_window(elements: &[Element]) -> Option<[i64; 3]> {
Some([a, b, (a + b) / 2])
}
/// Alpha of one element at instant `t`, under the linear ramp the port uses.
fn alpha_at(e: &Element, t: i64) -> u8 {
let ks = &e.keyframes;
let a = |k: &Keyframe| (u32::from_str_radix(k.fade_argb.trim_start_matches("0x"), 16)
.unwrap_or(0) >> 24) as i64;
let a = |k: &Keyframe| {
(u32::from_str_radix(k.fade_argb.trim_start_matches("0x"), 16).unwrap_or(0) >> 24) as i64
};
let timed: Vec<&Keyframe> = ks.iter().filter(|k| k.t.is_some()).collect();
if timed.is_empty() {
return 0;
@@ -888,7 +905,9 @@ fn forced_backdrop_first(order: Vec<usize>, elements: &[Element], design: [u32;
.filter_map(|k| k.t)
.map(i64::from)
.collect();
let Some(&lo) = span.first() else { return false };
let Some(&lo) = span.first() else {
return false;
};
// 🔴 COVERAGE IS TESTED AT EACH INSTANT, NOT ONCE FROM `size`.
// Declared size alone is not what the element draws: scale is a
// percent per axis and it animates. `pbafc.prm` is the disc's own
@@ -921,9 +940,10 @@ fn forced_backdrop_first(order: Vec<usize>, elements: &[Element], design: [u32;
return false;
}
// Every OTHER element must be visible somewhere inside that span.
elements.iter().enumerate().all(|(j, o)| {
j == *i || opaque.iter().any(|&t| alpha_at(o, t) > 0)
})
elements
.iter()
.enumerate()
.all(|(j, o)| j == *i || opaque.iter().any(|&t| alpha_at(o, t) > 0))
})
.map(|(i, _)| i)
.collect();

View File

@@ -97,13 +97,22 @@ const DOWNMIX_51: &str = "pan=stereo|FL=0.4142*FL+0.2929*FC+0.2929*BL
fn channels(src: &Path) -> Result<u32> {
let out = Command::new("ffprobe")
.args([
"-v", "error", "-select_streams", "a:0",
"-show_entries", "stream=channels", "-of", "csv=p=0",
"-v",
"error",
"-select_streams",
"a:0",
"-show_entries",
"stream=channels",
"-of",
"csv=p=0",
])
.arg(src)
.output()
.context("run ffprobe -- is it on PATH?")?;
Ok(String::from_utf8_lossy(&out.stdout).trim().parse().unwrap_or(2))
Ok(String::from_utf8_lossy(&out.stdout)
.trim()
.parse()
.unwrap_or(2))
}
/// Duration and frame rate of a finished transcode, straight from the file.
@@ -119,7 +128,8 @@ fn probe_timebase(out: &Path) -> (f64, f64) {
if stream {
c.args(["-select_streams", "v:0"]);
}
c.args(["-show_entries", entries, "-of", "csv=p=0"]).arg(out);
c.args(["-show_entries", entries, "-of", "csv=p=0"])
.arg(out);
c.output()
.map(|o| String::from_utf8_lossy(&o.stdout).trim().to_string())
.unwrap_or_default()
@@ -136,10 +146,20 @@ fn probe_timebase(out: &Path) -> (f64, f64) {
fn args(src: &Path, out: &Path, channels: u32) -> Vec<String> {
let mut v: Vec<String> = [
"-hide_banner", "-loglevel", "error", "-y",
"-i", &src.display().to_string(),
"-c:v", "libtheora", "-q:v", "8",
"-c:a", "libvorbis", "-q:a", "5",
"-hide_banner",
"-loglevel",
"error",
"-y",
"-i",
&src.display().to_string(),
"-c:v",
"libtheora",
"-q:v",
"8",
"-c:a",
"libvorbis",
"-q:a",
"5",
]
.iter()
.map(|s| s.to_string())
@@ -268,7 +288,10 @@ pub fn transcode(disc: &Path, out: &Path, m: &Movie) -> Result<Option<Transcoded
// updates it. The explanation would be correct in the source and absent on
// disc, which is the same shape as every other documented-but-unexercised
// thing this port has had to find the hard way.
if std::fs::read_to_string(&stamp).map(|s| s != want).unwrap_or(true) {
if std::fs::read_to_string(&stamp)
.map(|s| s != want)
.unwrap_or(true)
{
std::fs::write(&stamp, &want)?;
}
let (duration_s, fps) = probe_timebase(&ogv);

View File

@@ -11,7 +11,12 @@ xdvdfs = { workspace = true }
binrw = { workspace = true }
flate2 = "1" # zlib/DEFLATE for IPFB "Z1" entries (miniz_oxide backend, WASM-safe)
ttf-parser = { version = "0.24", default-features = false, features = ["std", "opentype-layout"] } # font metadata (OTF/TTF/ttcf), WASM-safe
tokio = { workspace = true }
# tokio is a DEV dependency only (see [dev-dependencies] below). Every use in
# this crate is inside a `mod tests`: three runtime builders in ship.rs and one
# `#[tokio::test]` in xiso.rs. As a normal dependency it pulled `tokio/full`,
# whose `net` feature drags in `mio`, which does not build for wasm32 —
# error: This wasm target is unsupported by mio.
# so the unused dependency was breaking the WASM job.
futures = { workspace = true }
thiserror = { workspace = true }
anyhow = { workspace = true }

View File

@@ -0,0 +1,92 @@
use sylpheed_formats::{pak, ui_layout};
fn main() {
let mut a = std::env::args().skip(1);
let pk = a.next().unwrap();
let i: usize = a.next().unwrap().parse().unwrap();
let ar = pak::PakArchive::open(pk).unwrap();
let by = ar.read(&ar.entries()[i]).unwrap();
let b = ui_layout::parse_build(&by).unwrap();
println!(
"entry {i}: {} elements, {} records, {} sprites",
b.elements.len(),
b.records.len(),
b.sprites.len()
);
let mut rk: Vec<&String> = b.records.keys().collect();
rk.sort();
println!(" records: {:?}", rk);
for (rn, &(o, sz)) in &b.records {
if o + sz > by.len() {
continue;
}
let Some(lb) = ui_layout::parse_build(&by[o..o + sz]) else {
continue;
};
println!(" RECORD {rn}: {} elements", lb.elements.len());
for le in &lb.elements {
let lts: Vec<String> = le
.keyframes
.iter()
.map(|k| {
format!(
"t{}a{}",
k.time.map(|v| v as i64).unwrap_or(-1),
k.fade >> 24
)
})
.collect();
println!(
" [{}] {:<22} kind=0x{:<6x} {}",
le.index,
le.name,
le.kind,
lts.join(" ")
);
}
}
for e in &b.elements {
let ts: Vec<String> = e
.keyframes
.iter()
.map(|k| {
format!(
"t{}a{}",
k.time.map(|v| v as i64).unwrap_or(-1),
k.fade >> 24
)
})
.collect();
println!(
" [{}] {:<24} kind=0x{:<6x} {}",
e.index,
e.name,
e.kind,
ts.join(" ")
);
if let Some(&(o, s)) = b.records.get(&e.name) {
if o + s <= by.len() {
if let Some(lb) = ui_layout::parse_build(&by[o..o + s]) {
for le in &lb.elements {
let lts: Vec<String> = le
.keyframes
.iter()
.map(|k| {
format!(
"t{}a{}",
k.time.map(|v| v as i64).unwrap_or(-1),
k.fade >> 24
)
})
.collect();
println!(
" leaf {:<20} kind=0x{:<6x} {}",
le.name,
le.kind,
lts.join(" ")
);
}
}
}
}
}
}

View File

@@ -0,0 +1,27 @@
use sylpheed_formats::{pak, ui_layout};
fn main() {
let mut a = std::env::args().skip(1);
let pk = a.next().unwrap();
let ar = pak::PakArchive::open(pk).unwrap();
for t in a {
let i: usize = t.parse().unwrap();
let by = ar.read(&ar.entries()[i]).unwrap();
let b = ui_layout::parse_build(&by).unwrap();
println!("=== entry {i} ===");
let order = ui_layout::derived_paint_order(&b, &by);
for e in &b.elements {
let k = ui_layout::sprite_layer_key(&b, &by, e);
let pos = order.iter().position(|&x| x == e.index);
println!(
" [{}] {:<24} kind=0x{:<5x} sprite={:<24} key={:<12} paint#{:?}",
e.index,
e.name,
e.kind,
e.sprite.clone().unwrap_or_else(|| "<none>".into()),
k.map(|v| format!("0x{v:08x}"))
.unwrap_or_else(|| "NONE".into()),
pos
);
}
}
}

View File

@@ -0,0 +1,88 @@
use sylpheed_formats::{pak, ratc, ui_layout};
fn main() {
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let ar = pak::PakArchive::open(format!("{root}/dat/GP_READY_ROOM.pak")).unwrap();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let Some(p) = b.elements.iter().find(|el| el.name == "pbafc.prm") else {
continue;
};
println!("=== entry {i}: {} elements ===", b.elements.len());
println!(
" pbafc.prm pivot=({},{}) -> {}x{}",
p.pivot_x,
p.pivot_y,
p.pivot_x * 2,
p.pivot_y * 2
);
for k in &p.keyframes {
println!(
" t={:<5} fade={:08x} a={:<4} xy=({},{}) s={}/{}",
k.time.map(|v| v as i64).unwrap_or(-1),
k.fade,
k.fade >> 24,
k.x,
k.y,
k.scale_x,
k.scale_y
);
}
// what does it cover, and is anything visible while it is opaque?
let rest = p.rest().unwrap();
let (px, py, pw, ph) = (
rest.x,
rest.y,
(p.pivot_x * 2) as i32,
(p.pivot_y * 2) as i32,
);
println!(" its rect at rest: ({px},{py}) {pw}x{ph}");
let tmax = b
.elements
.iter()
.flat_map(|e| e.keyframes.iter().filter_map(|k| k.time))
.max()
.unwrap_or(0);
let op: Vec<u32> = (0..=tmax)
.filter(|&t| p.pose_at(t).map(|k| k.fade >> 24) == Some(255))
.collect();
println!(
" opaque at {} instants (t={:?}..{:?}) of 0..{tmax}",
op.len(),
op.first(),
op.last()
);
let mut cov = 0;
let mut vis = 0;
for o in &b.elements {
if o.index == p.index {
continue;
}
let Some(ok) = o.rest() else { continue };
let (ow, oh) = ((o.pivot_x * 2) as i32, (o.pivot_y * 2) as i32);
let overlap = (px + pw).min(ok.x + ow) - px.max(ok.x) > 0
&& (py + ph).min(ok.y + oh) - py.max(ok.y) > 0;
if !overlap {
continue;
}
cov += 1;
if op
.iter()
.any(|&t| o.pose_at(t).map(|k| k.fade >> 24).unwrap_or(0) > 0)
{
vis += 1;
if vis <= 6 {
println!(" covered AND visible while opaque: {}", o.name);
}
}
}
println!(" elements its rect covers: {cov}; visible while it is opaque: {vis}");
break;
}
}

View File

@@ -0,0 +1,38 @@
use sylpheed_formats::{pak, ui_layout};
fn main() {
let mut a = std::env::args().skip(1);
let pk = a.next().unwrap();
let ar = pak::PakArchive::open(pk).unwrap();
for t in a {
let i: usize = t.parse().unwrap();
let by = ar.read(&ar.entries()[i]).unwrap();
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let top = u32::from_be_bytes(by[8..12].try_into().unwrap());
println!("entry {i:2} TOP +08 = {top}");
let mut ks: Vec<&String> = b.records.keys().collect();
ks.sort();
for rn in ks {
let &(o, s) = b.records.get(rn).unwrap();
if o + 16 > by.len() {
continue;
}
let magic = &by[o..o + 4];
let h4 = u32::from_be_bytes(by[o + 4..o + 8].try_into().unwrap());
let h8 = u32::from_be_bytes(by[o + 8..o + 12].try_into().unwrap());
let maxt = ui_layout::parse_build(&by[o..o + s])
.map(|lb| {
lb.elements
.iter()
.flat_map(|e| e.keyframes.iter().filter_map(|k| k.time))
.max()
.unwrap_or(0)
})
.unwrap_or(0);
println!(" {rn:<24} magic={:?} +04={:08x}({:.1}) +08={h8:<6} max keyframe t={maxt} ratio={:.4}",
String::from_utf8_lossy(magic), h4, h4 as f64/65536.0,
if maxt>0 {h8 as f64/maxt as f64} else {0.0});
}
}
}

View File

@@ -29,7 +29,9 @@ fn main() {
paks.sort();
for p in &paks {
let Ok(arc) = PakArchive::open(p) else { continue };
let Ok(arc) = PakArchive::open(p) else {
continue;
};
for (i, e) in arc.entries().iter().enumerate() {
let Ok(b) = arc.read(e) else { continue };
if !find(&b, b"ACHIEVEMENTS_REQUIREMENTS") {

View File

@@ -0,0 +1,41 @@
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").unwrap());
println!("# Which elements the reference renderer now draws ADDITIVE, per screen.");
println!("# Source: T8aD +0x04 bit 0x02, docs/re/structures/ui-blend-mode-decoded.md.");
println!("# Generated after ui_layout::blit gained an additive path (2026-09-01).");
println!("# Before that change EVERY row below was drawn alpha-over by our renderer,");
println!("# which is why `verify-screen` was structurally incapable on these screens.");
for pak in ["GP_TITLE", "GP_OPTIONS"] {
let Ok(ar) = PakArchive::open(root.join(format!("dat/{pak}.pak"))) else {
continue;
};
let n = ar.entries().len();
for e in 0..n {
let Ok(by) = ar.read(&ar.entries()[e]) else {
continue;
};
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let mut add: Vec<&String> = b
.sprites
.keys()
.filter(|s| ui_layout::blend_additive_by_name(&b, &by, s) == Some(true))
.collect();
if add.is_empty() {
continue;
}
add.sort();
println!(
"\n{pak} entry {e} -- {} of {} sprites additive",
add.len(),
b.sprites.len()
);
for s in add {
println!(" {s}");
}
}
}
}

View File

@@ -0,0 +1,61 @@
//! Does `resolve_movie_voice_region` start LATE, and by exactly how much?
//!
//! The port agent's arithmetic: the running decoder's three `ADV` XMA contexts sum
//! to **3 584 000** payload bytes, but the resolved voice region is **3 114 352** —
//! 15 % too small to hold them. One of the two spans is not what the other thinks
//! it is, and the disc side is this crate's.
//!
//! The gap is exact. `ctx0` declares **632** packets (1 294 336 B); the leading
//! chunk the resolver yields has **394** (806 912 B). The difference is **238
//! packets = 487 424 B**, a whole number of packets — which is what a start offset
//! looks like, not corruption.
//!
//! So: walk the region start backwards and report where `to_xma_riffs` first
//! reproduces the decoder's own three sizes. The probe's byte_sizes are the
//! control — this is not free to fit, it either lands on them or it does not.
//!
//! cargo run -p sylpheed-formats --example adv_region_extend
use sylpheed_formats::media::{self, DirectorySource, DiscSource};
use sylpheed_formats::slb::{self, VoiceLang};
/// What the running decoder reported (docs/re/structures/voice-three-streams-are-concurrent.md).
const WANT: [usize; 3] = [1_294_336, 1_118_208, 1_171_456];
fn main() {
let disc = std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC");
let src = DirectorySource::new(std::path::PathBuf::from(&disc));
let (start, end) =
media::resolve_movie_voice_region(&src, "ADV", VoiceLang::English).expect("region");
println!("resolver says {start}..{end} ({} B)", end - start);
println!(
"decoder wants {:?} = {} B payload\n",
WANT,
WANT.iter().sum::<usize>()
);
for back_packets in [0usize, 100, 200, 237, 238, 239, 300, 400] {
let back = (back_packets * 2048) as u64;
if back > start {
continue;
}
let s = start - back;
let Ok(bytes) = src.read_segment_range("dat/sound", s, (end - s) as usize) else {
println!("-{back_packets:4} packets: unreadable");
continue;
};
let riffs = slb::to_xma_riffs(&bytes);
let sizes: Vec<usize> = riffs.iter().map(|r| r.len() - 60).collect();
let hit = sizes.len() == 3 && sizes.iter().zip(WANT.iter()).all(|(a, b)| a == b);
println!(
"-{back_packets:4} packets (start {s}): {} chunk(s) {:?}{}",
riffs.len(),
sizes,
if hit {
" <== MATCHES THE DECODER"
} else {
""
}
);
}
}

View File

@@ -0,0 +1,44 @@
//! Dump `ADV`'s voice chunks as RIFF/XMA, so each can be decoded and identified.
//!
//! `intro-audio-decomposed.md` measured that the intro's output is the movie's own
//! WMA Pro 5.1 track at 0.600 **plus** three streams occupying a front pair, a
//! centre (with a silent partner) and a rear pair. What it could **not** say is
//! *which* stream sits where — the assignment there is by position, not content.
//! The port needs that to weight a positional downmix.
//!
//! This writes the chunks out so they can be decoded (ffmpeg has `xma2`) and
//! correlated against the per-channel residuals.
//!
//! cargo run -p sylpheed-formats --example adv_voice_dump -- OUTDIR [MOVIE]
use sylpheed_formats::media::{self, DirectorySource, DiscSource};
use sylpheed_formats::slb::{self, VoiceLang};
fn main() {
let out = std::env::args().nth(1).expect("OUTDIR");
let movie = std::env::args().nth(2).unwrap_or_else(|| "ADV".into());
let disc = std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC");
let src = DirectorySource::new(std::path::PathBuf::from(&disc));
std::fs::create_dir_all(&out).expect("outdir");
let (start, end) =
media::resolve_movie_voice_region(&src, &movie, VoiceLang::English).expect("voice region");
let bytes = src
.read_segment_range("dat/sound", start, (end - start) as usize)
.expect("region");
println!("{movie}: region {start}..{end} = {} B", end - start);
let riffs = slb::to_xma_riffs(&bytes);
println!("{} RIFF chunk(s)", riffs.len());
for (i, r) in riffs.iter().enumerate() {
let p = format!("{out}/{movie}_{i}.xma");
std::fs::write(&p, r).expect("write");
// the probe reports `byte_size` = RIFF total - 60; print both so the
// dump can be tied to a specific XMA context by its own number
println!(
" chunk {i}: {} B byte_size-equivalent {} -> {p}",
r.len(),
r.len() as i64 - 60
);
}
}

View File

@@ -1,9 +1,18 @@
use sylpheed_formats::{game_data as gd, PakArchive};
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_HANGAR_ARSENAL.pak")).unwrap();
let a=gd::load_arsenal(&pak);
for (hp,list) in [("NOSE",&a.nose),("ARM1",&a.arm1),("ARM2",&a.arm2),("ARM3",&a.arm3)]{
println!("{hp} ({}): {:?}", list.len(), list.iter().take(8).collect::<Vec<_>>());
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_HANGAR_ARSENAL.pak")).unwrap();
let a = gd::load_arsenal(&pak);
for (hp, list) in [
("NOSE", &a.nose),
("ARM1", &a.arm1),
("ARM2", &a.arm2),
("ARM3", &a.arm3),
] {
println!(
"{hp} ({}): {:?}",
list.len(),
list.iter().take(8).collect::<Vec<_>>()
);
}
}

View File

@@ -0,0 +1,44 @@
//! List a sound bank's streams and their declared rates.
//!
//! cargo run -p sylpheed-formats --example bank_streams -- <disc> BGM_102.slb …
use sylpheed_formats::media::{self, DirectorySource};
use sylpheed_formats::{hash::name_hash, slb};
fn main() {
let mut a = std::env::args().skip(1);
let disc = a.next().expect("usage: bank_streams <disc> NAME.slb…");
let src = DirectorySource::new(std::path::PathBuf::from(&disc));
for name in a {
let h = name_hash(&name);
match media::read_sound_bank(&src, h) {
Ok(bytes) => {
let riffs = slb::to_xma_riffs(&bytes);
println!(
"{name} (hash {h:08x}, {} B on disc) header {:?} -> {} stream(s)",
bytes.len(),
slb::bank_header_len(&bytes),
riffs.len()
);
for (i, r) in riffs.iter().enumerate() {
let rate = if r.len() >= 0x28 {
u32::from_le_bytes(r[0x20..0x24].try_into().unwrap())
} else {
0
};
let payload = r.len() - 60;
println!(
" stream {i}: payload {payload} B ({} packets) declared {rate} B/s \
=> {:.3} s",
payload / 2048,
if rate > 0 {
payload as f64 / rate as f64
} else {
0.0
}
);
}
}
Err(e) => println!("{name}: {e}"),
}
}
}

View File

@@ -1,18 +1,38 @@
use sylpheed_formats::{game_data as gd, PakArchive};
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let units=gd::load_units(&pak); let vessels=gd::load_vessels(&pak);
let hp=|id:&str|->String{
units.iter().find(|u|u.id.as_deref()==Some(id)).and_then(|u|u.hp).map(|h|format!("{h:.0}hp"))
.or_else(||vessels.iter().find(|v|v.id.as_deref()==Some(id)).and_then(|v|v.hp).map(|h|format!("{h:.0}HP")))
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let units = gd::load_units(&pak);
let vessels = gd::load_vessels(&pak);
let hp = |id: &str| -> String {
units
.iter()
.find(|u| u.id.as_deref() == Some(id))
.and_then(|u| u.hp)
.map(|h| format!("{h:.0}hp"))
.or_else(|| {
vessels
.iter()
.find(|v| v.id.as_deref() == Some(id))
.and_then(|v| v.hp)
.map(|h| format!("{h:.0}HP"))
})
.unwrap_or("·".into())
};
let rosters=gd::load_unit_rosters(&pak);
for r in rosters.iter().filter(|r|r.stage.is_some()).take(4){
println!("\n{}{} combatants:", r.stage.as_deref().unwrap(), r.units.len());
for u in r.units.iter().filter(|u|u.contains("ADAN")).take(6){
let short=u.trim_start_matches("UN_").split('_').skip(1).collect::<Vec<_>>().join("_");
let rosters = gd::load_unit_rosters(&pak);
for r in rosters.iter().filter(|r| r.stage.is_some()).take(4) {
println!(
"\n{}{} combatants:",
r.stage.as_deref().unwrap(),
r.units.len()
);
for u in r.units.iter().filter(|u| u.contains("ADAN")).take(6) {
let short = u
.trim_start_matches("UN_")
.split('_')
.skip(1)
.collect::<Vec<_>>()
.join("_");
println!(" {short:32} {}", hp(u));
}
}

View File

@@ -8,13 +8,22 @@ fn main() {
let bytes = std::fs::read(&a[1]).unwrap();
let names = sylpheed_formats::mesh::xbg7_resource_names(&bytes);
let ids: Vec<String> = {
let mut v: Vec<String> = names.iter().filter(|n| is_base_part(n))
.filter_map(|n| ship_id_of(n).map(|s| s.to_string())).collect();
v.sort(); v.dedup(); v.truncate(5); v
let mut v: Vec<String> = names
.iter()
.filter(|n| is_base_part(n))
.filter_map(|n| ship_id_of(n).map(|s| s.to_string()))
.collect();
v.sort();
v.dedup();
v.truncate(5);
v
};
for id in &ids {
let want: HashSet<String> = names.iter()
.filter(|n| ship_id_of(n) == Some(id.as_str())).cloned().collect();
let want: HashSet<String> = names
.iter()
.filter(|n| ship_id_of(n) == Some(id.as_str()))
.cloned()
.collect();
let t = Instant::now();
let got = Xbg7Model::models_named(&bytes, &want, &|| false);
println!("{id}: {} models in {:?}", got.len(), t.elapsed());

View File

@@ -28,7 +28,10 @@ fn main() {
std::process::exit(1);
};
let (vc, ic) = markers[0];
println!("{name}: {} marker(s), first = {vc} verts / {ic} indices, stride {stride}", markers.len());
println!(
"{name}: {} marker(s), first = {vc} verts / {ic} indices, stride {stride}",
markers.len()
);
// Where did the decoder put it?
let ours = Xbg7Model::stage_models(&bytes)
@@ -38,7 +41,10 @@ fn main() {
println!("our anchor: {ours:?}");
let starts = debug_vertex_run_starts(&bytes, stride);
println!("{} candidate vertex-run starts for stride {stride}", starts.len());
println!(
"{} candidate vertex-run starts for stride {stride}",
starts.len()
);
// Score every (start, pad): degenerate triangles, winding against the stored
// normals, and whether the run covers the pool exactly.
@@ -67,12 +73,15 @@ fn main() {
]
})
.collect();
if pos.iter().any(|p| p.iter().any(|c| !c.is_finite() || c.abs() > 1e6)) {
if pos
.iter()
.any(|p| p.iter().any(|c| !c.is_finite() || c.abs() > 1e6))
{
continue;
}
let mut degen = 0usize;
let (mut agree, mut counted) = (0usize, 0usize);
for t in idx.chunks_exact(3) {
for t in idx.as_chunks::<3>().0 {
let (x, y, z) = (t[0] as usize, t[1] as usize, t[2] as usize);
if x == y || y == z || x == z {
degen += 1;
@@ -82,8 +91,16 @@ fn main() {
// stand-in so this stays declaration-agnostic: a consistent mesh
// has all faces pointing away from the centroid on a convex-ish
// hull. Weak, so degeneracy leads the sort.
let e1 = [pos[y][0] - pos[x][0], pos[y][1] - pos[x][1], pos[y][2] - pos[x][2]];
let e2 = [pos[z][0] - pos[x][0], pos[z][1] - pos[x][1], pos[z][2] - pos[x][2]];
let e1 = [
pos[y][0] - pos[x][0],
pos[y][1] - pos[x][1],
pos[y][2] - pos[x][2],
];
let e2 = [
pos[z][0] - pos[x][0],
pos[z][1] - pos[x][1],
pos[z][2] - pos[x][2],
];
let f = [
e1[1] * e2[2] - e1[2] * e2[1],
e1[2] * e2[0] - e1[0] * e2[2],
@@ -104,12 +121,19 @@ fn main() {
agree += 1;
}
}
let w = if counted == 0 { 0.0 } else { agree as f32 / counted as f32 };
let w = if counted == 0 {
0.0
} else {
agree as f32 / counted as f32
};
rows.push((degen, w.max(1.0 - w), vb, pad, max_idx, max_idx + 1 == vc));
}
}
rows.sort_by(|a, b| a.0.cmp(&b.0).then(b.1.total_cmp(&a.1)));
println!("\n{} in-range candidates; best 12 by (degenerate, winding):", rows.len());
println!(
"\n{} in-range candidates; best 12 by (degenerate, winding):",
rows.len()
);
for (d, w, vb, pad, mx, cov) in rows.iter().take(12) {
let mark = if Some(*vb) == ours { " <-- ours" } else { "" };
println!(

View File

@@ -0,0 +1,28 @@
//! Dump one BGM bank's waves as RIFF/XMA so they can be decoded and compared
//! against a capture of the running game.
//!
//! cargo run -p sylpheed-formats --example bgm_dump -- BGM_103.slb OUTDIR
use sylpheed_formats::media::{self, DirectorySource};
use sylpheed_formats::slb;
fn main() {
let name = std::env::args()
.nth(1)
.unwrap_or_else(|| "BGM_103.slb".into());
let out = std::env::args().nth(2).expect("OUTDIR");
let disc = std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC");
let src = DirectorySource::new(std::path::PathBuf::from(&disc));
std::fs::create_dir_all(&out).expect("outdir");
let h = sylpheed_formats::hash::name_hash(&name);
let bytes = media::read_sound_bank(&src, h).expect("bank");
println!("{name}: {} B", bytes.len());
for (i, r) in slb::to_xma_riffs(&bytes).iter().enumerate() {
let p = format!("{out}/{}_{i}.xma", name.trim_end_matches(".slb"));
std::fs::write(&p, r).expect("write");
println!(
" wave {i}: {} B (byte_size {}) -> {p}",
r.len(),
r.len() - 60
);
}
}

View File

@@ -0,0 +1,106 @@
//! Does a screen declare its own OPAQUE BLACK backdrop? Disc-wide.
//!
//! `sylpheed-port` observed that the splash builds declare `palogo_eff0.prm` as a
//! full-screen primitive at t=0 with `fade_argb 0xff000000` -- alpha 255 over RGB
//! 000000 -- and turned it into a candidate predicate: a declared opaque-black
//! backdrop separates STANDALONE screens from COMPOSITED ones. On their sixteen
//! exported screens it splits 12 / 4, with all four exceptions independently known
//! to be composited (the two `press_start` plates, and two loading builds that
//! carry the `pgloading_*` set without its backdrop).
//!
//! That matters because the corpus previously told them "no content rule exists,
//! take the entry index" -- correct for the question asked (recognise the splash),
//! but this is a content rule for a different and useful question. They asked for
//! it to be tested against an archive they do not have. This is that test.
//!
//! CONTROL: it must reproduce the 12/4 split on GP_TITLE's sixteen composable
//! bundles before its disc-wide numbers mean anything.
//!
//! cargo run -p sylpheed-formats --example black_backdrop_predicate
use std::io::Write;
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
/// A screen declares its own backdrop if some `.prm` primitive holds
/// `fade == 0xff000000` at t = 0: full alpha over black.
fn has_black_backdrop(b: &ui_layout::UiBuild) -> Option<String> {
for el in &b.elements {
if !el.name.ends_with(".prm") {
continue;
}
if let Some(k) = el.keyframes.iter().find(|k| k.time == Some(0)) {
if k.fade == 0xff00_0000 {
return Some(el.name.clone());
}
}
}
None
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
println!("== CONTROL: GP_TITLE's 16 composable bundles (port reports 12 with, 4 without)");
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE.pak");
let (mut y, mut n) = (0, 0);
for e in 0..16usize {
let Ok(by) = ar.read(&ar.entries()[e]) else {
continue;
};
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
match has_black_backdrop(&b) {
Some(nm) => {
y += 1;
println!(" entry {e:>2} YES {nm}")
}
None => {
n += 1;
println!(" entry {e:>2} no")
}
}
}
println!(" -> {y} with, {n} without\n");
println!("== DISC-WIDE, over every screen build");
let mut paks: Vec<PathBuf> = std::fs::read_dir(root.join("dat"))
.expect("dat/")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().is_some_and(|x| x == "pak"))
.collect();
paks.sort();
let (mut tot, mut with) = (0usize, 0usize);
for pak in &paks {
let Ok(ar) = PakArchive::open(pak) else {
continue;
};
let name = pak.file_name().unwrap().to_string_lossy().to_string();
let (mut t, mut w) = (0usize, 0usize);
for e in ar.entries() {
let Ok(by) = ar.read(e) else { continue };
if !ui_layout::is_build(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
t += 1;
if has_black_backdrop(&b).is_some() {
w += 1
}
}
if t > 0 {
println!("{name:30} {w:4} / {t:<4} declare a black backdrop");
std::io::stdout().flush().ok();
}
tot += t;
with += w;
}
println!(
"\n{with} of {tot} screen builds disc-wide declare an opaque-black backdrop \
({:.1} %)",
100.0 * with as f64 / tot as f64
);
println!("--- END ---");
}

View File

@@ -0,0 +1,107 @@
//! Control for the new public accessor `ui_layout::sprite_blend_additive`.
//!
//! `blend_vs_t8ad_bit` established the field by reading the `T8aD` header inline.
//! The exporter cannot do that — `Element` exposed nothing at `+0x04`, which is
//! why a blend map keyed by SCREEN NAME had to be authored, and why the Japanese
//! menus were being asserted-by-omission to blend differently from the English
//! ones. This checks the accessor the exporter will actually call, against the
//! same 35 oracle rows, so a later refactor cannot silently change the field.
//!
//! cargo run -p sylpheed-formats --example blend_api_check
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
/// (build entry, sprite, measured additive?) — from `data/blend-bit-vs-oracle.txt`,
/// every label an `RB_BLENDCONTROL0` value read out of the guest command stream.
const MEASURED: &[(usize, &str, bool)] = &[
(4, "ptbase2.t32", false),
(4, "ptlogo1.t32", false),
(4, "ptlogo2.t32", false),
(4, "ptlogo_tm.t32", false),
(4, "ptcopyright.t32", false),
(4, "ptlogo_back2.t32", false),
(4, "ptlogo_back2eff.t32", false),
(2, "ptbtn00.t32", false),
(2, "ptbtn00f.t32", true),
(5, "ptbase.t32", false),
(5, "ptmsg.t32", false),
(5, "ptbtn01f.t32", false),
(5, "ptbtneff01.t32", false),
(5, "pteff10.t32", true),
(5, "pteff12.t32", true),
(6, "pteff21.t32", true),
(6, "pteff22.t32", true),
(6, "pteff23.t32", true),
(6, "ptframe3.t32", true),
(6, "ptframe4.t32", true),
(6, "pteff03.t32", true),
(6, "pteff03a.t32", true),
];
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
let (mut ok, mut bad, mut missing) = (0, 0, 0);
println!(
"{:<7} {:<22} {:<10} {:<10} ",
"entry", "sprite", "expected", "accessor"
);
for e in [2usize, 4, 5, 6] {
let by = ar.read(&ar.entries()[e]).expect("entry");
let b = ui_layout::parse_build(&by).expect("build");
for &(oe, name, additive) in MEASURED {
if oe != e {
continue;
}
// Prefer the Element accessor; fall back to the by-name one for
// focused variants, which are reached through `opt ` and carry no
// top-level element of their own.
let got = b
.elements
.iter()
.find(|x| x.sprite.as_deref() == Some(name))
.and_then(|el| ui_layout::sprite_blend_additive(&b, &by, el))
.or_else(|| ui_layout::blend_additive_by_name(&b, &by, name));
if got.is_none() {
println!("{e:<7} {name:<22} {additive:<10} {:<10} MISSING", "-");
missing += 1;
continue;
}
match got {
Some(g) if g == additive => {
ok += 1;
println!("{e:<7} {name:<22} {additive:<10} {g:<10} OK");
}
other => {
bad += 1;
println!("{e:<7} {name:<22} {additive:<10} {other:?} MISMATCH");
}
}
}
}
println!(
"\n{ok} agree, {bad} mismatched, {missing} not found (of {})",
MEASURED.len()
);
// The control that removes the test's own subject: the accessor must also
// report a MIX. An accessor stuck at one value would pass every `false` row.
let by = ar.read(&ar.entries()[6]).expect("entry");
let b = ui_layout::parse_build(&by).expect("build");
let add = b
.elements
.iter()
.filter(|e| ui_layout::sprite_blend_additive(&b, &by, e) == Some(true))
.count();
let over = b
.elements
.iter()
.filter(|e| ui_layout::sprite_blend_additive(&b, &by, e) == Some(false))
.count();
println!("control -- entry 6 must report BOTH values: additive={add} alpha-over={over}");
assert!(add > 0 && over > 0, "accessor is not discriminating");
assert_eq!(
bad, 0,
"the public accessor disagrees with the committed oracle"
);
println!("PASS");
}

View File

@@ -0,0 +1,61 @@
//! A PREDICTION, written before the capture that tests it.
//!
//! `blend_vs_t8ad_bit` finds that `T8aD +0x04` bit `0x02` separates additive from
//! alpha-over on all 35 elements whose blend has been measured off the GPU, and
//! that no other bit of the 48-byte header does. That is a fit to three screens.
//!
//! The developer splash (`GP_TITLE` entries 10 and 13) has **never been captured**
//! and is one of the five screens the port ships. This prints what the bit says
//! its elements should be, so the capture can falsify it rather than confirm it.
//!
//! Takes an archive and a build list, so the prediction can be written for any
//! screen -- including one in a DIFFERENT pak, which is the sharper test: the
//! splash predicts alpha-over for both its elements and so can only fail, never
//! discriminate, while a screen with a predicted MIX can do both.
//!
//! cargo run -p sylpheed-formats --example blend_prediction_splash
//! cargo run -p sylpheed-formats --example blend_prediction_splash -- GP_OPTIONS 0 1 2
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let args: Vec<String> = std::env::args().skip(1).collect();
let pak = args
.iter()
.find(|a| a.parse::<usize>().is_err())
.cloned()
.unwrap_or_else(|| "GP_TITLE".to_string());
let ar = PakArchive::open(root.join(format!("dat/{pak}.pak"))).expect("pak");
let builds: Vec<usize> = args.iter().filter_map(|a| a.parse().ok()).collect();
let builds = if builds.is_empty() {
(0..ar.entries().len()).collect()
} else {
builds
};
for e in builds {
let Ok(by) = ar.read(&ar.entries()[e]) else {
continue;
};
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
println!("=== {pak} entry {e} ===");
let mut names: Vec<&String> = b.sprites.keys().collect();
names.sort();
for n in names {
let (off, size) = b.sprites[n];
let s = &by[off..(off + size).min(by.len())];
if s.len() < 8 || &s[0..4] != b"T8aD" {
continue;
}
let w = u32::from_be_bytes([s[4], s[5], s[6], s[7]]);
println!(
"{n:<26} +0x04 = {w:08X} bit 0x02 {} PREDICT {}",
if w & 2 != 0 { "SET " } else { "clear" },
if w & 2 != 0 { "ADDITIVE" } else { "alpha-over" }
);
}
println!();
}
}

View File

@@ -0,0 +1,298 @@
//! Does `T8aD +0x04` bit `0x02` predict the blend the GAME uses?
//!
//! ⚠️ **`REFUTED.md` kills this claim**: *"`T8aD +0x04` bit `0x02` selects an
//! additive blend" → mine, and refuted. Blending those sprites additively
//! worsens every measure against the capture.* That refutation rests entirely on
//! **our renderer** — it is a claim about our renderer, and the corpus's own rule
//! says so. Since it was written, the blend has been measured off the GPU per
//! draw on three screens (`structures/ui-blend-mode-measured.md`), so the claim
//! can now be tested against the oracle instead of against a render.
//!
//! The labels below are **not** from a render. Every one is a
//! `RB_BLENDCONTROL0` value read out of the guest command stream and attributed
//! to an element by quad size:
//! `data/ui-blend-mode-measured.txt`, `data/ui-blend-title-and-replication.txt`,
//! `data/ui-blend-extras-complete.txt`.
//!
//! cargo run -p sylpheed-formats --example blend_vs_t8ad_bit
use std::collections::BTreeMap;
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
/// (build entry, sprite, measured additive?) — the oracle's verdicts, verbatim.
const MEASURED: &[(usize, &str, bool)] = &[
// --- GP_TITLE entry 4 + 2, the live title -------------------------------
(4, "ptbase2.t32", false),
(4, "ptlogo1.t32", false),
(4, "ptlogo2.t32", false),
(4, "ptlogo_tm.t32", false),
(4, "ptcopyright.t32", false),
(4, "ptlogo_back2.t32", false),
(4, "ptlogo_back2eff.t32", false),
(2, "ptbtn00.t32", false),
(2, "ptbtn00f.t32", true),
// --- entry 5, the main menu ---------------------------------------------
(5, "ptbase.t32", false),
(5, "ptmsg.t32", false),
(5, "ptbtn01f.t32", false),
(5, "ptbtneff01.t32", false),
(5, "pteff10.t32", true),
(5, "pteff12.t32", true),
(5, "ptframe1.t32", true),
(5, "ptframe2.t32", true),
(5, "pteff03.t32", true), // the rotated sweep strips, via ptloop01/02
(5, "pteff03a.t32", true),
// --- entry 6, EXTRAS ------------------------------------------------------
(6, "ptbase.t32", false),
(6, "ptmsg2.t32", false),
(6, "pttitle.t32", false),
(6, "ptbtn11f.t32", false),
(6, "ptbtn12.t32", false),
(6, "ptbtn13.t32", false),
(6, "ptbtneff02.t32", false),
(6, "pteff10.t32", true),
(6, "pteff20.t32", true),
(6, "pteff21.t32", true),
(6, "pteff22.t32", true),
(6, "pteff23.t32", true),
(6, "ptframe3.t32", true),
(6, "ptframe4.t32", true),
(6, "pteff03.t32", true),
(6, "pteff03a.t32", true),
];
fn main() {
if std::env::args().any(|a| a == "decl") {
decl_rivals();
return;
}
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
let mut hdr: BTreeMap<(usize, String), u32> = BTreeMap::new();
for e in [2usize, 4, 5, 6] {
let by = ar.read(&ar.entries()[e]).expect("entry");
let b = ui_layout::parse_build(&by).expect("build");
for (n, &(off, size)) in &b.sprites {
let s = &by[off..(off + size).min(by.len())];
if s.len() < 8 || &s[0..4] != b"T8aD" {
continue;
}
hdr.insert((e, n.clone()), u32::from_be_bytes([s[4], s[5], s[6], s[7]]));
}
}
println!(
"{:<10} {:<22} {:<10} {:>10} measured blend",
"entry", "sprite", "+0x04", "bit 0x02"
);
let (mut tp, mut tn, mut fp, mut fnn, mut missing) = (0, 0, 0, 0, 0);
for &(e, n, additive) in MEASURED {
let Some(&w) = hdr.get(&(e, n.to_string())) else {
println!(
"{e:<10} {n:<22} {:<10} {:>10} {}",
"MISSING",
"-",
if additive { "ADDITIVE" } else { "alpha-over" }
);
missing += 1;
continue;
};
let bit = w & 0x02 != 0;
match (bit, additive) {
(true, true) => tp += 1,
(false, false) => tn += 1,
(true, false) => fp += 1,
(false, true) => fnn += 1,
}
println!(
"{e:<10} {n:<22} {:08X} {:>10} {}{}",
w,
bit,
if additive { "ADDITIVE" } else { "alpha-over" },
if bit == additive {
""
} else {
" <== DISAGREES"
}
);
}
println!("\nbit set & additive {tp}");
println!("bit clear & alpha-over {tn}");
println!("bit set & alpha-over {fp} <- false positives");
println!("bit clear & additive {fnn} <- false negatives");
println!("sprite not found {missing}");
println!(
"\n{}",
if fp == 0 && fnn == 0 && missing == 0 {
"PERFECT PARTITION on every element whose blend was measured."
} else {
"THE BIT DOES NOT PREDICT THE MEASURED BLEND."
}
);
// ── THE CONTROL THAT MATTERS ────────────────────────────────────────────
// A perfect partition is worthless if half the header partitions equally
// well: then the sample is too small to single out a field, and picking
// `+0x04` bit 0x02 out of the tie is the same mistake as picking `+0x08`
// 0x8050 was. So: how many OTHER bits of the first 12 header words separate
// the same 35 elements without error?
let mut rivals: Vec<String> = Vec::new();
let mut words: BTreeMap<(usize, String), Vec<u32>> = BTreeMap::new();
for e in [2usize, 4, 5, 6] {
let by = ar.read(&ar.entries()[e]).expect("entry");
let b = ui_layout::parse_build(&by).expect("build");
for (n, &(off, size)) in &b.sprites {
let s = &by[off..(off + size).min(by.len())];
if s.len() < 48 || &s[0..4] != b"T8aD" {
continue;
}
words.insert(
(e, n.clone()),
(0..12)
.map(|k| {
u32::from_be_bytes([s[k * 4], s[k * 4 + 1], s[k * 4 + 2], s[k * 4 + 3]])
})
.collect(),
);
}
}
for w in 0..12 {
for bit in 0..32 {
let mut ok = true;
let mut set_seen = false;
let mut clear_seen = false;
for &(e, n, additive) in MEASURED {
let Some(v) = words.get(&(e, n.to_string())) else {
ok = false;
break;
};
let on = (v[w] >> bit) & 1 == 1;
if on {
set_seen = true
} else {
clear_seen = true
}
if on != additive {
ok = false;
break;
}
}
// A constant bit trivially "agrees" with nothing; require both sides.
if ok && set_seen && clear_seen {
rivals.push(format!("+0x{:02X} bit {bit} (0x{:X})", w * 4, 1u32 << bit));
}
}
}
println!("\nRIVAL FIELDS — other bits of the first 12 header words that separate");
println!("the same 35 elements with zero errors: {}", rivals.len());
for r in &rivals {
println!(" {r}");
}
if rivals.len() == 1 {
println!(" -> the sample singles out ONE field. Nothing else in the header does it.");
} else {
println!(
" -> the sample does NOT single out a field; {} candidates tie.",
rivals.len()
);
}
}
// ── An integrity check the published decode did NOT do ──────────────────────
// The rival sweep above covers the 48-byte T8aD header. It does NOT cover the
// 60-byte DECLARATION entry, and the earlier declaration hunt was run with
// labels taken from the port's RENDER -- which put pteff10, pteff12, pteff20 and
// pteff21..23 on the alpha-over side, where the oracle says all six are
// additive. So the declaration has never been swept with correct labels, and if
// one of its words also partitions the 35 without error, "the field is the T8aD
// bit" is underdetermined.
//
// Run as: cargo run -p sylpheed-formats --example blend_vs_t8ad_bit -- decl
#[allow(dead_code)]
fn decl_rivals() {
use std::collections::BTreeMap;
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
const AT: usize = 0x20;
const STRIDE: usize = 60;
let mut decl: BTreeMap<(usize, String), Vec<u32>> = BTreeMap::new();
for e in [2usize, 4, 5, 6] {
let Ok(by) = ar.read(&ar.entries()[e]) else {
continue;
};
if by.len() < 0x18 {
continue;
}
let count = u32::from_be_bytes([by[0x14], by[0x15], by[0x16], by[0x17]]) as usize;
for i in 0..count {
let at = AT + i * STRIDE;
if at + STRIDE > by.len() {
break;
}
let end = by[at..at + 12].iter().position(|&c| c == 0).unwrap_or(12);
let name = String::from_utf8_lossy(&by[at..at + end]).to_string();
decl.insert(
(e, name),
(0..15)
.map(|k| {
u32::from_be_bytes([
by[at + k * 4],
by[at + k * 4 + 1],
by[at + k * 4 + 2],
by[at + k * 4 + 3],
])
})
.collect(),
);
}
}
let mut missing: Vec<String> = Vec::new();
for &(e, n, _) in MEASURED {
if !decl.contains_key(&(e, n.to_string())) {
missing.push(format!("entry {e} {n}"));
}
}
println!("\n=== DECLARATION-ENTRY RIVAL SWEEP ===");
println!(
"measured elements with NO declaration entry of their own: {} of {}",
missing.len(),
MEASURED.len()
);
for m in &missing {
println!(" {m}");
}
if !missing.is_empty() {
println!(" -> no declaration field can select the blend for these, because they");
println!(" have no declaration entry. The header is the only per-sprite home.");
}
let labelled: Vec<&(usize, &str, bool)> = MEASURED
.iter()
.filter(|(e, n, _)| decl.contains_key(&(*e, n.to_string())))
.collect();
let mut rivals = 0;
#[allow(clippy::needless_range_loop)]
for w in 0..15 {
for bit in 0..32 {
let (mut ok, mut s, mut c) = (true, false, false);
for &&(e, n, additive) in &labelled {
let on = (decl[&(e, n.to_string())][w] >> bit) & 1 == 1;
if on {
s = true
} else {
c = true
}
if on != additive {
ok = false;
break;
}
}
if ok && s && c {
println!(" RIVAL: declaration +0x{:02X} bit {bit}", w * 4);
rivals += 1;
}
}
}
println!(
"declaration bits that separate the {} labellable elements: {rivals}",
labelled.len()
);
}

View File

@@ -7,8 +7,8 @@
//! those float values.
//!
//! Usage: bounds_in_descriptor <container.xpr> <resource>...
use sylpheed_formats::mesh::{xbg7_descriptor_range, Xbg7Model};
use std::collections::HashSet;
use sylpheed_formats::mesh::{xbg7_descriptor_range, Xbg7Model};
fn main() {
let a: Vec<String> = std::env::args().collect();
@@ -24,7 +24,9 @@ fn main() {
}
}
}
let Some((d0, d1)) = xbg7_descriptor_range(&bytes, &m.name) else { continue };
let Some((d0, d1)) = xbg7_descriptor_range(&bytes, &m.name) else {
continue;
};
println!(
"{} descriptor 0x{d0:x}..0x{d1:x} ({} bytes), box lo{:?} hi{:?}",
m.name,
@@ -34,8 +36,12 @@ fn main() {
);
// Where in the descriptor does each bound value appear (±0.01)?
let targets: Vec<(&str, f32)> = vec![
("lo.x", lo[0]), ("lo.y", lo[1]), ("lo.z", lo[2]),
("hi.x", hi[0]), ("hi.y", hi[1]), ("hi.z", hi[2]),
("lo.x", lo[0]),
("lo.y", lo[1]),
("lo.z", lo[2]),
("hi.x", hi[0]),
("hi.y", hi[1]),
("hi.z", hi[2]),
];
for (label, v) in targets {
let mut at: Vec<usize> = Vec::new();
@@ -47,7 +53,10 @@ fn main() {
}
o += 4;
}
println!(" {label:5} {v:10.3} at descriptor offsets {:x?}", &at[..at.len().min(6)]);
println!(
" {label:5} {v:10.3} at descriptor offsets {:x?}",
&at[..at.len().min(6)]
);
}
}
}

View File

@@ -1,24 +1,39 @@
use sylpheed_formats::{game_data, localization::TextIndex, PakArchive};
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let text=TextIndex::build(&pak);
let mut stages=game_data::load_stages(&pak);
stages.retain(|s|s.id.starts_with('S') && s.id.len()==3 && s.id[1..].parse::<u32>().map(|n|n<=16).unwrap_or(false));
stages.sort_by(|a,b|a.id.cmp(&b.id));
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let text = TextIndex::build(&pak);
let mut stages = game_data::load_stages(&pak);
stages.retain(|s| {
s.id.starts_with('S')
&& s.id.len() == 3
&& s.id[1..].parse::<u32>().map(|n| n <= 16).unwrap_or(false)
});
stages.sort_by(|a, b| a.id.cmp(&b.id));
println!("═══ CAMPAIGN (S01S16) ═══");
for s in &stages{
let obj=text.objectives(&s.id,1);
for s in &stages {
let obj = text.objectives(&s.id, 1);
println!("\n{} · {}", s.id, s.location.as_deref().unwrap_or("?"));
for o in obj.iter().take(2){ println!("{o}"); }
for o in obj.iter().take(2) {
println!("{o}");
}
}
// roster with real names
let mut chars=game_data::load_characters(&pak);
chars.retain(|c|c.faction.as_deref()==Some("TCAF") && c.unique==Some(true) && c.faces.len()>=4);
let mut chars = game_data::load_characters(&pak);
chars.retain(|c| {
c.faction.as_deref() == Some("TCAF") && c.unique == Some(true) && c.faces.len() >= 4
});
println!("\n═══ PRINCIPAL CAST (TCAF, named) ═══");
for c in &chars{
let id=c.id.as_deref().unwrap_or("");
let name=text.character_name(id.trim_start_matches("Character")).or_else(||c.name_key.as_deref().and_then(|k|text.get(k))).unwrap_or("?");
println!(" {name:12} ({} portraits) [{}]", c.faces.len(), id.trim_start_matches("Character"));
for c in &chars {
let id = c.id.as_deref().unwrap_or("");
let name = text
.character_name(id.trim_start_matches("Character"))
.or_else(|| c.name_key.as_deref().and_then(|k| text.get(k)))
.unwrap_or("?");
println!(
" {name:12} ({} portraits) [{}]",
c.faces.len(),
id.trim_start_matches("Character")
);
}
}

View File

@@ -17,9 +17,9 @@
//!
//! Usage:
//! cargo run --release --example capture_ib_truth -- <Stage_SNN.xpr> <capture.log>...
use std::collections::HashMap;
use sylpheed_formats::mesh::{debug_resource_params, xbg7_resource_names, Xbg7Model};
use sylpheed_formats::ship_capture::{parse_capture, CapturedDraw};
use std::collections::HashMap;
fn q(v: f32) -> i64 {
(v as f64 * 1e4).round() as i64
@@ -60,7 +60,13 @@ fn main() {
let mut o = 0usize;
while o + 12 <= bytes.len() {
let (x, y, z) = (be(o), be(o + 4), be(o + 8));
if x.is_finite() && y.is_finite() && z.is_finite() && x.abs() < 1e6 && y.abs() < 1e6 && z.abs() < 1e6 {
if x.is_finite()
&& y.is_finite()
&& z.is_finite()
&& x.abs() < 1e6
&& y.abs() < 1e6
&& z.abs() < 1e6
{
index.entry((q(x), q(y), q(z))).or_default().push(o as u32);
}
o += 4;
@@ -72,7 +78,9 @@ fn main() {
for dx in -1..=1i64 {
for dy in -1..=1i64 {
for dz in -1..=1i64 {
let Some(cands) = index.get(&(k.0 + dx, k.1 + dy, k.2 + dz)) else { continue };
let Some(cands) = index.get(&(k.0 + dx, k.1 + dy, k.2 + dz)) else {
continue;
};
for &off in cands {
for stride in (12..=64).step_by(4) {
let ok = (1..4).all(|j| {
@@ -96,7 +104,9 @@ fn main() {
eprintln!("no draw could be placed in this container");
std::process::exit(1);
};
println!("container load constant: vbase - file_offset = 0x{base_delta:X} ({n} buffers agree)");
println!(
"container load constant: vbase - file_offset = 0x{base_delta:X} ({n} buffers agree)"
);
// ── Our decoder's view of the same container.
let models = Xbg7Model::stage_models(&bytes);
@@ -104,14 +114,19 @@ fn main() {
for m in &models {
for sm in &m.meshes {
if let Some(off) = sm.vbuf_offset {
by_off
.entry(off)
.or_default()
.push((m.name.clone(), sm.positions.len(), sm.indices.len()));
by_off.entry(off).or_default().push((
m.name.clone(),
sm.positions.len(),
sm.indices.len(),
));
}
}
}
println!("decoded {} resources, {} distinct vertex offsets\n", models.len(), by_off.len());
println!(
"decoded {} resources, {} distinct vertex offsets\n",
models.len(),
by_off.len()
);
// Declared-but-not-decoded resources, indexed by their first marker's
// (vertex, index) counts. A drawn buffer our decoder cannot name is the one
@@ -133,13 +148,21 @@ fn main() {
}
// ── The report: one row per drawn BUFFER, aggregating its index batches.
let mut per_buf: HashMap<u32, (usize, Vec<sylpheed_formats::ship_capture::CapturedIndexBuffer>, u32)> =
HashMap::new();
let mut per_buf: HashMap<
u32,
(
usize,
Vec<sylpheed_formats::ship_capture::CapturedIndexBuffer>,
u32,
),
> = HashMap::new();
for (delta, voff, d) in &hits {
if *delta != base_delta {
continue;
}
let e = per_buf.entry(d.vbase).or_insert((*voff, Vec::new(), d.vcount));
let e = per_buf
.entry(d.vbase)
.or_insert((*voff, Vec::new(), d.vcount));
let ib = d.ib.unwrap();
if !e.1.contains(&ib) {
e.1.push(ib);
@@ -147,9 +170,10 @@ fn main() {
}
let (mut pad0, mut pad_small, mut pad_off, mut unnamed) = (0usize, 0usize, 0usize, 0usize);
let (mut cover_exact, mut cover_short, mut idx_equal, mut idx_partial) = (0usize, 0usize, 0usize, 0usize);
let (mut cover_exact, mut cover_short, mut idx_equal, mut idx_partial) =
(0usize, 0usize, 0usize, 0usize);
let mut rows: Vec<(usize, String)> = Vec::new();
for (_, (voff, ibs, vcount)) in per_buf.iter() {
for (voff, ibs, vcount) in per_buf.values() {
let batches = ibs.len();
let total: u32 = ibs.iter().map(|i| i.icount).sum();
let lo = ibs.iter().map(|i| i.ibase).min().unwrap() as i64 - base_delta;
@@ -157,8 +181,11 @@ fn main() {
let umax = ibs.iter().map(|i| i.imax).max().unwrap();
let gap = *voff as i64 - hi; // bytes from the end of the index data to the vertex buffer
let names = by_off.get(voff);
let dec_idx = names
.and_then(|v| v.iter().find(|(_, p, _)| *p as u32 == *vcount).map(|(_, _, i)| *i as u32));
let dec_idx = names.and_then(|v| {
v.iter()
.find(|(_, p, _)| *p as u32 == *vcount)
.map(|(_, _, i)| *i as u32)
});
// The decoder's assumption, scored: it expects the whole index buffer at
// `vb - 2*idx_count - pad`, pad ≤ 3.
let dec_pad = dec_idx.map(|i| *voff as i64 - (i as i64) * 2 - lo);
@@ -218,5 +245,7 @@ fn main() {
println!(
"index extent: our idx_count == sum of captured batches for {idx_equal} buffers, differs for {idx_partial}"
);
println!("vertex-pool coverage by the union of batches: exact {cover_exact} · short {cover_short}");
println!(
"vertex-pool coverage by the union of batches: exact {cover_exact} · short {cover_short}"
);
}

View File

@@ -12,9 +12,9 @@
//!
//! Usage:
//! cargo run --release --example capture_index_bytes -- <Stage_SNN.xpr> <capture.log>...
use std::collections::HashMap;
use sylpheed_formats::mesh::Xbg7Model;
use sylpheed_formats::ship_capture::{parse_capture, CapturedDraw};
use std::collections::HashMap;
fn q(v: f32) -> i64 {
(v as f64 * 1e4).round() as i64
@@ -34,7 +34,10 @@ fn main() {
let text = std::fs::read_to_string(log).expect("log");
for d in parse_capture(&text) {
let k = d.ib.map(|i| (i.ibase, i.icount)).unwrap_or((0, 0));
if d.ib.map_or(false, |i| i.head_len > 0) && d.pos.len() >= 4 && seen.insert((log.clone(), d.vbase, k)) {
if d.ib.is_some_and(|i| i.head_len > 0)
&& d.pos.len() >= 4
&& seen.insert((log.clone(), d.vbase, k))
{
draws.push(d);
}
}
@@ -48,7 +51,13 @@ fn main() {
let mut o = 0usize;
while o + 12 <= bytes.len() {
let (x, y, z) = (be(o), be(o + 4), be(o + 8));
if x.is_finite() && y.is_finite() && z.is_finite() && x.abs() < 1e6 && y.abs() < 1e6 && z.abs() < 1e6 {
if x.is_finite()
&& y.is_finite()
&& z.is_finite()
&& x.abs() < 1e6
&& y.abs() < 1e6
&& z.abs() < 1e6
{
index.entry((q(x), q(y), q(z))).or_default().push(o as u32);
}
o += 4;
@@ -60,7 +69,9 @@ fn main() {
for dx in -1..=1i64 {
for dy in -1..=1i64 {
for dz in -1..=1i64 {
let Some(cands) = index.get(&(k.0 + dx, k.1 + dy, k.2 + dz)) else { continue };
let Some(cands) = index.get(&(k.0 + dx, k.1 + dy, k.2 + dz)) else {
continue;
};
for &off in cands {
for stride in (12..=64).step_by(4) {
let ok = (1..4).all(|j| {
@@ -92,10 +103,11 @@ fn main() {
for m in &models {
for sm in &m.meshes {
if let Some(off) = sm.vbuf_offset {
by_off
.entry(off)
.or_default()
.push((m.name.clone(), sm.positions.len(), sm.indices.clone()));
by_off.entry(off).or_default().push((
m.name.clone(),
sm.positions.len(),
sm.indices.clone(),
));
}
}
}
@@ -112,7 +124,10 @@ fn main() {
continue;
}
let ibase = d.ib.unwrap().ibase as i64;
ib_start.entry(d.vbase).and_modify(|e| *e = (*e).min(ibase)).or_insert(ibase);
ib_start
.entry(d.vbase)
.and_modify(|e| *e = (*e).min(ibase))
.or_insert(ibase);
}
let (mut agree, mut disagree, mut unmatched, mut nooverlap) = (0usize, 0usize, 0usize, 0usize);

View File

@@ -1,21 +1,37 @@
//! Identify which stage + ship a capture log came from: match the capture's
//! draw vertex counts against every resource (incl. LODs) of every Stage_SNN.xpr.
//! cargo run --release --example capture_match -- <capture.log> <resource3d dir>
use std::collections::{BTreeMap, HashSet};
use sylpheed_formats::mesh::{xbg7_resource_names, Xbg7Model};
use sylpheed_formats::ship_capture::{parse_capture, parse_drawlog};
use std::collections::{BTreeMap, HashSet};
fn main() {
let a: Vec<String> = std::env::args().collect();
let text = std::fs::read_to_string(&a[1]).unwrap();
let mut draws = parse_capture(&text);
if draws.is_empty() { draws = parse_drawlog(&text); }
let caps: HashSet<u32> = draws.iter().map(|d| d.vcount).filter(|v| *v >= 100).collect();
eprintln!("{} draws, {} distinct vcounts>=100", draws.len(), caps.len());
if draws.is_empty() {
draws = parse_drawlog(&text);
}
let caps: HashSet<u32> = draws
.iter()
.map(|d| d.vcount)
.filter(|v| *v >= 100)
.collect();
eprintln!(
"{} draws, {} distinct vcounts>=100",
draws.len(),
caps.len()
);
let mut entries: Vec<_> = std::fs::read_dir(&a[2]).unwrap().filter_map(|e| e.ok())
.filter(|e| { let n = e.file_name().to_string_lossy().to_string(); n.starts_with("Stage_") && n.ends_with(".xpr") })
.map(|e| e.path()).collect();
let mut entries: Vec<_> = std::fs::read_dir(&a[2])
.unwrap()
.filter_map(|e| e.ok())
.filter(|e| {
let n = e.file_name().to_string_lossy().to_string();
n.starts_with("Stage_") && n.ends_with(".xpr")
})
.map(|e| e.path())
.collect();
entries.sort();
for path in entries {
let bytes = std::fs::read(&path).unwrap();
@@ -28,12 +44,18 @@ fn main() {
let vc: usize = m.meshes.iter().map(|s| s.positions.len()).sum();
if vc >= 100 && caps.contains(&(vc as u32)) {
let id = m.name.get(..4).unwrap_or("?").to_string();
hits.entry(id).or_default().push((m.name.clone(), vc as u32));
hits.entry(id)
.or_default()
.push((m.name.clone(), vc as u32));
}
}
let total: usize = hits.values().map(|v| v.len()).sum();
if total >= 3 {
println!("== {} : {} matching resources ==", path.file_name().unwrap().to_string_lossy(), total);
println!(
"== {} : {} matching resources ==",
path.file_name().unwrap().to_string_lossy(),
total
);
for (id, v) in &hits {
let s: Vec<String> = v.iter().map(|(n, c)| format!("{n}({c})")).collect();
println!(" {id}: {}", s.join(" "));

View File

@@ -10,8 +10,8 @@
//! `Stage_S01` gave us.
//!
//! Usage: capture_truth_scan <resource3d_dir> <capture.log>...
use sylpheed_formats::ship_capture::{parse_capture, parse_drawlog, CapturedDraw};
use std::collections::HashMap;
use sylpheed_formats::ship_capture::{parse_capture, parse_drawlog, CapturedDraw};
fn q(v: f32) -> i64 {
(v as f64 * 1e4).round() as i64
@@ -47,7 +47,9 @@ fn main() {
let mut placed = 0usize;
for f in &files {
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
// Index quantised position triples. Junk floats (NaN/huge) are skipped,
// which prunes most of a texture-heavy container.
let be = |at: usize| f32::from_be_bytes(bytes[at..at + 4].try_into().unwrap());
@@ -55,7 +57,12 @@ fn main() {
let mut o = 0usize;
while o + 12 <= bytes.len() {
let (x, y, z) = (be(o), be(o + 4), be(o + 8));
if x.is_finite() && y.is_finite() && z.is_finite() && x.abs() < 1e6 && y.abs() < 1e6 && z.abs() < 1e6
if x.is_finite()
&& y.is_finite()
&& z.is_finite()
&& x.abs() < 1e6
&& y.abs() < 1e6
&& z.abs() < 1e6
{
index.entry((q(x), q(y), q(z))).or_default().push(o as u32);
}
@@ -77,9 +84,8 @@ fn main() {
let ok = (1..4).all(|j| {
let at = off as usize + j * stride;
at + 12 <= bytes.len()
&& (0..3).all(|c| {
(be(at + c * 4) - d.pos[j][c]).abs() <= 1e-4
})
&& (0..3)
.all(|c| (be(at + c * 4) - d.pos[j][c]).abs() <= 1e-4)
});
if ok {
deltas

View File

@@ -71,15 +71,27 @@ fn main() {
for p in &base_parts {
let mut vcounts = Vec::new();
let mut pos = Vec::new();
for cand in [p.clone(), format!("{p}_m"), format!("{p}_l"), format!("{p}_d")] {
for cand in [
p.clone(),
format!("{p}_m"),
format!("{p}_l"),
format!("{p}_d"),
] {
if let Some(m) = models.iter().find(|m| m.name == cand) {
let mp: Vec<[f32; 3]> =
m.meshes.iter().flat_map(|s| s.positions.iter().copied()).collect();
let mp: Vec<[f32; 3]> = m
.meshes
.iter()
.flat_map(|s| s.positions.iter().copied())
.collect();
vcounts.push(mp.len() as u32);
pos.extend(mp);
}
}
parts.push(Part { base: p.clone(), vcounts, pos });
parts.push(Part {
base: p.clone(),
vcounts,
pos,
});
}
// Validate a draw against a part (direct or X-mirrored), like ship_capture.
@@ -88,7 +100,9 @@ fn main() {
return None;
}
let near = |a: &[f32; 3], b: &[f32; 3]| {
(a[0] - b[0]).abs() <= 1e-2 && (a[1] - b[1]).abs() <= 1e-2 && (a[2] - b[2]).abs() <= 1e-2
(a[0] - b[0]).abs() <= 1e-2
&& (a[1] - b[1]).abs() <= 1e-2
&& (a[2] - b[2]).abs() <= 1e-2
};
let (mut direct, mut mirror) = (0usize, 0usize);
for q in &d.pos {
@@ -144,7 +158,11 @@ fn main() {
}
}
}
eprintln!("{log}: {} validated draws, {} bdy_04 refs", labeled.len(), refs.len());
eprintln!(
"{log}: {} validated draws, {} bdy_04 refs",
labeled.len(),
refs.len()
);
}
// Cluster per part (greedy, 8-unit radius), print clusters with ≥3 samples.
@@ -165,7 +183,7 @@ fn main() {
None => clusters.push((*s, 1)),
}
}
clusters.sort_by(|x, y| y.1.cmp(&x.1));
clusters.sort_by_key(|x| std::cmp::Reverse(x.1));
let tops: Vec<String> = clusters
.iter()
.filter(|(_, n)| *n >= 3)

View File

@@ -22,14 +22,19 @@ fn main() {
let mut rows = vec![];
for e in arc.entries() {
let Ok(b) = arc.read(e) else { continue };
let Ok(o) = IdxdObject::parse(&b) else { continue };
let Ok(o) = IdxdObject::parse(&b) else {
continue;
};
if o.schema_hash != 0x3c9ae32e {
continue;
}
let t = o.tokens();
let stage = t
.iter()
.find_map(|s| s.strip_prefix("EnumUnit_").map(|x| x.trim_end_matches(".tbl").to_string()))
.find_map(|s| {
s.strip_prefix("EnumUnit_")
.map(|x| x.trim_end_matches(".tbl").to_string())
})
.unwrap_or("?".into());
let bg = o.get_raw("BackGroundID").unwrap_or("?").to_string();
rows.push((stage, bg, t.len()));
@@ -47,11 +52,20 @@ fn main() {
let mut all_tokens: Vec<(u32, Vec<String>)> = vec![];
for e in ch.entries() {
let Ok(b) = ch.read(e) else { continue };
let Ok(o) = IdxdObject::parse(&b) else { continue };
let Ok(o) = IdxdObject::parse(&b) else {
continue;
};
*by_schema.entry(o.schema_hash).or_default() += 1;
all_tokens.push((o.schema_hash, o.tokens().iter().map(|s| s.to_string()).collect()));
all_tokens.push((
o.schema_hash,
o.tokens().iter().map(|s| s.to_string()).collect(),
));
}
println!(" {} entries, {} IDXD objects", ch.entries().len(), all_tokens.len());
println!(
" {} entries, {} IDXD objects",
ch.entries().len(),
all_tokens.len()
);
for (h, n) in &by_schema {
println!(" schema {h:08x} x{n}");
}
@@ -66,10 +80,16 @@ fn main() {
let mut hits: std::collections::BTreeSet<String> = Default::default();
for e in arc.entries() {
let Ok(b) = arc.read(e) else { continue };
let Ok(o) = IdxdObject::parse(&b) else { continue };
let Ok(o) = IdxdObject::parse(&b) else {
continue;
};
for t in o.tokens() {
let l = t.to_ascii_lowercase();
if l.contains("challenge") || t.ends_with("_EX") || t.contains("_EX4") || t.contains("_EX5") {
if l.contains("challenge")
|| t.ends_with("_EX")
|| t.contains("_EX4")
|| t.contains("_EX5")
{
hits.insert(format!("{:08x} {t}", o.schema_hash));
}
}

View File

@@ -44,7 +44,9 @@ fn main() {
paks.sort();
for p in &paks {
let Ok(arc) = PakArchive::open(p) else { continue };
let Ok(arc) = PakArchive::open(p) else {
continue;
};
for (i, e) in arc.entries().iter().enumerate() {
let Ok(b) = arc.read(e) else { continue };
if KEYS.iter().filter(|k| find(&b, k.as_bytes())).count() < KEYS.len() {

View File

@@ -15,7 +15,9 @@ fn main() {
files.sort();
let (mut total, mut composite, mut composite_named) = (0usize, 0usize, 0usize);
for f in &files {
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
for m in Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) {
total += 1;
let has_nodes = !scene_world_nodes(&bytes, &m.name).is_empty();

View File

@@ -8,8 +8,11 @@
//! shift chain after the exact-coverage fix.
//!
//! Usage: consensus_check <resource3d_dir> [--list]
use sylpheed_formats::mesh::Xbg7Model;
use std::collections::{BTreeMap, HashMap};
use sylpheed_formats::mesh::Xbg7Model;
/// Every place one model name was seen: (container, verts, tris, span).
type Sightings = BTreeMap<String, Vec<(String, usize, usize, [i64; 3])>>;
fn main() {
let dir = std::env::args().nth(1).expect("resource3d dir");
@@ -23,9 +26,11 @@ fn main() {
files.sort();
// name -> [(container, verts, tris, span)]
let mut seen: BTreeMap<String, Vec<(String, usize, usize, [i64; 3])>> = BTreeMap::new();
let mut seen: Sightings = BTreeMap::new();
for f in &files {
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
let where_ = f.file_name().unwrap().to_string_lossy().to_string();
for m in Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) {
let (mut lo, mut hi) = ([f32::MAX; 3], [f32::MIN; 3]);
@@ -47,7 +52,9 @@ fn main() {
(hi[1] - lo[1]).round() as i64,
(hi[2] - lo[2]).round() as i64,
];
seen.entry(m.name.clone()).or_default().push((where_.clone(), v, t, span));
seen.entry(m.name.clone())
.or_default()
.push((where_.clone(), v, t, span));
}
}
@@ -81,7 +88,5 @@ fn main() {
println!("{r}");
}
}
println!(
"{minority} minority decodes across {resources} resources that have a majority"
);
println!("{minority} minority decodes across {resources} resources that have a majority");
}

View File

@@ -16,19 +16,18 @@
//! Usage:
//! SYLPHEED_ISO=... cargo run --release --example correlate_capture -- \
//! <capture.log> <Stage_SNN> <ship_id> [ref_part_substr] [--emit]
//! e.g. SYLPHEED_ISO="/home/fabi/RE - Project Sylpheed/Project Sylpheed - Arc of
//! Deception (USA, Europe) (En,Ja).iso" \
//! e.g. SYLPHEED_ISO="/path/to/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso" \
//! cargo run --release --example correlate_capture -- \
//! xenia_ship_capture.log Stage_S01 e106 bdy_04 --emit
use std::collections::HashSet;
use std::path::Path;
use sylpheed_formats::mesh::{xbg7_resource_names, Xbg7Model};
use sylpheed_formats::ship::{is_base_part, ship_id_of};
use sylpheed_formats::ship_capture::{
correlate, parse_capture, parse_drawlog, serialize_table, PartKey,
};
use sylpheed_formats::xiso::open_iso;
use std::collections::HashSet;
use std::path::Path;
fn main() {
let args: Vec<String> = std::env::args().collect();
@@ -58,10 +57,15 @@ fn main() {
// Decode the ship's base parts AND their LOD copies (vcount + leading
// positions are the match keys; LODs share the base part's local frame).
let bytes = {
let rt = tokio::runtime::Builder::new_current_thread().enable_all().build().unwrap();
let rt = tokio::runtime::Builder::new_current_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(async {
let mut r = open_iso(Path::new(&iso)).await.unwrap();
r.read_file(&format!("hidden/resource3d/{stage}.xpr")).await.unwrap()
r.read_file(&format!("hidden/resource3d/{stage}.xpr"))
.await
.unwrap()
})
};
let names = xbg7_resource_names(&bytes);
@@ -83,7 +87,12 @@ fn main() {
let models = Xbg7Model::models_named(&bytes, &want, &|| false);
let positions_of = |name: &str| -> Option<Vec<[f32; 3]>> {
let m = models.iter().find(|m| m.name == name)?;
Some(m.meshes.iter().flat_map(|s| s.positions.iter().copied()).collect())
Some(
m.meshes
.iter()
.flat_map(|s| s.positions.iter().copied())
.collect(),
)
};
// One PartKey per (part, variant-vcount present in the capture) — correlate
@@ -94,18 +103,33 @@ fn main() {
// variant is the same part in the same local frame.
let mut keys: Vec<PartKey> = Vec::new();
for part in &base_parts {
let variants =
[part.clone(), format!("{part}_m"), format!("{part}_l"), format!("{part}_d")];
let union: Vec<[f32; 3]> =
variants.iter().filter_map(|v| positions_of(v)).flatten().collect();
let variants = [
part.clone(),
format!("{part}_m"),
format!("{part}_l"),
format!("{part}_d"),
];
let union: Vec<[f32; 3]> = variants
.iter()
.filter_map(|v| positions_of(v))
.flatten()
.collect();
let mut any = false;
for cand in &variants {
if let Some(pos) = positions_of(cand) {
let vcount = pos.len() as u32;
if draws.iter().any(|d| d.vcount == vcount) {
let lod = if cand == part { "full" } else { cand.rsplit('_').next().unwrap_or("?") };
let lod = if cand == part {
"full"
} else {
cand.rsplit('_').next().unwrap_or("?")
};
eprintln!(" {part:20} try vcount={vcount:6} [{lod}]");
keys.push(PartKey { part: part.clone(), vcount, ref_pos: union.clone() });
keys.push(PartKey {
part: part.clone(),
vcount,
ref_pos: union.clone(),
});
any = true;
}
}
@@ -120,9 +144,15 @@ fn main() {
return;
};
eprintln!("\nreference = {} → ship-relative placement:", ship.reference);
eprintln!(
"\nreference = {} → ship-relative placement:",
ship.reference
);
for p in &ship.parts {
eprintln!(" {:18} T=[{:9.1}{:9.1}{:9.1}]", p.part, p.t[0], p.t[1], p.t[2]);
eprintln!(
" {:18} T=[{:9.1}{:9.1}{:9.1}]",
p.part, p.t[0], p.t[1], p.t[2]
);
}
for part in &base_parts {
if !ship.parts.iter().any(|p| &p.part == part) {

View File

@@ -16,19 +16,23 @@
//! SYLPHEED_ISO=... cargo run --release --example correlate_frames -- \
//! <capture.log> <Stage_SNN> <ship_id> [ref_part_substr] [--min-parts N]
use std::collections::{BTreeMap, HashSet};
use std::path::Path;
use sylpheed_formats::mesh::{xbg7_resource_names, Xbg7Model};
use sylpheed_formats::ship::{is_base_part, ship_id_of};
use sylpheed_formats::ship_capture::{
correlate, parse_capture, parse_drawlog, segment_frames, PartKey,
};
use sylpheed_formats::xiso::open_iso;
use std::collections::{BTreeMap, HashSet};
use std::path::Path;
fn median(mut v: Vec<f32>) -> f32 {
v.sort_by(|a, b| a.partial_cmp(b).unwrap());
let n = v.len();
if n % 2 == 1 { v[n / 2] } else { 0.5 * (v[n / 2 - 1] + v[n / 2]) }
if n % 2 == 1 {
v[n / 2]
} else {
0.5 * (v[n / 2 - 1] + v[n / 2])
}
}
fn main() {
@@ -54,13 +58,22 @@ fn main() {
draws = parse_drawlog(&text);
}
let frames = segment_frames(&draws);
println!("{} draws → {} camera-consistent blocks", draws.len(), frames.len());
println!(
"{} draws → {} camera-consistent blocks",
draws.len(),
frames.len()
);
let bytes = {
let rt = tokio::runtime::Builder::new_current_thread().enable_all().build().unwrap();
let rt = tokio::runtime::Builder::new_current_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(async {
let mut r = open_iso(Path::new(&iso)).await.unwrap();
r.read_file(&format!("hidden/resource3d/{stage}.xpr")).await.unwrap()
r.read_file(&format!("hidden/resource3d/{stage}.xpr"))
.await
.unwrap()
})
};
let names = xbg7_resource_names(&bytes);
@@ -81,7 +94,12 @@ fn main() {
let models = Xbg7Model::models_named(&bytes, &want, &|| false);
let positions_of = |name: &str| -> Option<Vec<[f32; 3]>> {
let m = models.iter().find(|m| m.name == name)?;
Some(m.meshes.iter().flat_map(|s| s.positions.iter().copied()).collect())
Some(
m.meshes
.iter()
.flat_map(|s| s.positions.iter().copied())
.collect(),
)
};
// part -> [T per frame], and how many frames placed it at all.
@@ -91,20 +109,33 @@ fn main() {
for (fi, fr) in frames.iter().enumerate() {
let mut keys: Vec<PartKey> = Vec::new();
for part in &base_parts {
let variants =
[part.clone(), format!("{part}_m"), format!("{part}_l"), format!("{part}_d")];
let union: Vec<[f32; 3]> =
variants.iter().filter_map(|v| positions_of(v)).flatten().collect();
let variants = [
part.clone(),
format!("{part}_m"),
format!("{part}_l"),
format!("{part}_d"),
];
let union: Vec<[f32; 3]> = variants
.iter()
.filter_map(|v| positions_of(v))
.flatten()
.collect();
for cand in &variants {
if let Some(pos) = positions_of(cand) {
let vcount = pos.len() as u32;
if fr.iter().any(|d| d.vcount == vcount) {
keys.push(PartKey { part: part.clone(), vcount, ref_pos: union.clone() });
keys.push(PartKey {
part: part.clone(),
vcount,
ref_pos: union.clone(),
});
}
}
}
}
let Some(ship) = correlate(id, fr, &keys, ref_sub) else { continue };
let Some(ship) = correlate(id, fr, &keys, ref_sub) else {
continue;
};
if ship.parts.len() < min_parts {
continue;
}
@@ -114,7 +145,10 @@ fn main() {
// Averaging them together is what makes an otherwise clean result look
// like it disagrees by exactly the distance between the two references.
if !ship.reference.contains(ref_sub) {
println!(" block {fi:2}: skipped — reference fell back to {}", ship.reference);
println!(
" block {fi:2}: skipped — reference fell back to {}",
ship.reference
);
continue;
}
used_frames += 1;
@@ -173,7 +207,8 @@ fn main() {
let spread: Vec<f32> = (0..3)
.map(|a| {
let v: Vec<f32> = cl.iter().map(|t| t[a]).collect();
v.iter().cloned().fold(f32::MIN, f32::max) - v.iter().cloned().fold(f32::MAX, f32::min)
v.iter().cloned().fold(f32::MIN, f32::max)
- v.iter().cloned().fold(f32::MAX, f32::min)
})
.collect();
let verdict = if cl.len() < 2 {
@@ -187,14 +222,21 @@ fn main() {
// (turret aiming, engine gimballing) does not — which is what separates
// "the assembler has the rotation wrong" from "the part moved".
let all_ms = rots.get(part).cloned().unwrap_or_default();
let ms: Vec<[[f32; 3]; 3]> =
cl_idx.iter().filter_map(|&i| all_ms.get(i).copied()).collect();
let ms: Vec<[[f32; 3]; 3]> = cl_idx
.iter()
.filter_map(|&i| all_ms.get(i).copied())
.collect();
// Keep a rotation from INSIDE the cluster: the first sample overall can
// belong to another instance, and diffing static against that reads as a
// rotation error that is really an instance mix-up.
consensus.insert(
part.clone(),
(med, ms.first().copied().unwrap_or([[1.0, 0.0, 0.0], [0.0, 1.0, 0.0], [0.0, 0.0, 1.0]])),
(
med,
ms.first()
.copied()
.unwrap_or([[1.0, 0.0, 0.0], [0.0, 1.0, 0.0], [0.0, 0.0, 1.0]]),
),
);
let rot_var = ms
.iter()
@@ -219,8 +261,12 @@ fn main() {
// re-expressed in the reference part's frame before comparing — and the
// rotation is compared too, because "wrong orientation" is half of the
// reported viewer symptom and a translation-only check cannot see it.
let Some(si) = args.iter().position(|a| a == "--static") else { return };
let Some(spath) = args.get(si + 1) else { return };
let Some(si) = args.iter().position(|a| a == "--static") else {
return;
};
let Some(spath) = args.get(si + 1) else {
return;
};
let sbytes = std::fs::read(spath).expect("read stage container");
// `include_external = true` — the engine cluster, the bridge and cross-id
// turrets live in SEPARATE composites (`e_rou_e106_eng`, 3 nodes) that the
@@ -269,12 +315,19 @@ fn main() {
.fold(0.0f32, f32::max);
worst_t = worst_t.max(dtm);
worst_r = worst_r.max(drm);
let mark = if dtm < 1.0 && drm < 0.02 { "MATCH" } else { "DIFFERS" };
let mark = if dtm < 1.0 && drm < 0.02 {
"MATCH"
} else {
"DIFFERS"
};
println!(
" {part:18} static=[{:9.1}{:9.1}{:9.1}] dT={dtm:7.2} dR={drm:6.3} {mark}",
r[0], r[1], r[2]
);
}
println!("\nworst dT={worst_t:.2} worst dR={worst_r:.3} ({} static parts, {} captured)",
scene.len(), samples.len());
println!(
"\nworst dT={worst_t:.2} worst dR={worst_r:.3} ({} static parts, {} captured)",
scene.len(),
samples.len()
);
}

View File

@@ -6,8 +6,8 @@
//! is well founded. This measures the slack on every block that DOES decode: if
//! real geometry always covers its pool, under-coverage is good evidence of a
//! wrong candidate and the gate stands.
use sylpheed_formats::mesh::Xbg7Model;
use std::collections::BTreeMap;
use sylpheed_formats::mesh::Xbg7Model;
fn main() {
let dir = std::env::args().nth(1).expect("resource3d dir");
@@ -22,7 +22,9 @@ fn main() {
let mut hist: BTreeMap<i64, usize> = BTreeMap::new();
let mut worst: Vec<(i64, String)> = Vec::new();
for f in &files {
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
for m in Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) {
for sub in &m.meshes {
if sub.positions.is_empty() || sub.indices.is_empty() {
@@ -32,14 +34,21 @@ fn main() {
let slack = sub.positions.len() as i64 - 1 - max_idx;
*hist.entry(slack.min(20)).or_default() += 1;
if slack > 4 {
worst.push((slack, format!("{} in {}", m.name, f.file_name().unwrap().to_string_lossy())));
worst.push((
slack,
format!("{} in {}", m.name, f.file_name().unwrap().to_string_lossy()),
));
}
}
}
}
println!("unreferenced tail vertices (vtx_count 1 max index), over decoded sub-meshes:");
for (slack, n) in &hist {
println!(" {:>3}{} : {n}", slack, if *slack == 20 { "+" } else { " " });
println!(
" {:>3}{} : {n}",
slack,
if *slack == 20 { "+" } else { " " }
);
}
worst.sort_by_key(|(s, _)| std::cmp::Reverse(*s));
for (s, w) in worst.iter().take(5) {

View File

@@ -12,7 +12,13 @@ use sylpheed_formats::{movie_subtitle, PakArchive};
fn movie_secs(path: &str) -> Option<f32> {
let out = Command::new("ffprobe")
.args([
"-v", "error", "-show_entries", "format=duration", "-of", "csv=p=0", path,
"-v",
"error",
"-show_entries",
"format=duration",
"-of",
"csv=p=0",
path,
])
.output()
.ok()?;
@@ -27,7 +33,9 @@ fn main() {
let mut over = 0;
let mut worst: Vec<(String, f32, f32)> = Vec::new();
let dir = format!("{disc}/dat/movie");
let Ok(rd) = std::fs::read_dir(&dir) else { return };
let Ok(rd) = std::fs::read_dir(&dir) else {
return;
};
for e in rd.flatten() {
let p = e.path();
if p.extension().is_none_or(|x| x != "wmv") {
@@ -39,7 +47,9 @@ fn main() {
continue;
}
let last = cues.iter().map(|(_, t)| *t).fold(0.0f32, f32::max);
let Some(secs) = movie_secs(&p.to_string_lossy()) else { continue };
let Some(secs) = movie_secs(&p.to_string_lossy()) else {
continue;
};
checked += 1;
if last > secs {
over += 1;

View File

@@ -0,0 +1,65 @@
//! Does a textured element's declaration carry anything that distinguishes the
//! two FRAME elements from every other element on the main menu?
//!
//! `sylpheed-port` asks for the blend/alpha mode of `ptframe1`/`ptframe2`. Prior
//! work is on `.prm` PRIMITIVES (`ui-prm-blend-mode.md`, undecodable with reach —
//! no field, the declaration words are constant) and on a refuted `T8aD +0x04`
//! bit. Neither covers a `.t32` element's own declaration entry, which is 60
//! bytes and mostly unread.
//!
//! This dumps every declaration entry on the menu and reports, per 4-byte word,
//! whether the two frames share a value that no other element has. A word that
//! separates exactly those two is a candidate; one that does not, is not.
//!
//! cargo run -p sylpheed-formats --example decl_entry_diff
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
const AT: usize = 0x20;
const N: usize = 60;
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
let by = ar.read(&ar.entries()[5]).expect("entry 5");
let b = ui_layout::parse_build(&by).expect("build");
let names: Vec<String> = b.elements.iter().map(|e| e.name.clone()).collect();
let frames: Vec<usize> = names
.iter()
.enumerate()
.filter(|(_, n)| n.starts_with("ptframe"))
.map(|(i, _)| i)
.collect();
println!("{} elements; frames at indices {:?}", names.len(), frames);
let word = |i: usize, w: usize| -> u32 {
let o = AT + i * N + w * 4;
u32::from_be_bytes([by[o], by[o + 1], by[o + 2], by[o + 3]])
};
println!("\nper-word: does a value separate EXACTLY the two frames?");
for w in 0..N / 4 {
let fv: Vec<u32> = frames.iter().map(|&i| word(i, w)).collect();
let same_in_frames = fv.windows(2).all(|p| p[0] == p[1]);
let others: Vec<u32> = (0..names.len())
.filter(|i| !frames.contains(i))
.map(|i| word(i, w))
.collect();
let unique = same_in_frames && !others.contains(&fv[0]);
let distinct = {
let mut v: Vec<u32> = (0..names.len()).map(|i| word(i, w)).collect();
v.sort_unstable();
v.dedup();
v.len()
};
println!(
" +0x{:02X} frames {:?} distinct values {distinct:2}{}",
w * 4,
fv.iter().map(|v| format!("{v:08X}")).collect::<Vec<_>>(),
if unique {
" <- SEPARATES THE FRAMES"
} else {
""
}
);
}
}

View File

@@ -0,0 +1,45 @@
//! Which elements carry which values at the low-cardinality declaration words?
//!
//! `decl_entry_diff` found nothing separating `ptframe1`/`ptframe2` except their
//! NAME — +0x00 and +0x08 are the name string ("ptfr", ".t32"), so those two hits
//! are a false positive of that test, not a field.
//!
//! The remaining candidates for a per-element mode flag are the words with few
//! distinct values: +0x28 (3) and +0x2C (6). This prints who has what.
//!
//! cargo run -p sylpheed-formats --example decl_flag_words
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
const AT: usize = 0x20;
const N: usize = 60;
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
let by = ar.read(&ar.entries()[5]).expect("entry 5");
let b = ui_layout::parse_build(&by).expect("build");
let w = |i: usize, off: usize| -> u32 {
let o = AT + i * N + off;
u32::from_be_bytes([by[o], by[o + 1], by[o + 2], by[o + 3]])
};
println!(
"{:<22} {:>10} {:>10} {:>10} {:>10}",
"element", "+0x28", "+0x2C", "+0x34", "kind"
);
for (i, e) in b.elements.iter().enumerate() {
let mark = if e.name.starts_with("ptframe") {
" <- FRAME"
} else {
""
};
println!(
"{:<22} {:>10} {:>10} {:>10} {:>#10x}{mark}",
e.name,
w(i, 0x28),
w(i, 0x2C) as i32,
w(i, 0x34),
e.kind
);
}
}

View File

@@ -16,12 +16,16 @@ use sylpheed_formats::{pak, ratc, ui_layout};
const OFFS: [usize; 4] = [28, 36, 44, 56];
fn be32(b: &[u8], o: usize) -> u32 {
if o + 4 > b.len() { return 0; }
if o + 4 > b.len() {
return 0;
}
u32::from_be_bytes([b[o], b[o + 1], b[o + 2], b[o + 3]])
}
fn main() {
let path = std::env::args().nth(1).expect("usage: decl_word_probe <pak> [entry]");
let path = std::env::args()
.nth(1)
.expect("usage: decl_word_probe <pak> [entry]");
let want: Option<usize> = std::env::args().nth(2).and_then(|s| s.parse().ok());
let ar = pak::PakArchive::open(&path).expect("open pak");
let entries: Vec<_> = ar.entries().to_vec();
@@ -29,34 +33,62 @@ fn main() {
let mut hit = [0usize; 4];
let mut tot = 0usize;
for (i, e) in entries.iter().enumerate() {
if want.is_some_and(|w| w != i) { continue; }
let Ok(bytes) = ar.read(e) else { continue };
let Some(build) = ui_layout::parse_build(&bytes) else { continue };
let Some(kids) = ratc::parse(&bytes) else { continue };
// Index space to test against: the T8aD children, in child order.
let t8: Vec<&ratc::RatcChild> = kids.iter().filter(|c| c.kind == "T8aD").collect();
if build.elements.iter().all(|el| el.sprite.is_some() || el.kind & 0x10 != 0) {
if want.is_some_and(|w| w != i) {
continue;
}
println!("== entry {i} ({} elements, {} T8aD children)", build.elements.len(), t8.len());
for (n, c) in t8.iter().enumerate() { println!(" child[{n:2}] {}", c.name); }
let Ok(bytes) = ar.read(e) else { continue };
let Some(build) = ui_layout::parse_build(&bytes) else {
continue;
};
let Some(kids) = ratc::parse(&bytes) else {
continue;
};
// Index space to test against: the T8aD children, in child order.
let t8: Vec<&ratc::RatcChild> = kids.iter().filter(|c| c.kind == "T8aD").collect();
if build
.elements
.iter()
.all(|el| el.sprite.is_some() || el.kind & 0x10 != 0)
{
continue;
}
println!(
"== entry {i} ({} elements, {} T8aD children)",
build.elements.len(),
t8.len()
);
for (n, c) in t8.iter().enumerate() {
println!(" child[{n:2}] {}", c.name);
}
for el in &build.elements {
if el.kind & 0x10 != 0 { continue; }
if el.kind & 0x10 != 0 {
continue;
}
let d = &bytes[0x20 + el.index * 60..0x20 + (el.index + 1) * 60];
let words: Vec<u32> = OFFS.iter().map(|&o| be32(d, o)).collect();
// The control: for a RESOLVED element, which T8aD child is it?
let truth = el.sprite.as_ref()
let truth = el
.sprite
.as_ref()
.and_then(|s| t8.iter().position(|c| &c.name == s));
if let Some(t) = truth {
tot += 1;
for (k, w) in words.iter().enumerate() {
if *w as usize == t { hit[k] += 1; }
if *w as usize == t {
hit[k] += 1;
}
}
}
println!(
" [{:2}] {:26} sprite={:?} child={:?} +28={} +36={} +44={} +56={}",
el.index, el.name, el.sprite, truth,
words[0] as i32, words[1] as i32, words[2] as i32, words[3] as i32
el.index,
el.name,
el.sprite,
truth,
words[0] as i32,
words[1] as i32,
words[2] as i32,
words[3] as i32
);
}
}

View File

@@ -1,59 +1,108 @@
use sylpheed_formats::{ratc, idxd::IdxdObject, PakArchive};
use std::collections::BTreeMap;
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
use sylpheed_formats::{idxd::IdxdObject, ratc, PakArchive};
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
// 1. RATC child-type census across the big RATC paks
let mut childtypes:BTreeMap<String,u64>=BTreeMap::new();
let mut ratc_unparsed=0u64;
for pk in ["GP_READY_ROOM","GP_MOVIE_THEATER","GP_DIALOG","GP_DEBRIEFING_PILOTLOG","GP_TITLE","GP_BUNK"]{
let Ok(arc)=PakArchive::open(format!("{disc}/dat/{pk}.pak")) else{continue};
for e in arc.entries(){
let Ok(b)=arc.read(e) else{continue};
if !ratc::is_ratc(&b){continue;}
match ratc::parse(&b){
Some(kids)=> for k in kids{
let ext=k.name.rsplit('.').next().unwrap_or("?").to_lowercase();
*childtypes.entry(ext).or_default()+=1;
},
None=>ratc_unparsed+=1,
let mut childtypes: BTreeMap<String, u64> = BTreeMap::new();
let mut ratc_unparsed = 0u64;
for pk in [
"GP_READY_ROOM",
"GP_MOVIE_THEATER",
"GP_DIALOG",
"GP_DEBRIEFING_PILOTLOG",
"GP_TITLE",
"GP_BUNK",
] {
let Ok(arc) = PakArchive::open(format!("{disc}/dat/{pk}.pak")) else {
continue;
};
for e in arc.entries() {
let Ok(b) = arc.read(e) else { continue };
if !ratc::is_ratc(&b) {
continue;
}
match ratc::parse(&b) {
Some(kids) => {
for k in kids {
let ext = k.name.rsplit('.').next().unwrap_or("?").to_lowercase();
*childtypes.entry(ext).or_default() += 1;
}
}
None => ratc_unparsed += 1,
}
}
}
println!("=== RATC child-type census (big RATC paks) ===");
let mut cv:Vec<_>=childtypes.into_iter().collect(); cv.sort_by_key(|x|std::cmp::Reverse(x.1));
for (e,c) in &cv{ println!(" .{e:8} ×{c}"); }
let mut cv: Vec<_> = childtypes.into_iter().collect();
cv.sort_by_key(|x| std::cmp::Reverse(x.1));
for (e, c) in &cv {
println!(" .{e:8} ×{c}");
}
println!(" (RATC bundles that failed to parse: {ratc_unparsed})");
// 2. The 00000002 mystery format (GP_MAIN_GAME_E)
let arc=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
for e in arc.entries(){
let Ok(b)=arc.read(e) else{continue};
if b.len()>=4 && b[0..4]==[0,0,0,2]{
let hx:String=b[..48.min(b.len())].iter().map(|x|format!("{x:02x}")).collect::<Vec<_>>().join(" ");
let asc:String=b[..64.min(b.len())].iter().map(|&x|if(0x20..0x7f).contains(&x){x as char}else{'.'}).collect();
println!("\n=== 00000002 format sample ({}B) ===\n{hx}\n{asc}",b.len());
let arc = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
for e in arc.entries() {
let Ok(b) = arc.read(e) else { continue };
if b.len() >= 4 && b[0..4] == [0, 0, 0, 2] {
let hx: String = b[..48.min(b.len())]
.iter()
.map(|x| format!("{x:02x}"))
.collect::<Vec<_>>()
.join(" ");
let asc: String = b[..64.min(b.len())]
.iter()
.map(|&x| {
if (0x20..0x7f).contains(&x) {
x as char
} else {
'.'
}
})
.collect();
println!(
"\n=== 00000002 format sample ({}B) ===\n{hx}\n{asc}",
b.len()
);
break;
}
}
// 3. Sample the top undecoded IDXD schemas: first tokens (guess semantics)
println!("\n=== top undecoded IDXD schemas — sample tokens (semantic hints) ===");
let targets:[u32;6]=[0xb412e6d8,0x026379ab,0x43faa517,0x3c5b0549,0x6ab4825a,0x0426e81d];
for want in targets{
let mut shown=false;
for e in arc.entries(){
if shown{break;}
let Ok(b)=arc.read(e) else{continue};
if b.len()<12 || &b[0..4]!=b"IDXD"{continue;}
let s=u32::from_be_bytes([b[8],b[9],b[10],b[11]]);
if s!=want{continue;}
if let Ok(o)=IdxdObject::parse(&b){
let t=o.tokens();
let sample:Vec<String>=t.iter().take(14).map(|s|{let s=s.chars().take(18).collect::<String>();s}).collect();
let targets: [u32; 6] = [
0xb412e6d8, 0x026379ab, 0x43faa517, 0x3c5b0549, 0x6ab4825a, 0x0426e81d,
];
for want in targets {
let mut shown = false;
for e in arc.entries() {
if shown {
break;
}
let Ok(b) = arc.read(e) else { continue };
if b.len() < 12 || &b[0..4] != b"IDXD" {
continue;
}
let s = u32::from_be_bytes([b[8], b[9], b[10], b[11]]);
if s != want {
continue;
}
if let Ok(o) = IdxdObject::parse(&b) {
let t = o.tokens();
let sample: Vec<String> = t
.iter()
.take(14)
.map(|s| {
let s = s.chars().take(18).collect::<String>();
s
})
.collect();
println!(" {want:08x}: {sample:?}");
shown=true;
shown = true;
}
}
if !shown{ println!(" {want:08x}: (parse failed / not found)"); }
if !shown {
println!(" {want:08x}: (parse failed / not found)");
}
}
}

View File

@@ -13,8 +13,11 @@ fn is_number(s: &str) -> bool {
}
fn is_key(s: &str) -> bool {
!s.is_empty()
&& s.chars().all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-')
&& s.chars().next().is_some_and(|c| c.is_ascii_alphabetic() || c == '_')
&& s.chars()
.all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-')
&& s.chars()
.next()
.is_some_and(|c| c.is_ascii_alphabetic() || c == '_')
&& !is_number(s)
}
fn is_value(s: &str) -> bool {
@@ -22,14 +25,20 @@ fn is_value(s: &str) -> bool {
}
fn main() {
let root = std::env::var("SYLPHEED_DISC")
.unwrap_or_else(|_| "/home/fabi/RE - Project Sylpheed/sylph_extract".into());
// No hardcoded fallback: it made SYLPHEED_DISC look like a control while
// one machine's directory layout decided the outcome (#16).
let Ok(root) = std::env::var("SYLPHEED_DISC") else {
eprintln!("set SYLPHEED_DISC to the extracted disc root");
std::process::exit(2);
};
let wanted: Vec<String> = std::env::args().skip(1).collect();
let arc = PakArchive::open(std::path::Path::new(&root).join("dat/GP_MAIN_GAME_E.pak")).unwrap();
for e in arc.entries() {
let Ok(bytes) = arc.read(e) else { continue };
let Ok(obj) = IdxdObject::parse(&bytes) else { continue };
let Ok(obj) = IdxdObject::parse(&bytes) else {
continue;
};
let toks = obj.tokens().to_vec();
let mut hits: Vec<String> = vec![];
for (i, t) in toks.iter().enumerate() {
@@ -44,7 +53,12 @@ fn main() {
});
}
if !hits.is_empty() {
println!("0x{:08x} {:<44} {}", obj.schema_hash, obj.identity(), hits.join(" "));
println!(
"0x{:08x} {:<44} {}",
obj.schema_hash,
obj.identity(),
hits.join(" ")
);
}
}
}

View File

@@ -20,7 +20,9 @@ fn is_key(s: &str) -> bool {
!s.is_empty()
&& s.chars()
.all(|c| c.is_ascii_alphanumeric() || c == '_' || c == '-')
&& s.chars().next().is_some_and(|c| c.is_ascii_alphabetic() || c == '_')
&& s.chars()
.next()
.is_some_and(|c| c.is_ascii_alphabetic() || c == '_')
&& !is_number(s)
}
@@ -29,9 +31,14 @@ fn is_value(s: &str) -> bool {
}
fn main() {
// argv[1], else SYLPHEED_DISC. No hardcoded fallback -- see #16.
let root = std::env::args()
.nth(1)
.unwrap_or_else(|| "/home/fabi/RE - Project Sylpheed/sylph_extract".into());
.or_else(|| std::env::var("SYLPHEED_DISC").ok())
.unwrap_or_else(|| {
eprintln!("usage: defaulted_fields <disc-root> [paks...] (or set SYLPHEED_DISC)");
std::process::exit(2);
});
let paks: Vec<String> = std::env::args().skip(2).collect();
let paks = if paks.is_empty() {
vec![
@@ -71,7 +78,11 @@ fn main() {
}
let prev = if i == 0 { None } else { Some(&toks[i - 1]) };
let valued = prev.map(|p| is_value(p)).unwrap_or(false);
let v = if valued { Some(toks[i - 1].clone()) } else { None };
let v = if valued {
Some(toks[i - 1].clone())
} else {
None
};
seen_here.entry(t.clone()).or_insert(v);
}
for (k, v) in seen_here {
@@ -107,17 +118,14 @@ fn main() {
0xb412_e6d8 => "MESSAGE",
_ => "?",
};
let defaulted: Vec<_> = keys
.iter()
.filter(|(_, s)| s.1 > 0)
.collect();
let defaulted: Vec<_> = keys.iter().filter(|(_, s)| s.1 > 0).collect();
if defaulted.is_empty() {
continue;
}
println!("\n--- schema 0x{schema:08x} {name} ({n_obj} objects) ---");
println!(
"{:<30} {:>5} {:>5} {}",
"KEY", "set", "dflt", "values seen (≤12) | owners defaulting"
"{:<30} {:>5} {:>5} values seen (≤12) | owners defaulting",
"KEY", "set", "dflt"
);
for (k, (n_set, n_def, vals, owners)) in defaulted {
let vv: Vec<&str> = vals.iter().map(|s| s.as_str()).collect();

View File

@@ -49,12 +49,16 @@ fn main() {
if r + 12 > desc.len() {
break;
}
let (o, code, usage) = (be32(desc, r), be32(desc, r + 4), be32(desc, r + 8) >> 16);
let (o, code, usage) =
(be32(desc, r), be32(desc, r + 4), be32(desc, r + 8) >> 16);
if o == 0x00FF_0000 || code == 0xFFFF_FFFF || o > 0x1000 {
println!(" end marker @0x{r:X}: off=0x{o:X} code=0x{code:X}");
break;
}
println!(" off {o:>3} code 0x{:06X} usage {usage}", code & 0xFF_FFFF);
println!(
" off {o:>3} code 0x{:06X} usage {usage}",
code & 0xFF_FFFF
);
stride = stride.max(o + 4);
r += 12;
}

View File

@@ -0,0 +1,82 @@
//! How often is a screen's design size READ, and how often is it FABRICATED?
//!
//! `ui_layout.rs` scans the `.rat` records for a `(w,h)` at `+0x18`/`+0x1c` and,
//! finding none, falls back to `(DESIGN_W, DESIGN_H)` = 1280x720. Its own comment
//! says "every screen seen is 1280x720, **which is also the fallback**" -- which
//! is precisely the problem: the fabricated value equals the expected one, so no
//! output of the parser can distinguish a read design size from an invented one.
//! The port sizes its screens off this number.
//!
//! This replicates the scan through the public RATC API and counts.
//!
//! cargo run -p sylpheed-formats --example design_size_fallback
use std::io::Write;
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ratc, ui_layout};
fn be32(b: &[u8], o: usize) -> u32 {
if o + 4 > b.len() {
return 0;
}
u32::from_be_bytes([b[o], b[o + 1], b[o + 2], b[o + 3]])
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let mut paks: Vec<PathBuf> = std::fs::read_dir(root.join("dat"))
.expect("dat/")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().is_some_and(|x| x == "pak"))
.collect();
paks.sort();
let (mut read, mut fell_back, mut nonstd) = (0usize, 0usize, 0usize);
for pak in &paks {
let Ok(ar) = PakArchive::open(pak) else {
continue;
};
let name = pak.file_name().unwrap().to_string_lossy().to_string();
let (mut r, mut f) = (0usize, 0usize);
for e in ar.entries() {
let Ok(by) = ar.read(e) else { continue };
if !ui_layout::is_build(&by) {
continue;
}
let Some(kids) = ratc::parse(&by) else {
continue;
};
// the same predicate ui_layout uses, over the same records
// ⚠️ A first version took EVERY RATC child and failed its control:
// it reported all 965 builds stating a non-1280x720 size, where
// `screen list` prints 1280x720 for every one. `records` in
// ui_layout is the `.rat` children only; a T8aD sprite header read
// at +0x18 is garbage that passes the range test.
let found = kids
.iter()
.filter(|k| k.kind == "RATC" || k.name.ends_with(".rat"))
.find_map(|k| {
let rec = &by[k.offset..(k.offset + k.size).min(by.len())];
let (w, h) = (be32(rec, 0x18), be32(rec, 0x1c));
(w > 0 && h > 0 && w <= 8192 && h <= 8192).then_some((w, h))
});
match found {
Some((w, h)) => {
r += 1;
if (w, h) != (1280, 720) {
nonstd += 1;
println!(" {name} : a build states a NON-standard design size {w}x{h}");
}
}
None => f += 1,
}
}
if r + f > 0 {
println!("{name:30} {r:5} read {f:5} FABRICATED");
std::io::stdout().flush().ok();
}
read += r;
fell_back += f;
}
println!("\n{read} builds state a design size, {fell_back} get the 1280x720 FALLBACK");
println!("{nonstd} builds state something other than 1280x720");
println!("--- END ---");
}

View File

@@ -0,0 +1,59 @@
//! Is `GP_DIALOG` entry 2 the `DLG_SELECT_DIFFICULTY` screen?
//!
//! The image lists `DLG_SELECT_DIFFICULTY` among the `DLG_*` names at
//! `0x820A41BB`, so DIFFICULTY is a DIALOG, not a GamePart screen with its own
//! pak — which is why a search for an 8-record `btn` build in a difficulty-named
//! archive found nothing. `GP_DIALOG` entry 2 carries `pcbtn00`..`03`: four
//! buttons, matching EASY / NORMAL / HARD / BACK.
//!
//! CONTROL: `GP_TITLE` entry 5's five buttons must come back at the rows the disc
//! is independently known to place them (162/242/322/401/482, spacing 80).
//!
//! cargo run -p sylpheed-formats --example dialog_button_rows
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn rows(ar: &PakArchive, entry: usize, what: &str) {
let Ok(by) = ar.read(&ar.entries()[entry]) else {
return;
};
let Some(b) = ui_layout::parse_build(&by) else {
return;
};
let mut v: Vec<(i32, String)> = b
.elements
.iter()
.filter(|e| {
let n = &e.name;
(n.starts_with("pcbtn") || n.starts_with("ptbtn")) && !n.contains('f')
})
.map(|e| {
(
e.rest().map(|k| k.y).unwrap_or(e.pivot_y as i32),
e.name.clone(),
)
})
.collect();
v.sort_by_key(|r| r.0);
println!("\n{what} (entry {entry}):");
for (y, n) in &v {
println!(" y {y:5} {n}");
}
if v.len() > 1 {
let sp: Vec<i32> = v.windows(2).map(|w| w[1].0 - w[0].0).collect();
println!(" spacing {sp:?}");
}
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let t = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
rows(
&t,
5,
"CONTROL: GP_TITLE main menu (must be 162/242/322/401/482)",
);
let d = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
rows(&d, 2, "GP_DIALOG candidate for DLG_SELECT_DIFFICULTY");
rows(&d, 3, "GP_DIALOG entry 3 (the pair)");
}

View File

@@ -0,0 +1,70 @@
//! Are the 37 equal-button-count `GP_DIALOG` pairs language pairs, or not?
//!
//! 26 of 65 adjacent pairs differ in BUTTON COUNT — two languages cannot, so those
//! are unrelated dialogs. For the rest my language reading was left UNSUPPORTED
//! rather than refuted, and both agents observed that nothing rewards closing it.
//!
//! A language pair must share its BUTTON NAMES and ROWS exactly (a locale changes
//! glyphs, not layout) and differ only elsewhere. An unrelated pair will differ in
//! button names or rows too.
//!
//! CONTROL: entries 2/3 (identical element sets) must come out as "buttons match".
//!
//! cargo run -p sylpheed-formats --example dialog_pair_37
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn sig(ar: &PakArchive, i: usize) -> Option<(Vec<(String, i32)>, usize)> {
let by = ar.read(&ar.entries()[i]).ok()?;
let b = ui_layout::parse_build(&by)?;
let mut v: Vec<(String, i32)> = b
.elements
.iter()
.filter(|e| e.name.contains("btn"))
.map(|e| {
(
e.name.clone(),
e.rest().map(|k| k.y).unwrap_or(e.pivot_y as i32),
)
})
.collect();
v.sort();
let n = v.len();
Some((v, n))
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
let n = ar.entries().len();
let (mut match_btn, mut differ_btn, mut ctrl) = (0, 0, false);
let mut examples = 0;
for k in (0..n).step_by(2) {
let (Some((a, na)), Some((b, nb))) = (sig(&ar, k), sig(&ar, k + 1)) else {
continue;
};
if na != nb {
continue; // the 26 already settled
}
if a == b {
match_btn += 1;
if k == 2 {
ctrl = true
}
} else {
differ_btn += 1;
if examples < 5 {
println!(" entries {k:3}/{:<3} buttons DIFFER", k + 1);
println!(" {:?}", a.iter().map(|x| &x.0).collect::<Vec<_>>());
println!(" {:?}", b.iter().map(|x| &x.0).collect::<Vec<_>>());
examples += 1;
}
}
}
println!("\nequal-button-count pairs whose button NAMES+ROWS match : {match_btn}");
println!("equal-button-count pairs whose buttons DIFFER : {differ_btn}");
println!(
"control (entries 2/3 counted as matching): {}",
if ctrl { "PASSED" } else { "FAILED" }
);
}

View File

@@ -0,0 +1,45 @@
//! Do adjacent `GP_DIALOG` entries differ in BUTTON COUNT?
//!
//! I offered an untested reading for why 63 of 65 adjacent pairs have different
//! element sets: dialog text baked into language-specific sprites, so EN/JP
//! entries differ by construction. `sylpheed-port` refuted it with a count — two
//! languages of one dialog cannot differ in how many buttons they have. This
//! re-derives that with my own reader before I record the refutation.
//!
//! cargo run -p sylpheed-formats --example dialog_pair_button_counts
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn btns(ar: &PakArchive, i: usize) -> Option<usize> {
let by = ar.read(&ar.entries()[i]).ok()?;
let b = ui_layout::parse_build(&by)?;
Some(b.elements.iter().filter(|e| e.name.contains("btn")).count())
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
let n = ar.entries().len();
let (mut diff, mut same, mut skip) = (0, 0, 0);
let mut show = 0;
for k in (0..n).step_by(2) {
match (btns(&ar, k), btns(&ar, k + 1)) {
(Some(a), Some(b)) => {
if a != b {
diff += 1;
if show < 6 {
println!(" entries {k:3}/{:<3} button counts {a} vs {b}", k + 1);
show += 1;
}
} else {
same += 1
}
}
_ => skip += 1,
}
}
println!("\nadjacent pairs differing in BUTTON COUNT: {diff}");
println!("adjacent pairs with equal button counts : {same}");
println!("unreadable : {skip}");
println!("\ntwo languages of one dialog cannot differ in button count.");
}

View File

@@ -0,0 +1,51 @@
//! What differs between equal-button-count `GP_DIALOG` adjacent pairs?
//!
//! All 39 share button names and rows. That is consistent with a LANGUAGE PAIR and
//! equally with TWO DIALOGS SHARING A BUTTON TEMPLATE (two yes/no boxes differing
//! only in their message sprite). The difference is in what else differs: a
//! language pair should differ in the SAME slots with locale-marked names.
//!
//! cargo run -p sylpheed-formats --example dialog_pair_diffs
use std::collections::BTreeSet;
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn names(ar: &PakArchive, i: usize) -> Option<BTreeSet<String>> {
let by = ar.read(&ar.entries()[i]).ok()?;
let b = ui_layout::parse_build(&by)?;
Some(b.elements.iter().map(|e| e.name.clone()).collect())
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
let n = ar.entries().len();
let mut shown = 0;
for k in (0..n).step_by(2) {
let (Some(a), Some(b)) = (names(&ar, k), names(&ar, k + 1)) else {
continue;
};
if a == b {
continue;
}
let oa: Vec<&String> = a.difference(&b).collect();
let ob: Vec<&String> = b.difference(&a).collect();
// only the equal-button-count ones
let ba = a.iter().filter(|x| x.contains("btn")).count();
let bb = b.iter().filter(|x| x.contains("btn")).count();
if ba != bb {
continue;
}
if shown < 6 {
println!(
"entries {k:3}/{:<3} shared {} only-in-{k}: {:?} only-in-{}: {:?}",
k + 1,
a.intersection(&b).count(),
oa,
k + 1,
ob
);
shown += 1;
}
}
}

View File

@@ -0,0 +1,58 @@
//! Are `GP_DIALOG` entries 0/1 and 2/3 a LANGUAGE PAIR or a DUPLICATE?
//!
//! They are the only two adjacent pairs in that archive with identical element
//! sets; every other adjacent pair is two unrelated dialogs. Left open as
//! "untested" — identical element names are equally consistent with a language
//! pair (same layout, different glyphs baked into the textures) and with a
//! byte-for-byte duplicate.
//!
//! The bytes decide it: identical entries are a duplicate; entries that share
//! every element name but differ in payload are a language pair.
//!
//! CONTROL: entries 10/11, known to be two DIFFERENT dialogs (stage 10 vs stage
//! 02), must come out as differing — and by a lot. A comparator that cannot
//! separate two unrelated dialogs cannot judge two similar ones.
//!
//! cargo run -p sylpheed-formats --example dialog_pair_identity
use std::path::PathBuf;
use sylpheed_formats::pak::PakArchive;
fn cmp(ar: &PakArchive, a: usize, b: usize, what: &str) {
let (Ok(x), Ok(y)) = (ar.read(&ar.entries()[a]), ar.read(&ar.entries()[b])) else {
println!("{what}: unreadable");
return;
};
let same_len = x.len() == y.len();
let n = x.len().min(y.len());
let diff = (0..n).filter(|&i| x[i] != y[i]).count();
let first = (0..n).find(|&i| x[i] != y[i]);
println!("{what}");
println!(
" sizes {} / {} ({})",
x.len(),
y.len(),
if same_len { "equal" } else { "DIFFER" }
);
println!(
" differing bytes over the common prefix: {diff} / {n} ({:.2}%)",
100.0 * diff as f64 / n as f64
);
match first {
None if same_len => println!(" => BYTE-IDENTICAL — a duplicate"),
None => println!(" => one is a prefix of the other"),
Some(o) => println!(" => first difference at offset 0x{o:X}"),
}
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
cmp(
&ar,
10,
11,
"CONTROL: entries 10/11 — known two different dialogs",
);
cmp(&ar, 0, 1, "entries 0/1");
cmp(&ar, 2, 3, "entries 2/3 — the DIFFICULTY build");
}

View File

@@ -0,0 +1,58 @@
//! Are `GP_DIALOG`'s 140 entries adjacent EN/JP pairs, one per dialog record?
//!
//! The dialog table has 70 records and the archive has 140 entries. If the
//! pairing is adjacent — (0,1), (2,3), … — then dialog index = entry / 2, and the
//! unbound id-to-entry join becomes an ordering question rather than a search.
//!
//! Test: for each pair, compare the SET of element names. GP_TITLE's EN/JP pairs
//! share their sprite sets exactly except for the title art (4/7), so identical
//! sets are the signature of a language pair.
//!
//! cargo run -p sylpheed-formats --example dialog_pairing
use std::collections::BTreeSet;
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn names(ar: &PakArchive, i: usize) -> Option<BTreeSet<String>> {
let by = ar.read(&ar.entries()[i]).ok()?;
let b = ui_layout::parse_build(&by)?;
Some(b.elements.iter().map(|e| e.name.clone()).collect())
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
let n = ar.entries().len();
let (mut adj_same, mut adj_diff, mut skipped) = (0, 0, 0);
for k in (0..n).step_by(2) {
match (names(&ar, k), names(&ar, k + 1)) {
(Some(a), Some(b)) => {
if a == b {
adj_same += 1;
println!(" identical pair: entries {k}/{}", k + 1)
} else {
adj_diff += 1
}
}
_ => skipped += 1,
}
}
println!("ADJACENT pairing (2k, 2k+1): identical {adj_same} differing {adj_diff} unreadable {skipped}");
// rival hypothesis: halves, (i, i+70)
let (mut h_same, mut h_diff, mut h_skip) = (0, 0, 0);
for k in 0..n / 2 {
match (names(&ar, k), names(&ar, k + n / 2)) {
(Some(a), Some(b)) => {
if a == b {
h_same += 1
} else {
h_diff += 1
}
}
_ => h_skip += 1,
}
}
println!(
"HALVES pairing (i, i+70): identical {h_same} differing {h_diff} unreadable {h_skip}"
);
}

View File

@@ -0,0 +1,29 @@
//! How is `GP_DIALOG.pak` organised? Testing whether dialog id maps positionally.
//!
//! The dialog table gives name -> id (70 records, `DLG_SELECT_DIFFICULTY` = 2000)
//! and the disc gives a unique four-button build at GP_DIALOG entries 2/3. Nothing
//! joins them. If the archive were laid out in table order, or in id order, the
//! join would be positional — this checks.
//!
//! cargo run -p sylpheed-formats --example dialog_pak_shape
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_DIALOG.pak")).expect("GP_DIALOG");
let n = ar.entries().len();
let mut builds = 0;
let mut with_btn = 0;
for e in ar.entries() {
let Ok(by) = ar.read(e) else { continue };
if let Some(b) = ui_layout::parse_build(&by) {
builds += 1;
if b.elements.iter().any(|el| el.name.contains("btn")) {
with_btn += 1;
}
}
}
println!("entries {n}, parse as builds {builds}, of those with a btn element {with_btn}");
println!("dialog table has 70 records; 70 x 2 (EN/JP) = 140");
}

View File

@@ -1,13 +1,30 @@
use sylpheed_formats::{game_data, localization::TextIndex, PakArchive};
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let text=TextIndex::build(&pak);
let msgs=game_data::load_demo_messages(&pak);
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let text = TextIndex::build(&pak);
let msgs = game_data::load_demo_messages(&pak);
println!("{} dialogue lines total\n", msgs.len());
for m in msgs.iter().filter(|m|m.character.is_some()&&!m.page_keys.is_empty()).take(8){
let who=m.character.as_deref().unwrap_or("?").trim_start_matches("Character");
let line:String=m.page_keys.iter().filter_map(|k|text.get(k)).collect::<Vec<_>>().join(" ");
println!(" {who:10} [{}] “{}", m.voice_clip.as_deref().unwrap_or("-"), line.chars().take(64).collect::<String>());
for m in msgs
.iter()
.filter(|m| m.character.is_some() && !m.page_keys.is_empty())
.take(8)
{
let who = m
.character
.as_deref()
.unwrap_or("?")
.trim_start_matches("Character");
let line: String = m
.page_keys
.iter()
.filter_map(|k| text.get(k))
.collect::<Vec<_>>()
.join(" ");
println!(
" {who:10} [{}] “{}",
m.voice_clip.as_deref().unwrap_or("-"),
line.chars().take(64).collect::<String>()
);
}
}

View File

@@ -1,29 +1,60 @@
use sylpheed_formats::{idxd::IdxdObject, PakArchive};
use std::collections::BTreeMap;
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let arc=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let tables:[(u32,&str);4]=[(0x0426e81d,"Player / physics+scoring"),(0x6ab4825a,"Weapon"),(0x43faa517,"Unit / craft"),(0x3c5b0549,"Vessel / capital ship")];
for (want,label) in tables{
use sylpheed_formats::{idxd::IdxdObject, PakArchive};
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let arc = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let tables: [(u32, &str); 4] = [
(0x0426e81d, "Player / physics+scoring"),
(0x6ab4825a, "Weapon"),
(0x43faa517, "Unit / craft"),
(0x3c5b0549, "Vessel / capital ship"),
];
for (want, label) in tables {
// collect all records of this schema
let mut recs:Vec<IdxdObject>=vec![];
for e in arc.entries(){ let Ok(b)=arc.read(e) else{continue}; let Ok(o)=IdxdObject::parse(&b) else{continue}; if o.schema_hash==want{recs.push(o);} }
let mut recs: Vec<IdxdObject> = vec![];
for e in arc.entries() {
let Ok(b) = arc.read(e) else { continue };
let Ok(o) = IdxdObject::parse(&b) else {
continue;
};
if o.schema_hash == want {
recs.push(o);
}
}
// field-union (explicit-valued keys), with occurrence count
let mut cols:BTreeMap<String,u32>=BTreeMap::new();
for o in &recs{ for (k,_) in o.resolved_fields(){ *cols.entry(k.into()).or_default()+=1; } }
let mut cols: BTreeMap<String, u32> = BTreeMap::new();
for o in &recs {
for (k, _) in o.resolved_fields() {
*cols.entry(k.into()).or_default() += 1;
}
}
println!("\n╔══ {label} [{want:08x}] {} records ══", recs.len());
let mut cv:Vec<_>=cols.into_iter().collect(); cv.sort_by_key(|x|std::cmp::Reverse(x.1));
let colstr:String=cv.iter().take(28).map(|(k,c)|format!("{k}({c})")).collect::<Vec<_>>().join(" ");
let mut cv: Vec<_> = cols.into_iter().collect();
cv.sort_by_key(|x| std::cmp::Reverse(x.1));
let colstr: String = cv
.iter()
.take(28)
.map(|(k, c)| format!("{k}({c})"))
.collect::<Vec<_>>()
.join(" ");
println!("║ numeric/enum fields: {colstr}");
// dump 2 sample records: identity + explicit fields
for o in recs.iter().take(2){
let id=o.get_raw("ID").unwrap_or("?");
let name=o.get_raw("Name").unwrap_or("");
for o in recs.iter().take(2) {
let id = o.get_raw("ID").unwrap_or("?");
let name = o.get_raw("Name").unwrap_or("");
print!("║ • {id}");
if !name.is_empty(){print!(" «{name}»");}
if !name.is_empty() {
print!(" «{name}»");
}
println!();
let fields:Vec<String>=o.resolved_fields().iter().map(|(k,v)|format!("{k}={v}")).collect();
for chunk in fields.chunks(5){ println!("{}", chunk.join(" ")); }
let fields: Vec<String> = o
.resolved_fields()
.iter()
.map(|(k, v)| format!("{k}={v}"))
.collect();
for chunk in fields.chunks(5) {
println!("{}", chunk.join(" "));
}
}
}
}

View File

@@ -1,11 +1,29 @@
use sylpheed_formats::{game_data, PakArchive};
use std::collections::BTreeMap;
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let chars=game_data::load_characters(&pak);
let mut byfac:BTreeMap<String,Vec<String>>=Default::default();
for c in &chars{ byfac.entry(c.faction.clone().unwrap_or("·".into())).or_default().push(format!("{}({})",c.id.clone().unwrap_or_default().trim_start_matches("Character"),c.faces.len())); }
println!("{} characters across {} factions:",chars.len(),byfac.len());
for (f,mut v) in byfac{ v.sort(); println!(" [{f}] {}", v.join(" ")); }
use sylpheed_formats::{game_data, PakArchive};
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let chars = game_data::load_characters(&pak);
let mut byfac: BTreeMap<String, Vec<String>> = Default::default();
for c in &chars {
byfac
.entry(c.faction.clone().unwrap_or("·".into()))
.or_default()
.push(format!(
"{}({})",
c.id.clone()
.unwrap_or_default()
.trim_start_matches("Character"),
c.faces.len()
));
}
println!(
"{} characters across {} factions:",
chars.len(),
byfac.len()
);
for (f, mut v) in byfac {
v.sort();
println!(" [{f}] {}", v.join(" "));
}
}

View File

@@ -1,14 +1,83 @@
use sylpheed_formats::{idxd::IdxdObject, PakArchive};
fn short(s:&str)->String{ s.trim_start_matches("Weapon_").trim_start_matches("UN_").trim_start_matches("UnitName_UN_").into() }
fn g<'a>(o:&'a IdxdObject,k:&str)->String{ o.get_f32(k).map(|v|{if v==v.trunc(){format!("{}",v as i64)}else{format!("{v}")}}).or_else(||o.get_raw(k).filter(|x|x.chars().next().map(|c|c.is_ascii_digit()).unwrap_or(false)).map(|s|s.to_string())).unwrap_or("·".into()) }
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let arc=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let recs=|want:u32|->Vec<IdxdObject>{ arc.entries().iter().filter_map(|e|arc.read(e).ok()).filter_map(|b|IdxdObject::parse(&b).ok()).filter(|o|o.schema_hash==want).collect() };
println!("### WEAPONS (name | target | load | int | power | vel | range | trig)");
for o in recs(0x6ab4825a).iter().take(16){ println!("{:<34}\t{}\t{}\t{}\t{}\t{}\t{}\t{}", short(o.get_raw("ID").unwrap_or("?")), o.get_raw("TargetType").unwrap_or("·"), g(o,"LoadingCount"),g(o,"Interval"),g(o,"Power"),g(o,"Velocity"),g(o,"MaximumRange"),g(o,"TriggerShotCount")); }
println!("\n### UNITS/CRAFT (name | HP | cruise | accel | radar | turrets | score)");
for o in recs(0x43faa517).iter().take(16){ println!("{:<38}\t{}\t{}\t{}\t{}\t{}\t{}", short(o.get_raw("ID").unwrap_or("?")), g(o,"HP"),g(o,"CruisingVelocity"),g(o,"Acceleration"),g(o,"RadarRange"),g(o,"TurretCount"),g(o,"ScorePoint")); }
println!("\n### VESSELS/CAPITAL SHIPS (name | HP | Sz_X | Sz_Z | radar | turrets | bridges | hatches | shieldgen | thrusters)");
for o in recs(0x3c5b0549).iter(){ println!("{:<30}\t{}\t{}\t{}\t{}\t{}\t{}\t{}\t{}\t{}", short(o.get_raw("ID").unwrap_or("?")), g(o,"HP"),g(o,"Size_X"),g(o,"Size_Z"),g(o,"RadarRange"),g(o,"TurretCount"),g(o,"BridgeCount"),g(o,"HatchCount"),g(o,"ShieldGeneratorCount"),g(o,"ThrusterCount")); }
fn short(s: &str) -> String {
s.trim_start_matches("Weapon_")
.trim_start_matches("UN_")
.trim_start_matches("UnitName_UN_")
.into()
}
fn g(o: &IdxdObject, k: &str) -> String {
o.get_f32(k)
.map(|v| {
if v == v.trunc() {
format!("{}", v as i64)
} else {
format!("{v}")
}
})
.or_else(|| {
o.get_raw(k)
.filter(|x| {
x.chars()
.next()
.map(|c| c.is_ascii_digit())
.unwrap_or(false)
})
.map(|s| s.to_string())
})
.unwrap_or("·".into())
}
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let arc = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let recs = |want: u32| -> Vec<IdxdObject> {
arc.entries()
.iter()
.filter_map(|e| arc.read(e).ok())
.filter_map(|b| IdxdObject::parse(&b).ok())
.filter(|o| o.schema_hash == want)
.collect()
};
println!("### WEAPONS (name | target | load | int | power | vel | range | trig)");
for o in recs(0x6ab4825a).iter().take(16) {
println!(
"{:<34}\t{}\t{}\t{}\t{}\t{}\t{}\t{}",
short(o.get_raw("ID").unwrap_or("?")),
o.get_raw("TargetType").unwrap_or("·"),
g(o, "LoadingCount"),
g(o, "Interval"),
g(o, "Power"),
g(o, "Velocity"),
g(o, "MaximumRange"),
g(o, "TriggerShotCount")
);
}
println!("\n### UNITS/CRAFT (name | HP | cruise | accel | radar | turrets | score)");
for o in recs(0x43faa517).iter().take(16) {
println!(
"{:<38}\t{}\t{}\t{}\t{}\t{}\t{}",
short(o.get_raw("ID").unwrap_or("?")),
g(o, "HP"),
g(o, "CruisingVelocity"),
g(o, "Acceleration"),
g(o, "RadarRange"),
g(o, "TurretCount"),
g(o, "ScorePoint")
);
}
println!("\n### VESSELS/CAPITAL SHIPS (name | HP | Sz_X | Sz_Z | radar | turrets | bridges | hatches | shieldgen | thrusters)");
for o in recs(0x3c5b0549).iter() {
println!(
"{:<30}\t{}\t{}\t{}\t{}\t{}\t{}\t{}\t{}\t{}",
short(o.get_raw("ID").unwrap_or("?")),
g(o, "HP"),
g(o, "Size_X"),
g(o, "Size_Z"),
g(o, "RadarRange"),
g(o, "TurretCount"),
g(o, "BridgeCount"),
g(o, "HatchCount"),
g(o, "ShieldGeneratorCount"),
g(o, "ThrusterCount")
);
}
}

View File

@@ -1,15 +1,21 @@
use sylpheed_formats::{game_data, localization::TextIndex, PakArchive};
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let text=TextIndex::build(&pak);
for n in 1..=16u32{
let sid=format!("S{n:02}");
use sylpheed_formats::{localization::TextIndex, PakArchive};
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_MAIN_GAME_E.pak")).unwrap();
let text = TextIndex::build(&pak);
for n in 1..=16u32 {
let sid = format!("S{n:02}");
// primary objective across phases (first that resolves)
let obj:Vec<String>=(1..=3).flat_map(|p|text.objectives(&sid,p)).map(|s|s.to_string()).collect();
let lose:Vec<String>=(1..=3).flat_map(|p|text.lose_conditions(&sid,p)).map(|s|s.to_string()).collect();
let full_obj=obj.join(" ");
let full_lose=lose.into_iter().take(2).collect::<Vec<_>>().join(" ");
let obj: Vec<String> = (1..=3)
.flat_map(|p| text.objectives(&sid, p))
.map(|s| s.to_string())
.collect();
let lose: Vec<String> = (1..=3)
.flat_map(|p| text.lose_conditions(&sid, p))
.map(|s| s.to_string())
.collect();
let full_obj = obj.join(" ");
let full_lose = lose.into_iter().take(2).collect::<Vec<_>>().join(" ");
println!("{sid}\t{full_obj}\t{full_lose}");
}
}

View File

@@ -3,8 +3,8 @@
//! `XBG7_EDGE_CAP` sets the cap; this reports, for one setting, how much
//! geometry decodes and how self-consistent it is across containers — the two
//! numbers any change to the cap has to trade off. Run it once per cap value.
use sylpheed_formats::mesh::Xbg7Model;
use std::collections::BTreeMap;
use sylpheed_formats::mesh::Xbg7Model;
fn main() {
let dir = std::env::args().nth(1).expect("resource3d dir");
@@ -20,7 +20,9 @@ fn main() {
let mut seen: BTreeMap<String, Vec<([i64; 3], usize, usize)>> = BTreeMap::new();
let (mut models, mut verts) = (0usize, 0usize);
for f in &files {
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
for m in Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) {
let (mut lo, mut hi) = ([f32::MAX; 3], [f32::MIN; 3]);
for s in &m.meshes {
@@ -64,7 +66,7 @@ fn main() {
}
}
let (mut shared, mut inconsistent) = (0usize, 0usize);
for (_, list) in &seen {
for list in seen.values() {
if list.len() < 2 || !list.iter().all(|e| e.1 == list[0].1 && e.2 == list[0].2) {
continue;
}

View File

@@ -0,0 +1,113 @@
//! Every record reachable from an element — leaf **and** `focus_link` — plus a
//! disc-wide census of how many elements have more than one.
//!
//! ⚠️ WHY. I claimed `ptbtn00f`'s peak alpha of 80 was undeclared, having read
//! `ptbtn00.rat` (the leaf, flat 255) and stopped. The pulse is in
//! `ptbtn00f.rat`, the focus record. `focus_link` was already parsed and
//! `ui_layout.rs` already documented it: the format was known and I did not
//! consult it. An absence claim is only as good as its enumeration, so this
//! enumerates rather than asking the reader to remember.
//!
//! cargo run -p sylpheed-formats --example element_records -- GP_TITLE ptbtn00
//! cargo run -p sylpheed-formats --example element_records -- --census
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let argv: Vec<String> = std::env::args().skip(1).collect();
if argv.iter().any(|a| a == "--census") {
let (mut els, mut linked, mut screens_with) = (0usize, 0usize, 0usize);
let mut paks: Vec<_> = std::fs::read_dir(root.join("dat"))
.expect("dat")
.filter_map(|e| e.ok())
.map(|e| e.path())
.filter(|p| p.extension().map(|x| x == "pak").unwrap_or(false))
.collect();
paks.sort();
for p in &paks {
let Ok(ar) = PakArchive::open(p) else {
continue;
};
for ent in ar.entries() {
let Ok(by) = ar.read(ent) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let n = b.elements.iter().filter(|e| e.focus_link.is_some()).count();
els += b.elements.len();
linked += n;
if n > 0 {
screens_with += 1
}
}
}
println!("elements disc-wide : {els}");
println!(
"with a focus_link record : {linked} ({:.1}%)",
100.0 * linked as f64 / els as f64
);
println!("builds containing at least 1: {screens_with}");
println!("\nEach of those carries a SECOND record whose keyframes are invisible");
println!("to anyone who looks up the leaf by name and stops.");
return;
}
let pak = argv.first().cloned().unwrap_or_else(|| "GP_TITLE".into());
let want = argv.get(1).cloned();
let ar = PakArchive::open(root.join(format!("dat/{pak}.pak"))).expect("pak");
for (i, ent) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(ent) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
for el in &b.elements {
if let Some(w) = &want {
if !el.name.starts_with(w.as_str()) {
continue;
}
}
if el.focus_link.is_none() && want.is_none() {
continue;
}
println!("entry {i}: {}", el.name);
let stem = el.name.trim_end_matches(".rat");
for (tag, rec) in [
("leaf", format!("{stem}.rat")),
("focus", el.focus_link.clone().unwrap_or_default()),
] {
if rec.is_empty() {
continue;
}
match b.records.get(rec.as_str()) {
Some(&(lo, ls)) => {
let bytes = &by[lo..(lo + ls).min(by.len())];
let loop_u = ui_layout::loop_length_units(bytes);
let kf: Vec<String> = ui_layout::parse_build(bytes)
.map(|lb| {
lb.elements
.iter()
.map(|e| {
format!(
"{} [{} keys, peak a{}]",
e.name,
e.keyframes.len(),
e.keyframes
.iter()
.map(|k| k.fade >> 24)
.max()
.unwrap_or(0)
)
})
.collect()
})
.unwrap_or_default();
println!(" {tag:<6} {rec:<20} loop {:?} {}", loop_u, kf.join(", "));
}
None => println!(" {tag:<6} {rec:<20} (no such record)"),
}
}
}
}
}

View File

@@ -8,13 +8,16 @@
//! however big, is part of the silhouette.
//!
//! Usage: envelope_screen <resource3d_dir> [protrusion_fraction]
use std::collections::{BTreeSet, HashSet};
use sylpheed_formats::mesh::Xbg7Model;
use sylpheed_formats::ship::{assemble_ship, ship_id_of};
use std::collections::{BTreeSet, HashSet};
fn main() {
let dir = std::env::args().nth(1).expect("resource3d dir");
let limit: f32 = std::env::args().nth(2).and_then(|s| s.parse().ok()).unwrap_or(0.35);
let limit: f32 = std::env::args()
.nth(2)
.and_then(|s| s.parse().ok())
.unwrap_or(0.35);
let mut files: Vec<_> = std::fs::read_dir(&dir)
.unwrap()
.flatten()
@@ -25,7 +28,9 @@ fn main() {
let mut flagged = 0usize;
for f in &files {
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
let ids: BTreeSet<String> = Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false)
.iter()
.filter_map(|m| ship_id_of(&m.name).map(|s| s.to_string()))
@@ -40,7 +45,9 @@ fn main() {
// World box per placement.
let mut boxes: Vec<(String, [f32; 3], [f32; 3])> = Vec::new();
for p in &placed {
let Some(m) = models.iter().find(|m| m.name == p.resource) else { continue };
let Some(m) = models.iter().find(|m| m.name == p.resource) else {
continue;
};
let (mut lo, mut hi) = ([f32::MAX; 3], [f32::MIN; 3]);
for s in &m.meshes {
for q in &s.positions {
@@ -102,5 +109,8 @@ fn main() {
}
}
}
println!("{flagged} parts protrude more than {:.0}% of their ship's size", 100.0 * limit);
println!(
"{flagged} parts protrude more than {:.0}% of their ship's size",
100.0 * limit
);
}

View File

@@ -0,0 +1,48 @@
//! Is `ptbtn11` the TOP item of the `EXTRAS` screen?
//!
//! `sylpheed-port` authors `extras/initial_focus: ptbtn11` and states it is
//! correct under the surviving reading — "a submenu resets to the item it opens
//! on". The oracle shows EXTRAS opening on `MISSION SELECT`, the first of
//! MISSION SELECT / MOVIE THEATER / BACK. So their value is right only if
//! `ptbtn11` is that first item. This checks it against the disc.
//!
//! CONTROL: the same read on the MAIN MENU build, whose five buttons have a known
//! top-to-bottom order (NEW GAME first). If the ordering rule cannot reproduce a
//! known screen it cannot be trusted on an unknown one.
//!
//! cargo run -p sylpheed-formats --example extras_button_order
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn report(ar: &PakArchive, entry: usize, what: &str) {
let Ok(by) = ar.read(&ar.entries()[entry]) else {
return;
};
let Some(b) = ui_layout::parse_build(&by) else {
return;
};
let mut rows: Vec<(i32, String, u32)> = b
.elements
.iter()
.filter(|e| e.name.starts_with("ptbtn") && !e.name.contains('f'))
.map(|e| {
let y = e.rest().map(|k| k.y).unwrap_or(e.pivot_y as i32);
(y, e.name.clone(), e.kind)
})
.collect();
rows.sort_by_key(|r| r.0);
println!("\n{what} (entry {entry}) — buttons top to bottom:");
for (y, n, k) in &rows {
println!(" y {y:5} {n:14} kind 0x{k:04x}");
}
if let Some((_, first, _)) = rows.first() {
println!(" => TOP item is {first}");
}
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE.pak");
report(&ar, 5, "CONTROL: main menu (NEW GAME must be top)");
report(&ar, 6, "EXTRAS");
}

View File

@@ -5,8 +5,8 @@
//! assembler and the viewer) can reach a different answer from a whole-container
//! decode. This measures that directly.
//! Usage: filter_consistency <container.xpr> [resource...]
use sylpheed_formats::mesh::Xbg7Model;
use std::collections::HashSet;
use sylpheed_formats::mesh::Xbg7Model;
fn main() {
let a: Vec<String> = std::env::args().collect();
let bytes = std::fs::read(&a[1]).expect("container");
@@ -27,9 +27,16 @@ fn main() {
if off(f) != off(s) {
differ += 1;
if differ <= 10 {
println!("{n}: full decode at 0x{:x}, filtered at 0x{:x}", off(f), off(s));
println!(
"{n}: full decode at 0x{:x}, filtered at 0x{:x}",
off(f),
off(s)
);
}
}
}
println!("{differ} of {} resources decode differently when filtered", names.len());
println!(
"{differ} of {} resources decode differently when filtered",
names.len()
);
}

View File

@@ -0,0 +1,69 @@
//! Where does the `DIFFICULTY` screen live?
//!
//! `boot-config-and-gamepart-registry.md` records a count-match — "Ⓑ = event 0,
//! four menu items load an external archive, EXTRAS stays inside GP_TITLE" —
//! explicitly as an observation, not a decode. The disc can test half of it:
//! OPTIONS, LOAD GAME and TUTORIAL have their own paks, and EXTRAS' two items
//! have GP_MISSION_SELECT / GP_MOVIE_THEATER while EXTRAS itself is GP_TITLE
//! entries 6/9. NEW GAME is the fourth, and there is no GP_DIFFICULTY.pak.
//!
//! So: which archive holds a build with EASY / NORMAL / HARD buttons?
//!
//! CONTROL: the same scan must find the EXTRAS build in GP_TITLE, whose location
//! is independently known (entries 6/9, buttons ptbtn11/12/13).
//!
//! cargo run -p sylpheed-formats --example find_difficulty_build
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let dat = root.join("dat");
let mut paks: Vec<_> = std::fs::read_dir(&dat)
.expect("dat")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().map(|x| x == "pak").unwrap_or(false))
.collect();
paks.sort();
let mut found_extras = false;
for p in &paks {
let Ok(ar) = PakArchive::open(p) else {
continue;
};
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let btns: Vec<&String> = b
.records
.keys()
.filter(|n| n.starts_with("ptbtn") || n.contains("btn"))
.collect();
if btns.len() != 8 {
continue;
}
let name = p.file_name().unwrap().to_string_lossy();
// CONTROL: the known MAIN MENU build (11 records, so this control is now vacuous) must show up.
if name == "GP_TITLE.pak" && (i == 5 || i == 8) {
found_extras = true;
println!("CONTROL {name} entry {i}: {} button records — the known MAIN MENU build (11 records, so this control is now vacuous)",
btns.len());
}
// any build outside GP_TITLE with a small button set is a candidate
if name != "GP_TITLE.pak" {
let mut names: Vec<String> = btns.iter().map(|s| (*s).clone()).collect();
names.sort();
println!(
" {name:28} entry {i:3} {} buttons {:?}",
btns.len(),
&names[..names.len().min(8)]
);
}
}
}
println!("\ncontrol {} — the known MAIN MENU build (11 records, so this control is now vacuous) was {}found",
if found_extras { "PASSED" } else { "FAILED" },
if found_extras { "" } else { "NOT " });
}

View File

@@ -0,0 +1,68 @@
//! Where is the `DIFFICULTY` screen? Search by NAME, not by structure.
//!
//! A previous pass searched every pak for a build with exactly 8 `btn`-named
//! records, on the assumption that DIFFICULTY's four items (EASY / NORMAL / HARD
//! / BACK) pair with `f` focus variants the way GP_TITLE's screens do. Nothing
//! plausible turned up, and the assumption was mine — recorded as a negative
//! narrower than "not found" (data/gp-title-holds-three-button-screens.txt).
//!
//! This drops the structural assumption and looks for the words instead, across
//! every sprite AND record name in every build on the disc.
//!
//! CONTROL: the same scan must find `ptbtn11` in GP_TITLE — a name whose home is
//! independently known — when asked for it. A name scan that finds nothing
//! proves nothing unless it can find something.
//!
//! cargo run -p sylpheed-formats --example find_difficulty_names
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
const WANTED: &[&str] = &["easy", "normal", "hard", "diff", "level", "rank"];
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let mut paks: Vec<_> = std::fs::read_dir(root.join("dat"))
.expect("dat")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().map(|x| x == "pak").unwrap_or(false))
.collect();
paks.sort();
let mut control = false;
let mut hits = 0usize;
for p in &paks {
let Ok(ar) = PakArchive::open(p) else {
continue;
};
let pname = p.file_name().unwrap().to_string_lossy().to_string();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let all: Vec<String> = b.sprites.keys().chain(b.records.keys()).cloned().collect();
if pname == "GP_TITLE.pak" && all.iter().any(|n| n.contains("ptbtn11")) {
control = true;
}
let m: Vec<&String> = all
.iter()
.filter(|n| {
let l = n.to_lowercase();
WANTED.iter().any(|w| l.contains(w))
})
.collect();
if !m.is_empty() {
hits += 1;
let mut s: Vec<String> = m.iter().map(|x| (*x).clone()).collect();
s.sort();
s.dedup();
println!(" {pname:28} entry {i:3} {:?}", &s[..s.len().min(6)]);
}
}
}
println!(
"\ncontrol (found ptbtn11 in GP_TITLE): {}",
if control { "PASSED" } else { "FAILED" }
);
println!("{hits} build(s) carried a difficulty-ish name");
}

View File

@@ -7,8 +7,8 @@
//! mirrored pair.
//!
//! Usage: find_mirror <container.xpr> <resource>...
use sylpheed_formats::mesh::Xbg7Model;
use std::collections::HashSet;
use sylpheed_formats::mesh::Xbg7Model;
fn main() {
let a: Vec<String> = std::env::args().collect();
@@ -18,7 +18,12 @@ fn main() {
let be = |at: usize| f32::from_be_bytes(bytes[at..at + 4].try_into().unwrap());
for m in &models {
let pos: Vec<[f32; 3]> = m.meshes.iter().flat_map(|s| s.positions.clone()).take(8).collect();
let pos: Vec<[f32; 3]> = m
.meshes
.iter()
.flat_map(|s| s.positions.clone())
.take(8)
.collect();
if pos.len() < 8 {
continue;
}

View File

@@ -0,0 +1,125 @@
//! Which cue owns an XMA stream of a given payload size?
//!
//! A boot with `--xma_param_probe` logs each decoded stream's `byte_size`. Three
//! of the five on the take-2 `ADV` boot are that movie's own streams; two —
//! 1 150 976 and 1 269 760 B — belong to something unidentified. The probe gives
//! a size and nothing else, so the disc has to be asked which cue has a stream
//! that long.
//!
//! Searches every inter-descriptor span of the continuous voice stream, and
//! every `sound.pak` entry, for a stream whose payload matches.
//!
//! cargo run -p sylpheed-formats --example find_stream_by_size -- <disc> <bytes>…
use sylpheed_formats::media::{DirectorySource, DiscSource};
use sylpheed_formats::{slb, PakArchive};
const DESC_MARK: u32 = 0x11;
const DESC_REPEAT: usize = 0x800;
const ID_MAX: u32 = 0x1_0000;
fn all_descriptors(buf: &[u8]) -> Vec<(usize, u32)> {
let be = |o: usize| u32::from_be_bytes([buf[o], buf[o + 1], buf[o + 2], buf[o + 3]]);
let mut out = Vec::new();
if buf.len() < DESC_REPEAT + 8 {
return out;
}
let end = buf.len() - (DESC_REPEAT + 4);
let mut o = 0;
while o <= end {
let id = be(o);
if (1..ID_MAX).contains(&id) && be(o + 4) == DESC_MARK && be(o + DESC_REPEAT) == id {
out.push((o, id));
}
o += 4;
}
out
}
fn main() {
let mut args = std::env::args().skip(1);
let disc = args
.next()
.expect("usage: find_stream_by_size <disc> <bytes>…");
let wanted: Vec<usize> = args.filter_map(|a| a.parse().ok()).collect();
assert!(!wanted.is_empty(), "give at least one payload size");
// A `to_xma_riffs` chunk is the payload plus a 60-byte RIFF wrapper.
let want_riff: Vec<usize> = wanted.iter().map(|w| w + 60).collect();
println!("looking for payloads {wanted:?} (riff sizes {want_riff:?})\n");
let src = DirectorySource::new(std::path::PathBuf::from(&disc));
// --- 1. the continuous movie-voice stream, span by span
let tpak = src.open_pak("dat/tables.pak").expect("tables.pak");
let marker = "eng\\Movie\\VOICE_ADV.slb";
let registry = tpak
.entries()
.iter()
.find_map(|e| {
tpak.read(e)
.ok()
.filter(|b| b.windows(marker.len()).any(|w| w == marker.as_bytes()))
})
.expect("registry");
let ids = sylpheed_formats::movie_voice::registry_voice_ids(&registry);
let name_of: std::collections::HashMap<u32, String> =
ids.iter().map(|(n, &i)| (i, n.clone())).collect();
let win_start: u64 = 421_739_888 & !3;
let buf = src
.read_segment_range("dat/sound", win_start, 116_300_000)
.expect("window");
let descs = all_descriptors(&buf);
println!("voice stream: {} descriptors", descs.len());
let mut hits = 0;
for w in descs.windows(2) {
let (a, b) = (w[0].0, w[1].0);
if b <= a || b - a < 4096 {
continue;
}
for (i, r) in slb::to_xma_riffs(&buf[a..b]).iter().enumerate() {
if want_riff.contains(&r.len()) {
let name = name_of
.get(&w[1].1)
.cloned()
.unwrap_or_else(|| format!("id{}", w[1].1));
println!(
" ✅ cue {name} (id {}) stream {i}: payload {} B",
w[1].1,
r.len() - 60
);
hits += 1;
}
}
}
println!(" {hits} hit(s) in the voice stream\n");
// --- 2. every sound.pak entry
let stoc = src.read_file("dat/sound.pak").expect("sound.pak toc");
let entries = PakArchive::parse_toc(&stoc).expect("toc");
println!("sound.pak: {} entries", entries.len());
let mut phits = 0;
let mut scanned = 0usize;
for e in &entries {
// Only entries big enough to hold the target.
let need = wanted.iter().copied().min().unwrap_or(0) as u32;
if e.comp_size < need {
continue;
}
let Ok(bytes) = src.read_segment_range("dat/sound", e.offset as u64, e.comp_size as usize)
else {
continue;
};
scanned += 1;
for (i, r) in slb::to_xma_riffs(&bytes).iter().enumerate() {
if want_riff.contains(&r.len()) {
println!(
" ✅ sound.pak entry hash {:08x} offset {} size {} — stream {i}: payload {} B",
e.name_hash,
e.offset,
e.comp_size,
r.len() - 60
);
phits += 1;
}
}
}
println!(" scanned {scanned} entries large enough; {phits} hit(s)");
}

View File

@@ -1,16 +1,22 @@
use sylpheed_formats::{game_data as gd, PakArchive};
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let pak=PakArchive::open(format!("{disc}/dat/GP_HANGAR_ARSENAL.pak")).unwrap();
let rosters=gd::load_pilot_rosters(&pak);
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let pak = PakArchive::open(format!("{disc}/dat/GP_HANGAR_ARSENAL.pak")).unwrap();
let rosters = gd::load_pilot_rosters(&pak);
// distinct rosters by their pilot set
let mut seen=std::collections::BTreeSet::new(); let mut shown=0;
let mut seen = std::collections::BTreeSet::new();
let mut shown = 0;
println!("{} pilot-roster configs; distinct line-ups:", rosters.len());
for r in &rosters{
let key:String=r.pilots().iter().map(|(c,p)|format!("{c}:{p}")).collect::<Vec<_>>().join(",");
if seen.insert(key) && shown<8 {
shown+=1;
let flt:Vec<String>=r.pilots().iter().map(|(c,p)|format!("{c}={p}")).collect();
for r in &rosters {
let key: String = r
.pilots()
.iter()
.map(|(c, p)| format!("{c}:{p}"))
.collect::<Vec<_>>()
.join(",");
if seen.insert(key) && shown < 8 {
shown += 1;
let flt: Vec<String> = r.pilots().iter().map(|(c, p)| format!("{c}={p}")).collect();
println!(" {}", flt.join(" "));
}
}

View File

@@ -0,0 +1,98 @@
//! Which focus records have a VARYING alpha — disc-wide, not export-wide?
//!
//! `rest()` returns an element's last hold keyframe. For a constant-alpha
//! element that is harmless. For one that pulses it returns the PEAK, which is
//! the `ui-settle-time.md` pathology: the plate's `ptbtn00f` ramps 0→80→0 and
//! `rest()` reports 80, its maximum.
//!
//! The port censused this over its own export (34 records, 2 varying) and
//! concluded there is nothing to fix. That conclusion is only as wide as the
//! export. This asks the same question of the whole disc.
use sylpheed_formats::{pak, ratc, ui_layout};
fn main() {
let root =
std::env::var("SYLPHEED_DISC").expect("set SYLPHEED_DISC to the extracted disc root");
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat"))
.expect("dat/")
.flatten()
.map(|e| e.path())
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak"))
.collect();
paks.sort();
let (mut n_rec, mut n_elem, mut varying) = (0usize, 0usize, 0usize);
let (mut at_peak, mut mid_ramp) = (0usize, 0usize);
let mut by_pak: std::collections::BTreeMap<String, usize> = Default::default();
let mut hits: Vec<String> = Vec::new();
for p in &paks {
let pn = p.file_name().unwrap().to_string_lossy().to_string();
let Ok(ar) = pak::PakArchive::open(p) else {
continue;
};
for (ei, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
if !ratc::is_ratc(&by) {
continue;
}
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
for (rn, &(o, s)) in &b.records {
// A focus record is one whose name is another record's plus `f`.
let Some(stem) = rn.strip_suffix("f.rat") else {
continue;
};
if !b.records.contains_key(&format!("{stem}.rat")) {
continue;
}
if o + s > by.len() {
continue;
}
let Some(lb) = ui_layout::parse_build(&by[o..o + s]) else {
continue;
};
n_rec += 1;
for el in &lb.elements {
if el.keyframes.is_empty() {
continue;
}
n_elem += 1;
let a: Vec<u32> = el.keyframes.iter().map(|k| k.fade >> 24).collect();
let (lo, hi) = (*a.iter().min().unwrap(), *a.iter().max().unwrap());
if lo == hi {
continue;
}
varying += 1;
let rest = el.rest().map(|k| k.fade >> 24).unwrap_or(0);
if rest == hi {
at_peak += 1
} else {
mid_ramp += 1
}
*by_pak.entry(pn.clone()).or_default() += 1;
hits.push(format!(
"{pn} [{ei}] {rn}::{} alpha {lo}..{hi} rest()={rest}{}",
el.name,
if rest == hi { " 🔴 == PEAK" } else { "" }
));
}
}
}
}
println!("focus records disc-wide : {n_rec}");
println!(" their timed elements : {n_elem}");
println!(" with a VARYING alpha : {varying}");
println!(" of which rest() == the PEAK : {at_peak} <- burns bright forever");
println!(" of which rest() is MID-RAMP : {mid_ramp} <- neither extreme; looks plausible");
println!("\nby pak:");
for (k, v) in &by_pak {
println!(" {k:<34} {v}")
}
println!("\nevery varying one:");
hits.sort();
hits.dedup();
for h in &hits {
println!(" {h}")
}
println!("\n({} distinct)", hits.len());
}

View File

@@ -0,0 +1,99 @@
//! Reconcile two ink counts for one screen that were never counting the same pixels.
//!
//! The port agent double-witnessed the pixel-cost claim in Godot — a renderer
//! sharing no code with `compose` — and got `GP_TITLE` entry 12 at **59 530 px**
//! ink above threshold 0 and **48 368** above 1. This crate reported **49 771**.
//! Neither is wrong; the question is which convention each was using, and on a
//! mostly-dark frame the answer moves thousands of pixels.
//!
//! So: count the same composite every way, and print the family. Whichever row
//! the port's numbers land in is the convention, and then the two renderers can be
//! compared on purpose rather than by coincidence.
//!
//! cargo run -p sylpheed-formats --example forced_backdrop_ink_thresholds
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
use ui_layout::ComposeOptions;
fn order_without_rule(build: &ui_layout::UiBuild, bundle: &[u8]) -> Vec<usize> {
let mut idx: Vec<usize> = (0..build.elements.len()).collect();
idx.sort_by_key(|&i| {
let el = &build.elements[i];
(
ui_layout::sprite_layer_key(build, bundle, el)
.or_else(|| ui_layout::implied_layer_key(&el.name))
.unwrap_or(u32::MAX),
i,
)
});
idx
}
fn counts(rgba: &[u8], t: u8) -> (usize, usize) {
let rgb = rgba
.as_chunks::<4>()
.0
.iter()
.filter(|p| p[0] > t || p[1] > t || p[2] > t)
.count();
let alpha = rgba.as_chunks::<4>().0.iter().filter(|p| p[3] > t).count();
(rgb, alpha)
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE.pak");
for entry in [12usize, 15] {
let by = ar.read(&ar.entries()[entry]).expect("entry");
let b = ui_layout::parse_build(&by).expect("parse");
for (label, opts) in [
(
"primitives on (what the cost run used)",
ComposeOptions {
include_primitives: true,
backdrop: [0, 0, 0, 255],
..Default::default()
},
),
(
"primitives+focus+animated",
ComposeOptions {
include_primitives: true,
include_focus: true,
include_animated: true,
backdrop: [0, 0, 0, 255],
..Default::default()
},
),
] {
let with = ui_layout::derived_paint_order(&b, &by);
let without = order_without_rule(&b, &by);
let a = ui_layout::compose_with_order(&b, &by, opts, None, Some(&with));
let c = ui_layout::compose_with_order(&b, &by, opts, None, Some(&without));
println!(
"\n== GP_TITLE entry {entry}{label} ({}x{})",
a.width, a.height
);
println!(
" threshold | RGB>t with rule | A>t with rule | RGB>t WITHOUT | A>t WITHOUT"
);
for t in [0u8, 1, 2, 4, 8, 16] {
let (r1, a1) = counts(&a.rgba, t);
let (r0, a0) = counts(&c.rgba, t);
println!(" >{t:<8} | {r1:>16} | {a1:>14} | {r0:>13} | {a0:>11}");
}
let changed = a
.rgba
.as_chunks::<4>()
.0
.iter()
.zip(c.rgba.as_chunks::<4>().0.iter())
.filter(|(x, y)| x != y)
.count();
println!(" exact-RGBA changed pixels between the two orders: {changed}");
}
}
}

View File

@@ -0,0 +1,73 @@
//! Of the forced instances the rule merely CONFIRMS, how many have a key READ
//! FROM THE FILE, and how many an IMPLIED key that is itself a measurement?
//!
//! `forced_backdrop_necessity.rs` asked only whether an element had *a* key,
//! collapsing `sprite_layer_key` (a `u16` read out of the `T8aD` header — decoded)
//! with `implied_layer_key` (this crate's per-name table of positions **measured
//! in the running game**). For counting whether the rule moves anything that is
//! the right question. For describing what a confirmation is *made of*, it is not:
//! "the file already settles it" and "another measurement already settles it" are
//! different claims, and a reader who sees "own key" will take the first.
//!
//! Raised by the port agent 2026-08-30.
//!
//! cargo run -p sylpheed-formats --example forced_backdrop_key_source
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let mut paks: Vec<PathBuf> = std::fs::read_dir(root.join("dat"))
.expect("dat/")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().is_some_and(|x| x == "pak"))
.collect();
paks.sort();
let (mut read, mut implied, mut none) = (0usize, 0usize, 0usize);
println!("# archive entry element key_source key");
for pak in &paks {
let Ok(ar) = PakArchive::open(pak) else {
continue;
};
let name = pak.file_name().unwrap().to_string_lossy().to_string();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
for el in &b.elements {
if !ui_layout::forced_backdrop(&b, el) {
continue;
}
let (src, key) = match ui_layout::sprite_layer_key(&b, &by, el) {
Some(k) => {
read += 1;
("read_T8aD", Some(k))
}
None => match ui_layout::implied_layer_key(&el.name) {
Some(k) => {
implied += 1;
("implied_MEASURED", Some(k))
}
None => {
none += 1;
("none", None)
}
},
};
println!(
" {name} {i} {} {src} {}",
el.name,
key.map(|k| format!("0x{k:08X}")).unwrap_or("-".into())
);
}
}
}
println!("\n# forced instances by key source:");
println!("# read from the T8aD header (decoded): {read}");
println!("# implied — this crate's MEASURED name table: {implied}");
println!("# none — only forced_backdrop can speak: {none}");
}

View File

@@ -0,0 +1,117 @@
//! Which screens does `forced_backdrop` DECIDE, and which does it merely agree with?
//!
//! Every check this corpus has run on the rule measured its **stability** — that
//! no verdict moved when something else changed. That is a different property
//! from **necessity**: an element whose position is already fixed by a read or an
//! implied key is confirmed by the rule, not decided by it.
//!
//! So: compute `derived_paint_order` with the rule, and again with the
//! `forced_backdrop` fallback removed, and report every entry whose order moves.
//! Where nothing moves, the rule is decorative on that screen; where it moves,
//! the rule is the only thing holding the order up.
//!
//! Raised by the port agent 2026-08-30. Reach note in
//! `docs/re/structures/ui-forced-backdrop.md`.
//!
//! cargo run -p sylpheed-formats --example forced_backdrop_necessity -- [pak...]
//!
//! 🔴 With no argument this used to default to `GP_TITLE` alone, so a bare run
//! reported **6 instances, not 80** — a thirteenth of the census, printed in the
//! same format and reading like the whole thing. The port agent hit it and nearly
//! filed the discrepancy back at me. It now walks every `dat/*.pak` by default and
//! says on stderr how many archives it opened, because "I ran your instrument" has
//! to mean the same thing to both of us.
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn order_without_rule(build: &ui_layout::UiBuild, bundle: &[u8]) -> Vec<usize> {
let mut idx: Vec<usize> = (0..build.elements.len()).collect();
idx.sort_by_key(|&i| {
let el = &build.elements[i];
(
ui_layout::sprite_layer_key(build, bundle, el)
.or_else(|| ui_layout::implied_layer_key(&el.name))
.unwrap_or(u32::MAX),
i,
)
});
idx
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let (mut total_decides, mut total_agrees) = (0usize, 0usize);
let mut paks: Vec<PathBuf> = std::env::args().skip(1).map(PathBuf::from).collect();
if paks.is_empty() {
let mut all: Vec<PathBuf> = std::fs::read_dir(root.join("dat"))
.expect("dat/")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().is_some_and(|x| x == "pak"))
.collect();
all.sort();
paks = all;
}
eprintln!("# scanning {} archive(s)", paks.len());
for path in &paks {
let ar = PakArchive::open(path).expect("pak");
println!("# {}", path.display());
println!("# entry forced decides elements note");
let mut decides = Vec::new();
let mut agrees = Vec::new();
#[allow(unused)]
let _ = (&decides, &agrees);
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let with = ui_layout::derived_paint_order(&b, &by);
let without = order_without_rule(&b, &by);
// Which elements does the rule fire on, and of those, which have no key
// of their own to fall back on?
let mut forced = Vec::new();
let mut keyless = Vec::new();
for el in &b.elements {
if !ui_layout::forced_backdrop(&b, el) {
continue;
}
forced.push(el.name.clone());
let own = ui_layout::sprite_layer_key(&b, &by, el)
.or_else(|| ui_layout::implied_layer_key(&el.name));
if own.is_none() {
keyless.push(el.name.clone());
}
}
if forced.is_empty() {
continue;
}
let moved = with != without;
if moved {
decides.push(i);
} else {
agrees.push(i);
}
println!(
" {i:>5} {:>6} {:>7} {:>8} forced=[{}] keyless=[{}]",
forced.len(),
if moved { "YES" } else { "no" },
b.elements.len(),
forced.join(","),
keyless.join(","),
);
}
println!("# rule DECIDES the order on entries {decides:?}");
println!("# rule merely AGREES on entries {agrees:?}\n");
total_decides += decides.len();
total_agrees += agrees.len();
}
println!(
"# TOTAL over {} archive(s): {total_decides} deciding entries, \
{total_agrees} agreeing",
paks.len()
);
}

View File

@@ -0,0 +1,125 @@
//! What does `forced_backdrop` cost IN PIXELS on the screens it decides?
//!
//! `forced_backdrop_necessity.rs` answers "does the derived ORDER move", which is
//! a property of the sort. The port agent then pointed out — correctly — that its
//! re-run of that probe was **my code executed twice**, not a second witness, so
//! the disc-wide 62 has one measurement behind it and only `GP_TITLE` has two.
//!
//! This does not fix that (it is still this crate), but it moves the question to a
//! **different layer**: render each deciding build twice, once in the order
//! `compose` derives and once with the `forced_backdrop` fallback removed, and
//! count the pixels that differ. "The order moved" and "the picture moved" are not
//! the same claim, and the second is the one anybody cares about — the tie-break
//! work already found overlapping reorders that cost exactly zero pixels.
//!
//! Each entry carries its own CONTROL: the pixel count of the composite itself.
//! If a build renders empty, its zero means the instrument saw nothing, not that
//! the rule is free.
//!
//! cargo run -p sylpheed-formats --example forced_backdrop_pixel_cost -- [pak...]
//!
//! With no argument it walks **every `dat/*.pak`** — the necessity probe defaulted
//! to `GP_TITLE`, which made a bare run report a thirteenth of the census and read
//! like the whole thing.
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
use ui_layout::ComposeOptions;
fn order_without_rule(build: &ui_layout::UiBuild, bundle: &[u8]) -> Vec<usize> {
let mut idx: Vec<usize> = (0..build.elements.len()).collect();
idx.sort_by_key(|&i| {
let el = &build.elements[i];
(
ui_layout::sprite_layer_key(build, bundle, el)
.or_else(|| ui_layout::implied_layer_key(&el.name))
.unwrap_or(u32::MAX),
i,
)
});
idx
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let mut paks: Vec<PathBuf> = std::env::args().skip(1).map(PathBuf::from).collect();
if paks.is_empty() {
let mut all: Vec<PathBuf> = std::fs::read_dir(root.join("dat"))
.expect("dat/")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().is_some_and(|x| x == "pak"))
.collect();
all.sort();
paks = all;
}
eprintln!("# scanning {} archive(s)", paks.len());
let opts = ComposeOptions {
include_primitives: true,
backdrop: [0, 0, 0, 255],
..Default::default()
};
println!("# archive entry element changed_px total_px ink_px(control) pct");
let (mut decided, mut zero_cost, mut blind) = (0usize, 0usize, 0usize);
for pak in &paks {
let Ok(ar) = PakArchive::open(pak) else {
continue;
};
let name = pak.file_name().unwrap().to_string_lossy().to_string();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let with = ui_layout::derived_paint_order(&b, &by);
let without = order_without_rule(&b, &by);
if with == without {
continue;
}
let forced: Vec<&str> = b
.elements
.iter()
.filter(|el| ui_layout::forced_backdrop(&b, el))
.map(|el| el.name.as_str())
.collect();
let a = ui_layout::compose_with_order(&b, &by, opts, None, Some(&with));
let c = ui_layout::compose_with_order(&b, &by, opts, None, Some(&without));
let n = a
.rgba
.as_chunks::<4>()
.0
.iter()
.zip(c.rgba.as_chunks::<4>().0.iter())
.filter(|(x, y)| x != y)
.count();
// Control: does this build put any ink down at all, against the bare
// backdrop? A build that renders to nothing cannot show a reorder.
let ink = a
.rgba
.as_chunks::<4>()
.0
.iter()
.filter(|p| p[..3] != [0, 0, 0])
.count();
let total = a.rgba.len() / 4;
decided += 1;
if ink == 0 {
blind += 1;
} else if n == 0 {
zero_cost += 1;
}
println!(
" {name} {i} {} {n} {total} {ink} {:.2}%",
forced.join(","),
100.0 * n as f64 / total as f64
);
}
}
println!("\n# builds whose ORDER the rule decides: {decided}");
println!("# of those, costing ZERO pixels: {zero_cost}");
println!("# of those, BLIND (build renders no ink, control fails): {blind}");
}

View File

@@ -0,0 +1,67 @@
//! Is `GP_DIALOG` 2/3 the ONLY build on the disc with four buttons at 259/329/399/469?
//!
//! Both agents recorded the same reach on the DIFFICULTY identification: entries
//! 2/3 are picked out by button count and geometry, not by a binding from
//! `DLG_SELECT_DIFFICULTY` to a pak entry, so "another four-button dialog with the
//! same rows would be indistinguishable". This tests whether such a rival exists.
//!
//! CONTROL: the scan must find GP_DIALOG 2 and 3 themselves. A rival-search that
//! cannot find the incumbent proves nothing.
//!
//! cargo run -p sylpheed-formats --example four_button_row_rivals
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
const WANT: [i32; 4] = [259, 329, 399, 469];
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let mut paks: Vec<_> = std::fs::read_dir(root.join("dat"))
.expect("dat")
.filter_map(|e| e.ok().map(|e| e.path()))
.filter(|p| p.extension().map(|x| x == "pak").unwrap_or(false))
.collect();
paks.sort();
let (mut incumbent, mut rivals) = (0, 0);
for p in &paks {
let Ok(ar) = PakArchive::open(p) else {
continue;
};
let pname = p.file_name().unwrap().to_string_lossy().to_string();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let mut ys: Vec<i32> = b
.elements
.iter()
.filter(|el| el.name.contains("btn") && !el.name.contains('f'))
.map(|el| el.rest().map(|k| k.y).unwrap_or(el.pivot_y as i32))
.collect();
ys.sort();
ys.dedup();
if ys.len() != 4 {
continue;
}
let close = ys.iter().zip(WANT.iter()).all(|(a, b)| (a - b).abs() <= 6);
if close {
let is_inc = pname == "GP_DIALOG.pak" && (i == 2 || i == 3);
if is_inc {
incumbent += 1
} else {
rivals += 1
}
println!(
" {}{pname:24} entry {i:4} rows {ys:?}",
if is_inc { "INCUMBENT " } else { "RIVAL " }
);
}
}
}
println!(
"\ncontrol: found {incumbent} incumbent build(s) (want 2) — {}",
if incumbent == 2 { "PASSED" } else { "FAILED" }
);
println!("{rivals} rival build(s) elsewhere on the disc");
}

View File

@@ -0,0 +1,83 @@
//! The main menu's sprites, by their ALPHA channel — is `ptframe1`/`ptframe2`'s
//! "no fully-opaque pixel" a property of the artwork, and does any alpha value
//! look like a scale the game expands (e.g. 0..128) rather than 0..255?
//!
//! The port measures both frames as rendering too DARK against the capture, with
//! the shortfall correlating with the BACKGROUND. Two different causes predict
//! that: a background-scaling blend selected in code, or an alpha that is too
//! LOW in our decode. This example tests the second, which is on the disc.
//!
//! cargo run -p sylpheed-formats --example frame_alpha_census
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, t8ad, ui_layout};
fn census(name: &str, img: &t8ad::T8adImage) {
let n = (img.width * img.height) as usize;
let mut hist = [0usize; 256];
for p in 0..n {
hist[img.rgba[p * 4 + 3] as usize] += 1;
}
let zero = hist[0];
let full = hist[255];
let max = (0..256).rev().find(|&a| hist[a] > 0).unwrap_or(0);
let nonzero = n - zero;
// the top five alpha values that actually occur, by population
let mut top: Vec<(usize, usize)> = (1..256)
.map(|a| (hist[a], a))
.filter(|&(c, _)| c > 0)
.collect();
top.sort_unstable_by_key(|a| std::cmp::Reverse(a.0));
let top5: Vec<String> = top
.iter()
.take(5)
.map(|&(c, a)| format!("{a}x{c}"))
.collect();
println!(
"{name:<16} {}x{:<4} px={n:<8} a=0:{:5.1}% a=255:{:5.1}% max={max:<3} \
partial(1..254)/nonzero={:5.1}% top:[{}]",
img.width,
img.height,
100.0 * zero as f64 / n as f64,
100.0 * full as f64 / n as f64,
if nonzero > 0 {
100.0 * (nonzero - full) as f64 / nonzero as f64
} else {
0.0
},
top5.join(" ")
);
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let argv: Vec<String> = std::env::args().skip(1).collect();
let pak = argv
.iter()
.find(|a| a.parse::<usize>().is_err())
.cloned()
.unwrap_or_else(|| "GP_TITLE".to_string());
let ar = PakArchive::open(root.join(format!("dat/{pak}.pak"))).expect("pak");
// Builds default to the two the port ships and can be overridden, so the
// same census serves the title (4) and the `PRESS (A)` plate (2).
let args: Vec<usize> = argv.iter().filter_map(|a| a.parse().ok()).collect();
let builds: Vec<usize> = if args.is_empty() { vec![5, 6] } else { args };
for build in builds {
let Ok(by) = ar.read(&ar.entries()[build]) else {
continue;
};
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
println!("=== {pak} build {build} ===");
let mut names: Vec<&String> = b.sprites.keys().collect();
names.sort();
for n in names {
let (off, size) = b.sprites[n];
let s = &by[off..(off + size).min(by.len())];
match t8ad::parse(s) {
Some(img) => census(n, &img),
None => println!("{n:<16} (not a T8aD / failed to parse)"),
}
}
}
}

View File

@@ -0,0 +1,79 @@
//! The keyframe record's two unexplained words (`+4`, `+8`) and the fade/tint —
//! do any of them separate the four elements the port measures as rendering too
//! dark (`ptframe1`/`2`, `ptframe3`/`4`) from the ones it measures as accurate?
//!
//! The T8aD header does not: no word and no bit of `+0x04`/`+0x08` puts the four
//! frames on one side and `pteff10` (max alpha 130, wholly semi-transparent, and
//! rendered nearly exact) on the other. The keyframe is the other place a
//! per-element draw mode could live.
//!
//! cargo run -p sylpheed-formats --example frame_keyframe_unknowns
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
println!(
"{:<22} {:>5} {:>3} {:>10} {:>10} {:>8} {:>8} {:>8}",
"element", "build", "kf", "unknown_4", "unknown_8", "fade", "tint", "rot"
);
let mut frame_sets: Vec<(String, i32, i32, u32, u32, i32)> = Vec::new();
let mut other_sets: Vec<(String, i32, i32, u32, u32, i32)> = Vec::new();
for build in [5usize, 6] {
let by = ar.read(&ar.entries()[build]).expect("entry");
let b = ui_layout::parse_build(&by).expect("build");
for e in &b.elements {
for (i, k) in e.keyframes.iter().enumerate() {
println!(
"{:<22} {build:>5} {i:>3} {:>10} {:>10} {:08X} {:08X} {:>8}",
e.name, k.unknown_4, k.unknown_8, k.fade, k.tint, k.rotation_deg
);
let row = (
e.name.clone(),
k.unknown_4,
k.unknown_8,
k.fade,
k.tint,
k.rotation_deg,
);
if e.name.contains("frame") {
frame_sets.push(row)
} else {
other_sets.push(row)
}
}
}
}
println!(
"\nframe keyframes: {} other keyframes: {}",
frame_sets.len(),
other_sets.len()
);
for (label, get) in [
("unknown_4", 0usize),
("unknown_8", 1),
("fade", 2),
("tint", 3),
("rotation", 4),
] {
let val = |r: &(String, i32, i32, u32, u32, i32)| -> i64 {
match get {
0 => r.1 as i64,
1 => r.2 as i64,
2 => r.3 as i64,
3 => r.4 as i64,
_ => r.5 as i64,
}
};
let fv: std::collections::BTreeSet<i64> = frame_sets.iter().map(val).collect();
let ov: std::collections::BTreeSet<i64> = other_sets.iter().map(val).collect();
let only_frames: Vec<&i64> = fv.iter().filter(|v| !ov.contains(v)).collect();
println!(
"{label:<10} frames take {:?} others take {} distinct values; frame-only values: {:?}",
fv,
ov.len(),
only_frames
);
}
}

View File

@@ -0,0 +1,96 @@
//! Which T8aD header word, if any, separates the FOUR elements the port measures
//! as rendering too dark (`ptframe1`/`2` on the main menu, `ptframe3`/`4` on
//! `EXTRAS`) from the elements on the same two screens it measures as accurate?
//!
//! The control that matters: `pteff10` has max alpha 130 and no fully-opaque
//! pixel — the same "wholly semi-transparent" property the port proposed as the
//! reason the frames are special — and it renders nearly exact. So the separator
//! must put `pteff10` on the ACCURATE side.
//!
//! cargo run -p sylpheed-formats --example frame_vs_accurate_words
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
let mut rows: Vec<(String, usize, Vec<u32>)> = Vec::new();
for build in [5usize, 6] {
let by = ar.read(&ar.entries()[build]).expect("entry");
let b = ui_layout::parse_build(&by).expect("build");
let mut names: Vec<&String> = b.sprites.keys().collect();
names.sort();
for n in names {
let (off, size) = b.sprites[n];
let s = &by[off..(off + size).min(by.len())];
if s.len() < 48 || &s[0..4] != b"T8aD" {
continue;
}
let ws: Vec<u32> = (0..12)
.map(|k| u32::from_be_bytes([s[k * 4], s[k * 4 + 1], s[k * 4 + 2], s[k * 4 + 3]]))
.collect();
rows.push((n.clone(), build, ws));
}
}
let is_frame = |n: &str| n.starts_with("ptframe");
println!(
"{:<16} {:>5} +0x04 +0x08 +0x1C +0x2C",
"sprite", "build"
);
for (n, b, w) in &rows {
println!(
"{n:<16} {b:>5} {:08X} {:08X} {:08X} {:08X}{}",
w[1],
w[2],
w[7],
w[11],
if is_frame(n) { " <- TOO DARK" } else { "" }
);
}
println!("\nwords where every ptframe* agrees and NO other sprite takes that value:");
let frames: Vec<&(String, usize, Vec<u32>)> =
rows.iter().filter(|(n, _, _)| is_frame(n)).collect();
let mut any = false;
for k in 0..12 {
let v = frames[0].2[k];
if !frames.iter().all(|r| r.2[k] == v) {
continue;
}
if rows.iter().any(|(n, _, w)| !is_frame(n) && w[k] == v) {
continue;
}
println!(" word {k} (+0x{:02X}) = {v:08X}", k * 4);
any = true;
}
if !any {
println!(" NONE — no header word separates the four frames from the rest");
}
println!(
"\nper-bit check on +0x04 and +0x08 (a bit that is 1 on all frames, 0 on all others):"
);
let mut anyb = false;
for &k in &[1usize, 2] {
for bit in 0..32 {
let on = |v: u32| (v >> bit) & 1 == 1;
if frames.iter().all(|r| on(r.2[k]))
&& rows.iter().all(|(n, _, w)| is_frame(n) || !on(w[k]))
{
println!(" +0x{:02X} bit {bit} (0x{:X})", k * 4, 1u32 << bit);
anyb = true;
}
if frames.iter().all(|r| !on(r.2[k]))
&& rows.iter().all(|(n, _, w)| is_frame(n) || on(w[k]))
{
println!(
" +0x{:02X} bit {bit} (0x{:X}) INVERTED",
k * 4,
1u32 << bit
);
anyb = true;
}
}
}
if !anyb {
println!(" NONE");
}
}

View File

@@ -1,11 +1,14 @@
//! Which gate stops the resources that never decode?
//! Usage: gate_histogram <resource3d_dir> [max_resources]
use sylpheed_formats::mesh::{debug_best_rejection, xbg7_resource_names, Xbg7Model};
use std::collections::{BTreeMap, HashSet};
use sylpheed_formats::mesh::{debug_best_rejection, xbg7_resource_names, Xbg7Model};
fn main() {
let dir = std::env::args().nth(1).expect("resource3d dir");
let cap: usize = std::env::args().nth(2).and_then(|s| s.parse().ok()).unwrap_or(usize::MAX);
let cap: usize = std::env::args()
.nth(2)
.and_then(|s| s.parse().ok())
.unwrap_or(usize::MAX);
let mut files: Vec<_> = std::fs::read_dir(&dir)
.unwrap()
.flatten()
@@ -20,7 +23,9 @@ fn main() {
if done >= cap {
break;
}
let Ok(bytes) = std::fs::read(f) else { continue };
let Ok(bytes) = std::fs::read(f) else {
continue;
};
let names = xbg7_resource_names(&bytes);
if names.is_empty() {
continue;

View File

@@ -0,0 +1,32 @@
//! Every button record in `GP_TITLE.pak`, per entry.
//!
//! Testing half of the count-match in boot-config-and-gamepart-registry.md:
//! "four menu items load an external archive, EXTRAS stays inside GP_TITLE".
//! If DIFFICULTY (NEW GAME's destination, EASY/NORMAL/HARD/BACK) is also inside
//! GP_TITLE, then NEW GAME loads nothing external and that reading is wrong.
//!
//! cargo run -p sylpheed-formats --example gp_title_buttons
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE.pak");
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else { continue };
let Some(b) = ui_layout::parse_build(&by) else {
continue;
};
let mut btns: Vec<String> = b
.records
.keys()
.filter(|n| n.starts_with("ptbtn"))
.cloned()
.collect();
btns.sort();
if btns.is_empty() {
continue;
}
println!("entry {i:2} {:2} button records {:?}", btns.len(), btns);
}
}

View File

@@ -0,0 +1,24 @@
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").unwrap());
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).unwrap();
for (i, e) in ar.entries().iter().enumerate() {
let Ok(by) = ar.read(e) else {
println!("{i:2} <unreadable>");
continue;
};
let names: Vec<String> = ui_layout::parse_build(&by)
.map(|b| b.sprites.keys().take(2).cloned().collect())
.unwrap_or_default();
let rec: Vec<String> = ui_layout::parse_build(&by)
.map(|b| b.records.keys().take(2).cloned().collect())
.unwrap_or_default();
println!(
"{i:2} {} B sprites {:?} records {:?}",
by.len(),
names,
rec
);
}
}

View File

@@ -0,0 +1,57 @@
//! Is `GP_TITLE.pak` really "8 screens shipped twice, EN/JP"?
//!
//! The Q2 headline says each screen appears twice. The entry dump raised a
//! doubt: entry 11 shows `palogo_gamearts` and entry 14 shows `palogo_seta`,
//! which are different studios, not a language pair. If the two halves of a
//! "pair" declare different sprites, "shipped twice" is the wrong description of
//! at least that pair.
//!
//! CONTROL: a pair known to be a real EN/JP pair must come out as matching. 2/3
//! (the PRESS Ⓐ plate) is byte-identical in size and is the control.
//!
//! cargo run -p sylpheed-formats --example gp_title_pair_check
use std::collections::BTreeSet;
use std::path::PathBuf;
use sylpheed_formats::{pak::PakArchive, ui_layout};
fn sprites(ar: &PakArchive, i: usize) -> BTreeSet<String> {
let Ok(by) = ar.read(&ar.entries()[i]) else {
return BTreeSet::new();
};
ui_layout::parse_build(&by)
.map(|b| b.sprites.keys().cloned().collect())
.unwrap_or_default()
}
fn main() {
let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE.pak");
let pairs = [
(0, 1, "loading plain"),
(2, 3, "PRESS (A) plate [CONTROL]"),
(4, 7, "title art"),
(5, 8, "main menu"),
(6, 9, "EXTRAS"),
(10, 13, "publisher splash"),
(11, 14, "developer splash"),
(12, 15, "loading dressed"),
];
for (a, b, what) in pairs {
let (sa, sb) = (sprites(&ar, a), sprites(&ar, b));
let only_a: Vec<_> = sa.difference(&sb).cloned().collect();
let only_b: Vec<_> = sb.difference(&sa).cloned().collect();
let shared = sa.intersection(&sb).count();
let verdict = if only_a.is_empty() && only_b.is_empty() {
"IDENTICAL SET"
} else {
"DIFFERS"
};
println!("\n{a:2}/{b:<2} {what:26} {shared:3} shared {verdict}");
if !only_a.is_empty() {
println!(" only in {a}: {only_a:?}");
}
if !only_b.is_empty() {
println!(" only in {b}: {only_b:?}");
}
}
}

View File

@@ -1,2 +1,7 @@
fn main(){let a:Vec<String>=std::env::args().collect();let b=std::fs::read(&a[1]).unwrap();
for l in sylpheed_formats::mesh::debug_grouped_report(&b,&a[2],a[3].parse().unwrap()){println!("{l}")}}
fn main() {
let a: Vec<String> = std::env::args().collect();
let b = std::fs::read(&a[1]).unwrap();
for l in sylpheed_formats::mesh::debug_grouped_report(&b, &a[2], a[3].parse().unwrap()) {
println!("{l}")
}
}

View File

@@ -1,43 +1,144 @@
use sylpheed_formats::{hash::name_hash, movie_manifest, movie_subtitle as ms, movie_voice, slb, PakArchive};
use std::fs;use std::io::{Read,Seek,SeekFrom};use std::process::Command;
fn rg(disc:&str,g:u64,n:usize)->Vec<u8>{let mut segs=vec![];let mut cum=0u64;for i in 0..5{let p=format!("{disc}/dat/sound.p{i:02}");if let Ok(m)=fs::metadata(&p){segs.push((cum,m.len(),p));cum+=m.len();}}let mut out=vec![];let(mut need,mut pos)=(n,g);for(base,len,path)in &segs{if need==0||pos>=base+len||pos<*base{continue;}let local=pos-base;let take=need.min((len-local)as usize);let mut f=fs::File::open(path).unwrap();f.seek(SeekFrom::Start(local)).unwrap();let mut b=vec![0u8;take];f.read_exact(&mut b).unwrap();out.extend_from_slice(&b);need-=take;pos+=take as u64;}out}
fn ct(h:&[u8],n:&[u8])->bool{h.windows(n.len()).any(|w|w==n)}
fn dur(w:&str)->String{let o=Command::new("ffprobe").args(["-v","error","-show_entries","format=duration","-of","default=nw=1:nk=1",w]).output().unwrap();String::from_utf8_lossy(&o.stdout).trim().to_string()}
fn main(){
let disc=std::env::var("SYLPHEED_DISC").unwrap();
let tpak=PakArchive::open(format!("{disc}/dat/tables.pak")).unwrap();
let man=tpak.entries().iter().find_map(|e|tpak.read(e).ok().filter(|b|movie_manifest::is_manifest(b))).unwrap();
let lpak=PakArchive::open(format!("{disc}/dat/movie/eng.pak")).unwrap();
let reg=tpak.entries().iter().find_map(|e|tpak.read(e).ok().filter(|b|ct(b,b"eng\\Movie\\VOICE_ADV.slb"))).unwrap();
let ids=movie_voice::registry_voice_ids(&reg);
let stoc=fs::read(format!("{disc}/dat/sound.pak")).unwrap();
let ents=PakArchive::parse_toc(&stoc).unwrap();
use std::fs;
use std::io::{Read, Seek, SeekFrom};
use std::process::Command;
use sylpheed_formats::{
hash::name_hash, movie_manifest, movie_subtitle as ms, movie_voice, slb, PakArchive,
};
fn rg(disc: &str, g: u64, n: usize) -> Vec<u8> {
let mut segs = vec![];
let mut cum = 0u64;
for i in 0..5 {
let p = format!("{disc}/dat/sound.p{i:02}");
if let Ok(m) = fs::metadata(&p) {
segs.push((cum, m.len(), p));
cum += m.len();
}
}
let mut out = vec![];
let (mut need, mut pos) = (n, g);
for (base, len, path) in &segs {
if need == 0 || pos >= base + len || pos < *base {
continue;
}
let local = pos - base;
let take = need.min((len - local) as usize);
let mut f = fs::File::open(path).unwrap();
f.seek(SeekFrom::Start(local)).unwrap();
let mut b = vec![0u8; take];
f.read_exact(&mut b).unwrap();
out.extend_from_slice(&b);
need -= take;
pos += take as u64;
}
out
}
fn ct(h: &[u8], n: &[u8]) -> bool {
h.windows(n.len()).any(|w| w == n)
}
fn dur(w: &str) -> String {
let o = Command::new("ffprobe")
.args([
"-v",
"error",
"-show_entries",
"format=duration",
"-of",
"default=nw=1:nk=1",
w,
])
.output()
.unwrap();
String::from_utf8_lossy(&o.stdout).trim().to_string()
}
fn main() {
let disc = std::env::var("SYLPHEED_DISC").unwrap();
let tpak = PakArchive::open(format!("{disc}/dat/tables.pak")).unwrap();
let man = tpak
.entries()
.iter()
.find_map(|e| tpak.read(e).ok().filter(|b| movie_manifest::is_manifest(b)))
.unwrap();
let lpak = PakArchive::open(format!("{disc}/dat/movie/eng.pak")).unwrap();
let reg = tpak
.entries()
.iter()
.find_map(|e| {
tpak.read(e)
.ok()
.filter(|b| ct(b, b"eng\\Movie\\VOICE_ADV.slb"))
})
.unwrap();
let ids = movie_voice::registry_voice_ids(&reg);
let stoc = fs::read(format!("{disc}/dat/sound.pak")).unwrap();
let ents = PakArchive::parse_toc(&stoc).unwrap();
// demo->token from bound hokyu
let hok:Vec<_>=movie_manifest::parse(&man).into_iter().filter(|m|m.movie.starts_with("hokyu_")).collect();
let resolve=|movie:&str|->Option<String>{
movie_manifest::voice_token(&man,movie).or_else(||{
let want=ms::track_voice_cues(&lpak,movie).first().map(|&(d,_)|d)?;
hok.iter().find_map(|e|{let t=e.voice_token.clone().filter(|_|e.movie.starts_with("hokyu_"))?; ms::track_voice_cues(&lpak,&e.movie).iter().any(|&(d,_)|d==want).then_some(t)})
let hok: Vec<_> = movie_manifest::parse(&man)
.into_iter()
.filter(|m| m.movie.starts_with("hokyu_"))
.collect();
let resolve = |movie: &str| -> Option<String> {
movie_manifest::voice_token(&man, movie).or_else(|| {
let want = ms::track_voice_cues(&lpak, movie)
.first()
.map(|&(d, _)| d)?;
hok.iter().find_map(|e| {
let t = e
.voice_token
.clone()
.filter(|_| e.movie.starts_with("hokyu_"))?;
ms::track_voice_cues(&lpak, &e.movie)
.iter()
.any(|&(d, _)| d == want)
.then_some(t)
})
})
};
for e in &hok{
let mv=&e.movie;
let bound=e.voice_token.is_some();
let tok=resolve(mv);
let demo=ms::track_voice_cues(&lpak,mv).first().map(|&(d,_)|d);
let mut d="".to_string();
if let Some(tok)=&tok{
if let Some(&id)=ids.get(tok){
if let Some(anchor)=["Movie","etc","Voice"].iter().find_map(|dir|{let h=name_hash(&format!("eng\\{dir}\\{tok}.slb"));ents.binary_search_by_key(&h,|x|x.name_hash).ok().map(|i|ents[i].offset as u64)}){
let ws=(anchor.saturating_sub(2*1024*1024))&!3; let win=rg(&disc,ws,8*1024*1024);
if let Some(el)=movie_voice::find_descriptor(&win,id){let end=ws+el as u64;
let start=movie_voice::find_descriptor(&win,id.wrapping_sub(1)).or_else(||movie_voice::find_descriptor_before(&win,el)).map(|o|ws+o as u64).filter(|&s|s<end&&end-s<1_500_000).unwrap_or(anchor);
let region=rg(&disc,start,(end-start)as usize); let mut rf=slb::to_xma_riffs(&region); if rf.is_empty(){rf=slb::to_xma_riff_best(&region).into_iter().collect();}
if let Some(r)=rf.first(){let xp=format!("/tmp/hd_{mv}.xma.wav");let wp=format!("/tmp/hd_{mv}.wav");fs::write(&xp,r).unwrap();let _=Command::new("ffmpeg").args(["-hide_banner","-v","error","-y","-i",&xp,&wp]).status();d=dur(&wp);}
for e in &hok {
let mv = &e.movie;
let bound = e.voice_token.is_some();
let tok = resolve(mv);
let demo = ms::track_voice_cues(&lpak, mv).first().map(|&(d, _)| d);
let mut d = "".to_string();
if let Some(tok) = &tok {
if let Some(&id) = ids.get(tok) {
if let Some(anchor) = ["Movie", "etc", "Voice"].iter().find_map(|dir| {
let h = name_hash(&format!("eng\\{dir}\\{tok}.slb"));
ents.binary_search_by_key(&h, |x| x.name_hash)
.ok()
.map(|i| ents[i].offset as u64)
}) {
let ws = (anchor.saturating_sub(2 * 1024 * 1024)) & !3;
let win = rg(&disc, ws, 8 * 1024 * 1024);
if let Some(el) = movie_voice::find_descriptor(&win, id) {
let end = ws + el as u64;
let start = movie_voice::find_descriptor(&win, id.wrapping_sub(1))
.or_else(|| movie_voice::find_descriptor_before(&win, el))
.map(|o| ws + o as u64)
.filter(|&s| s < end && end - s < 1_500_000)
.unwrap_or(anchor);
let region = rg(&disc, start, (end - start) as usize);
let mut rf = slb::to_xma_riffs(&region);
if rf.is_empty() {
rf = slb::to_xma_riff_best(&region).into_iter().collect();
}
if let Some(r) = rf.first() {
let xp = format!("/tmp/hd_{mv}.xma.wav");
let wp = format!("/tmp/hd_{mv}.wav");
fs::write(&xp, r).unwrap();
let _ = Command::new("ffmpeg")
.args(["-hide_banner", "-v", "error", "-y", "-i", &xp, &wp])
.status();
d = dur(&wp);
}
}
}
}
}
println!("{mv:16} {:8} demo={:?} -> {:11} voice={d}s", if bound{"BOUND"}else{"unbound"}, demo, tok.unwrap_or("(silent)".into()));
println!(
"{mv:16} {:8} demo={:?} -> {:11} voice={d}s",
if bound { "BOUND" } else { "unbound" },
demo,
tok.unwrap_or("(silent)".into())
);
}
}

Some files were not shown because too many files have changed in this diff Show More