July 21, 2026

The Anatomy of a .MOD File: Inside the Original Music Module

How one Amiga program turned a song into a self-playing package of notes and sound — and gave the "module" its name

Open almost any music file today — an MP3, a WAV, a FLAC — and what you get is a recording: a long list of amplitude values that a player just reads back in order. A .mod file is a different kind of object entirely. It's a small, self-contained package that bundles raw instrument samples together with the instructions for playing them, so that the file itself carries both the "what" and the "how" of a piece of music. That combination is exactly why it's called a module, and it's the direct ancestor of every tracker format that followed, from Scream Tracker's .s3m to Impulse Tracker's .it.

A Short History: From a German Bedroom to the Demoscene

The format traces back to a single program: the Ultimate Soundtracker, written by 22-year-old German developer Karsten Obarski in the summer of 1987 for the brand-new Commodore Amiga 1000. Obarski built it to score music for a friend's game, and it was published by the German company EAS at the end of 1987. Before Soundtracker, making music on a home computer generally meant programming synthesizer chip commands directly. Soundtracker changed the model entirely: instead of describing sounds mathematically, it let a musician record or import short digitized samples — a plucked bass note, a drum hit, a vocal snippet — and then arrange those samples on a grid of rows and columns representing the Amiga's four hardware audio channels.

The file that Soundtracker saved bundled the samples and the arrangement data together, and that file became known as a "module." The now-familiar .mod format and its "M.K." signature bytes were solidified in 1988, by a derivative called DOC SoundTracker IX, coded by Michael Kleps (known in the scene as Unknown/DOC) — which is in fact where those two letters come from, a detail often mistakenly credited to the Swedish musicians Mahoney and Kaktus instead. From there the format spread fast: NoiseTracker and then ProTracker extended Soundtracker's original fifteen-sample limit to thirty-one and added far more pattern effects, and both became the dominant tools of the booming Amiga demoscene and game industry in the late 1980s and early 1990s. When trackers later spread to MS-DOS PCs, the same layered idea of "samples plus pattern data" was carried forward into newer formats — Scream Tracker's S3M, Impulse Tracker's IT, and FastTracker's XM — all of which are, in essence, MOD's direct descendants with more channels, more effects, and more headroom.

Why "Module"? A Self-Contained Piece of Music Software

The word "module" wasn't a marketing flourish; it described something genuinely new about the file. A MOD file isn't just sheet music (which needs a separate instrument to be heard) and it isn't just a recording (which can't be edited note by note). It's a self-sufficient unit that contains everything required to reproduce a song: the raw sound data for every instrument used, plus the exact sequence and timing of when each sample should be triggered, at what pitch, at what volume, and with what effect. Drop that one file onto any compatible player and it "plugs in" and plays back identically, with no separate synthesizer, soundfont, or sample library required — the same way a hardware module plugs into a rack and works on its own. That self-containment is the property later formats like S3M, XM, and IT all inherited, and it's also what made MOD files so easy to pass around demoscene bulletin boards: a few hundred kilobytes carried both the score and the instruments.

Inside the File: The Four Building Blocks

A classic 4-channel MOD file, as produced by ProTracker, is really four sections stitched together in a fixed binary layout. Every player, from the original Amiga Paula chip routines to modern engines like OpenMPT and libxmp, reads the file in this order:

+-----------------------------------------------------------+
| 1. Song title              (20 bytes)                     |
+-----------------------------------------------------------+
| 2. Sample headers           31 x 30 bytes                 |
|    (name, length, finetune, volume, loop start/length)    |
+-----------------------------------------------------------+
| 3. Song arrangement                                       |
|    - song length (1 byte)                                 |
|    - pattern order table (128 bytes)                      |
|    - format tag, e.g. "M.K." (4 bytes)                    |
+-----------------------------------------------------------+
| 4. Pattern data              N patterns x 1024 bytes       |
|    (4 channels x 64 rows x 4 bytes per note)               |
+-----------------------------------------------------------+
| 5. Sample data                raw 8-bit PCM, back to back  |
+-----------------------------------------------------------+

1. The Song Title

The first 20 bytes are simply a null-padded ASCII string — the song's name, as typed by the composer. It has no effect on playback; it's there purely for identification, much like an ID3 tag.

2. The Sample Headers

Next come 31 fixed-size sample header records (early Soundtracker files had only 15). Each 30-byte entry describes one instrument slot, even if that slot is empty:

Sample name (22 bytes) — a label, and in early scene culture often repurposed to hide greetings, credits, or ASCII art rather than a literal instrument name.
Sample length — how many bytes of raw audio belong to this instrument, stored as word counts to be multiplied by two.
Finetune — a small pitch adjustment, letting a sample play back very slightly sharp or flat without retuning the whole instrument.
Default volume — the instrument's starting loudness, from 0 to 64.
Loop start and loop length — which portion of the sample repeats, so a short recording of a plucked string or an organ tone can be sustained indefinitely for a held note.

Note that the actual sample audio isn't stored here — only the description of it. The real waveform data lives in the very last section of the file.

3. The Song Arrangement

This short section tells the player how to structure playback. A single byte gives the "song length," the number of pattern slots actually used. A 128-byte order table then lists, in sequence, which numbered pattern to play at each position — so a song can reuse the same pattern multiple times (a chorus, a verse) without storing it twice. Finally, a 4-byte tag such as M.K. identifies the format variant and, crucially, how many channels and samples the file uses — the detail a player checks first to know how to interpret everything that follows.

4. The Pattern Data

This is the actual "score." Each pattern is a grid of 64 rows (time steps) by 4 columns (channels, one per Amiga hardware voice). Every cell is encoded in exactly 4 bytes:

Bits	Contents
4 bits + 12 bits	Sample number (split across two bytes) and note period
4 bits	Effect command number
8 bits	Effect parameter

The pitch of a note isn't stored as a familiar note name like "C-4." Instead it's stored as an Amiga hardware period value — a number that tells Paula how many clock cycles to wait between each sample point it outputs. Lower period values play a sample back faster, and therefore higher in pitch; higher period values play it slower and lower. ProTracker's standard period table runs from 856 (the note C-1, close to middle C) down to 113 (roughly three octaves higher), and every tracker of the era shared essentially the same values — a legacy of Paula's specific timing hardware baked directly into the file format.

The effect command and parameter give each note extra behavior beyond "play this pitch." A handful of the most common ProTracker effects:

0xy — arpeggio, rapidly cycling between three notes to fake a chord on one channel
1xx / 2xx — slide the pitch up or down, for glissando or pitch-bend effects
3xx — tone portamento, sliding smoothly from the previous note to a new one
Axy — volume slide, fading a note louder or softer over time
Cxx — set volume directly
Fxx — set the song's speed or tempo

With four channels, 64 rows, and 4 bytes per cell, a single pattern always takes up exactly 1024 bytes — a nice, predictable size that made MOD files easy for early players to parse quickly even on modest Amiga hardware.

5. The Sample Data

Last comes the payload the earlier headers were describing: the raw instrument recordings themselves, stored back-to-back as uncompressed, signed 8-bit PCM audio, sampled at whatever rate the composer recorded at. There's no compression and no separate audio codec involved — the bytes here are quite literally the same waveform data the Amiga's DAC would output. This is also why the .mod format was so efficient to play: the Amiga's Paula chip could stream these samples almost directly from memory with very little CPU overhead, leaving the processor free to run the rest of a game or demo.

Why this design worked so well: every piece of the file exists for a reason tied directly to 1987 Amiga hardware — 4 channels because Paula had exactly 4 DMA audio channels, 8-bit PCM because that's what the DAC expected, periods instead of note names because that's the unit the hardware actually used for timing, and 64-row patterns because that made for tidy, fast-to-scan memory blocks. The format wasn't designed in the abstract; it's a direct reflection of the chip it was built to drive.

From MOD to the Rest of the Tracker Family

Once MOD proved the idea, later trackers pushed the same "samples plus pattern data" template further. Scream Tracker's S3M format added support for FM instruments and up to 32 channels; Impulse Tracker's IT format added instrument envelopes and a low-pass filter; and FastTracker II's XM format introduced multi-sample instruments and more elaborate envelopes still. Every one of them keeps MOD's central idea intact: a module is a portable little machine for making music, samples and score bundled as one.