showstack

GitHub
Free forever·no account, no tracking, no third-party requests ·open data, free API
showstack / compare / ltc-vs-mtc

LTC vs MIDI Timecode

Which timecode should I send to lighting and video? Below is every field we hold on both, side by side. Each one is sourced on the individual entry, and anything nobody could source is left blank rather than guessed.

Side by side

LTCMIDI Timecode
Categorytimecode-synctimecode-sync
FlowClock and sync — tiny, ruthlessly regularClock and sync — tiny, ruthlessly regular
Transportothermidi-din, usb
Multicastnono
Spec availabilityopen-publishedopen-published
StewardSMPTE (Society of Motion Picture and Television Engineers)The MIDI Association (MIDI Manufacturers Association)
Statuscurrentcurrent
Our confidenceverifiedreported

Both are clock and sync flows. Jitter, an unaware switch delaying the timestamps it was meant to correct, and two devices both convinced they are the master. That applies equally to either, so it is not a discriminator here.

Speaks both (20)

These are the safe choices if you have not committed to either, or need to bridge the two.

LTC only (40)

MIDI Timecode only (8)

What goes wrong with LTC

The 80-bit word carries no frame-rate field. The reader infers the rate from the incoming bit rate, so a 25 fps generator into a 30 fps reader produces numbers that look plausible and quietly drift.
Drop-frame at 29.97 skips frame numbers, not time. Cue sheets written non-drop against a drop-frame master run out by roughly 3.6 seconds an hour, and the error is invisible in the first five minutes of a tech.
ST 12-1 asks for 1 to 2 V peak-to-peak with 40 microsecond rise and fall times. Route LTC through a compressor, a de-esser, a lossy codec or a consumer wireless link and the edges round off until the reader loses lock.
LTC is unreadable at very low transport speeds because there are no transitions to clock from. A paused master stops sending position entirely, so downstream devices either freewheel or drop out.
It is an audio signal, so it bleeds. Keep it off adjacent channels, out of foldback and out of anything that goes to a speaker; a burst of LTC in the PA during a quiet scene is a career moment.
The eight four-bit user groups are free-form and every manufacturer fills them differently. Do not assume date or reel data survives a round trip through a converter or a distribution amp.

What goes wrong with MIDI Timecode

Quarter-frame messages carry one nibble at a time, four per frame, so a complete timecode value takes two frames to arrive. Every MTC reader is inherently one to two frames behind. Compensate in the receiver, do not nudge the master.
The frame rate lives in bits 5-6 of the hours byte and encodes only 24, 25, 30 drop-frame and 30. There is no 23.976, 48, 50 or 60 value, so a 23.98 project has to travel as 24 and be reconciled at the far end.
The full-frame sysex F0 7F cc 01 01 hr mn sc fr F7 only locates the receiver. Nothing actually runs until quarter-frames start arriving, which is why a device can display the correct time and still not be chasing.
A receiver that ignores the frame-rate bits will run 25 fps code as 30 and drift by a fifth. The numbers look sane the whole time, which is what makes it expensive to spot.
Quarter-frames are continuous traffic on a 31.25 kbit/s DIN line. Share that cable with MSC and your cue messages queue behind the clock.
Only the low nibble of each user-bit data byte is used in the user-bits sysex. Converters that repack user bits between LTC and MTC routinely lose or reorder them.

Sources

Disagree with any of this?

Every claim above comes from one of the two entries and carries a source. If one is wrong, correcting it is a single file and it fixes this page automatically. Edit LTC or edit MIDI Timecode.