The data chunk of an RMI file holds a complete Standard MIDI File, built from chunks of its own. This page and the ones after it describe those bytes. Offsets are counted from the start of the MIDI file, which is the start of the data chunk’s contents: offset 20 in the file when the data chunk comes first. Unlike the RIFF sizes around it, every number in the MIDI file is big-endian, most significant byte first.
The MIDI file starts with the header chunk MThd, which says what kind of
file this is, how many tracks follow and how time is counted. The
track chunks come after it.
00000000 4D 54 68 64 00 00 00 06 00 01 00 12 00 C0 4D 54 MThd..........MT
00000010 72 6B rkNo RMI file was among the files examined for this site; the examples on these pages come from Standard MIDI Files, whose bytes are the same as those in a data chunk.
Chunks
Every chunk of the MIDI file has the same 8-byte head. There is no padding between chunks, unlike the RIFF chunks around them: the next chunk starts straight after the last byte of the one before.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 4 | ASCII | type | MThd for the header, MTrk for a track. Any other type is a chunk to skip. |
| 4 | 4 | u32 BE | length | The number of data bytes that follow, not counting these 8. |
| 8 | length | data | The chunk’s contents. |
The MIDI file is one MThd chunk followed by the MTrk chunks,
as many as the header says, and it ends where the data chunk ends.
The header chunk
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 4 | ASCII | type | MThd (4D 54 68 64). |
| 4 | 4 | u32 BE | length | 6. Readers must accept a larger value and skip the bytes after the three fields. |
| 8 | 2 | u16 BE | format | The type of file, 0, 1 or 2. See Format. |
| 10 | 2 | u16 BE | ntrks | The number of track chunks. See Tracks. |
| 12 | 2 | u16 BE | division | How delta times are counted. See Division. |
In the example above, 00 00 00 06 is the length, 00 01 is
type 1, 00 12 is 18 tracks and 00 C0 is 192 ticks a quarter
note.
Format
| Value | Type | Meaning |
|---|---|---|
| 0 | Single track | One track chunk holds everything: every channel, the tempo and the time signature. |
| 1 | Several tracks | Tracks that play at the same time. The first track should hold the tempo map: the tempo and time signature events. All tracks share it. |
| 2 | Independent patterns | Each track is a pattern of its own, with its own tempo events. A sequence number meta event can identify each one. |
Type 0 and type 1 are the usual ones; type 2 is rare. The explorer times a type 2 file’s patterns one after another, each starting at 120 beats a minute with its own tempo events.
Tracks
ntrks is the number of MTrk chunks in the MIDI file. It is
always 1 in a type 0 file. Some files have a count that does not match the chunks
present. The explorer reads every MTrk chunk it finds in the data chunk
and reports the difference.
Division
The top bit of division chooses one of two ways of counting time.
| Bit 15 | Bits 14 to 8 | Bits 7 to 0 | Meaning |
|---|---|---|---|
| 0 | ticks per quarter note, 1 to 32,767 | Delta times are fractions of a beat; how long a beat lasts depends on the tempo. | |
| 1 | minus the SMPTE frame rate | ticks per frame | Delta times are fixed fractions of a second. See SMPTE timing. |
Ticks per quarter note are often called PPQ, pulses per quarter note. Common values are 96, 120, 192, 384 and 480.
SMPTE timing
When bit 15 is set, the high byte is a negative number in two’s complement, minus the frame rate, and the low byte is the number of ticks in each frame.
| High byte | Value | Frame rate |
|---|---|---|
E8 | −24 | 24 frames a second |
E7 | −25 | 25 frames a second |
E3 | −29 | 30 drop-frame, 29.97 frames a second |
E2 | −30 | 30 frames a second |
For example, E7 28 is 25 frames of 40 ticks: 1,000 ticks a second, so
each tick is a millisecond. With SMPTE timing, tempo events do not change how long a
tick lasts.
Unknown chunks
A reader must skip a MIDI chunk whose type it does not know, whole, by its length. This lets later versions add chunk types without breaking older readers. The explorer shows such chunks with their bytes and carries on.
When the bytes after a chunk do not start another chunk, the explorer looks for the
next MTrk inside the data chunk and carries on from there; zero bytes at
the end are shown as padding. These are chunks of the MIDI file; unknown RIFF chunks
around the data chunk are described under
RIFF chunks.