What is LTC timecode? How audio timecode works — and how to read it

LTC in one paragraph

LTC stands for linear timecode (historically “longitudinal timecode”), defined in the SMPTE 12M family of standards. It encodes a running clock — hours, minutes, seconds, frames — as an audio-frequency signal. Because it is just audio, it can be recorded on any spare audio track, passed through any audio cable, and survive being copied between systems that know nothing about video. When a camera has no timecode input, feeding LTC into one of its audio channels is the classic workaround: the picture file then carries its own clock, hidden in a spare channel.

The number you see — 14:32:07:18 — is a time-of-day or arbitrary counter stamped once per frame. Every device sharing the same clock stamps the same numbers at the same instant, which is what makes automatic sync possible later: match the numbers, and picture and sound line up.

How the signal works: biphase mark, in human language

LTC uses biphase mark encoding (also called differential Manchester — the same idea AES3 audio uses):

• Time is divided into equal slots, one per bit. Eighty bits make up one frame’s worth of timecode.
• The signal is a square wave that always flips polarity at the start of every bit slot. That constant flipping is the metronome — it is why a decoder never needs a separate clock line.
• A zero is a slot with no extra flip in the middle. A one is a slot with one additional flip halfway through.

This gives LTC three properties that made it indestructible in practice: it is self-clocking (the transitions themselves tell the decoder how fast the signal runs), polarity-insensitive (a miswired balanced cable does not corrupt it), and readable forwards and backwards — the sync word, below, reveals the direction.

At 25 fps, 80 bits per frame works out to a bit rate of 2,000 bits per second — the fundamental tones of the signal sit roughly between 1 and 2.4 kHz depending on frame rate and bit pattern. That is squarely inside the range every microphone preamp, audio codec and cable on Earth handles comfortably, which is exactly the point.

What lives inside the 80 bits

Each frame of LTC carries one 80-bit word:

• 26 bits of time — frames, seconds, minutes and hours, encoded as binary-coded decimal (each decimal digit gets its own group of bits).
• 32 bits of user data (“user bits”) — eight free hex digits. Productions use them for the shoot date, reel or camera ID, or leave them at zero. Nothing in the standard enforces a meaning, so treat user bits as a convention agreed per production, not as data you can rely on blindly.
• Flag bits — including the drop-frame flag (is this 29.97 fps drop-frame counting?) and the colour framing flag, plus polarity-correction and binary-group flags most workflows ignore.
• A 16-bit sync word — the fixed pattern 0011 1111 1111 1101. Its long run of ones cannot occur anywhere else in a valid word, so the decoder uses it to find where each 80-bit word starts and whether the signal is running forwards or backwards.

Frame rates and the drop-frame wrinkle

LTC counts frames, so it must agree with the picture’s frame rate: 23.976, 24, 25, 29.97 or 30 fps. Two details bite people regularly:

• Drop-frame vs non-drop-frame only exists at 29.97 fps. Drop-frame skips frame numbers (never actual frames) so the displayed time tracks wall-clock time. Mixing DF and NDF devices on one shoot produces offsets that grow over the day — about 3.6 seconds per hour — and it looks exactly like mysterious drift until someone checks the flag. Written notation gives it away: 01:00:00;02 (semicolon) is drop-frame, 01:00:00:02 is not.
• 23.976 fps has no LTC of its own. There is no fractional-frame LTC standard below 29.97; a 23.976 production typically runs 24-frame counting pulled down, or 29.97/30-frame code that gets converted. When sync is off by a consistent tiny ratio (about 0.1%), a 24/23.976 mismatch is the first suspect — our guide to 23.976 vs 25 fps sync problems covers how to diagnose and repair it.

How LTC gets onto a shoot

Three common patterns, from most to least equipment:

• Dedicated sync boxes on every camera and recorder, jammed from one master; each device stamps timecode into its own file metadata, and LTC is the jamming signal between boxes.
• LTC into a camera’s audio channel. Cameras without TC inputs — most mirrorless bodies, many drones and action cameras — record the tone on channel 1 or 2. The file’s metadata timecode stays meaningless, but the audio channel carries the real clock, waiting to be decoded in post.
• Recorder as master. The sound recorder generates timecode; anything that can listen gets fed the signal.

Why LTC breaks: the five usual suspects

A decoder needs to see clean transitions at predictable times. Everything that goes wrong with LTC in the wild is some way of smearing, clipping or warping those transitions.

1. Level too low

Recorded at -50 dBFS under camera preamp noise, the square wave drowns and the decoder finds transitions late or not at all. Aim for a healthy nominal level — around -20 to -12 dBFS — and disable any automatic gain control, which will otherwise “ride” the constant tone downward.

2. Level too hot, or auto-gain artifacts

Clipping rounds the wave into something with ringing and DC offsets; AGC pumping modulates its amplitude. Both push individual transitions off their expected positions. Occasional errors are recoverable (a good decoder interpolates across bad words), but sustained distortion is not.

3. Lossy compression

AAC and MP3 encoders are built to preserve what humans hear, and a biphase square wave is precisely the kind of signal they mangle: pre-echo smears the edges and the phase relationships the decoder relies on are not protected. LTC recorded into an AAC camera track (common on consumer cameras and screen recorders) often survives — but marginally, and re-encoding it a second time frequently kills it. Keep LTC in PCM (WAV) whenever you control the format.

4. Resampling and speed changes

Sample-rate conversion done well is harmless. Done badly — or combined with a hidden speed change, such as 48 kHz audio played at 48.048 or a variframe recording — the bit clock no longer matches any standard rate. The decoder can often still lock (self-clocking helps), but the decoded times will crawl relative to the picture, which shows up as one device “drifting” even though the original stamps were fine.

5. Crosstalk and bleed

LTC is loud, constant and midrange, so it bleeds: into the adjacent channel, into a scratch mic on the same camera, occasionally into production sound. Bleed rarely stops decoding, but the reverse problem is real — a channel of dialogue with faint LTC underneath may decode intermittently and produce false locks. Decoders should be told which channel is the TC channel, not left guessing from whichever locks first.

Jam-sync and drift: why “jammed at call” is not enough

Jam-syncing means setting a device’s internal timecode clock from an external source, then disconnecting. From that moment the device free-runs on its own crystal oscillator — and no two crystals run at exactly the same speed.

Crystals are specified in parts per million. A camera at ±5 ppm gains or loses about 0.4 frames per hour at 25 fps; cheaper hardware is several times worse, and temperature swings (a camera in the sun, a recorder in a bag) push oscillators further. Dedicated sync boxes use temperature-compensated oscillators well under 1 ppm — which is why they hold a frame for days while a jammed camera may not hold it through the afternoon. For the full numbers — ppm ratings in frames per hour, temperature effects, and the head/tail measurement that separates drift from a rate mismatch — see the dedicated guide on timecode drift: causes and fixes.

The practical rules that follow:

• Re-jam every 4–6 hours, and always after lunch (power cycles reset some cameras’ TC clocks).
• Timecode gets you frame accuracy, not sample accuracy. Even a perfect TC match only aligns to the nearest frame boundary — up to half a frame (20 ms at 25 fps) of residual offset is normal; tighter alignment has to come from the audio waveforms themselves.
• Log which device was master. When numbers disagree in post, you need to know which clock to believe.

How to actually read LTC in post

You can recognise LTC by ear — solo the channel and you will hear the unmistakable harsh digital buzz. Confirming and using it takes a decoder. What the decoding process needs:

1. The right channel. On a stereo camera file the tone is usually one side, with a scratch mic on the other.
2. A lock on the bit clock. The decoder measures transition spacing and derives the bit rate, hence the frame rate family. Damaged signals fail here first.
3. Sync-word alignment. Finding 0011 1111 1111 1101 frames the 80-bit words and reveals play direction.
4. Continuity checking. Good decoders read the whole file, verify successive words count up by exactly one frame, and flag jumps — a mid-file jump usually means a re-jam while rolling, or a dropout.
5. Anchoring. The decoded time at a known sample position becomes the file’s effective start timecode, replacing whatever the camera metadata claimed.

Once every file — camera originals with LTC in an audio channel, sound rolls with proper file timecode — carries a trustworthy start stamp, syncing is arithmetic. For what happens when files carry no timecode at all, see our companion guide on syncing external audio without a clapper; for how synced material should be delivered to an editor, see the editor package.

Where Launchr Post fits

Launchr Post does the decoding described above automatically. Point it at a shoot day and it pairs sound and picture by file timecode first; where a camera has LTC hiding in an audio track, it reads the LTC directly from the recording, verifies continuity and uses it as the sync reference — then refines the match to sample accuracy against the waveforms. Everything runs on your own machine, and the sync report states per clip whether timecode or waveform made the match.