Difference between pages "FF8/Menu mngrp bin" and "MIDI format"

From Final Fantasy Inside
< FF8(Difference between pages)
Jump to navigation Jump to search
my_wiki>Sebanisu
(Mapped Data: found another string location)
 
my_wiki>Halkun
 
Line 1: Line 1:
This file is an archive the contains 117 files. I created map by reading [[FF8/Menu_mngrphd_bin|mngrphd.bin]] and filling in data from [http://forums.qhimm.com/index.php?topic=17099.0 FF8 - mngrp.bin by JWP].
+
= Standard MIDI File (SMF) Format =
==Mapped Data==
+
 
{| class="wikitable"
+
The <B>Standard MIDI File</B> (SMF) is a file format used to store MIDI data (plus some
|-
+
other kinds of data typically needed by a sequencer.
! Pos
+
 
! Seek
+
This format stores the standard MIDI messages (ie, status bytes with appropriate data bytes)
! Size
+
plus a time-stamp for each message (ie, a series of bytes that represent how many clock pulses
! Filename
+
to wait before "playing" the event). The format also allows saving information about tempo,
! Description
+
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
| 0
+
sequencer can preserve these structures when loading the file.
| 0x0
+
 
| 0x800
+
<B><FONT COLOR=RED>NOTE:</FONT></B> A <B>track</B> usually is analogous to one musical part,
| [[FF8/Menu_tkmnmes|tkmnmes1.bin]]
+
such as a Trumpet part. A <B>pattern</B> would be analogous to all of the musical parts (ie,
| Encoded string archive
+
Trumpet, Drums, Piano, etc) for one song.
Starts with padding values<br/>
+
 
Has location values before strings<br/>
+
The format was designed to be generic so that the most important data can be read by all
Strings end with '''0x00'''
+
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
| 1
+
all capable of reading that file. But, unlike ASCII, MIDI file format saves data in <B>chunks</B>
| 0x800
+
(ie, groups of bytes preceded by an ID and size) which can be parsed, loaded, skipped, etc.
| 0x1800
+
Therefore, SMF format is flexible enough for a particular sequencer to store
| [[FF8/Menu_tkmnmes|tkmnmes2.bin]]
+
its own proprietary, "extra" data in such a way that another sequencer won't be confused when
| Encoded string archive
+
loading the file and can safely ignore this extra stuff that it doesn't need.
Starts with padding values<br/>
+
For example, maybe a sequencer wants to save a "flag byte"
Has location values before strings<br/>
+
that indicates whether the user has turned on an audible metronome click. The sequencer can save
Strings end with '''0x00'''
+
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
| 2
+
extended to include new "official" chunks that all sequencer programs may elect to load and use.
| 0x2000
+
This can be done without making old data files obsolete, nor making old sequencers no longer
| 0x2000
+
able to load the new files. So, the format is designed to be
| [[FF8/Menu_tkmnmes|tkmnmes3.bin]]
+
extensible in a backwardly compatible way.
| Encoded string archive
+
 
Starts with padding values<br/>
+
Of course, SMF files may be used by other MIDI software than just sequencers.
Has location values before strings<br/>
+
Since SMF files can store any and all types of MIDI messages, including System Exclusive
Strings end with '''0x00'''
+
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
| 3
+
"timestamp" for each message may be irrelevant to such a Patch Editor. But it's easily
| 0x4000
+
ignored for programs that don't really need it).
| 0xE000
+
 
|
+
In conclusion, any software that saves or loads MIDI data should use SMF format for its data
|
+
files.
|-
+
 
| 4
+
== Chunks ==
| 0x12000
+
 
| 0x1000
+
Data is always saved within a <B>chunk</B>. 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.
| 5
+
 
| 0x13000
+
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
| 0x6800
+
a different chunk. So, a chunk is simply a group of related bytes.
| [[FF8/Menu_sp2#Content_of_face1.tex_and_face2.tex|face1.tim]]
+
 
| Character portraits
+
Each chunk must begin with a 4 character (ie, 4 ascii bytes) <B>ID</B> which tells what "type"
|-
+
of chunk this is.
| 6
+
 
| 0x19800
+
The next 4 bytes must form a 32-bit length (ie, size) of the chunk.
| 0x6800
+
 
| [[FF8/Menu_sp2#Content_of_face1.tex_and_face2.tex|face2.tim]]
+
<U>All chunks must begin with these two fields</U> (ie, 8 bytes), which are referred to as the
| GF portraits
+
<B>chunk header</B>.
|-
+
 
| 7
+
Here's what a chunk's header looks like if you defined it in C:
| 0x20000
+
<pre>
| 0x800
+
struct CHUNK_HEADER
| magita.tim
+
{
| Tutorial/Magazine background texture
+
  char            ID[4];
|-
+
  unsigned long    Length;
| 8
+
};
| 0x20800
+
</pre>
| 0xE000
+
<B><FONT COLOR=RED>NOTE:</FONT></B> The <B>Length</B> does not include the 8 byte chunk
| start00_and_start01.tim
+
header. It simply tells you how many bytes of data are in the chunk <U>following this header</U>.
| Title screen logo
+
 
|-
+
And here's an example chunk header (with bytes expressed in hex) if you examined it with a hex editor:
| 9
+
 
| 0x2E800
+
4D 54 68 64 00 00 00 06
| 0xC800
+
 
| [[ff8/Menu_mag_textures|mag00.tim]]
+
Note that the first 4 bytes make up the ascii ID of <B>MThd</B> (ie, the first four
| Weapons Monthly, 1st Issue
+
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
| 10
+
of the file).
| 0x3B000
+
 
| 0xC800
+
=== MThd Chunk ===
| [[ff8/Menu_mag_textures|mag07.tim]]
+
 
| Pet Pals
+
The MThd header has an ID of <B>MThd</B>, and a Length of <B>6</B>.
|-
+
 
| 11
+
Let's examine the 6 data bytes (which follow the MThd header) in an MThd chunk.
| 0x47800
+
 
| 0xC800
+
The first two data bytes tell the <B>Format</B> (which I prefer to call "type").
| [[ff8/Menu_mag_textures|mag00.tim]]
+
There are actually 3 different types (ie, formats) of MIDI files. A type of 0 means that the file
| Weapons Monthly, 1st Issue
+
contains one single track containing midi data on possibly all 16 midi channels. If your sequencer
duplicate of 0x2E800
+
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
| 12
+
more simultaneous (ie, all start from an assumed time of 0) tracks, perhaps each on a single midi
| 0x54000
+
channel. Together, all of these tracks are considered one sequence or pattern. If your
| 0xC800
+
sequencer separates its midi data (i.e. tracks) into different blocks of memory but plays them back
| [[ff8/Menu_mag_textures|mag01.tim]]
+
simultaneously (ie, as one "pattern"), it will read/write this type. A type of 2 means that the
| Weapons Monthly, March Issue
+
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,
| 13
+
each block is considered a different "excerpt" or "song"), then it will read/write this type.
| 0x60800
+
 
| 0xC800
+
The next 2 bytes tell how many tracks are stored in the file, <B>NumTracks</B>. Of course,
| [[ff8/Menu_mag_textures|mag02.tim]]
+
for format type 0, this is always 1. For the other 2 types, there can be numerous tracks.
| Weapons Monthly, April Issue
+
 
|-
+
The last two bytes indicate how many Pulses (i.e. clocks) Per Quarter Note (abbreviated as PPQN) resolution the time-stamps are based upon, <B>Division</B>. For example, if your sequencer has 96 ppqn, this field would be (in hex):
| 14
+
 
| 0x6D000
+
00 60
| 0xC800
+
 
| [[ff8/Menu_mag_textures|mag03.tim]]
+
<B><FONT COLOR=RED>NOTE:</FONT></B> The 4 bytes that make up the <B>Length</B> are stored in (Motorola) "Big Endian" byte order, not (Intel) "Little Endian" reverse byte order. (ie, The 06 is the fourth byte instead
| Weapons Monthly, May Issue
+
of the first of the four).
|-
+
 
| 15
+
In fact, all MIDI files begin with the above <B>MThd header</B> (and that's how you know that it's
| 0x79800
+
a MIDI file).
| 0xC800
+
 
| [[ff8/Menu_mag_textures|mag04.tim]]
+
Alternately, if the first byte of Division is negative, then this represents the division
| Weapons Monthly, June Issue
+
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
| 16
+
positive number) is the resolution within a frame (ie, subframe). Typical values may be 4 (MIDI
| 0x86000
+
Time Code), 8, 10, 80 (SMPTE bit resolution), or 100.
| 0xC800
+
 
| [[ff8/Menu_mag_textures|mag05.tim]]
+
You can specify millisecond-based timing by the data bytes of -25 and 40 subframes.
| Weapons Monthly, July Issue
+
 
|-
+
Here's what an MThd chunk looks like if you defined it in C:
| 17
+
 
| 0x92800
+
<pre>
| 0xC800
+
struct MTHD_CHUNK
| [[ff8/Menu_mag_textures|mag06.tim]]
+
{
| Weapons Monthly, August Issue
+
  /* Here's the 8 byte header that all chunks must have */
|-
+
  char          ID[4];  /* This will be 'M','T','h','d' */
| 18
+
  unsigned long  Length; /* This will be 6 */
| 0x9F000
+
 
| 0xC800
+
  /* Here are the 6 bytes */
| [[ff8/Menu_mag_textures|mag08.tim]]
+
  unsigned short Format;
| Occult Fan I & II
+
  unsigned short NumTracks;
|-
+
  unsigned short Division;
| 19
+
};
| 0xAB800
+
</pre>
| 0xC800
+
 
| [[ff8/Menu_mag_textures|mag09.tim]]
+
And here's an example of a complete MThd chunk (with header) if you examined it in a hex editor:
| Occult Fan III & IV
+
<pre>
|-
+
4D 54 68 64    MThd ID
| 20
+
00 00 00 06    Length of the MThd chunk is always 6.
| 0xB8000
+
00 01          The Format type is 1.
| 0xC800
+
00 02          There are 2 MTrk chunks in this file.
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc00.tim]]
+
E7 28          Each increment of delta-time represents a millisecond.
| Card textures for menus
+
</pre>
|-
+
 
| 21
+
=== MTrk Chunk ===
| 0xC4800
+
After the MThd chunk, you should find an <B>MTrk chunk</B>, as this is the only other
| 0xC800
+
currently defined chunk. (If you find some other chunk ID, it must be proprietary to some other
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc01.tim]]
+
program, so skip it by ignoring the following data bytes indicated by the chunk's
| Card textures for menus
+
Length).
|-
+
 
| 22
+
An MTrk chunk contains all of the midi data (with timing bytes), plus optional non-midi data
| 0xD1000
+
for <U>one track</U>. Obviously, you should encounter as many MTrk chunks in the file as the
| 0xC800
+
MThd chunk's NumTracks field indicated.
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc02.tim]]
+
 
| Card textures for menus
+
The MTrk header begins with the ID of <b>MTrk</B>, followed by the Length (ie, number of data bytes for this track). The Length will likely be different for each track. (After all, a track containing the violin part for a Bach concerto will likely contain more data than a track containing a simple 2 bar drum beat).
|-
+
 
| 23
+
Here's what an MTrk chunk looks like if you defined it in C:
| 0xDD800
+
<pre>
| 0xC800
+
struct MTRK_CHUNK
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc03.tim]]
+
{
| Card textures for menus
+
  /* Here's the 8 byte header that all chunks must have */
|-
+
  char          ID[4];  /* This will be 'M','T','r','k' */
| 24
+
  unsigned long  Length;  /* This will be the actual size of Data[] */
| 0xEA000
+
 
| 0xC800
+
  /* Here are the data bytes */
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc04.tim]]
+
  unsigned char  Data[];  /* Its actual size is Data[Length] */
| Card textures for menus
+
};
|-
+
</pre>
| 25
+
 
| 0xF6800
+
 
| 0xC800
+
==== Variable Quantities ====
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc05.tim]]
+
Think of a track in the MIDI file in the same way that you normally think of a track in a
| Card textures for menus
+
sequencer. A sequencer track contains a series of <B>events</B>. For example, the first
|-
+
event in the track may be to sound a middle C note. The second event may be to sound the
| 26
+
E above middle C. These two events may both happen at the same time. The third event may
| 0x103000
+
be to release the middle C note. This event may happen a few musical beats after the first
| 0xC800
+
two events (ie, the middle C note is held down for a few musical beats). Each event has a
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc06.tim]]
+
"time" when it must occur, and the events are arranged within a "chunk" of memory in the order
| Card textures for menus
+
that they occur.
|-
+
 
| 27
+
In a MIDI file, an event's "time" precedes the data bytes that make up that event itself. In
| 0x10F800
+
other words, the bytes that make up the event's time-stamp come first. A given event's
| 0xC800
+
time-stamp is referenced from the previous event. For example, if the first event occurs 4 clocks
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc07.tim]]
+
after the start of play, then its "delta-time" is 04. If the next event occurs simultaneously with
| Card textures for menus
+
that first event, its time is 00.  So, a delta-time is the duration (in clocks) between an event
|-
+
and the preceding event.
| 28
+
 
| 0x11C000
+
<B><FONT COLOR=RED>NOTE:</FONT></B> Since all tracks start with an assumed time of 0, the first
| 0xC800
+
event's delta-time is referenced from 0.
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc08.tim]]
+
 
| Card textures for menus
+
A delta-time is stored as a series of bytes which is called a <B>variable length
|-
+
quantity</B>. Only the first 7 bits of each byte is significant (right-justified; sort of like an
| 29
+
ASCII byte). So, if you have a 32-bit delta-time, you have to unpack it into a series of 7-bit
| 0x128800
+
bytes (ie, as if you were going to transmit it over midi in a SYSEX message). Of course, you
| 0xC800
+
will have a variable number of bytes depending upon your delta-time. To indicate which is the
| [[FF8/Menu_sp2#Content_of_mc00.tex-mc09.tex|mc09.tim]]
+
last byte of the series, you leave bit #7 clear. In all of the preceding bytes, you set bit #7. So,
| Card textures for menus
+
if a delta-time is between 0-127, it can be represented as one byte. The largest delta-time
|-
+
allowed is 0FFFFFFF, which translates to 4 bytes variable length. Here are examples of
| 30
+
delta-times as 32-bit values, and the variable length quantities that they translate to:
| 0x135000
+
 
| 0x11800
+
<pre>
| PSX_Controller00.tim
+
NUMBER        VARIABLE QUANTITY
| Field controls tutorial image
+
00000000              00
|-
+
00000040              40
| 31
+
0000007F              7F
| 0x146800
+
00000080            81 00
| 0x11800
+
00002000            C0 00
| PSX_Controller01.tim
+
00003FFF            FF 7F
| World map controls tutorial image
+
00004000          81 80 00
|-
+
00100000          C0 80 00
| 32
+
001FFFFF          FF FF 7F
| 0x158000
+
00200000          81 80 80 00
| 0x11800
+
08000000          C0 80 80 00
| PSX_Controller02.tim
+
0FFFFFFF          FF FF FF 7F
| Battle controls tutorial image
+
</pre>
|-
+
 
| 33
+
Here are some C routines to read and write variable length quantities such as delta-times. With
| 0x169800
+
<B>WriteVarLen()</B>, you pass a 32-bit value (ie, unsigned long) and it spits out the correct
| 0xC800
+
series of bytes to a file. <B>ReadVarLen()</B> reads a series of bytes from a file until it
| [[ff8/Menu_mag_textures|mag10.tim]]
+
reaches the last byte of a variable length quantity, and returns a 32-bit value.
| Triple Triad tutorial
+
 
|-
+
<pre>
| 34
+
void WriteVarLen(register unsigned long value)
| 0x176000
+
{
| 0xC800
+
  register unsigned long buffer;
| [[ff8/Menu_mag_textures|mag11.tim]]
+
  buffer = value & 0x7F;
| Triple Triad tutorial
+
 
|-
+
  while ( (value >>= 7) )
| 35
+
  {
| 0x182800
+
    buffer <<= 8;
| 0xC800
+
    buffer |= ((value & 0x7F) | 0x80);
| [[ff8/Menu_mag_textures|mag12.tim]]
+
  }
| Triple Triad tutorial
+
 
|-
+
  while (TRUE)
| 36
+
  {
| 0x18F000
+
      putc(buffer,outfile);
| 0xC800
+
      if (buffer & 0x80)
| [[ff8/Menu_mag_textures|mag13.tim]]
+
          buffer >>= 8;
| Battle tutorial
+
      else
|-
+
          break;
| 37
+
  }
| 0x19B800
+
}
| 0xC800
+
 
| [[ff8/Menu_mag_textures|mag14.tim]]
+
unsigned long ReadVarLen()
| Battle tutorial
+
{
|-
+
    register unsigned long value;
| 38
+
    register unsigned char c;
| 0x1A8000
+
 
| 0x3000
+
    if ( (value = getc(infile)) & 0x80 )
| [[FF8/Menu_mngrp_strings_locations|strings_locations00.bin]]
+
    {
| Encoded string archive.
+
      value &= 0x7F;
Has location values before strings<br/>
+
      do
Strings end with '''0x00'''
+
      {
|-
+
        value = (value << 7) + ((c = getc(infile)) & 0x7F);
| 39
+
      } while (c & 0x80);
| 0x1AB000
+
    }
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations01.bin]]
+
    return(value);
| Encoded string archive.
+
}
Has location values before strings<br/>
+
</pre>
Strings end with '''0x00'''
+
 
|-
+
<B><FONT COLOR=RED>NOTE:</FONT></B> The concept of variable length quantities (ie, breaking up a
| 40
+
large value into a series of bytes) is used with other fields in a MIDI file besides delta-times,
| 0x1AB800
+
as you'll see later.
| 0x1000
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations02.bin]]
+
For those not writing in C, you may benefit from a psuedo-code explanation of
| Encoded string archive.
+
the above routines. In pseudo-code, ReadVarLen() is:
Has location values before strings<br/>
+
 
Strings end with '''0x00'''
+
<OL>
|-
+
<LI>Initialize the variable which will hold the value. Set it to 0. We'll
| 41
+
call this variable 'result'.</LI>
| 0x1AC800
+
<LI>Read the next byte of the Variable Length quantity from the MIDI file.</LI>
| 0x1000
+
<LI>Shift all of the bits in 'result' 7 places to the left. (ie, Multiply 'result' by 128).</LI>
| [[FF8/Menu_mngrp_strings_locations|strings_locations03.bin]]
+
<LI>Logically OR 'result' with the byte that was read in, but first mask off bit #7
| Encoded string archive.
+
of the byte. (ie, AND the byte with hexadecimal 7F before you OR with
Has location values before strings<br/>
+
'result'. But make sure you save the original value of the byte for the test
Strings end with '''0x00'''
+
in the next step).</LI>
|-
+
<LI>Test if bit #7 of the byte is set. (ie, Is the byte AND hexadecimal
| 42
+
80 equal to hexadecimal 80)? If so, loop back to step #2. Otherwise,
| 0x1AD800
+
you're done, and 'result' now has the appropriate value.</LI>
| 0x800
+
</OL>
| [[FF8/Menu_mngrp_strings_locations|strings_locations04.bin]]
+
 
| Encoded string archive.
+
In pseudo code, WriteVarLen() could be:
Has location values before strings<br/>
+
 
Strings end with '''0x00'''
+
<OL>
|-
+
<LI>Assume that you have a variable named 'result' which
| 43
+
contains the value to write out as a Variable Length Quantity.</LI>
| 0x1AE000
+
 
| 0x800
+
<LI>Declare an array which can contain 4 numbers. We'll call
| [[FF8/Menu_mngrp_strings_locations|strings_locations05.bin]]
+
this variable 'array'. Initialize a variable named 'count' to 0.</LI>
| Encoded string archive.
+
<LI>Is 'result' less than 128? If so, skip to step #8.</LI>
Has location values before strings<br/>
+
<LI>Take the value 'result' AND with hexadecimal 7F, and OR
Strings end with '''0x00'''
+
with hexadecimal 80, and store it in 'count' element of 'array'.
|-
+
(ie, The first time through  the loop, this gets stored in the first
| 44
+
element of 'array'). NOTE: Don't alter the value of 'result' itself.
| 0x1AE800
+
<LI>Increment 'count' by 1.</LI>
| 0x800
+
<LI>Shift all bits in 'result' 7 places to the right. (This can be done by dividing by 128).</LI>
| [[FF8/Menu_mngrp_strings_locations|strings_locations06.bin]]
+
<LI>Loop back to step #3.</LI>
| Encoded string archive.
+
<LI>Take the value 'result' AND with hexadecimal 7F, and store
Has location values before strings<br/>
+
it in 'count' element of 'array'.</LI>
Strings end with '''0x00'''
+
<LI>Increment 'count' by 1.</LI>
|-
+
<LI>Write out the values stored in 'array'. Start with the last
| 45
+
element stored above, and finish with the first element stored.
| 0x1AF000
+
(ie, Write them out in reverse order so that the first element of
| 0x800
+
'array' gets written to the MIDI file last). NOTE: The variable
| [[FF8/Menu_mngrp_strings_locations|strings_locations07.bin]]
+
'count' tells you how many total bytes to write. It also can be
| Encoded string archive.
+
used as an index into the array (if you subtract one from it, and
Has location values before strings<br/>
+
keep writing out bytes until it is -1).</LI>
Strings end with '''0x00'''
+
</OL>
|-
+
 
| 46
+
==== Events in an MTrk ====
| 0x1AF800
+
 
| 0x800
+
An MTrk can contain MIDI events and non-MIDI events (ie, events that contain data such as
| [[FF8/Menu_mngrp_strings_locations|strings_locations08.bin]]
+
tempo settings, track names, etc).
| Encoded string archive.
+
 
Has location values before strings<br/>
+
The first (1 to 4) byte(s) in an MTrk will be the first event's delta-time as a variable length
Strings end with '''0x00'''
+
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
| 47
+
(or the first midi data byte if running status). For example, if the byte is hex 90, then this
| 0x1B0000
+
event is a <B>Note-On</B> upon midi channel 0. If for example, the byte was hex 23, you'd have to
| 0x800
+
recall the previous event's status (ie, midi running status). Obviously, the first MIDI event in
| [[FF8/Menu_mngrp_strings_locations|strings_locations09.bin]]
+
the MTrk <U>must</U> have a status byte. After a midi status byte comes its 1 or 2 data bytes
| Encoded string archive.
+
(depending upon the status - some MIDI messages only have 1 subsequent data byte). After that
Has location values before strings<br/>
+
you'll find the next event's delta time (as a variable quantity), etc.
Strings end with '''0x00'''
+
 
|-
+
----
| 48
+
 
| 0x1B0800
+
<CENTER><FONT COLOR=RED><B>SYSEX events</B></FONT></CENTER>
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations10.bin]]
+
SYSEX (system exclusive) events (status = F0) are a special case because a SYSEX event can
| Encoded string archive.
+
be any length. After the F0 status (which is always stored -- no running status here), you'll find
Has location values before strings<br/>
+
yet another series of variable length bytes. Combine them with ReadVarLen() and you'll come up
Strings end with '''0x00'''
+
with a 32-bit value that tells you how many more bytes follow which make up this SYSEX event.
|-
+
This length doesn't include the F0 status.
| 49
+
 
| 0x1B1000
+
For example, consider the following SYSEX MIDI message:
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations11.bin]]
+
F0 7F 7F 04 01 7F 7F F7
| Encoded string archive.
+
 
Has location values before strings<br/>
+
This would be stored in a MIDI file as the following series of bytes (minus the delta-time
Strings end with '''0x00'''
+
bytes which would precede it):
|-
+
 
| 50
+
F0 07 7F 7F 04 01 7F 7F F7
| 0x1B1800
+
 
| 0x800
+
The 07 above is the variable length quantity (which happens to fit in just one byte for this
| [[FF8/Menu_mngrp_strings_locations|strings_locations12.bin]]
+
example). It indicates that there are seven, following bytes that comprise this SYSEX message.
| Encoded string archive.
+
 
Has location values before strings<br/>
+
Really oddball midi units send a system exclusive message as a series of small "packets" (with
Strings end with '''0x00'''
+
a time delay inbetween transmission of each packet). The first packet begins with an F0, but it
|-
+
doesn't end with an F7. The subsequent packets don't start with an F0 nor end with F7.  The last
| 51
+
packet doesn't start with an F0, but does end with the F7. So, between the first packet's opening F0 and
| 0x1B2000
+
the last packet's closing F7, there's 1 SYSEX message there. (Note: only extremely poor designs,
| 0x800
+
such as the crap marketed by Casio exhibit such horrid behavior). Of course, since a delay is
| [[FF8/Menu_mngrp_strings_locations|strings_locations13.bin]]
+
needed inbetween each packet, you need to store each packet as a separate event with its own
| Encoded string archive.
+
time in the MTrk. Also, you need some way of knowing which events shouldn't begin with an F0
Has location values before strings<br/>
+
(ie, all of them except the first packet). So, the MIDI file redefines a midi status of F7
Strings end with '''0x00'''
+
(normally used as an end mark for SYSEX packets) as a way to indicate an event that doesn't
|-
+
begin with F0. If such an event follows an F0 event, then it's assumed that the F7 event is the
| 52
+
second "packet" of a series. In this context, it's referred to as a SYSEX CONTINUATION event.
| 0x1B2800
+
Just like the F0 type of event, it has a variable length followed by data bytes. On the other
| 0x800
+
hand, the F7 event could be used to store MIDI REALTIME or MIDI COMMON messages. In this case,
| [[FF8/Menu_mngrp_strings_locations|strings_locations14.bin]]
+
after the variable length bytes, you should expect to find a MIDI Status byte of F1, F2, F3, F6,
| Encoded string archive.
+
F8, FA, FB, FC, or FE. (Note that you wouldn't find any such bytes inside of a SYSEX CONTINUATION
Has location values before strings<br/>
+
event). When used in this manner, the F7 event is referred to as an ESCAPED event.
Strings end with '''0x00'''
+
----
|-
+
<CENTER><FONT COLOR=RED><B>Non-MIDI events</B></FONT></CENTER>
| 53
+
 
| 0x1B3000
+
A status of FF is reserved to indicate a special non-MIDI event. (Note that FF is used in MIDI
| 0x800
+
to mean "reset", so it wouldn't be all that useful to store in a data file. Therefore, the MIDI
| [[FF8/Menu_mngrp_strings_locations|strings_locations15.bin]]
+
file arbitrarily redefines the use of this status). After the FF status byte is another byte that
| Encoded string archive.
+
tells you what <B>Type</B> of non-MIDI event it is. It's sort of like a second status byte. Then
Has location values before strings<br/>
+
after this byte is another byte(s -- a variable length quantity again) that tells how many more
Strings end with '''0x00'''
+
data bytes follow in this event (ie, its Length). This Length doesn't include the FF, Type
|-
+
byte, nor the Length byte. These special, non-MIDI events are called <B>Meta-Events</B>, and
| 54
+
most are optional unless otherwise noted. The section of this online book entitled "Meta-Events"
| 0x1B3800
+
lists the currently defined Meta-Events. Note that unless otherwise mentioned, more than one of
| 0x800
+
these events can be placed in an MTrk (even the same Meta-Event) at any delta-time. (Just like
| [[FF8/Menu_mngrp_strings_locations|strings_locations16.bin]]
+
all midi events, Meta-Events have a delta-time from the previous event regardless of what type
| Encoded string archive.
+
of event that may be. So, you can freely intermix MIDI and Meta events).
Has location values before strings<br/>
+
 
Strings end with '''0x00'''
+
==== Meta-Events in an MTrk ====
|-
+
----
| 55
+
===== Sequence Number =====
| 0x1B4000
+
FF 00 02 <I><FONT COLOR=RED><B>ss ss</B></FONT></I>
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations17.bin]]
+
or...
| Encoded string archive.
+
 
Has location values before strings<br/>
+
FF 00 00
Strings end with '''0x00'''
+
 
|-
+
This optional event must occur at the beginning of a MTrk (ie, before any non-zero
| 56
+
delta-times and before any midi events). It specifies the sequence number. The two data bytes
| 0x1B4800
+
<I><FONT COLOR=RED><B>ss ss</B></FONT></I>, are that number which corresponds to the <B>MIDI
| 0x800
+
Cue</B> message. In a format 2 MIDI file, this number identifies each "pattern" (ie, Mtrk) so
| [[FF8/Menu_mngrp_strings_locations|strings_locations18.bin]]
+
that a "song" sequence can use the MIDI Cue message to refer to patterns.
| Encoded string archive.
+
 
Has location values before strings<br/>
+
If the <I><FONT COLOR=RED><B>ss ss</B></FONT></I> numbers are omitted (ie, the second form
Strings end with '''0x00'''
+
shown above), then the MTrk's location in the file is used. (ie, The first MTrk chunk is
|-
+
sequence number 0. The second MTrk is sequence number 1. Etc).
| 57
+
 
| 0x1B5000
+
In format 0 or 1, which contain only one "pattern" (even though format 1 contains
| 0x800
+
several MTrks), this event is placed in only the first MTrk. So, a group of format 0 or 1 files
| [[FF8/Menu_mngrp_strings_locations|strings_locations19.bin]]
+
with different sequence numbers can comprise a "song collection".
| Encoded string archive.
+
 
Has location values before strings<br/>
+
There can be only one of these events per MTrk chunk in a Format 2. There can be only one
Strings end with '''0x00'''
+
of these events in a Format 0 or 1, and it must be in the first MTrk.
|-
+
----
| 58
+
===== Text =====
| 0x1B5800
+
FF 01 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations20.bin]]
+
Any amount of text (amount of bytes = <I><FONT COLOR=GREEN><B>len</B></FONT></I>) for any
| Encoded string archive.
+
purpose. It's best to put this event at the beginning of an MTrk. Although this text could be
Has location values before strings<br/>
+
used for any purpose, there are other text-based Meta-Events for such things as orchestration,
Strings end with '''0x00'''
+
lyrics, track name, etc. This event is primarily used to add "comments" to a MIDI file which a
|-
+
program would be expected to ignore when loading that file.
| 59
+
 
| 0x1B6000
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
| 0x800
+
is expressed as a variable length quantity.
| [[FF8/Menu_mngrp_strings_locations|strings_locations21.bin]]
+
----
| Encoded string archive.
+
===== Copyright =====
Has location values before strings<br/>
+
FF 02 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
Strings end with '''0x00'''
+
 
|-
+
A copyright message. It's best to put this event at the beginning of an MTrk.
| 60
+
 
| 0x1B6800
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
| 0x800
+
is expressed as a variable length quantity.
| [[FF8/Menu_mngrp_strings_locations|strings_locations22.bin]]
+
----
| Encoded string archive.
+
===== Sequence/Track Name =====
Has location values before strings<br/>
+
FF 03 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
Strings end with '''0x00'''
+
 
|-
+
The name of the sequence or track. It's best to put this event at the beginning of an
| 61
+
MTrk.
| 0x1B7000
+
 
| 0x800
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
| [[FF8/Menu_mngrp_strings_locations|strings_locations23.bin]]
+
is expressed as a variable length quantity.
| Encoded string archive.
+
----
Has location values before strings<br/>
+
===== Instrument =====
Strings end with '''0x00'''
+
FF 04 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
|-
+
 
| 62
+
The name of the instrument (ie, MIDI module) being used to play the track. This may be
| 0x1B7800
+
different than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk)
| 0x800
+
is "Butterfly", but since the track is played upon a Roland S-770, you may also include an
| [[FF8/Menu_mngrp_strings_locations|strings_locations24.bin]]
+
Instrument Name of "Roland S-770".
| Encoded string archive.
+
 
Has location values before strings<br/>
+
It's best to put one (or more) of this event at the beginning of an MTrk to provide the user
Strings end with '''0x00'''
+
with identification of what instrument(s) is playing the track. Usually, the instruments (ie,
|-
+
patches, tones, banks, etc) are setup on the audio devices via <B>MIDI Program Change</B>
| 63
+
and <B>MIDI Bank Select Controller</B> events within the MTrk. So, this event exists merely to
| 0x1B8000
+
provide the user with visual feedback of what instruments are used for a track.
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations25.bin]]
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
| Encoded string archive.
+
is expressed as a variable length quantity.
Has location values before strings<br/>
+
----
Strings end with '''0x00'''
+
===== Lyric =====
|-
+
FF 05 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
| 64
+
 
| 0x1B8800
+
A song lyric which occurs on a given beat. A single Lyric
| 0x800
+
MetaEvent should contain only one syllable.
| [[FF8/Menu_mngrp_strings_locations|strings_locations26.bin]]
+
 
| Encoded string archive.
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
Has location values before strings<br/>
+
is expressed as a variable length quantity.
Strings end with '''0x00'''
+
----
|-
+
===== Marker =====
| 65
+
 
| 0x1B9000
+
FF 06 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations27.bin]]
+
The text for a marker which occurs on a given beat. Marker events might be used to denote a loop start and loop end (ie, where the sequence loops back to a previous event).
| Encoded string archive.
+
 
Has location values before strings<br/>
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
Strings end with '''0x00'''
+
is expressed as a variable length quantity.
|-
+
----
| 66
+
===== Cue Point=====
| 0x1B9800
+
FF 07 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations28.bin]]
+
The text for a cue point which occurs on a given beat. A Cue Point might be used to denote
| Encoded string archive.
+
where a WAVE (ie, sampled sound) file starts playing, for example, where the
Has location values before strings<br/>
+
<I><FONT COLOR=RED><B>text</B></FONT></I> would be the WAVE's filename.
Strings end with '''0x00'''
+
 
|-
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
| 67
+
is expressed as a variable length quantity.
| 0x1BA000
+
----
| 0x800
+
===== Program (Patch) Name =====
| [[FF8/Menu_mngrp_strings_locations|strings_locations29.bin]]
+
FF 08 <I><FONT COLOR=GREEN><B>len</B></FONT></I> <I><FONT COLOR=RED><B>text</B></FONT></I>
| Encoded string archive.
+
 
Has location values before strings<br/>
+
The name of the program (ie, patch) used to play the MTrk. This may be
Strings end with '''0x00'''
+
different than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk)
|-
+
is "Butterfly", but since the track is played upon an electric piano patch, you may also include a
| 68
+
Program Name of "ELECTRIC PIANO".
| 0x1BA800
+
 
| 0x800
+
Usually, the instruments (ie, patches, tones, banks, etc) are setup on the audio devices via
| [[FF8/Menu_mngrp_strings_locations|strings_locations30.bin]]
+
<B>MIDI Program Change</B> and <B>MIDI Bank Select Controller</B> events within the MTrk. So,
| Encoded string archive.
+
this event exists merely to provide the user with visual feedback of what particular patch is
Has location values before strings<br/>
+
used for a track. But it can also give a hint to intelligent software if patch remapping needs
Strings end with '''0x00'''
+
to be done. For example, if the MIDI file was created on a non-General MIDI instrument, then
|-
+
the <B>MIDI Program Change</B> event will likely contain the
| 69
+
wrong value when played on a General MIDI instrument. Intelligent software can use the
| 0x1BB000
+
Program Name event to look up the correct value for the <B>MIDI Program Change</B> event.
| 0x800
+
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations31.bin]]
+
Note that <I><FONT COLOR=GREEN><B>len</B></FONT></I> could be a series of bytes since it
| Encoded string archive.
+
is expressed as a variable length quantity.
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 70
 
| 0x1BB800
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations32.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 71
 
| 0x1BC000
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations33.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 72
 
| 0x1BC800
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations34.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 73
 
| 0x1BD000
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations35.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 74
 
| 0x1BD800
 
| 0x800
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Map.bin]]
 
| Map for Complex Strings 00-05
 
|-
 
| 75
 
| 0x1BE000
 
| 0x4800
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Strings00.bin]]
 
| Encoded string archive.
 
|-
 
| 76
 
| 0x1C2800
 
| 0x4000
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Strings01.bin]]
 
| Encoded string archive.
 
|-
 
| 77
 
| 0x1C6800
 
| 0x4800
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Strings02.bin]]
 
| Encoded string archive.
 
|-
 
| 78
 
| 0x1CB000
 
| 0x4000
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Strings03.bin]]
 
| Encoded string archive.
 
|-
 
| 79
 
| 0x1CF000
 
| 0x2800
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Strings04.bin]]
 
| Encoded string archive.
 
|-
 
| 80
 
| 0x1D1800
 
| 0x4800
 
| [[FF8/Menu_mngrp_complex_strings|Complex_Strings05.bin]]
 
| Encoded string archive.
 
|-
 
| 81
 
| 0x1D6000
 
| 0x1000
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations36.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 82
 
| 0x1D7000
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations37.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 83
 
| 0x1D7800
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations38.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 84
 
| 0x1D8000
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations39.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 85
 
| 0x1D8800
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations40.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 86
 
| 0x1D9000
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations41.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 87
 
| 0x1D9800
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations42.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 88
 
| 0x1DA000
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations43.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 89
 
| 0x1DA800
 
| 0x800
 
|-
 
| 90
 
| 0x1DB000
 
| 0x800
 
|-
 
| 91
 
| 0x1DB800
 
| 0x800
 
|-
 
| 92
 
| 0x1DC000
 
| 0x800
 
|-
 
| 93
 
| 0x1DC800
 
| 0x800
 
|-
 
| 94
 
| 0x1DD000
 
| 0x800
 
|-
 
| 95
 
| 0x1DD800
 
| 0x800
 
|-
 
| 96
 
| 0x1DE000
 
| 0x800
 
|-
 
| 97
 
| 0x1DE800
 
| 0x800
 
|-
 
| 98
 
| 0x1DF000
 
| 0x800
 
|
 
| text with binary data
 
GF names some misspelled/truncated
 
|-
 
| 99
 
| 0x1DF800
 
| 0x800
 
|-
 
| 100
 
| 0x1E0000
 
| 0x800
 
|
 
| text with binary data
 
GF names some misspelled/truncated<BR/>
 
Very similar to 0x1DF000
 
|-
 
| 101
 
| 0x1E0800
 
| 0xC800
 
| [[ff8/Menu_mag_textures|mag15.tim]]
 
| Chocobo world cartoon
 
|-
 
| 102
 
| 0x1ED000
 
| 0xC800
 
| [[ff8/Menu_mag_textures|mag16.tim]]
 
| Tutorial image
 
|-
 
| 103
 
| 0x1F9800
 
| 0xC800
 
| [[ff8/Menu_mag_textures|mag17.tim]]
 
| Tutorial image
 
|-
 
| 104
 
| 0x206000
 
| 0xC800
 
| [[ff8/Menu_mag_textures|mag18.tim]]
 
| Chocobo world sketch cartoon
 
|-
 
| 105
 
| 0x212800
 
| 0xC800
 
| [[ff8/Menu_mag_textures|mag19.tim]]
 
| Chocobo world sketch cartoon<br/>
 
Duplicate of 0x206000
 
|-
 
| 106
 
| 0x21F000
 
| 0x800
 
| [[FF8/Menu_m000_m004|m000.bin]]
 
| Locations for msg file
 
|-
 
| 107
 
| 0x21F800
 
| 0x800
 
| [[FF8/Menu_m000_m004|m001.bin]]
 
| Locations for msg file
 
|-
 
| 108
 
| 0x220000
 
| 0x800
 
| [[FF8/Menu_m000_m004|m002.bin]]
 
| Locations for msg file
 
|-
 
| 109
 
| 0x220800
 
| 0x800
 
| [[FF8/Menu_m000_m004|m003.bin]]
 
| Locations for msg file
 
|-
 
| 110
 
| 0x221000
 
| 0x800
 
| [[FF8/Menu_m000_m004|m004.bin]]
 
| Locations for msg file
 
|-
 
| 111
 
| 0x221800
 
| 0x1800
 
| [[FF8/Menu_m000_m004|m000.msg]]
 
| Strings end with '''0x00'''
 
|-
 
| 112
 
| 0x223000
 
| 0x2000
 
| [[FF8/Menu_m000_m004|m001.msg]]
 
| Strings end with '''0x00'''
 
|-
 
| 113
 
| 0x225000
 
| 0x800
 
| [[FF8/Menu_m000_m004|m002.msg]]
 
| Strings end with '''0x00'''
 
|-
 
| 114
 
| 0x225800
 
| 0x800
 
| [[FF8/Menu_m000_m004|m003.msg]]
 
| Strings end with '''0x00'''
 
|-
 
| 115
 
| 0x226000
 
| 0x1800
 
| [[FF8/Menu_m000_m004|m004.msg]]
 
| Strings end with '''0x00'''
 
|-
 
| 116
 
| 0x227800
 
| 0x800
 
| [[FF8/Menu_mngrp_strings_locations|strings_locations44.bin]]
 
| Encoded string archive.
 
Has location values before strings<br/>
 
Strings end with '''0x00'''
 
|-
 
| 117
 
| 0x228000
 
| 0x800
 
|}
 

Revision as of 17:33, 12 March 2005

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.

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:

struct CHUNK_HEADER
{
   char             ID[4];
   unsigned long    Length; 
};

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).

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:

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;
};

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

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.

MTrk Chunk

After the MThd chunk, you should find an MTrk chunk, as this is the only other currently defined chunk. (If you find some other chunk ID, it must be proprietary to some other program, so skip it by ignoring the following data bytes indicated by the chunk's Length).

An MTrk chunk contains all of the midi data (with timing bytes), plus optional non-midi data for one track. Obviously, you should encounter as many MTrk chunks in the file as the MThd chunk's NumTracks field indicated.

The MTrk header begins with the ID of MTrk, followed by the Length (ie, number of data bytes for this track). The Length will likely be different for each track. (After all, a track containing the violin part for a Bach concerto will likely contain more data than a track containing a simple 2 bar drum beat).

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

struct MTRK_CHUNK
{
   /* Here's the 8 byte header that all chunks must have */
   char           ID[4];   /* This will be 'M','T','r','k' */
   unsigned long  Length;  /* This will be the actual size of Data[] */

   /* Here are the data bytes */
   unsigned char  Data[];  /* Its actual size is Data[Length] */
};


Variable Quantities

Think of a track in the MIDI file in the same way that you normally think of a track in a sequencer. A sequencer track contains a series of events. For example, the first event in the track may be to sound a middle C note. The second event may be to sound the E above middle C. These two events may both happen at the same time. The third event may be to release the middle C note. This event may happen a few musical beats after the first two events (ie, the middle C note is held down for a few musical beats). Each event has a "time" when it must occur, and the events are arranged within a "chunk" of memory in the order that they occur.

In a MIDI file, an event's "time" precedes the data bytes that make up that event itself. In other words, the bytes that make up the event's time-stamp come first. A given event's time-stamp is referenced from the previous event. For example, if the first event occurs 4 clocks after the start of play, then its "delta-time" is 04. If the next event occurs simultaneously with that first event, its time is 00. So, a delta-time is the duration (in clocks) between an event and the preceding event.

NOTE: Since all tracks start with an assumed time of 0, the first event's delta-time is referenced from 0.

A delta-time is stored as a series of bytes which is called a variable length quantity. Only the first 7 bits of each byte is significant (right-justified; sort of like an ASCII byte). So, if you have a 32-bit delta-time, you have to unpack it into a series of 7-bit bytes (ie, as if you were going to transmit it over midi in a SYSEX message). Of course, you will have a variable number of bytes depending upon your delta-time. To indicate which is the last byte of the series, you leave bit #7 clear. In all of the preceding bytes, you set bit #7. So, if a delta-time is between 0-127, it can be represented as one byte. The largest delta-time allowed is 0FFFFFFF, which translates to 4 bytes variable length. Here are examples of delta-times as 32-bit values, and the variable length quantities that they translate to:

 NUMBER        VARIABLE QUANTITY
00000000              00
00000040              40
0000007F              7F
00000080             81 00
00002000             C0 00
00003FFF             FF 7F
00004000           81 80 00
00100000           C0 80 00
001FFFFF           FF FF 7F
00200000          81 80 80 00
08000000          C0 80 80 00
0FFFFFFF          FF FF FF 7F

Here are some C routines to read and write variable length quantities such as delta-times. With WriteVarLen(), you pass a 32-bit value (ie, unsigned long) and it spits out the correct series of bytes to a file. ReadVarLen() reads a series of bytes from a file until it reaches the last byte of a variable length quantity, and returns a 32-bit value.

void WriteVarLen(register unsigned long value)
{
   register unsigned long buffer;
   buffer = value & 0x7F;

   while ( (value >>= 7) )
   {
     buffer <<= 8;
     buffer |= ((value & 0x7F) | 0x80);
   }

   while (TRUE)
   {
      putc(buffer,outfile);
      if (buffer & 0x80)
          buffer >>= 8;
      else
          break;
   }
}

unsigned long ReadVarLen()
{
    register unsigned long value;
    register unsigned char c;

    if ( (value = getc(infile)) & 0x80 )
    {
       value &= 0x7F;
       do
       {
         value = (value << 7) + ((c = getc(infile)) & 0x7F);
       } while (c & 0x80);
    }

    return(value);
}

NOTE: The concept of variable length quantities (ie, breaking up a large value into a series of bytes) is used with other fields in a MIDI file besides delta-times, as you'll see later.

For those not writing in C, you may benefit from a psuedo-code explanation of the above routines. In pseudo-code, ReadVarLen() is:

  1. Initialize the variable which will hold the value. Set it to 0. We'll call this variable 'result'.
  2. Read the next byte of the Variable Length quantity from the MIDI file.
  3. Shift all of the bits in 'result' 7 places to the left. (ie, Multiply 'result' by 128).
  4. Logically OR 'result' with the byte that was read in, but first mask off bit #7 of the byte. (ie, AND the byte with hexadecimal 7F before you OR with 'result'. But make sure you save the original value of the byte for the test in the next step).
  5. Test if bit #7 of the byte is set. (ie, Is the byte AND hexadecimal 80 equal to hexadecimal 80)? If so, loop back to step #2. Otherwise, you're done, and 'result' now has the appropriate value.

In pseudo code, WriteVarLen() could be:

  1. Assume that you have a variable named 'result' which contains the value to write out as a Variable Length Quantity.
  2. Declare an array which can contain 4 numbers. We'll call this variable 'array'. Initialize a variable named 'count' to 0.
  3. Is 'result' less than 128? If so, skip to step #8.
  4. Take the value 'result' AND with hexadecimal 7F, and OR with hexadecimal 80, and store it in 'count' element of 'array'. (ie, The first time through the loop, this gets stored in the first element of 'array'). NOTE: Don't alter the value of 'result' itself.
  5. Increment 'count' by 1.
  6. Shift all bits in 'result' 7 places to the right. (This can be done by dividing by 128).
  7. Loop back to step #3.
  8. Take the value 'result' AND with hexadecimal 7F, and store it in 'count' element of 'array'.
  9. Increment 'count' by 1.
  10. Write out the values stored in 'array'. Start with the last element stored above, and finish with the first element stored. (ie, Write them out in reverse order so that the first element of 'array' gets written to the MIDI file last). NOTE: The variable 'count' tells you how many total bytes to write. It also can be used as an index into the array (if you subtract one from it, and keep writing out bytes until it is -1).

Events in an MTrk

An MTrk can contain 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 Status. For 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 Note-On upon midi channel 0. If for example, the byte was hex 23, you'd have to recall the previous event's status (ie, midi running status). Obviously, the first MIDI event in the MTrk must have a status byte. After a midi status byte comes its 1 or 2 data bytes (depending upon the status - some MIDI messages only have 1 subsequent data byte). After that you'll find the next event's delta time (as a variable quantity), etc.


SYSEX events

SYSEX (system exclusive) events (status = F0) are a special case because a SYSEX event can be any length. After the F0 status (which is always stored -- no running status here), you'll find yet another series of variable length bytes. Combine them with ReadVarLen() and you'll come up with a 32-bit value that tells you how many more bytes follow which make up this SYSEX event. This length doesn't include the F0 status.

For example, consider the following SYSEX MIDI message:

F0 7F 7F 04 01 7F 7F F7

This would be stored in a MIDI file as the following series of bytes (minus the delta-time bytes which would precede it):

F0 07 7F 7F 04 01 7F 7F F7

The 07 above is the variable length quantity (which happens to fit in just one byte for this example). It indicates that there are seven, following bytes that comprise this SYSEX message.

Really oddball midi units send a system exclusive message as a series of small "packets" (with a time delay inbetween transmission of each packet). The first packet begins with an F0, but it doesn't end with an F7. The subsequent packets don't start with an F0 nor end with F7. The last packet doesn't start with an F0, but does end with the F7. So, between the first packet's opening F0 and the last packet's closing F7, there's 1 SYSEX message there. (Note: only extremely poor designs, such as the crap marketed by Casio exhibit such horrid behavior). Of course, since a delay is needed inbetween each packet, you need to store each packet as a separate event with its own time in the MTrk. Also, you need some way of knowing which events shouldn't begin with an F0 (ie, all of them except the first packet). So, the MIDI file redefines a midi status of F7 (normally used as an end mark for SYSEX packets) as a way to indicate an event that doesn't begin with F0. If such an event follows an F0 event, then it's assumed that the F7 event is the second "packet" of a series. In this context, it's referred to as a SYSEX CONTINUATION event. Just like the F0 type of event, it has a variable length followed by data bytes. On the other hand, the F7 event could be used to store MIDI REALTIME or MIDI COMMON messages. In this case, after the variable length bytes, you should expect to find a MIDI Status byte of F1, F2, F3, F6, F8, FA, FB, FC, or FE. (Note that you wouldn't find any such bytes inside of a SYSEX CONTINUATION event). When used in this manner, the F7 event is referred to as an ESCAPED event.


Non-MIDI events

A status of FF is reserved to indicate a special non-MIDI event. (Note that FF is used in MIDI to mean "reset", so it wouldn't be all that useful to store in a data file. Therefore, the MIDI file arbitrarily redefines the use of this status). After the FF status byte is another byte that tells you what Type of non-MIDI event it is. It's sort of like a second status byte. Then after this byte is another byte(s -- a variable length quantity again) that tells how many more data bytes follow in this event (ie, its Length). This Length doesn't include the FF, Type byte, nor the Length byte. These special, non-MIDI events are called Meta-Events, and most are optional unless otherwise noted. The section of this online book entitled "Meta-Events" lists the currently defined Meta-Events. Note that unless otherwise mentioned, more than one of these events can be placed in an MTrk (even the same Meta-Event) at any delta-time. (Just like 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


Sequence Number

FF 00 02 ss ss

or...

FF 00 00

This optional event must occur at the beginning of a MTrk (ie, before any non-zero delta-times and before any midi events). It specifies the sequence number. The two data bytes ss ss, are that number which corresponds to the MIDI Cue message. In a format 2 MIDI file, this number identifies each "pattern" (ie, Mtrk) so that a "song" sequence can use the MIDI Cue message to refer to patterns.

If the ss ss numbers are omitted (ie, the second form shown above), then the MTrk's location in the file is used. (ie, The first MTrk chunk is sequence number 0. The second MTrk is sequence number 1. Etc).

In format 0 or 1, which contain only one "pattern" (even though format 1 contains several MTrks), this event is placed in only the first MTrk. So, a group of format 0 or 1 files with different sequence numbers can comprise a "song collection".

There can be only one of these events per MTrk chunk in a Format 2. There can be only one of these events in a Format 0 or 1, and it must be in the first MTrk.


Text

FF 01 len text

Any amount of text (amount of bytes = len) for any purpose. It's best to put this event at the beginning of an MTrk. Although this text could be used for any purpose, there are other text-based Meta-Events for such things as orchestration, lyrics, track name, etc. This event is primarily used to add "comments" to a MIDI file which a program would be expected to ignore when loading that file.

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Copyright

FF 02 len text

A copyright message. It's best to put this event at the beginning of an MTrk.

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Sequence/Track Name

FF 03 len text

The name of the sequence or track. It's best to put this event at the beginning of an MTrk.

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Instrument

FF 04 len text

The name of the instrument (ie, MIDI module) being used to play the track. This may be different than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk) is "Butterfly", but since the track is played upon a Roland S-770, you may also include an Instrument Name of "Roland S-770".

It's best to put one (or more) of this event at the beginning of an MTrk to provide the user with identification of what instrument(s) is playing the track. Usually, the instruments (ie, patches, tones, banks, etc) are setup on the audio devices via MIDI Program Change and MIDI Bank Select Controller events within the MTrk. So, this event exists merely to provide the user with visual feedback of what instruments are used for a track.

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Lyric

FF 05 len text

A song lyric which occurs on a given beat. A single Lyric MetaEvent should contain only one syllable.

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Marker

FF 06 len text

The text for a marker which occurs on a given beat. Marker events might be used to denote a loop start and loop end (ie, where the sequence loops back to a previous event).

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Cue Point

FF 07 len text

The text for a cue point which occurs on a given beat. A Cue Point might be used to denote where a WAVE (ie, sampled sound) file starts playing, for example, where the text would be the WAVE's filename.

Note that len could be a series of bytes since it is expressed as a variable length quantity.


Program (Patch) Name

FF 08 len text

The name of the program (ie, patch) used to play the MTrk. This may be different than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk) is "Butterfly", but since the track is played upon an electric piano patch, you may also include a Program Name of "ELECTRIC PIANO".

Usually, the instruments (ie, patches, tones, banks, etc) are setup on the audio devices via MIDI Program Change and MIDI Bank Select Controller events within the MTrk. So, this event exists merely to provide the user with visual feedback of what particular patch is used for a track. But it can also give a hint to intelligent software if patch remapping needs to be done. For example, if the MIDI file was created on a non-General MIDI instrument, then the MIDI Program Change event will likely contain the 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 MIDI Program Change event.

Note that len could be a series of bytes since it is expressed as a variable length quantity.