In-RAM STR FMV file tables Confirmed

At a glance

In the game

Every full-motion video: the attract intro and the eight story movies, plus which field scene the game returns to when each ends.

Magic / marker

None - static initialised data in the cutscene overlay's data section (an overlay is a chunk of code + data loaded into RAM on demand)

Lives in

PROT 0970 (the STR / MDEC overlay) at link base 0x801CE818: path strings at 0x801CE810, return-scene labels at 0x801CE8AC, the dispatch table at 0x801D0A6C (23 × 32 B)

Retail reader

Selector in the master dispatch + the play loop (how we know)

Parser

legaia_asset::fmv_dispatch::FmvTable::from_str_overlay; engine mirror legaia_engine_core::cutscene::fmv_index_to_str_filename

Confidence

Confirmed - stride and layout pinned from the PROT 0970 disc bytes, byte-identical in the resident RAM capture; every field cross-validated against the play loop's reads; the retail fmv_id 0..=8 range pinned by nine trigger save states.

The dispatch table

The field-VM FMV-trigger op (see the cutscene subsystem) writes an s16 fmv_id to a global; the master dispatch multiplies it by 32 and indexes the table. The play loop opens the slot's file, seeks to start_frame, and streams until the demuxed frame number reaches end_frame - which is how one MVn.STR carries several cutscenes by frame range:

Record layout (32 bytes)

Because the table is static initialised data in PROT 0970, it decodes straight from the disc; the windowed player uses the frame range to seek to the right segment (cutscene_av::fmv_segment_window). The +0x18/+0x1C pair is the one place the record can be overruled: it sizes the decode rects once, then from the first demuxed frame onward the play loop overwrites the rects' width and height from the STR sector header's own fields. A slot whose dimensions disagree with the movie loses.

The nine retail movies (and the dev slots)

MV3.STR's four segments abut exactly. The scene + spawn word hand-offs write the next-scene name global (from the label table of seven CDNAME-shape names: town0b, map01, chitei2, map02, jou, uru2, town0e) plus a spawn/door word, then set field mode - so each mid-game FMV returns to a specific scene rather than the trigger scene. Every movie on the retail disc is dispatched. The path strings live in a packed null-terminated table at the overlay start; three of the nine (MOV.STR, MOV15.STR, MV1A.STR) are dev-only.

Which scene fires which movie

The fmv_id each scene fires is inline script data, not a runtime value: the trigger op carries its id as a literal i16 operand, so walking every scene MAN's scripts with the field-VM disassembler recovers the full assignment straight from the disc:

One trigger op per scene; no other scene MAN carries one. fmv_id 0 (the intro) fires from the title/new-game path rather than a scene script. Slot 5 appears in no scene MAN partition-1 script; a live playthrough capture pins taiku as the scene (it enters the movie mode with id 5 and resumes in taiku itself, exactly per the slot-5 hand-off), while the byte-level carrier of its trigger op sits in taiku's uncompressed scene structures outside partition 1 - the one open detail.

The look-alike table: libcd's directory cache

A second, unrelated table shares the overlay's data section and has been mistaken for the FMV table: libcd's CdSearchFile per-directory file cache (libcd is the CD-ROM library of PsyQ, the PlayStation SDK) at 0x801CAE08 - one 24-byte CdlFILE record per file of the last-searched directory: 4-byte BCD location, 4-byte size, 16-byte name. It starts with the . / .. entries; the contents change with whatever directory was searched last (the XA directory at the title screen, MOV during a movie). It describes the disc filesystem, not the cutscenes.

Rust API

use legaia_asset::fmv_dispatch::FmvTable;

// Decode the dispatch table straight from the PROT 0970 entry bytes.
let overlay = std::fs::read("extracted/PROT/0970_xxx_dat.BIN")?;
let table = FmvTable::from_str_overlay(&overlay).expect("dispatch table");

// fmv_id (the value the field VM writes) -> movie + range.
let e = table.entry(1).unwrap();
assert_eq!(e.engine_path(), "MOV/MV2.STR");
assert_eq!((e.start_frame, e.end_frame), (1, 0xf4));

// Dev slots decode too but engine_path() declines them.
assert_eq!(table.engine_path(10), None); // MOV15.STR, not on the retail disc

How we know

Full path-table offsets and the trigger-corpus save-state details are in the source of record: docs/formats/str-fmv-table.md.

See also