f64fb8f2a4
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
Sylpheed
A clean-room reverse engineering and port project for Project Sylpheed: Arc of Deception (Xbox 360, 2007).
Three things live here, in one repository so that a change spanning them lands as one commit:
| The decoders | crates/sylpheed-formats — the disc's formats, read and verified disc-wide |
| The port | port/ — a Godot 4 project, plus crates/sylpheed-export which converts a disc into the open asset tree it reads |
| The corpus | docs/re/ — what has been reverse engineered, with its evidence, its retractions and its dead ends |
You need your own copy of the game. No game content is in this repository and none ever will be. The exporter reads the disc you supply.
The oracle is the real game
sylpheed-cliand the Explorer are tools for verifying our decoding. They are hypotheses under test and they have been wrong. When something must be checked against the truth, the truth is the game running in Xenia Canary, captured — not any renderer of ours.
This is stated first because getting it backwards is the most expensive mistake this project has made.
Layout
crates/
sylpheed-formats/ the decoders. Disc-wide verified; the corpus is its spec
sylpheed-cli/ headless tools -- render a screen, dump a table, probe audio
sylpheed-viewer/ the Explorer: a human's window onto the disc. STATIC data only
sylpheed-export/ disc -> the open, moddable asset tree
port/ the Godot 4 project. Reads open formats ONLY
authored/ decisions that are NOT on the disc, each with its reason
data/
base/ generated by the exporter. Gitignored, never hand-edited
mods/ drop-in overrides. Yours
docs/
re/ the corpus: findings, refutations, method traps
game/ how the game is navigated -- menus, modals, flight
port/ the port's mission, its handoff contract, modding rules
agents/ how the agent team works together
tools/ capture harnesses, probes, the share tool
exchange/ transient inter-agent files. NOT in git
docker/ the agent containers
Where to start
docs/re/INDEX.md— what is decodeddocs/re/REFUTED.md— what has been tested and dieddocs/re/METHOD.md— traps this project has already paid fordocs/game/navigation.md— how the game is navigateddocs/port/MODDING.md— why the asset tree looks the way it does
Xenia Canary is a separate repository: it is a fork tracking upstream, and it carries our instrumentation.
Conventions
Confidence is per claim, never per document: ✅ CONFIRMED · 🟡 PROBABLE ·
❔ HYPOTHESIS · ❌ REFUTED. A withdrawn result is kept with its reasoning
rather than deleted — that is why the numbers here can be trusted.