Syplheed-Reborn/docs/port/HANDOFF.md

# Handoff — what the menu port needs, and where it stands

The single page the **port agent** reads. Everything here is produced by the
container agent's reverse engineering; nothing here is a design decision about
the port itself.

Keep it current. It is a summary with links into `docs/re/`, not a second copy of
the findings — but an answer that is not reachable from this page has not been
delivered.

## How to read an answer

Every row below is one of exactly three things, and the distinction is the point:

| | meaning | what the port should do |
|---|---|---|
| **decoded** | a field on the disc, with a disc-wide check | read it from the data |
| **measured** | not on the disc in any form we found, but the running game does *this* | hardcode it, and cite this page |
| **undecodable** | we looked in these places, it is not there, here is the reach of the negative | author it by hand, knowingly |

There is no fourth kind. If a row says *measured* or *undecodable*, the port is
**authoring** that value, not transcribing it — and it should be kept somewhere a
human can see it is a human decision, so that when it is later decoded the
authored version can be deleted.

## Status

| | Question | State | Answer / link |
|---|---|---|---|
| Q1 | keyframe time unit + ramp shape | ✅ answered | ramp is **linear**; **2 units per rendered frame**; **`1 unit = 1/60 s` — settled**, the idle title presents at 28.5 fps so the game is 30 Hz — [`ui-keyframe-time-unit.md`](../re/ui-keyframe-time-unit.md) |
| Q2 | which build is which screen state | ✅ answered | `GP_TITLE` is **8 screens shipped twice, EN/JP**: 4/7 title art, 2/3 the `PRESS Ⓐ` plate, 5/8 main menu, 6/9 `EXTRAS`, 0/1 and 10/11 two unidentified `DELTASABER` plates — [`ui-title-build-map.md`](../re/ui-title-build-map.md) |
| Q3 | paint order for the six screens | ✅ answered | **decoded**: a `u16` layer key at `+0x0A` of each `T8aD` sprite header, stable-sorted with declaration index; unkeyed elements get an implied key. Confirmed on 5 measured orders + `EXTRAS` vs a capture. One residual: the **tie-break** is unknown and bites on one element of the title — [`structures/ui-paint-order-key.md`](../re/structures/ui-paint-order-key.md) |
| Q4 | button → GamePart | ✅ answered | **measured** which screen all **5** buttons open — `NEW GAME` → `DIFFICULTY` → `SELECT DATA`, not a hang. The **GamePart id is still a name match**, not a measurement — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) |
| Q5 | navigation semantics | ✅ answered | **measured**: initial focus varies boot to boot (2× `TUTORIAL`, 2× `NEW GAME`); ⬆⬇ one step, **wraps both ends**; ⬅➡ do nothing; Ⓑ returns to the parent **with focus restored**; Ⓑ on the main menu → title; Ⓑ on the title → nothing — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) |
| Q6 | boot sequence + what drives it | ✅ answered | sequence **measured** end to end; the driver is **code, not data** — four search spaces closed, so the port **authors** the sequence — [`boot-config-and-gamepart-registry.md`](../re/boot-config-and-gamepart-registry.md) |
| Q7 | transitions | ✅ answered | a **fade through black**, drawn by the screen's own last-painting `.prm` quad. Fade-in ramp is **decoded** from its keyframes; the ~0.4 s fade-out is **measured** (not in the file) — [`screen-transitions.md`](../re/screen-transitions.md) |
| Q8 | menu audio bindings | ✅ answered | cue vocabulary + bank **decoded**; event binding is a **name match** (the authors' own event names); SE audio is **undecodable from the disc** — no XACT container exists anywhere — [`menu-audio-cues.md`](../re/menu-audio-cues.md) |
| Q9 | video binding + playback rules | ✅ answered | **decoded** from the movie manifest: `ADVERTISE_MOVIE`→`ADV.wmv` (boot intro *and* attract are one asset), `MS00A`→`S00A.wmv` is the new-game intro, `STAFF_ROLL`→the credits reel. ✅ **one Ⓐ skips a movie** (title at 57 s vs a 193 s baseline) — [`movie-binding.md`](../re/movie-binding.md) |
| Q10 | music-bank sub-wave roles (intro+loop?) | ✅ answered | **two stems of one performance, played together** — sample-synchronous, equal duration, 32/32 banks. **Concatenating is wrong.** Not a seamless loop either — [`structures/bgm-two-stems.md`](../re/structures/bgm-two-stems.md) |
| S1 | Ready Room go/no-go | ✅ **no-go** | it is 2D and enumerates fine (60 builds), but `GP_READY_ROOM.pak` holds **briefing/tactical-map** content, not the six-button Ready Room menu — [`ready-room-probe.md`](../re/ready-room-probe.md) |

## Already settled — the port can rely on these today

* **`GP_TITLE.pak` is eight screens, each shipped twice — English and Japanese.**
  Build 4 is the English title art and 7 its Japanese twin; **2/3 are the
  `PRESS Ⓐ BUTTON` plate, a build of their own** composited over the title and
  faded in a beat later; 5/8 are the five-button main menu; 6/9 are the `EXTRAS`
  submenu — the **only** submenu inside this archive. Builds 0/1 and 10/11 are a
  `DELTASABER / SYLPHEED A.I.` plate that was **never seen running**, in the boot
  path, any title-side screen, or the attract loop. ✅ measured against live
  captures for the four English screens the boot path shows;
  [`ui-title-build-map.md`](../re/ui-title-build-map.md).
  **Withdrawn:** the earlier "builds 6/8/9 are submenus" — 8 is the Japanese main
  menu. The other four main-menu buttons leave the archive, and where each one
  goes is **measured** — see the button-destination bullet below.
* **Buttons are identifiable as data.** Element kind `0x3002` = button, `0x0` =
  decoration, `0x10` = primitive. ✅ decoded **for the title-side screens**.
  ⚠️ `0x3002` is one member of a `0x3000` family with sub-bits, and it is not the
  only button kind on the disc: `GP_READY_ROOM`'s 902 bundles contain **zero**
  `0x3002` and use `0x3000` / `0x3004` / `0x300c` / `0x3008` instead. Nothing in
  this milestone changes — every screen in scope is `GP_TITLE` — but do not ship
  `kind == 0x3002` as a general button test.
  (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.)
* **The title's motion, decoded and attributed.** After building in, the *title
  art* is essentially static — a 22 s capture measures the wordmark region at
  sd 0.06 and the bottom-right corner at sd 0.003. Two things do move:
  * ✅ **Two slow light sweeps in build 4.** `ptloop01.rat` (an `opt `-linked
    `RATC` at `0xbb5966`) sweeps `pteff03.t32` left→right over **450 units =
    7.5 s**; `ptloop02.rat` sweeps `pteff03a.t32` right→left over **570 units =
    9.5 s**. Ordinary 40-byte keyframe blocks from `+0x68`, three keyframes each.
  * ✅ **The `PRESS Ⓐ BUTTON` plate pulses**, and it is the loudest thing on
    screen — a capture's per-tile amplitude map puts **sd 7.65** in the band
    x ≈ 318–954, y ≈ 560–672 against **0.06** on the wordmark. It is
    `ptbtn00f.rat`, the plate's highlight variant (build **2**, not build 4),
    whose alpha ramps **`0x00 → 0x06 → 0x4a → 0x50` (hold) `→ 0x4a → 0x06 → 0x00`**
    over **eight** keyframes at `t = 6, 29, 35, 50, 58, 97, 105, ?` — a glow that
    fades in and back out, **closing on fully transparent**, so it is a complete
    cycle rather than a one-shot ramp.
  🟡 Its cycle **length** is not readable, and this is now observed rather than
  assumed: the eighth block's time slot literally contains the ASCII terminator
  `end `, so the record ends there and the value does not exist. Declared span is
  therefore **≥ 105 units = 1.75 s** against a measured **≈ 2.3 s** — which would
  need a final step of ≈ 33 units. That number is **fitted to the measurement, not
  read**; the port should take ≈ 2.3 s as measured.
  ⚠️ An earlier version of this bullet said "the title screen loops at ≈ 2.2 s"
  and attributed it to `ptloop01/02`. Both halves were wrong: it is the **plate**,
  and it is a different build.
* **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
  ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
  disc's real navigation structure is unknown, and `opt ` is *not* a focus link
  (measured and refuted, see
  [`ui-focus-and-effect-elements.md`](../re/structures/ui-focus-and-effect-elements.md)).
* **Highlighted states pair by name** — `ptbtn01.rat` ↔ `ptbtn01f.rat`. 🟡 a
  naming convention that holds for all 54 real pairs, not a decoded field.
* **`rest()` was wrong for elements with no exit animation — fixed 2026-08-28.**
  A trailing run of identical keyframes was always treated as the exit and
  excluded; on an element that has no exit it *is* the hold, and `rest()` fell
  back to the element's **first** keyframe — off-position and transparent. Six
  elements on the main menu were affected, including `ptframe1`/`ptframe2`, the
  bright circuit bracket around the menu, which both the port's composite **and**
  `sylpheed-cli screen render` were dropping.
  The rule now: **a trailing run is the hold exactly when it is visible** (alpha
  ≠ 0). ⚠️ Not the pose-equality test the report proposed — `pgptitle.rat`'s
  trailing run also matches its last timed keyframe, and adopting that would erase
  the word PAUSE. Oracle correlation over the bracket region improved
  **0.9596 → 0.9748**; the PAUSE control is unchanged.
  This also closes the old ❔ on `ptframe1`/`ptframe2` "resting at alpha 0 but the
  capture shows the frame plainly".
* **The resting pose is the hold**, not the first, last or longest-dwell keyframe;
  a keyframe is the **start of a ramp**.
  [`ui-resting-pose.md`](../re/structures/ui-resting-pose.md). ✅
* **That ramp is linear, and it runs at 2 keyframe time units per rendered
  frame.** Measured frame-by-frame off the running game's own draw stream: a
  declared 15-unit fade lands on `round(255·k/15)` for all seven of its samples,
  with `k` stepping 2, 4, 6, 8, 10, 12, 14 on seven consecutive submitted frames.
  **measured**, not decoded — the disc says `t=30`, it does not say what a `t` is.
  ✅ **The seconds conversion is settled: `1 unit = 1/60 s`, a 30 Hz title.** The
  re-test this page used to name has been run — 300 submitted frames timed on the
  **idle** title (nothing loading) came out at **28.8 and 28.3 fps**, the same
  rate as the 27.6 fps measured during the loading splash. The competing 60 Hz
  reading is excluded: it needs the emulator at 47 % of real time while idling on
  a screen that costs ~5 draws per frame.
  A second, independent line agrees — the transition quad is declared black for
  12 units (0.20 s under this conversion) and a capture measured the pure-black
  plateau at 0.17–0.23 s
  ([`screen-transitions.md`](../re/screen-transitions.md)).
  ⚠️ Still **measured, not decoded**: no field on the disc says "sixtieths of a
  second".
* **The paint order is derivable from the file.** Each `T8aD` sprite header
  carries a **`u16` layer key at `+0x0A`** (the upper half of the 32-bit word at
  `+0x08` is zero in all 21 184 sprites on the disc). Paint order is that key,
  **stable-sorted** so equal keys keep declaration order; elements with no sprite
  (`.prm` primitives, `.tbm`) have no key and take an implied one — the backdrop
  and dim quads sort early, the screen-transition fade (`pteff00.prm`,
  `pfeff00.prm`) sorts **last**. ✅ decoded. Checked against five paint orders read
  off the running game, one of them (`GP_SAVE_LOAD`'s slot-list header, 6
  instances) **exact and independent of the screens the rule was fitted to**, and
  against a fresh `EXTRAS` capture. It reorders 341 of the disc's 965 builds, so
  it is not a no-op dressed as a rule.
  🟡 **The one residual: ties.** Where two elements share a key the game
  sometimes paints them in an order nothing predicts — eight candidates refuted,
  including declaration order, RATC child order, keyframe times, resting X/Y and
  `kind`. Measured cost: on the three screens with ground truth it changes the
  blend of **one element on one screen** (a title glow). Take the stable sort and
  accept that.

* **Ⓑ returns to the title, and that title still works.** Ⓐ on the Ⓑ-returned
  title opens the main menu — measured, with Ⓐ on the boot title as the control in
  the same run. (Only the *attract*-returned title is inert, which is an emulator-
  harness curiosity, not a port concern.)
* **Menu movement, measured off the running game.** ⬆⬇ move one item per press
  and **wrap at both ends** (5-item main menu and 3-item `EXTRAS` both). ⬅➡ do
  nothing. Ⓑ goes up one level **and restores focus to the item you came from**;
  Ⓑ on the main menu returns to the title; Ⓑ on the title does nothing. **Initial
  focus is not stable**: four boots of the same script gave `TUTORIAL`,
  `TUTORIAL`, `NEW GAME`, `NEW GAME`. Do not hardcode it; pick one and say you
  picked it. All **measured**, none of it on the disc.
* **Each button's destination is measured; its GamePart id is not.**
  **`NEW GAME` → `DIFFICULTY`** (`EASY`/`NORMAL`/`HARD`/`BACK`, opening on
  `NORMAL`) **→ `SELECT DATA`** — it does *not* hang; the run then hits the
  already-documented `sub_823070B0` cache crash, which is not a menu problem.
  `LOAD GAME` → the save-slot list, `TUTORIAL` → the lesson list, `OPTIONS` →
  the settings menu, `EXTRAS` → `GP_TITLE` build 6, `EXTRAS ▸ MISSION SELECT` →
  the stage list. The
  GamePart ids (`3`, `25`, `8`, `5`, `7`) are the entries of the decoded id table
  whose **names match the screens seen**; that binding is authored, not measured.

* **A screen change is a fade through black.** Each screen carries a full-screen
  black `.prm` quad that paints last (`pteff00.prm` / `pfeff00.prm`) whose
  keyframe group *is* the transition: black at `T0`, clear by `T1`, clear until
  `T2`, then back to black on exit. ✅ decoded, with a disc-wide check — and in
  `GP_TITLE` exactly the six **screen** builds carry it while the six overlays do
  not. The fade-in length is `T1 − T0` and is read from the file (0.87 s for
  `EXTRAS`, 0.97 s main menu, 4.08 s title). ❔ **The fade-OUT length is not on
  the disc** — the last keyframe has no time slot; **measured ~0.4 s**, twice.
  The black hold measures 0.17–0.23 s. ⚠️ Do not time the fade-in off a capture's
  brightness: the incoming screen's own element animations dominate it and run
  much longer than the quad.

* **The movie manifest names every boot-side video by role.** `dat/tables.pak`
  entry `0x5b983a08`: `LOGO1`–`LOGO4` → `logo1.wmv`–`logo4.wmv` (**not on the
  disc** — this is why the splash is a screen), **`ADVERTISE_MOVIE` → `ADV.wmv`**,
  `STAFF_ROLL` → `SYLPH_HD720p_8M-CBR_2ch.wmv`, **`MS00A` → `S00A.wmv`** (the
  new-game intro, 93.9 s, with subtitle + `VOICE_S00A` + a text overlay),
  `MS01A` → `S01A.wmv`. ✅ decoded — and **`S00A.wmv` is now also measured**: matched off the running game at 0.96–1.000 with a strictly monotone playhead over 25 consecutive 0.5 s samples. It starts ~4.5 s after Ⓐ on the save slot.
  **The boot intro and the attract movie are the SAME asset** — there is no
  separate boot slot, and 15 of 19 captured attract frames match `ADV.wmv` with a
  monotonically advancing playhead ending at its full 137 s. One video, not two.
  ✅ The attract movie **plays to its end**; nothing cuts it short.
  ✅ **A movie is skippable with a single Ⓐ.** Measured: one tap ~45 s into the
  boot brought the title at ~57 s against a ~193 s no-input baseline over three
  boots, with Canary's own keystroke counter proving exactly one press was
  delivered — and the skipped-to title is **fully functional** (`PRESS Ⓐ` plate
  present, Ⓐ opens the main menu). What breaks the boot is *hammering*: 88
  presses left a permanent black screen. One press is fine.

* **The menu's sound events are named on the disc.** `tables.pak`'s `SOUNDS`
  record carries 322 `SE_*` cues, and the low block is the UI vocabulary — named
  after the *event*: `SE_UI_CURSOR` (2), `SE_UI_DECIDE` (3), `SE_UI_CANSEL` (4),
  `SE_UI_IMPOSI` (5, the error), `SE_UI_SUB_WIN_OPN`/`_CLS` (8/9),
  `SE_UI_SPLASH_IN`/`_OUT` (12/13). ✅ decoded, full list in
  [`data/se-ui-cues.txt`](../re/data/se-ui-cues.txt). They all live in **one**
  bank — `BANK_SE` is a single field naming `Static.slb`, and 0 of the 322 has
  its own `FILES` entry.
  🟡 **Which event fires which cue is a name match**, not a measurement — strong,
  because these are the authors' own event names, but nobody has watched the game
  emit cue 2 on a d-pad press. The port is authoring it.
  ✅ **The SE audio IS extractable — by playing it.** (This corrects an earlier
  "cannot be extracted" on this page.) The disc carries no index: `Static.slb` has
  **0 `RIFF`/`seek`/`WAVE`** and there is **no XACT container anywhere** (0 ×
  `XGSF`/`SDBK`/`WBND` in 1.08 GB of `sound.pak`; no `XACT` string in the
  executable — those extensions are the authoring tool's). But Canary's
  `--xma_param_probe=true` logs every stream's head bytes, and searching them in
  `Static.slb` locates the wave exactly:
  **d-pad move → `0x1ec0` (4 pkts / 8 192 B, 0.533 s); Ⓐ confirm → `0x5d6c0`
  (6 pkts / 12 288 B, 1.016 s); Ⓑ back → `0x0ec0` (2 pkts / 4 096 B, 0.344 s)** —
  every cue the five screens need. Move and back reproduce with identical head
  bytes across **two independent boots**. Each matched at one offset only, and
  the first two are contiguous
  (`0x0ec0 + 4096 = 0x1ec0`) — the bank is a packed run of whole 2 048-byte
  packets with no delimiters, which is why nothing could be scanned for.
  ❔ **⬅ and ➡ play nothing distinct** — no new stream on either, so leave them
  silent (the probe dedups, so this excludes a *distinct* invalid cue, not a
  quiet replay of an already-heard one).
  🟡 The Ⓐ press both confirms and opens a screen, so whether its wave is the cue
  named `SE_UI_DECIDE` or `SE_UI_SUB_WIN_OPN` is not separated.
  ⚠️ The order is **not** cue-id order, so the index must be observed per cue, not
  counted. ✅ **The slices decode**: 0.533 s, 0.344 s and 1.016 s of mono 48 kHz
  audio with the attack-and-decay shape of UI blips, via
  `tools/re-capture/slb_extract_wave.py` — whose wrapper reproduces a known-good
  `BGM_001` decode to the same 173.808875 s, so it is verified, not assumed.

* **The boot sequence is not data-driven — the port authors it.** ❔ Four places
  were checked and the order is in none: `config.ini`'s `[SYSTEM]` is empty, the
  movie manifest carries assets not transitions, the requested GamePart id lives
  **only as a stack argument in flight** (no persistent field, no literal store),
  and the string `GP_ADVERTISE_DEMO` has **zero xrefs**. A transition is a call
  with an id argument, chosen by code.
  🟡 **But the states have names, and the transition uses them.** `sub_821C6458`,
  the title part's state function, calls **`sub_821CC860(…, "<NAME>", 0)`** with
  `TITLE_SCREEN`, `TITLE_MENU` and `LOADING` — the three states measured off the
  game, in the game's own words — and installs the result. So a transition is a
  call with a **name** argument, which is also why `GP_ADVERTISE_DEMO` has no
  xrefs: at this level the screen graph is name-keyed, not id-keyed.
  ✅ The argument is now **decoded** at 46 of that function's 48 call sites (28
  distinct names). ⚠️ It is a **generic name-keyed lookup**, not a screen factory —
  its arguments include `BG`, `BLACK`, `FADE`, `FILE`, `KEY`, `PAD`, `SOUND`,
  `GAMMA_RGB`. An earlier version of this page claimed `DIFFICULTY` and
  `EXTRA_MENU` as corroborated screen names; **neither is ever the argument**, and
  only `TUTORIAL_MENU` survives.
  ✅ **And the state machine itself is decoded**: `state = this+136`, ten states
  dispatched through a jump table at `0x821C6498`, with **18 transitions** each a
  literal `li`/`stw`. States **0, 2, 8** install `TITLE_SCREEN`, `TITLE_MENU`,
  `LOADING`. `4 → 0` is the only edge back to the title, reached from `2 → 4` —
  which matches Ⓑ-returns-to-title as measured. Full graph in
  [`data/title-state-machine.txt`](../re/data/title-state-machine.txt).
  ⚠️ **All of that is ONE PHASE.** `GamePart_Title` dispatches on an outer phase
  field at `this+132` (five values) before reaching any of it: phase 0 is the
  **developer splash** (`sub_821C5690`, the same function the corpus fingered
  independently), phase 4 is the title/menu machine. The ten states and
  eighteen edges above live inside phase 4 alone.
  ✅ **State 4's edge conditions are an event code** — `sub_821C6458`'s third
  argument. State 4 is the input-waiting state (reached straight after the menu
  is installed) and handles 6 of 26 events: **`0` → title**, **`3`, `5`, `8`,
  `25` → `LOADING`**, `10` → state 5.
  🟡 What the event *numbers* mean is not decoded — button id, menu row, or
  message id — so the port still takes the button→destination map from
  measurement. The one-to-title / four-to-loading shape matches the five-item
  menu with Ⓑ, but that is a **count-match, not a mapping**. The sequence itself is fully measured:
  splash → `ADV.wmv` → title + `PRESS Ⓐ` → (idle ~8–10 s → `ADV.wmv` in full →
  title) → Ⓐ → main menu, with Ⓑ from the main menu returning to the title.

* **`config.ini` picks the language, and that is what picks the EN/JP build.**
  The disc's **only** config file (400 bytes, at the root; one `find` over the
  whole extract). Its `[LANGUAGE]` section maps the console's `XC_LANGUAGE_*`
  value to `eng`/`jpn`/`deu`/`fra`/`esp`/`ita`, defaulting to `eng` — that code
  selects `GP_TITLE`'s English or Japanese build and the `<lang>.pak` families.
  ✅ decoded.
  ❔ Its `[SYSTEM]` section — which the file's own comment says holds what the
  game and every game part share — is **empty**, so the boot *order* is not in
  disc-side configuration at all.
* **Five GameParts are named but never registered.** Pulling every
  `RegisterToFactory<N, class silph::GamePart_X>` diagnostic string binds **24 of
  the 29 ids to a C++ class**
  ([`data/gamepart-class-ids.txt`](../re/data/gamepart-class-ids.txt)). Ids `1`,
  `2`, `16`, `18`, `28` have no registration site — including
  **`GP_ADVERTISE_DEMO` (1)**, which agrees with the measurement that the attract
  loop is the *title* replaying `ADV.wmv` rather than a separate part. 🟡 an
  argument from a diagnostic string, not from the code.
  Also: **`3` and `4` are both `GamePart_SaveLoad`** — one part, two ids.

* **The GamePart id table** — 29 entries at `.rdata 0x820A1630`, confirmed by the
  executable's own registration strings. ✅ This is the screen vocabulary; which
  button reaches which entry is Q4 and is *not* part of it.
* **The logo splash is a screen, not a video, and it renders.** `logo1`–`logo4`
  are manifest-bound with no `.wmv` on the disc. ✅ The screen is **two** bundles
  in `GP_TITLE.pak`, each shipped twice: entries **10/13** the white
  `SQUARE ENIX` publisher logo, entries **11/14** `GAME ARTS`/`SETA`/`studio
  anima`. ⚠️ They are **invisible to the default `screen list`/`render`** —
  `is_build` rejects them for having no `.rat` child. Pass **`--all`**, which
  renumbers `--build`. So the first of the five screens does have a reference
  composite. ✅ **And a capture**: both halves edge-correlate to their renders at
  **0.91** and **0.98** at zero shift, each rejected by the other (0.03, −0.03).
  ✅ **Its timing is DECODED, not just measured.** The splash **fades both ways**
  and the bundles carry the keyframes: `SQUARE ENIX` `[15 30 235 239 251 255]`,
  developer logos `[15 30 190 194 206 210]`, each with an `_eff` glow child on
  `[15 30 45]`. Under `1 unit = 1/60 s` that is a 0.25 s ramp in, a **3.42 s**
  / **2.67 s** hold, and a **0.33 s** fade out — and a 10 fps capture measures
  ≈ 3.5 s / ≈ 2.4 s holds and **≈ 0.3 s** fade-outs. The visible brightness
  overshoot on the way in is the `_eff` glow ramping after the logo, not a
  rendering artifact. Wall-clock: logos ≈ 0.4–4.7 s and ≈ 4.9–8.4 s, then
  `ADV.wmv` from ≈ 8.9 s. ⚠️ The cyan `SQUARE ENIX` at ≈ 9.5 s is the
  **movie's** opening, not a third splash screen.
* **Sprites carry their own labels.** No font rendering or localisation is needed
  for this milestone. ✅ — and the localisation is *already baked in*: the
  Japanese screens are separate builds in the same pak, not a text swap.

## Facts the port will trip over

* **`ADV.wmv` is WMV3 video + WMA Pro audio**, 1280×720 at 30 fps, 137 s. Godot 4
  plays only Ogg Theora natively. How to handle that is the port's decision, not
  ours — but it is not optional.
* **The disc holds 3.3 GB of video, and exactly two files are in scope:**
  `dat/movie/ADV.wmv` (the boot intro *and* the attract loop — one asset) and
  `dat/movie/S00A.wmv` (the new-game intro, 93.9 s). Named from the movie
  manifest, ✅ decoded.
* **`Static.slb` over-declares its size** by 616 768 bytes — it is the
  highest-offset entry in `sound.pak` and its size field is an allocation size. A
  reader must allow a short read there and only there.
* **Voice downmixes to mono, music does not.** The left-channel downmix is correct
  for spoken lines and discards half a music mix.
* **A music bank is TWO STEMS THAT PLAY TOGETHER — do not concatenate.**
  ✅ The "10 KB + 4.47 MB + 4.67 MB" reading was wrong: the 10 KB is the bank
  header, and a bank is exactly **two waves of identical duration** (32/32 banks
  on the disc). `BGM_001`'s two are **sample-synchronous** — transient
  correlation peaks at lag 0.00 s over ±5 s, and both stop at the same
  millisecond, 167.663 s. Wave 1 is quieter, far more L/R-decorrelated and has
  almost no bass, so it reads as a surround-rear pair or a second intensity
  layer — 🟡 which of those is unsettled, and `ChannelMask` is `0x0002` on both,
  so the file will not say. Today's 347 s concatenation plays the piece twice,
  the second time as a bass-less stem.
  ❔ **And it is not a seamless loop**: `BGM_001` fades out at 167.663 s and is
  followed by 6.15 s of silence, with no loop-point field identified. A menu loop
  is authored.
  ✅ **The menu's music is `BGM_103`.** The cue *table* cannot say — its BGM
  entries are numeric — but `GamePart_Title`'s `sub_821C5580` plays **cue 1103**,
  and `BGM_103.slb`'s two declared waves (3 876 864 / 3 930 112 B) are
  byte-for-byte the two streams the XMA probe saw decoding at the main menu.
  Static code, disc census and runtime all agree. The port does **not** have to
  choose a track.
* **`JNGL_001.slb` does not decode.** One bank in 9 519; its payload is not a whole
  number of XMA1 packets from any known data offset.

## What is still open

Every question above is answered, so this is the honest residue rather than a
work queue. **None of it blocks the five screens.** (Q1's seconds conversion was
here until 2026-08-28 and is now settled.)

| | what | why it is stuck |
|---|---|---|
| 🟡 | **cue NAME → event binding** (Q8) | event→**wave** is measured for move/confirm/back; that the cursor's wave is the cue *named* `SE_UI_CURSOR` is still read off the authors' identifiers |
| ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done |
| 🟡 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen |
| 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names |
| 🟡 | **the boot transitions in code** (Q6) | both levels decoded — phase at `this+132` (`entry→2`, `2→0`, `2→3`, `3→4`, `4→2`) and state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS Ⓐ`, phase 4 = menu. Unknown: what the event *numbers* mean |
| ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen anywhere in the boot path, the title-side screens or the attract loop. A mission load is the remaining candidate and this container kills runs before one completes |

(An earlier version of this table called the audio items blocked on "an emulator
whose audio path can be observed". That was wrong — this build already has
`--xma_param_probe`, and using it settled both.)

⚠️ **A container caveat that bounds all of the above:** the emulator has twice
been killed mid-run with no crash line in its own log (at ~50 s and ~145 s), on a
box sitting at ~1 GB free with swap exhausted. Dynamic experiments here have to
fit in roughly two minutes of guest time, which is why several of these residuals
are unfinished rather than unattempted.

## Reference data

Committed alongside the findings, so the port can be built without a disc in the
loop during development:

* `sylpheed-cli screen info --build <n> GP_TITLE.pak` — the element table, per
  build, with pivots, kinds, focus links, keyframes and resting poses.
* `sylpheed-cli screen render` — the reference composite. When the port draws a
  screen, this is what it should be diffed against; where they disagree, one of
  them is wrong and the disagreement is worth reporting back.
* `docs/re/captures/` — framebuffer captures of the real screens, for anything
  that has to be checked against the game rather than against our renderer.