MIDI format - Revision history

BukTop: 6 revisions imported

2019-07-14T22:20:11Z

6 revisions imported

BukTop: 5 revisions imported

2018-04-04T09:37:02Z

5 revisions imported

my_wiki>Qhimm: Very minor formatting changes, e.g. making use of special code tags

2005-03-19T17:54:54Z

Very minor formatting changes, e.g. making use of special code tags

Show changes

my_wiki>Halkun: /* Linked to MIDI events (There are a lot of them!) */

2005-03-12T14:55:26Z

‎Linked to MIDI events (There are a lot of them!)

my_wiki>Halkun at 14:49, 12 March 2005

2005-03-12T14:49:11Z

my_wiki>Halkun at 14:33, 12 March 2005

2005-03-12T14:33:52Z

Show changes

my_wiki>Halkun at 13:47, 12 March 2005

2005-03-12T13:47:17Z

New page

== Standard MIDI File (SMF) Format ==

The Standard MIDI File (SMF) is a file format used to store MIDI data (plus some
other kinds of data typically needed by a sequencer.

This format stores the standard MIDI messages (ie, status bytes with appropriate data bytes)
plus a time-stamp for each message (ie, a series of bytes that represent how many clock pulses
to wait before "playing" the event). The format also allows saving information about tempo,
time and key signatures, the names of tracks and patterns, and other information typically
needed by a sequencer. One SMF can store information for numerous patterns and tracks so that any
sequencer can preserve these structures when loading the file.

NOTE: A track usually is analogous to one musical part,
such as a Trumpet part. A pattern would be analogous to all of the musical parts (ie,
Trumpet, Drums, Piano, etc) for one song.

The format was designed to be generic so that the most important data can be read by all
sequencers. Think of a MIDI file as a musical version of an ASCII text file (except
that the MIDI file contains binary data), and the various sequencer programs as text editors
all capable of reading that file. But, unlike ASCII, MIDI file format saves data in chunks
(ie, groups of bytes preceded by an ID and size) which can be parsed, loaded, skipped, etc.
Therefore, SMF format is flexible enough for a particular sequencer to store
its own proprietary, "extra" data in such a way that another sequencer won't be confused when
loading the file and can safely ignore this extra stuff that it doesn't need.
For example, maybe a sequencer wants to save a "flag byte"
that indicates whether the user has turned on an audible metronome click. The sequencer can save
this flag byte in such a way that another sequencer can skip this byte without
having to understand what that byte is for. In the future, the SMF format can also be
extended to include new "official" chunks that all sequencer programs may elect to load and use.
This can be done without making old data files obsolete, nor making old sequencers no longer
able to load the new files. So, the format is designed to be
extensible in a backwardly compatible way.

Of course, SMF files may be used by other MIDI software than just sequencers.
Since SMF files can store any and all types of MIDI messages, including System Exclusive
messages, they may be used to store/load data by all kinds of MIDI software, such as a Patch
Editor that wants to save some System Exclusive messages it received from a MIDI module. (The
"timestamp" for each message may be irrelevant to such a Patch Editor. But it's easily
ignored for programs that don't really need it).

In conclusion, any software that saves or loads MIDI data should use SMF format for its data
files.

==== MIDI File Format: Chunks ====

Data is always saved within a chunk. There can be many chunks inside of a MIDI file.

Each chunk can be a different size (and likely will be). A chunk's size is how many (8-bit)
bytes are contained in the chunk.

The data bytes in a chunk are typically related in some way. For example, all of the bytes in one chunk may be for one particular sequencer track. The bytes for another sequencer track may be put in
a different chunk. So, a chunk is simply a group of related bytes.

Each chunk must begin with a 4 character (ie, 4 ascii bytes) ID which tells what "type"
of chunk this is.

The next 4 bytes must form a 32-bit length (ie, size) of the chunk.

All chunks must begin with these two fields (ie, 8 bytes), which are referred to as the
chunk header.

Here's what a chunk's header looks like if you defined it in C:
<pre>
struct CHUNK_HEADER
{
char ID[4];
unsigned long Length;
};
</pre>
NOTE: The Length does not include the 8 byte chunk
header. It simply tells you how many bytes of data are in the chunk following this header.

And here's an example chunk header (with bytes expressed in hex) if you examined it with a hex editor:

4D 54 68 64 00 00 00 06

Note that the first 4 bytes make up the ascii ID of MThd (ie, the first four
bytes are the ascii values for 'M', 'T', 'h', and 'd'). The next 4 bytes tell us that there should
be 6 more data bytes in the chunk (and after that we should find the next chunk header or the end
of the file).

=== MIDI File Format: MThd Chunk ===

The MThd header has an ID of MThd, and a Length of 6.

Let's examine the 6 data bytes (which follow the MThd header) in an MThd chunk.

The first two data bytes tell the Format (which I prefer to call "type").
There are actually 3 different types (ie, formats) of MIDI files. A type of 0 means that the file
contains one single track containing midi data on possibly all 16 midi channels. If your sequencer
sorts/stores all of its midi data in one single block of memory with the data in the order that it's
"played", then it should read/write this type. A type of 1 means that the file contains one or
more simultaneous (ie, all start from an assumed time of 0) tracks, perhaps each on a single midi
channel. Together, all of these tracks are considered one sequence or pattern. If your
sequencer separates its midi data (i.e. tracks) into different blocks of memory but plays them back
simultaneously (ie, as one "pattern"), it will read/write this type. A type of 2 means that the
file contains one or more sequentially independant single-track patterns. If your sequencer
separates its midi data into different blocks of memory, but plays only one block at a time (ie,
each block is considered a different "excerpt" or "song"), then it will read/write this type.

The next 2 bytes tell how many tracks are stored in the file, NumTracks. Of course,
for format type 0, this is always 1. For the other 2 types, there can be numerous tracks.

The last two bytes indicate how many Pulses (i.e. clocks) Per Quarter Note (abbreviated as PPQN) resolution the time-stamps are based upon, Division. For example, if your sequencer has 96 ppqn, this field would be (in hex):

00 60

NOTE: The 4 bytes that make up the Length are stored in (Motorola) "Big Endian" byte order, not (Intel) "Little Endian" reverse byte order. (ie, The 06 is the fourth byte instead
of the first of the four).

In fact, all MIDI files begin with the above MThd header (and that's how you know that it's
a MIDI file).

Alternately, if the first byte of Division is negative, then this represents the division
of a second that the time-stamps are based upon. The first byte will be -24, -25, -29, or -30,
corresponding to the 4 SMPTE standards representing frames per second. The second byte (a
positive number) is the resolution within a frame (ie, subframe). Typical values may be 4 (MIDI
Time Code), 8, 10, 80 (SMPTE bit resolution), or 100.

You can specify millisecond-based timing by the data bytes of -25 and 40 subframes.

Here's what an MThd chunk looks like if you defined it in C:

<pre>
struct MTHD_CHUNK
{
/* Here's the 8 byte header that all chunks must have */
char ID[4]; /* This will be 'M','T','h','d' */
unsigned long Length; /* This will be 6 */

/* Here are the 6 bytes */
unsigned short Format;
unsigned short NumTracks;
unsigned short Division;
};
</pre>

And here's an example of a complete MThd chunk (with header) if you examined it in a hex editor:
<pre>
4D 54 68 64 MThd ID
00 00 00 06 Length of the MThd chunk is always 6.
00 01 The Format type is 1.
00 02 There are 2 MTrk chunks in this file.
E7 28 Each increment of delta-time represents a millisecond.
</pre>

@@ Line 313: / Line 313: @@
 ==== Events in an MTrk ====
-An MTrk can contain MIDI events and non-MIDI events (ie, events that contain data such as
+An MTrk can contain [http://www.borg.com/~jglatt/tech/midispec.htm MIDI events] and non-MIDI events (ie, events that contain data such as
 tempo settings, track names, etc).
 The first (1 to 4) byte(s) in an MTrk will be the first event's delta-time as a variable length
 quantity. The next data byte is actually the first byte of that event itself. I'll refer to this as
-the event's <B>Status</B>. For MIDI events, this will be the actual MIDI Status byte
+the event's <B>Status</B>. For [http://www.borg.com/~jglatt/tech/midispec.htm MIDI events], this will be the actual MIDI Status byte
 (or the first midi data byte if running status). For example, if the byte is hex 90, then this
 event is a <B>Note-On</B> upon midi channel 0. If for example, the byte was hex 23, you'd have to
@@ Line 380: / Line 380: @@
 all midi events, Meta-Events have a delta-time from the previous event regardless of what type
 of event that may be. So, you can freely intermix MIDI and Meta events).
 ==== Meta-Events in an MTrk ====

@@ Line 497: / Line 497: @@
 wrong value when played on a General MIDI instrument. Intelligent software can use the
 Program Name event to look up the correct value for the <B>MIDI Program Change</B> event.
 Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
 is expressed as a variable length quantity.

← Older revision	Revision as of 22:20, 14 July 2019
(No difference)

← Older revision	Revision as of 09:37, 4 April 2018
(No difference)