Skip to content

XMI — Extended MIDI Audio (.XMI)

FA_2.LIB contains 78 .XMI files. XMI is Miles Sound System's Extended MIDI format — a compact IFF-based variant of Standard MIDI that supports multiple independent sequences in a single file. Confirmed by hex analysis: magic FORM...XDIR. All 78 are in FA_2.LIB only (FA_1.LIB contains none; FA_3.LIB is disc-2 content).

Tools

fx

fx xmi info   <file.XMI>                     # sequences, timbres, chunk inventory
fx xmi export <file.XMI> [-s N] -o out.mid   # sequence N (default 0) -> Standard MIDI

fx xmi export writes a Standard MIDI File (format 0) from the selected sequence: the AIL delay encoding is rewritten to SMF variable-length deltas and each note-on's XMI duration becomes a scheduled note-off. XMI→MID is a one-way translation, not a byte-identity round-trip. All 78 stock .XMI files export to structurally valid SMF (balanced note-on/note-off pairs, monotonic deltas, proper end-of-track); the output parses in independent MIDI libraries.

File Layout

IFF-style chunk structure — chunk sizes are big-endian, unlike every other FA format. Well-documented external format.

Offset Chunk Description
0x00 FORM IFF outer envelope
0x04 (size) u32 BE: total content size
0x08 XDIR Extended MIDI directory marker
0x0C INFO Sequence count block
CAT Sequence catalog
FORM XMID One entry per MIDI sequence
TIMB Instrument/timbre table
EVNT MIDI event stream (AIL delta encoding)

Key differences from Standard MIDI: - Fixed 120 BPM base; tempo encoded as AIL-specific multipliers - Delta times use AIL's variable-length encoding (not SMF) - Multiple sequences in one file via the CAT/XMID structure

TIMB chunk (instrument table)

u16 entry count (little-endian), then count × 2 bytes — one (patch, bank) pair per timbre the sequence uses. AIR003.XMI carries 18 entries in a 38-byte chunk (2 + 18×2). The per-entry field roles beyond patch/bank are not independently verified here (see Open Questions).

EVNT chunk (event stream) — decoded and validated

The event stream is Standard-MIDI status bytes with two AIL differences, recovered from the 78-file corpus and validated by the fx xmi export round-trip to SMF:

  • Delay (interval) encoding. Between events, every byte < 0x80 accumulates into the delay for the next event (a sum-of-bytes VLQ, not the SMF 7-bit VLQ). A delay of 256 ticks encodes as 7F 7F 02. The first byte ≥ 0x80 ends the delay and is the event's status byte.
  • Note-on carries an explicit duration. A 0x9n note-on is followed by note, velocity, and a duration as a standard 7-bit VLQ; there is no matching note-off in the stream. The exporter emits the note-on at the current tick and schedules a note-off duration ticks later.
  • All other events are Standard MIDI, with the usual data-byte counts: 0x8n/0xAn/0xBn/0xEn (two data bytes), 0xCn/0xDn (one), 0xF0/0xF7 sysex (SMF-VLQ length + data), and 0xFF meta (type + SMF-VLQ length + data). FF 2F ends the sequence. Status bytes are always explicit — running status cannot occur because data bytes (< 0x80) would be consumed as delay.

Open Questions

1. AIL tempo scaling and TIMB entry semantics

Two residual details are externally documented (Miles Sound System) but not independently verified against FA's files here: the exact mapping from AIL's tempo multipliers to microseconds-per-quarter-note (the exporter emits a default 120 BPM and passes any in-stream FF 51 tempo meta through unchanged), and the meaning of the TIMB entry fields beyond the (patch, bank) pair. Neither affects the note content of the exported MIDI.

Status: open — re-static (#54)

Formats: MUS — playlist DLLs that select XMI tracks by index; 11K — PCM audio formats (.5K, .11K) used for sound effects and voice.