Repository navigation
EMI Container Format
An .EMI is a header, a table of contents, and then the sections back to back, each padded to a CD sector.
0x000 u32 section count
0x004 u32 version
0x008 char[8] "MATH_TBL"
0x010 TOC entries, 16 bytes each, `count` of them
TOC entry
+0x00 u32 size of the section's data, in bytes
+0x04 u32 destination (see below)
+0x08 u8[4] the first four bytes of the section's data
+0x0C u16 type id
+0x0E u16 unused (garbage)
The eight-byte magic reads MATH_TBL in every file; the name's origin is unknown.
Section data starts at file offset 0x800, and every section is padded to a 2,048-byte boundary, so the next section begins where the previous one's padded extent ends:
next = cur + ((size + 0x7FF) >> 11) * 0x800
The four-byte preview at +0x08 is a copy of the section's first bytes. It is a free integrity check on the offset arithmetic: walk the file by the rule above, and if the bytes you land on do not match the preview you have the offsets wrong. All 6,344 sections across the 880 Japanese-disc files pass that check, and so do the 405 distinct code sections the archival project compiles.
For most types, +0x04 is the RAM address the section is copied to: 0x80196800 for the field engine, 0x80010000 for an area's message block, 0x80033800 for a party sprite arena, and so on. The engine does no relocation; the section is a memory image for that address.
For an image (type 3) the same field is a packed VRAM rectangle, not a RAM address. The high byte is the x column in 32-pixel units, the next byte the y row in 32-pixel units, then the size in 16 KB units, then a flag byte. 0x0E001000 is column 14 (448 pixels across), row 0, 256 KB, flag 0.
For the audio triplet (types 6, 8, 7) and for sequences (type 10) it is a small integer, the sound bank id 0..6, shared by all members of one group. Reading it as an address, as the community doc's wording invites, mis-parses every sound-bearing file.
EMI Section Types says what lives behind each type.
65 sections on the Japanese disc carry type id 1. They are the large party-sprite "arenas" (PL*, BPL*, BRT*, START), all bound for 0x80033800, and they are the only compressed data in the format. The PC port and the PSP release ship them decompressed, which is how the scheme was worked out:
u32 decompressed size
u16 0xFFFF
tokens until `size` bytes are out, then one 0xFF byte
first byte 0x11..0x1F 0x20 - b0 literal bytes follow (1..15)
first byte 0x10, then n 16 + n literal bytes follow (16..271)
otherwise b0, b1 a back-reference into the output:
distance = 0x800 - ((b0 >> 5) << 8 | b1) (1..2048)
length = (b0 & 0x0F) + 3; if that is 18, add the next byte
An LZ77 variant with an 11-bit window, no flag bits and no pre-filled window. A copy may overlap its own output. Decoding every one of the 65 and comparing with the PSP's and the PC's copies gives byte identity for 64 of 65; the 65th, BPLD27A, is edited differently by each port, and every byte of the decode agrees with one of them. The US, French and German discs decode to the same output as the Japanese one. Capcom's own decompressor has not been located in the boot executable (it is presumably in an overlay), so the meaning of the two marker values is known only from the 65 streams. Source: type1-compression.md.
The US and the three PAL discs (English, French, German) use the same container with the same section order. Between the Western languages, the only area-file section that changes size is the message block at 0x80010000; images, audio and map data stay byte-identical. The Japanese disc differs from the Western ones more widely because the boot executable was recompiled with a 0x3000 shift, so the low-RAM data addresses moved too: the area palette section is 0x8002D800 on JP and 0x80035800 on the Western builds. The PSP release carries the Japanese data byte for byte inside its own container format, with the type-1 sections already decompressed.
A worked example is BIN/BPLCHAR/BPLD012.EMI, the battle sprite file for the party of characters 0, 1 and 2:
| idx | type | size | +0x04 |
|---|---|---|---|
| 0, 1, 2 | 6, 8, 7 | 4,128 / 24 / 29,760 | bank 3 |
| 3 | 0 | 16,384 | 0x80033800 |
| 4, 5, 6 | 6, 8, 7 | 4,128 / 24 / 30,960 | bank 4 |
| 7 | 1 | 166,846 | 0x80033800 |
| 8, 9, 10 | 6, 8, 7 | 4,128 / 24 / 30,832 | bank 5 |
Three voice banks (one per party slot), a small uncompressed data block and the compressed arena, both for the same address. The two are alternate payloads for one buffer, and which one the loader uses is decided by the code that requests the file, not by the container.