.RMI File Format – Track chunks and events

Events

Every event has the same two parts:

<delta time> <event>

The delta time is the number of ticks since the previous event in the same track. The event is one of three kinds, told apart by its first byte, the status byte:

The other status bytes, F1 to F6 and F8 to FE, are system common and real-time messages. They are not events in a file and can only be sent inside an F7 escape. FF in a file is always a meta event, never System Reset.

Delta time

The delta time is a count of ticks, written as a variable-length quantity. It is 0 for an event at the same moment as the one before. How long a tick lasts is set by the header’s division and, for tick-per-beat timing, by the tempo: see Timing.

The delta time of the first event is counted from the start of the track. Adding the delta times up gives each event’s time in ticks from the start.

Variable-length quantities

Delta times, and the lengths of meta and system exclusive events, are written seven bits to a byte, the most significant group first. Every byte but the last has its top bit set. A quantity is at most four bytes long, so the largest value is 0FFFFFFF, 268,435,455. This is the MIDI file’s own encoding; the RIFF sizes around it are plain 32-bit little-endian numbers.

To read one:

1. Start with a value of 0.
2. Read a byte. Multiply the value by 128 and add the byte’s low seven bits (byte & 7F).
3. If the byte’s top bit is set (the byte is 80 or more), go back to step 2. Otherwise the value is complete.

To write one, take the value seven bits at a time from the bottom, then write the groups from the top down, setting the top bit on every byte but the last. The explorer turns down a quantity that runs on for more than four bytes.

Running status

When a channel message has the same status byte as the channel message before it, the status byte may be left out. The event is then just the delta time and the data bytes. A reader can tell, because the first byte after the delta time is below 80, and data bytes always are.

System exclusive and meta events cancel running status, so the first channel message after one must have its own status byte. A data byte with no earlier status to repeat is an error. When a file uses running status straight after a meta event, the explorer reads it with the status from before the meta event and says so.

An example from a real MIDI file, with the explorer’s reading:

End of track

The meta event FF 2F 00 must be the last event of every track. It gives the track an exact length: its delta time can place the end after the last note. Bytes after it, inside the track chunk, are not part of the track; the explorer shows them separately.

A track whose last event runs past the end of its chunk is damaged; the explorer shows such a file in its lenient reading. The last track also cannot run past the end of the data chunk, which is where the MIDI file ends.

Timing

With ticks per quarter note in the header, the length of a tick depends on the tempo, set by the Set tempo meta event in microseconds per quarter note:

seconds = ticks × tempo ÷ 1,000,000 ÷ ticks per quarter note

Until the first Set tempo event the tempo is 500,000 µs a quarter note, which is 120 beats a minute. The time signature is taken as 4/4 until the first Time signature event; that default is widely stated, but was not found in the text of the specification read for this page.

A tempo change applies from its tick onwards, so the time of an event is the sum, over each stretch between tempo events, of the ticks in that stretch at that stretch’s tempo. In types 0 and 1 every track runs on one clock, from the tempo events of the whole MIDI file (in type 1 they belong in the first track). In type 2 each pattern has its own.

Worked: at 192 ticks a quarter note and a tempo of 857,143 µs (70 beats a minute), 192 ticks last 192 × 857,143 ÷ 1,000,000 ÷ 192 = 0.857 seconds.

With SMPTE timing, a tick is a fixed fraction of a second, 1 ÷ (frames a second × ticks per frame), and tempo events do not change it.