MIDI timecode
MIDI timecode (MTC) is a sub-protocol of the Musical Instrument Digital Interface (MIDI) standard that embeds SMPTE timecode data within a series of compact quarter-frame messages to synchronize the timing of audio, video, and MIDI-enabled devices in multimedia environments.[1] Unlike MIDI clock, which relies on relative pulse counts tied to musical tempo, MTC provides absolute time references in hours, minutes, seconds, and frames, allowing for frame-accurate coordination across disparate systems such as sequencers, video decks, and lighting controllers.[2] Developed as an extension to the core MIDI 1.0 specification, MTC was formally adopted by the MIDI Manufacturers Association (MMA) in February 1987, adapting the established SMPTE timecode framework for efficient transmission over MIDI's serial interface.[3] At its core, MTC operates by dividing each SMPTE frame into four quarter-frame messages, each consisting of a status byte (0xF1) followed by a data byte that encodes portions of the timecode, requiring eight such messages to convey a complete time value (hours, minutes, seconds, and frames).[4] These messages are transmitted continuously at rates matching the selected frame rate—supporting 24, 25, 30 non-drop, or 30 drop-frame per second (fps)—with updates occurring every two frames to minimize bandwidth usage while maintaining synchronization.[5] Complementary full-frame messages, formatted as universal system exclusive (SysEx) packets (beginning with 0xF0 7F and ending with 0xF7), allow devices to jump to specific time points during cueing operations like fast-forward or rewind, after which quarter-frame messages resume for ongoing alignment.[1] Additional MTC features enhance its utility in professional settings, including user bits for transmitting up to 32 custom data bits per frame and setup messages that trigger predefined events at designated times via SysEx.[5] Notation information messages further integrate musical elements, such as time signatures and bar markers, to bridge time-based synchronization with score-based performance.[4] Widely implemented since the late 1980s, MTC remains a cornerstone for studio and live production workflows, ensuring reliable interoperability despite the evolution of digital audio and MIDI 2.0 protocols.[3]Overview
Definition and Purpose
MIDI timecode (MTC) is a protocol developed within the MIDI standard that embeds SMPTE-style timing information into MIDI messages, primarily quarter-frame messages, with full time addresses using system exclusive messages, enabling absolute time synchronization among MIDI-enabled devices.[6] This approach translates the linear, frame-accurate timing of SMPTE timecode—originally designed for video and film—into a format compatible with MIDI's data stream, allowing seamless integration without additional hardware interfaces.[7] The primary purpose of MTC is to facilitate precise alignment between MIDI sequencers, synthesizers, and digital audio workstations (DAWs) and time-based media such as video, film, or audio recordings that follow a fixed timeline.[7] By providing location information at specific intervals, MTC ensures that musical events trigger exactly at designated points in the media, which is crucial for post-production, live performances with visuals, and collaborative workflows involving multiple synchronized systems.[4] This contrasts with relative timing methods like MIDI Clock, which rely on pulse counts tied to musical tempo and can drift if speeds vary. At its core, MTC employs absolute time referencing in the hours:minutes:seconds:frames format, offering independence from musical structure or playback speed changes.[4] This absolute positioning allows devices to "locate" to any point in a sequence reliably, supporting professional audio/video production where timing must match external references like film reels or broadcast standards. MTC transmits this information primarily through quarter-frame messages, sent four times per video frame to maintain continuous updates.[7] MTC accommodates key frame rates used in media production, including 24 frames per second (fps) for film, 25 fps for PAL video, 29.97 fps (both non-drop and drop-frame variants) for NTSC video, and 30 fps for non-drop applications.[4] The time values are encoded using: frames (5 bits), seconds and minutes (6 bits each), hours (5 bits), with 2 bits for frame rate designation in the hours encoding, totaling 24 bits transmitted across eight 4-bit nibbles in the quarter-frame messages.[4]Historical Development
The Musical Instrument Digital Interface (MIDI) standard, first published in August 1983 by the MIDI Manufacturers Association (MMA), primarily facilitated the transmission of musical performance data such as note on/off events and controller values between synthesizers and sequencers, but it initially lacked mechanisms for precise synchronization with linear media like film or video.[8] This limitation became evident in the mid-1980s as musicians and audio engineers sought to integrate MIDI-based sequencing with time-based production workflows, such as scoring for motion pictures or synchronizing multitrack audio.[3] In 1986, Evan Brooks of Digidesign and Chris Meyer of Sequential Circuits proposed adapting the Society of Motion Picture and Television Engineers (SMPTE) timecode—a longstanding analog standard for frame-accurate timing in film and video—into a MIDI-compatible format to address these synchronization needs.[3] Their collaboration resulted in MIDI Time Code (MTC), initially referred to as "MSMPTE," which encoded SMPTE-like timing information using MIDI messages. The proposal gained traction through discussions within the MMA, leading to its formal adoption as a supplement to the MIDI 1.0 specification.[9] The official MTC specification, titled "MIDI Time Code and Cueing Detailed Specification," was approved by the MMA on February 12, 1987, marking its standardization as an extension to MIDI 1.0.[9] Early hardware implementations emerged shortly thereafter, with the first MTC-compatible products, including sequencers and SMPTE-to-MTC converters, demonstrated at the summer 1987 NAMM show.[3] These devices enabled reliable locking of MIDI sequences to tape machines and video equipment, significantly streamlining workflows in film scoring and post-production by allowing MIDI systems to chase external timecode without dedicated analog cabling.[10] By the early 1990s, MTC had become integral to the rise of digital audio workstations (DAWs), with software like Pro Tools—released in 1991—incorporating MTC support for hybrid analog-digital productions.[11] While subsequent MIDI updates, such as minor enhancements for additional frame rates in the late 1980s, refined compatibility, MTC underwent no major revisions after its 1987 debut and remains a legacy component of the protocol.[9] The advent of MIDI 2.0 in January 2020 introduced improved timing resolution and bidirectional communication for synchronization, yet MTC persists as the standard for legacy MIDI 1.0 systems in timecode applications.[12]Format and Messages
Full Time Address Messages
Full Time Address Messages in MIDI Time Code provide a complete timestamp in a single packet, enabling absolute positioning without relying on incremental updates. These messages are transmitted as universal real-time System Exclusive (SysEx) packets, allowing devices to synchronize to a specific point in time efficiently. The format supports all standard SMPTE frame rates—24, 25, 30 drop-frame, and 30 non-drop-frame—making it versatile for professional audio and video applications. Unlike ongoing synchronization, full time address messages are designed for discrete events, conserving MIDI bandwidth which is limited to approximately 31.25 kbps.[13] The message structure is fixed at 10 bytes, beginning with the SysEx start byte (F0) and ending with the end byte (F7). It follows the format: F0 7F [device ID] 01 01 [hh] [mm] [ss] [ff] F7, where 7F identifies it as a universal real-time message, the two 01 bytes specify MIDI Time Code and the full frame subtype, respectively, and the device ID (typically 7F for broadcast to all devices) targets the recipient. Each time component—hours (hh: 0-23), minutes (mm: 0-59), seconds (ss: 0-59), and frames (ff: 0-29, varying by frame rate)—is encoded in a 7-bit byte using binary-coded decimal (BCD) format, with the high bit always set to zero and 8 unused bits across the message also zeroed. The frame rate is embedded in the hours byte: bits 7-6 are 00 for 24 fps, 01 for 25 fps, 10 for 30 drop-frame, and 11 for 30 non-drop-frame; bits 5-4 hold the hours tens digit (0-2), and bits 3-0 the units digit (0-9). The remaining bytes use bits 7-4 for the tens digit (0-5 for mm/ss, 0-2 for ff) and bits 3-0 for the units digit (0-9). This BCD encoding mirrors the SMPTE standard while fitting MIDI's 7-bit constraint, ensuring compatibility. No standard checksum or error detection is included in MTC full time address messages, leaving validation to receiver implementations that may check byte ranges or sequence integrity.[13][9]| Byte | Value | Description |
|---|---|---|
| 1 | F0 | SysEx start |
| 2 | 7F | Universal real-time ID |
| 3 | [device ID] (e.g., 7F) | Target device (7F for all) |
| 4 | 01 | MTC ID |
| 5 | 01 | Full time address subtype |
| 6 | [hh] | Hours BCD + frame rate bits |
| 7 | [mm] | Minutes BCD |
| 8 | [ss] | Seconds BCD |
| 9 | [ff] | Frames BCD |
| 10 | F7 | SysEx end |
Quarter-Frame Messages
Quarter-frame messages in MIDI timecode provide an incremental method for transmitting time information, allowing continuous synchronization between devices by sending small portions of the timecode at regular intervals. Each message consists of a status byte of 0xF1 followed by a single 7-bit data byte, which encodes both the message type and a 4-bit nibble of the time value.[15][16] The data byte is structured with the high nibble (bits 7-4) indicating the message type (0 to 7) and the low nibble (bits 3-0) carrying the time data, enabling the reconstruction of a complete timecode value—hours, minutes, seconds, and frames—from eight sequential messages.[4][9] The eight message types correspond to specific parts of the timecode, transmitted in sequence starting from type 0 (frames low nibble) to type 7 (hours high nibble with frame rate). Odd-numbered messages (types 1, 3, 5, 7) convey the high nibble of their respective time component, while even-numbered ones (types 0, 2, 4, 6) convey the low nibble; for type 7, the low nibble additionally encodes the frame rate using two bits (00 for 24 fps, 01 for 25 fps, 10 for 29.97 drop-frame fps, 11 for 30 non-drop fps), with the hours' most significant bit (bit 4) in bit 3 and bit 0 set to 0.[16][4] The following table summarizes the message types and their contents:| Type (High Nibble) | Data Byte Format | Time Component Encoded |
|---|---|---|
| 0 (0x0X) | 0x00 | X | Frames low nibble (units BCD, bits 0-3) |
| 1 (0x1X) | 0x10 | X | Frames tens BCD (0-2) |
| 2 (0x2X) | 0x20 | X | Seconds low nibble (units BCD, bits 0-3) |
| 3 (0x3X) | 0x30 | X | Seconds tens BCD (0-5) |
| 4 (0x4X) | 0x40 | X | Minutes low nibble (units BCD, bits 0-3) |
| 5 (0x5X) | 0x50 | X | Minutes tens BCD (0-5) |
| 6 (0x6X) | 0x60 | X | Hours low nibble (units BCD, bits 0-3) |
| 7 (0x7X) | 0x70 | X | Hours high 4 bits (bits 7-4 of hours byte: rate in 7-6, tens BCD in 5-4) |