The bulk of information for this article comes from public domain sources, in particular Standard MIDI File Format by Dustin Caldwell. The rest was filled in through various sources and contributions. As such, even though most articles on this site are licensed under the Creative Commons Attribution license, this article is here by released into the public domain.

MIDI sequence files are made up of chunks of data. The header chunk describes information about the MIDI file as a whole. The header chunk is followed by one or more track chunks, each of which contain a sequence of MIDI events. MIDI events consist of some kind of command or status with associated data plus a time-stamp for each message. Each track may contain information for up to 16 MIDI channels. Events and data are stored big-endian which is the most significant byte first. Events are stored in a variable-length format which may use one or more bytes. The high-order bit is used to determine the last byte in a sequence. If the high-order bit is set to 1 then another byte follows, if the high-order bit is 0 then this is the last byte in the sequence. The lower 7 bits of each byte are used to store the actual data. As the commands are read the data must be reformatted for the specific platform.

The first chunk in the file is the header chunk. The header chunk always starts with a magic value 'MThd'. This is stored in the first 4 bytes of the file. The next four bytes is the size of the header in bytes. This size does not count the magic value or the size field of the header. As such, this value will always be 6.

4D 54 68 64 00 00 00 06 ff ff nn nn dd dd

Following the size field is a 16-bit field specifying the file format (ff ff above). This will be one of three values:

0 - single-track
1 - multiple tracks, synchronous
2 - multiple tracks, asynchronous

Single track is only one track that contains all of the MIDI events for the entire file, including the song title, time signature, tempo and music events. Synchronous multiple tracks contains more than one track each of which start at the same time. The first track typically contains song information such as the title and copyright information, time signature, tempo, etc. The following tracks contain a title, musical event data, etc. specific to that track. Asynchronous multiple tracks also contains multiple tracks however they do not have to start at the same time.

The next field is a 16-bit value specifying the number of tracks in the file (nn nn above). For single-track this value is 1. For multiple track files this can be up to 65535.

The last field is a 16-bit value specifying the number of delta-time ticks per quarter note (dd dd above) or frames per second. If the most significant bit is 0 the remaining bits specify the delta-time ticks per beat. If the most significant bit is 1 the remaining bits specify the delta-time in frames per second. For ticks per beat, common values range from 48 to 960.

Frames per second is defined by breaking the remaining 15 bits into two values. The top 7 bits define a value for the number of SMPTE frames and can be 24, 25, 29 (for 29.97 fps) or 30. The remaining 8 bits define how many ticks there are per frame.

In C the header structure looks something like this:

#define MID_ID		'dhTM'
#define MID_HDR_SIZE	0x06000000
 
#define MID_FMT_SINGLE	0x0000	// single track
#define MID_FMT_MULTIS	0x0100	// multiple tracks, synchronous
#define MID_FMT_MULTIA	0x0200	// multiple tracks, asynchronous
 
#pragma pack(push, 1)
 
struct mid_header {
	unsigned int	id;	// identifier "MThd"
	unsigned int	size;	// always 6 in big-endian format
	unsigned short	format;	// big-endian format
	unsigned short  tracks;	// number of tracks, big-endian
	unsigned short	ticks;	// number of ticks per quarter note, big-endian
};
 
#pragma pack(pop)

Following the header is one or more track chunks. Each track has one header followed by a stream of MIDI event. Similar to the file header, the track header always starts with a magic value 'MTrk'. This is stored in the first 4 bytes of the track header. The next four bytes is the size of the size of the track in bytes. This size does not count the magic value or the size field of the header.

4D 54 72 6B xx xx xx xx

In C the header structure looks something like this:

#define MID_TRK_ID	'krTM'
 
struct mid_track {
	unsigned int	id;	// identifier "MTrk"
	unsigned int	length;	// track length, big-endian
};

Following the header are the actual MIDI events. MIDI events consist of a delta-time followed by a MIDI event. The delta-time is the number of ticks after which the MIDI event should be executed. The delta-time is a variable length encoded value. Each byte of the value contains 7 bits of data and 1 bit for continuation. The first byte is read and the 7 least significant bits are extracted. If the most significant bit is 1, the next byte is read. The 7 least significant bits are extracted. The previous value is multiplied by 128 and the new value is added. If the most significant bit is 0, the process is done. The delta-time should never be more than 4 bytes long.

The delta-time is relative to the last event. If two or more events should be executed simultaneously, the first event specifies the delta-time to wait since the previous event, the following events have a delta-time of 0. Simply put, wait 0 ticks from the previous event to execute this event.

Example:

Play note A followed by note B 100 ticks later, stop A after 200 ticks, stop B at the same time as A.

Ticks     Event              Description
--------------------------------------------------------------
0         Note A on event    Note A starts playing immediately
100       Note B on event    Note B starts playing 100 ticks after A
100       Note A off event   Note A stops playing after 200 total ticks
0         Note B off event   Note B stops at the same time as A (after 100 ticks)

Each midi event has a command byte followed by one or more data bytes. The command byte will always have a most significant bit of 1. Each command has different parameters and lengths, but the data that follows the command will have a most significant bit of 0. The exception to this is a meta-event, which may contain data with a most significant bit of 1. However, meta-events require a length parameter which alleviates confusion.

For all of these messages, a convention called the "running status byte" or "running mode" may be used. If the transmitter wishes to send another message of the same type on the same channel, thus the same status byte, the status byte need not be resent. Running mode is identified by checking the most significant bit of the next "event byte". If the most significant bit is 0, the "event byte" is not really the next event but the first parameter to the event. The actual event byte was omitted and the previous event byte is used.

+--7----6----5----4----3----2----1----0-+
|  1 |  Event type  |  Channel number   |
+---------------------------------------+

Each command byte has 2 parts. The left nibble (4 bits) contains the actual command, and the right nibble (xxxx) contains the midi channel number on which the command will be executed. There are 16 midi channels and 8 midi commands. The data bytes that follow the command will have a most significant bit of 0.

The following table lists meta-events which have no midi channel number. They are of the format:

FF xx nn dd

All meta-events start with FF followed by the command (xx), the length, or number of bytes that will contain data (nn), and the actual data (dd).

  bpm = beats per minute.
  60000000 / bpm = tt tt tt.
  
  nn = delta-time ticks per beat. (specified in the header chunk)
  tt tt tt = microseconds per beat. (specified by the tempo event)
  tt tt tt / nn = microseconds per delta-time tick. (PPQN Clock)
  
  96 delta-time ticks per beat. (header)
  120 beats per minute = 500000 microseconds per beat. (tempo event)
  500000 / 96 = 5208.3 microseconds per delta-time tick.
  
  500000 / 48 = 10416.7 microseconds per delta-time tick.

The following are system messages which control the entire system. These commands are used to control physical MIDI devices and are not typically found in MIDI files. They have no midi channel number. (They will generally only apply to controlling a midi keyboard, etc.)

A large amount of System Exclusive data in a Normal System Exclusive Event could cause following MIDI Channel Events to be transmitted after the time they should be played. This will cause an unwanted delay in play back of the following events. The second type of System Exclusive Events solve this problem by allowing a large amount of System Exclusive data to be divided into smaller blocks, transmitted with a delay between each division to allow the transmission of other MIDI events in order to prevent congesting of the limited MIDI bandwidth. The initial Divided System Exclusive Event follows the same format as a Normal System Exclusive Event with the exception that the last data byte is not 0xF7. This indicates the the System Exclusive data is not finished and will be continued in an upcoming Divided System Exclusive Event. Any following Divided System Exclusive Events before the final one use the a similar format as the first, only the start byte is 0xF7 instead of 0xF0 to signal continuation of System Exclusive data. The final block follows the same format as the continuation blocks, except the last data byte is 0xF7 to signal the completion of the divided System Exclusive data.

The last type of System Exclusive Event authorizes and enables the transmission of special messages such as Song Position Pointer, MIDI Time Code and Song Select messages. These System Exclusive Events use the event type value 0xF7.

This table lists the controller codes used in the controller setting change command above.

*Note: This equals the number of channels, or zero if the number of channels equals the number of voices in the receiver.

The following table lists the numbers corresponding to notes for use in note on and note off commands.

The heart of General MIDI (GM) is the Instrument Patch Map This is a list of 128 sounds, with corresponding MIDI program numbers. Most of these are imitative sounds, though the list includes synth sounds, ethnic instruments and a handful of sound effects.

The sounds fall roughly into sixteen families of eight variations each. Grouping sounds makes it easy to re-orchestrate a piece using similar sounds. The instrument map isn't the final word on musical instruments of the world, but it's pretty complete.

General MIDI also includes a Percusssion Key Map. This mapping derives from the Roland/Sequential mapping used on early drum machines. As with the Instrument Map, it doesn't cover every percussive instrument in the world, but it's more than adequate as a basic set.

To avoid concerns with channels, GM restricts percussion to MIDI Channel 9. Theoretically, the lower nine channels (0 - 8) are for the instruments, but the GM spec states that a sound module must respond to all sixteen MIDI channels, with dynamic voice allocation and a minimum of 24 voices.

• "Standard MIDI File Format" - Dustin Caldwell
• "MIDI File Format"
• "MIDI Technical Fanatic's Brainwashing Center"
• "The USENET MIDI Primer" - Bob McQueer

• The MIDI Manual, Third Edition: A Practical Guide to MIDI in the Project Studio
• MIDI Power!: The Comprehensive Guide
• Game Audio Programming (Charles River Media Game Development)
• Video Game Music File Formats, including: Xm (file Format), Mod (file Format), Module File, S3m (file Format), Midi Timecode, General Midi, Yamaha Xg, ... Audio Midi Setup, General Midi Level 2