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. The single most useful test artifact is a kit that ships the same sounds across generations (a Rosetta stone): identical sample names in an unknown binary reveal its record structure.

format × generation matrix
formathardware / softwarecontainersamples / PCMacidcat
.sndMPC2000, 2000XL (3000?)binary, 38 or 42-byte header + PCM16-bit signed LE, stereo non-interleaved, 44.1k nativeverified (16 files)
.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)covered (WAV walker)
.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 (101 files)
what we need from hardware-written files
the software-export vs hardware-native question Our vintage .pgm / .snd specimens are software exports (a converter writing files for the hardware). A file written by the actual machine may differ. To confirm, we want files saved on-device by:
• an MPC2000 / 2000XL (SCSI/floppy save) -- confirms the hardware .pgm layout (documented as name-table at 0x05 with note + mixer records) and whether the .snd header is 42 bytes there
• an MPC3000 -- is its .SND/.PGM the same family as the 2000 or its own?
• an MPC4000 program -- confirm it is the AKAI/APRG format (the .akp walker would then cover it)
• an MPC5000 .PGM -- the extended MPC1000 variant
• more MPC500 .50s and, if we chase it, MPC60 12-bit sounds
the 5 format eras (~20 models collapse to these)

acidcat needs ~5 format families, not 20 walkers. The time sinks are the intra-era forks (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, the exports we have use a compact 38-byte header -- so acidcat resolves it 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

Fields verified across all 16 kit sounds. 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). acidcat handles both by size-fit; a real on-device .snd would let us confirm the classic field set directly.
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, not yet surfaced)

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. acidcat surfaces the layers today; these are a mechanical enrichment.

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 (acidcat tells them apart on the MPC1000 magic). The specimens we have are software exports: 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 -- needs a specimen 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. We have no on-device file, so acidcat parses the verified 0x02 software-export table only. A hardware-written MPC2000 .pgm is the single most useful specimen to get.
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 (flagged per-entry).

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)