0.1 Standard midi files  (Page 3/3)

For example, consider the unsigned integer 0x42 = 0b0100_0010 (66 decimal), which can fit within seven bits. Since the MSB is clear (is zero), the parser will not seek any further bytes, and will conclude that the numerical value is 0x42.

Now consider the slightly larger value 0x80 = 0b1000_0000 (128 in decimal), which requires all eight bits of the byte. Since a VLF byte only has seven usable bits, this value must be encoded in two bytes, like this: 0x81 0x00. Why? If we group the original value into two 7-bit groups, we have the two binary values 0b000_0001 and 0b000_0000. The MSB of the first group must be set to 1 to indicate that more bytes follow, so it becomes 0b1000_0001 = 0x81. The MSB of the second group must be set to 0 to indicate that no bytes follow, so it becomes 0b0000_0000 = 0x00.

Running status

Running status is another technique developed to minimize the size of a standard MIDI file. Consider a long sequence of Note-On and Note-Off messages (“long”meaning perhaps thousands of events). Eventually you would notice that storing the status byte for each and every note message would seem redundant and wasteful. Instead, it would be more economical to store one complete Note-On message (a status byte followed by the note number byte and the velocity byte), and then from that point onwards store only the note number byte and velocity byte.

Clearly this is a simple solution for the application that creates the MIDI file, but what about the application that must read and parse the file? How can the parser know whether or not the status byte has been omitted from a message? Fortunately, the status byte can easily be distinguished from the data bytes by examination of the MSB (most-significant bit). When the parser expects a new message to start and finds that the byte has its MSB cleared (set to zero), the parser recovers the status information by using the information from the most-recent complete message. That is, the status continues to be the same as whatever was indicated by the most recent status byte received. In this way, a series of Note On messages can be conveyed by only two bytes per message instead of three.

But how do notes get turned off without storing a Note-Off message? Fortunately a Note-On message with zero velocity is equivalent to a Note-Off event! Thus, once the running status is established as“note on,”it is possible to turn notes on and off for as long as you like, with each event requiring only two bytes.

Any time another message type needs to be inserted (such as a Program Change), the running status changes to match the new type of message. Alternatively, when a different channel is required for a note message, a fresh Note-On status byte must be sent. For these reasons, most standard MIDI files are organized as Type 1 (multi-track, vertically synchronous), where each track corresponds to a different voice on its own channel. The Program Change message occur at the beginning of the track to select the desired voice, a complete Note-On message is sent, and running status is used for the duration of the track to send Note-On and Note-Off messages as two-byte values.

Meta-events

Meta-events provide a mechanism for file-related information to be represented, such as track name, tempo, copyright notice, lyric text, and so on. A meta-event begins with an 8-bit unsigned integer of value 0xFF. Note that the MSB (most-significant bit) is set, so a meta-event begins in the same way as a MIDI message status byte, whose MSB is also set. Next, the meta-event type is indicated by an 8-bit unsigned integer. After this, the number of bytes remaining in the meta-event is indicated by a numerical value in variable-length format (VLF); see an earlier section for full details). Lastly, the remainder of the meta-event information follows.

Some common meta-event types include 0x01 (text event ), 0x02 ( copyright notice ), 0x03 (track name ), 0x04 ( instrument name ), 0x05 ( lyric text ), and 0x7F ( sequencer-specific ). All of these meta-events can have an arbitrary length. Sequencer-specific is analogous to the System-Exclusive MIDI message, in that the data contained in the meta-event is arbitrary, and can normally be interpreted only by the sequencer application that created the standard MIDI file.

Tracks normally conclude with the end-of-track meta-event, whose type is 0x2F and whose length is zero. The end-of-track meta-event appears as the byte sequence 0xFF 0x2F 0x00 (meta-event, end-of-track type, zero length, with no data following).

The set-tempo meta-event (type 0x51) provides the value microseconds per quarter note , a 24-bit (3-byte) unsigned integer. This value in conjunction with the division value in the header chunk (division = ticks per quarter note) determines how to translate a delta time in ticks to a time in seconds. If the set-tempo meta-event is not included in the standard MIDI file, the value defaults to 500,000 microseconds per quarter note (or 0.5 seconds per quarter note).

Exercise: Given T (the value of a set-tempo meta-event) and D (the division value in the header chunk), determine an equation that can convert a delta time in ticks to a delta time in seconds.

For further study

• Description of MIDI Standard File Format
• Standard MIDI Files 1.0
• The USENET MIDI Primer by Bob McQueer
• Outline of the Standard MIDI File Structure
• Textbook: Francis Rumsey, MIDI Systems and Control, 2nd ed., Focal Press, 1994. See Table 5.2 (A selection of common meta-event type identifiers)