ACIDCAT . FILE FORMAT REFERENCE

Akai MPC Anatomy

MPC + S-series familyvintage → modern
rev 2026.07

Hover a field to light its bytes, click a field with a + for its table. Color marks kind (see the key).

The Akai MPC line spans nearly four decades of sampler formats, from 12-bit floppy sounds to gzipped JSON kits. Every binary format is little-endian. This sheet collects them; the tabs open each one's byte layout. Akai red = verified against real files, amber = documented but needs a hardware specimen to confirm.

format × generation matrix
formathardware / softwarecontainersamples / PCMstatus
.sndMPC2000, 2000XL (3000?)binary, 38 or 42-byte header + PCM16-bit signed LE, stereo non-interleaved, 44.1k nativeverified
.pgmMPC2000, 2000XL, 3000binary, 17-byte name-tablereferences .snd by namesw-export verified
.PGMMPC1000, 2500binary, "MPC1000 PGM 1.00" magic, 64×164B padsreferences .WAV by nameverified (factory default)
.WAVMPC1000/2500/5000standard RIFF/WAVE16-bit LE, interleaved (normal WAV)standard RIFF
.50sMPC500 / JJOSbinary, "S80p" magicprogram + embedded PCM (135 KB)needs RE
programMPC4000Akai Z-series engine (APRG)references .WAVneeds specimen
.mpcpatternMPC 2.x / 3.x softwarebare JSONsequence events, no audioboth schemas
.xpmMPC 2.x / 3.x softwareXML (<MPCVObject>)references .WAVverified
.xpnMPC 2.x / 3.x softwareZIP packagebundles programs + .WAV + artverified
.xtdMPC 3.x / Forcegzip + ACVS + JSONreferences .WAV by name+pathverified
.s3pAkai S3000 (adjacent)binary, "PSYSSS30" (a tool export)proprietary charset, no ASCIIneeds tool-ID / charset
.akpAkai S5000/S6000 (adjacent)RIFF/APRG (IFF)references .WAVverified
hardware-written files: what is unconfirmed
the software-export vs hardware-native question The vintage .pgm / .snd layouts here are drawn from software exports (a converter writing files for the hardware). A file written by the actual machine may differ. Unconfirmed against on-device files:
• MPC2000 / 2000XL (SCSI/floppy save) -- the hardware .pgm layout (documented as name-table at 0x05 with note + mixer records) and whether the .snd header is 42 bytes there
• MPC3000 -- whether its .SND/.PGM is the same family as the 2000 or its own
• MPC4000 program -- whether it is the AKAI/APRG format
• MPC5000 .PGM -- the extended MPC1000 variant
• MPC500 .50s and MPC60 12-bit sounds
the 5 format eras (~20 models collapse to these)

The ~20 models collapse to ~5 format families. The forks that matter are intra-era (software-vs-hardware .pgm, JJOS variants), not new models.

1 . Linn floppyMPC60 (1988, 12-bit), 60mkII, MPC3000 (1994, 16-bit) -- old .snd + .pgm, floppy/SCSI
2 . 2000 / 2000XL1997-2000, floppy + SCSI/SmartMedia -- 38/42-byte .snd, 07 00 name-table .pgm; the sw-vs-hw fork lives here
3 . MPC40002002, the odd branch -- Akai Z-series sampler engine (APRG), not the 1000 lineage
4 . CF / JJOSMPC1000/2500/500/5000 (2003-2008) -- MPC1000 PGM .PGM, external .WAV, MPC500 S80p .50s; JJOS is a 3rd-party OS with its own variants
5 . software OSRenaissance (2012) then Live/X/One/Key/Force -- the XML/JSON/ZIP/gzip family (.xpm, .xpn, .xtd, .mpcpattern)
magic0x01 <5 <name>
endianlittle
header38 or 42 bytes
statusverified ×16

The MPC2000 sound: a fixed header then raw 16-bit signed little-endian PCM. Stereo is stored non-interleaved (the full left block, then the full right). The header size is variant-dependent -- classic hardware is 42 bytes, software exports a compact 38-byte header -- so it resolves by size-fit: header + frames × channels × 2 must land exactly on EOF. The register map below is a real kick from the CPM7 kit (38-byte). Hover any byte to read the field.

header + PCM

The channel byte at 0x15 discriminates perfectly (0 mono / 1 stereo), and the frame count times the channel stride hits the file size to the byte.

the 42-byte classic variant A hardware-written .snd is documented as a 42-byte header: it keeps the same name/level/channel fields but the total frame count moves to 0x1e, and it adds an explicit loop length (0x22), loop mode (0x26), and sample rate (0x28, u16). Both resolve by size-fit; the classic field set is documented but not confirmed against an on-device file.
magic"MPC1000 PGM 1.00" @ 4
endianlittle
pads64 × 164 bytes
statusverified

The MPC1000/2500 program. A 24-byte header (file size, then the magic), then 64 pads of 164 bytes each. There is no program-name field -- the name is the filename. Each pad holds four 24-byte layers, and each layer opens with a NUL-terminated sample name referencing an external .WAV. Samples are not stored in the program.

header
pad layer

Real layer 0 of pad 0 (a velocity-switched kick: this layer plays velocities 70-127, layer 1 the softer 0-69). Offsets verified against a factory-default program.

pad parameters (documented)

After the four layers (+0x60 in the pad), the pad carries voice overlap + mute group, amp attack/decay, two filters, mixer level/pan, output routing, and FX send. The footer at 0x2918 holds the per-pad MIDI-note table, the note-to-pad map (64 = unassigned), the MIDI program number, and two Q-Link slider records.

magicnone (17-byte records)
endianlittle
records16-char name + 1
statussw-export only

The older MPC2000/2000XL/3000 program -- a different format that shares the .pgm extension with the MPC1000 form (the MPC1000 magic tells them apart). The software-export form is a table of 17-byte records (a 16-character space-padded sample name + one trailing byte) starting at offset 2, terminated by an empty name. The program references its sounds (the sibling .snd files) by these names.

name-table record
hardware-native layout -- unconfirmed Paul Kellett's hardware documentation describes a different arrangement for a file written by the machine: lead bytes (0x07, 0x04), a sample count at 0x02, the name table at 0x05, a (0x1E,0x00) section marker, then a 16-char program name, 25-byte per-note records (notes 35-98: sample index, play mode, velocity/decay switch, tune, filter, envelopes) and 6-byte mixer records. That arrangement is documented but not confirmed against an on-device file; only the 0x02 software-export table is verified.
magic{ "pattern": { ... } }
endiann/a (JSON)
eraMPC 2.x + 3.x
statusboth schemas

The MPC "MIDI": bare JSON, {"pattern": {"length", "events": [...]}}. length is often 9223372036854775807 (INT64_MAX) as an "unbounded" sentinel. Two event schemas ship, both handled -- the flat MPC2 event and the nested MPC3 note object.

MPC2 event (flat)
▸type 2050 = notenumbered keys
type2050 note . 1 / 257 markers
time / lentick position, length
"1"pitch (MIDI note)
"2"velocity (0.0-1.0 float)
mod / modValmodifier + value
prob / ratchetprobability %, ratchet count
MPC3 event (nested)
▸type 3 = note"note" object
version / type2 . 3 = note, 1 = automation
channeltrack channel
note.notepitch
note.velocity0.0-1.0
note.lengthticks
note.probability / ratchet% . count
note.articulationarticulation id
modifierValue0..15per-modifier state
EnumCerealisationWrapper(...)a C++ enum serializer leaking its wrapper name -- a provenance tell
magic<MPCVObject>
endiann/a (XML)
eraMPC 2.x + 3.x
statusverified

The modern keygroup / drum program: XML with an <MPCVObject> root. Content-sniffed (an X11 pixmap shares the .xpm extension). Samples are external .WAV files referenced by name.

structure
<MPCVObject>root element
<Version><File_Version>e.g. 2.1
<Program type="...">Keygroup | Drum
<ProgramName>program name
<KeygroupNumKeygroups>keygroup count
<Instrument> × Neach with a <SampleName> (external .WAV, no extension)
magicPK\x03\x04 + Expansion.xml
endianlittle (ZIP)
eraMPC 2.x + 3.x
statusverified

An expansion package: a ZIP bundling an Expansion.xml manifest with the .xpm programs, .WAV samples, and cover art. Note the programs inside a distributed .xpn are usually deflated, so a carve of a program region yields a raw deflate stream, not the literal .xpm.

structure
Expansion.xmlmanifest: title, manufacturer, type, version, identifier, description, cover img
*.xpmthe keygroup/drum programs
*.wavthe samples
*.jpgcover art
magicgzip → "ACVS"
endiann/a (JSON)
eraMPC 3.x / Force
statusverified

The MPC3 track/kit: gzip wrapping an ACVS container -- newline-delimited header lines (magic, app version, data type, format, platform) then a JSON body. MPC3 kits are SerialisableTrackData. The decompressed read is capped (64 MB) as a gzip-bomb guard.

ACVS header + JSON
line 0"ACVS" (magic)
line 1app version, e.g. 3.6.0.134
line 2data type, e.g. SerialisableTrackData
line 3 / 4format (json) . platform (Linux)
data.namekit name
data.programembedded program (name + type)
data.samples[]references: name + relative path (../Samples/*.wav)