ACIDCAT . FILE FORMAT REFERENCE

Amiga Music Anatomy

SMUS / OKT / MED / FCIFF-family . big-endian
rev 2026.07
magic FORM / OKTASONG / MMDx / FC14
endian big (68k)
container IFF + trackers
lineage Amiga 1985

The Amiga gave home computers real sampled sound in 1985, and a whole family of music formats grew around it — all big-endian, because the Amiga is a Motorola 68000. This page covers the four outside the mainstream tracker family (MOD/XM/IT): SMUS, the Sonix musical score (an IFF FORM, sibling of AIFF); OKT, the Oktalyzer 8-channel tracker; MED / OctaMED (magic MMD0MMD3); and Future Composer, a synth-driver chiptune (SMOD / FC14). IFF — EA's Interchange File Format, born on the Amiga — is the direct ancestor of RIFF/WAV. The tabs open each, drawn byte by byte from real files. Hover a field to light its bytes, click a field with a + for its table. Color marks kind (see the key).

Two shapes cover these four formats. SMUS is an IFF file — the same FORM + tagged-chunk structure as AIFF, big-endian — so it reads like a cousin of AIFF and 8SVX. The other three are modules: OKT (Oktalyzer) uses IFF-style id+size chunks after an OKTASONG magic; MED and Future Composer are pointer-based, a fixed header of offsets into song/pattern/sample regions. The IFF ones decode fully; the pointer-based ones give up only their header without chasing offsets.

the four, at a glance
SMUS FORM/SMUS "Hava Nagila!" 5 tracks, 4 instruments — IFF, like AIFF OKT OKTASONG 8 voices, 36 samples — IFF-style chunks MED MMD0 116,090-byte OctaMED module — pointer-based FC FC14 Future Composer chiptune, seq 988 B — offset table
the Amiga, dated
1985Commodore Amiga + IFF — the Amiga shipped with four-channel sampled sound, and EA's Interchange File Format (FORM, tagged chunks, big-endian) to store it. IFF is the direct ancestor of AIFF and RIFF/WAV.
SonixSMUS — Aegis Sonix saved scores as FORM SMUS: an SHDR header (tempo, volume, track count), NAME, INS1 instrument registers, and TRAK note tracks.
trackersOKT / OctaMED — the tracker scene pushed the Amiga's four hardware channels to eight by software-mixing pairs. Oktalyzer and OctaMED are the eight-channel workhorses.
chiptuneFuture Composer — not a sample tracker but a synth driver: tiny files that generate sound from waveform/frequency tables at playback, the roots of chiptune.
IFF is the granddaddy. The FORM / 4-byte-id / big-endian-size / word-padded structure of SMUS is exactly what AIFF and 8SVX use, and RIFF/WAV is the little-endian rewrite of it. SMUS reads with the same IFF reader as AIFF — only the chunk meanings differ.
eight channels from four. The Amiga's Paula chip has four hardware voices; OKT and OctaMED double that to eight by mixing two software voices per hardware channel. That is why OKT's CMOD chunk stores per-channel split flags — a set flag turns one hardware channel into two voices.
pointer-based, so header-only. MED and FC do not lay their data out in walkable chunks — they open with a table of absolute offsets into song, pattern, and sample regions, meant to be chased in RAM. The header (magic, module length, sequence length) reads directly; a full pattern/sample decode means chasing those offsets by hand.
formFORM "SMUS"endianbigSHDRtempo / vol / trackschunksNAME / INS1 / TRAK

A Sonix score is textbook IFF: a FORM wrapper of type SMUS, then tagged chunks. SHDR is the score header (tempo, master volume, track count); NAME is the title; each INS1 registers an instrument by name; each TRAK is a stream of note events. The two maps are the FORM wrapper and the SHDR from a real score, "Hava Nagila!".

FORM wrapper (12 bytes)

The IFF envelope — identical in shape to AIFF and 8SVX.

SHDR chunk (id + size + 4-byte body)

Hover ctTrack — this score has 5 note tracks.

same envelope as AIFF. FORM, a big-endian size, a 4-byte form type, then word-padded chunks — SMUS shares its container with AIFF and 8SVX exactly. Only the chunk vocabulary (SHDR, TRAK, INS1, Sonix's private SNX1) is score-specific. Any IFF reader walks it unchanged.
instruments are names, tracks are events. An INS1 chunk registers an instrument the score references ("acoustic guitar", "fender Bass"...); the TRAK chunks are the actual note streams, one per voice. So a SMUS file is a small sequence, not a sample bank — the sounds come from Sonix's own instrument set.
magic"OKTASONG"chunksCMOD / SAMP / SPEEvoicesup to 8samples32-byte entries

Oktalyzer opens with an 8-byte OKTASONG magic, then IFF-style id+size chunks. CMOD holds the channel setup — four words that decide how many voices the four hardware channels become; SAMP is the sample table (32 bytes per entry); SPEE, SLEN, PLEN carry speed and length. The maps are the magic and the CMOD from a real Oktalyzer song.

OKTASONG magic (8 bytes)

The whole magic is one token — no version field.

CMOD chunk (id + size + four channel words)

Hover a channel word — each non-zero word splits one hardware channel into two voices.

CMOD is the eight-channel switch. The Amiga has four hardware voices. Each of CMOD's four words is a per-channel flag: 0 leaves the channel as one voice, non-zero splits it into two. All four split here, so this song plays 8 voices — the Oktalyzer signature. Summing them gives the voice count.
samples are 32-byte records. The SAMP chunk is a flat table — its size divided by 32 is the sample count (36 here). Each entry names a sample and gives its length and loop. The count and the names come free; the sample PCM sits in later regions the module points to.
MEDMMD0–MMD3FCSMOD / FC14shapepointer tablesdecodeheader-level

MED/OctaMED and Future Composer are pointer-based rather than chunked: after a short magic and a length, the header is a table of absolute offsets into the song, pattern, sample and (for FC) waveform regions — laid out to be chased in memory, not walked as chunks. Both are identified by magic, and the header summarises cheaply; a full decode means chasing the tables. The maps are the headers of an OctaMED module and a Future Composer tune.

MED header (MMD0, first 16 bytes)

Hover modlen — the declared module length, checked against the file size.

Future Composer header (FC14, first 16 bytes)

The magic dates the version; the words after it are region lengths/offsets.

the magic dates the version. MED steps MMD0MMD1MMD2MMD3 across MED, OctaMED, OctaMED Pro and SoundStudio; Future Composer is SMOD (v1.3) or FC14 (v1.4). The four bytes map straight to the variant name — the one field these header-only formats give up cheaply.
modlen is a file-integrity check. The MMDx header's modlen should equal the file length; a mismatch is a quick tell for a truncated module. Future Composer instead leads with region lengths (sequence, pattern, sample tables) that a player adds up to find each section.
why the header is where it stops. Chasing the pointer tables into pattern and sample data carries real ambiguity across the MMDx revisions. Magic, variant and module length are the fields that verify cleanly; the regions past them need version-specific handling.