Hack64 Wiki
Other Titles
Hack64 Wiki
Other Titles
In Paper Mario: The Thousand-Year Door's root file structure, audio is stored in root/sound.
Said sub-folder is split into two further folders.
Where most of the sound effects are stored for the game, save for a handful that are stm files (which qualify more as short jingles or BGSs) and in the root/sound/stream folder. Samplebanks normally store instrument samples in other games, but Intelligent Systems decided to have the samplebank store SFXs instead, for whichever reason.
A file with no header with a repeating 32-byte structure that encodes sample info for the bank.
Nametable for SFX files. Last byte before the next SFX increments up to 0xFF and then rolls back to 0x00. A list of said SFX files
Junk-text is in the names and exists up to the 30th character. There is no known associated offset or length data that specifies a fixed index that can be multiplied by 32. I.e, SE3_AMB_RIVER1: 2*32=64 or 0x40-0x60 (0x40+60, record length[32] in hex) which corresponds with “SE3_AMB_RIVER1.IO_JUMP2..LING2”
Duplicate of pmario.etbl?
“.IO” and onward is a null terminator followed by an 'afterimage' of names before it. If names afterwards do not take up the 30 chars max (last two are reserved for an unknown thing), it just re-prints the last used chars on next line.
Also:
pmario_sound_bgm_env_db
pmario_sound_bgm_env_db2
pmario_sound_sfx_txt_db
Database list for the stms, includes some sound effects but is generally used for streaming the game's BGMs directly from the disc. Uses the .tbl filename as an identifier. Generally worthless from a hacking perspective, besides giving short japanese names for the music in-game.
The main format for the game's BGMs and BGSs, and also used in Fire Emblem: Path of Radiance and Cubivore. It is a proprietary audio format by Nintendo, so not much documentation is available for it.
The stm file-format is near identical to dsp in terms of coding, there is just only a file-format name difference. Here is a list of known stm files in the game.
u16 field00: 0x00, always 512, a version number of 2.0?
u16 sampleRate: 0x02, usually 32000 (Hz)
u32 numChannels: 0x04, usually 2 (may be preset, 2 represents Stereo)
u32 adpcmData2Offset: 0x08, byte offset set to the second channel's adpcm data (relative to the header's end+all channel headers)
u32 adpcmLoopStartOffset: 0x0C, byte loop start offset equal to 0xFFFFFFFF if not in use (relative to the start of the data itself)
u32 adpcmData2OffsetAux1: 0x10, same as adpcmData2Offset
u32 adpcmData2OffsetAux2: 0x14, same as adpcmData2Offset
u32 adpcmLoopStartOffsetAux1: 0x18, if adpcmLoopOffset != 0xFFFFFFFF then same value else value is 0
u32 adpcmLoopStartOffsetAux2: 0x1C, same as adpcmData2OffsetAux1
u8 padding[32]: 0x20, 32 bytes unused
Notes:
*standard dspadpcm is after numChannels
*after dspadpcm header is the first channel
*if the second channel is present, it will seek to the adpcmData20Offset to get the second channel's data
*32 bytes of alignment between adpcm data blocks
*then is some unknown alignment or fixed amount of space-padding at the end of the file
*which value indicates loopend offset is unknown
*all game music loops from start to end, but most tracks have their loop startpoint a couple of seconds after 0:00
*adpcmData2OffsetAux1 or adpcmData2OffsetAux2 may be loop end offset