Continuous MIDI Time Code Bandwidth Overhead

Continuous MIDI Time Code (MTC) transmission requires a predictable slice of serial throughput that directly impacts the available data capacity of a traditional MIDI connection. When transmitted over a standard 5-pin DIN MIDI link operating at 31,250 baud, continuous MTC consumes between 6.14% and 7.68% of the total bandwidth, depending on the SMPTE frame rate. This article breaks down the physical serial constraints of MIDI 1.0, calculates the exact byte and bit rate of MTC quarter-frame messages, and explains the real-world performance implications of sharing this bandwidth with musical performance data.

The MIDI 1.0 Physical Layer

To calculate bandwidth overhead, start with the standard MIDI 1.0 transmission specifications:

• Baud Rate: 31,250 bits per second (bps).
• Byte Encoding: Asynchronous serial transmission with 1 start bit, 8 data bits, and 1 stop bit, totaling 10 bits per transmitted byte.
• Maximum Theoretical Throughput: 31,250 bits/sec ÷ 10 bits/byte = 3,125 bytes per second.

MTC Quarter-Frame Structure

During continuous playback, MTC does not send full timecode addresses continuously. Instead, it breaks timecode into Quarter-Frame messages:

• Message Size: 2 bytes (one Status byte 0xF1, followed by one Data byte containing a nibble of timecode data and a 3-bit message identifier).
• Transmission Frequency: Exactly 4 quarter-frame messages per SMPTE frame. A full timecode address requires 8 individual quarter-frame messages, meaning a complete address update resolves every 2 SMPTE frames.

Bandwidth Consumption by Frame Rate

The continuous transmission overhead scales with the frame rate of the project:

• 24 fps (Film):

  • 24 frames/sec × 4 messages = 96 messages/second
  • 96 messages × 2 bytes = 192 bytes/second
  • 192 bytes/sec × 10 bits/byte = 1,920 bps
  • Overhead: 1,920 ÷ 31,250 = 6.14%

• 25 fps (PAL):

  • 25 frames/sec × 4 messages = 100 messages/second
  • 100 messages × 2 bytes = 200 bytes/second
  • 200 bytes/sec × 10 bits/byte = 2,000 bps
  • Overhead: 2,000 ÷ 31,250 = 6.40%

• 30 fps / 29.97 fps (NTSC / Standard):

  • 30 frames/sec × 4 messages = 120 messages/second
  • 120 messages × 2 bytes = 240 bytes/second
  • 240 bytes/sec × 10 bits/byte = 2,400 bps
  • Overhead: 2,400 ÷ 31,250 = 7.68%

Implications on a Shared Cable

While a constant 7.7% overhead leaves roughly 92% of the cable's theoretical bandwidth available, the operational impact on a single shared 5-pin DIN connection is often greater than the percentage suggests:

1. Jitter and Timing Latency: MIDI 1.0 uses serial FIFO queues without packet prioritization. An MTC message takes approximately 0.64 milliseconds to transmit. If notes, control change messages, or pitch bends arrive while an MTC byte is being transmitted, musical events are delayed, causing audible timing jitter.
2. Disruption of Running Status: Standard performance data often relies on MIDI Running Status to save bandwidth by omitting redundant status bytes. While MTC Quarter-Frame messages (0xF1) are System Common messages and technically do not clear Running Status under the MIDI 1.0 specification, some legacy receivers incorrectly reset their Running Status buffers upon receiving them, forcing controllers to resend full 3-byte messages and exacerbating bandwidth congestion.
3. High-Density Controller Choking: Dense continuous controller (CC) sweeps, polyphonic aftertouch, or pitch bend manipulation can easily saturate a 31,250 bps connection. Reserving 240 bytes every second for continuous MTC on the same wire significantly reduces the buffer ceiling, leading to dropped messages or audible delays during peak data bursts.

For reliable operation in complex setups, continuous MTC should be routed through a dedicated physical MIDI DIN port or transferred over modern multi-port USB-MIDI or network interfaces (RTP-MIDI), where bandwidth limitations are effectively eliminated.