Hvad er LTC-timecode? Sådan virker lyd-timecode, og sådan læser du den
LTC er den summende, faxagtige tone, der bærer et ur inde i et lydsignal. Det er stadig den mest robuste måde at holde kameraer og lydoptagere på samme tid, og samtidig det man oftest finder halvt ødelagt i en rushes-mappe. Her er hvordan signalet faktisk virker, hvorfor det fejler, og hvad en dekoder skal have fra dig.
LTC i ét afsnit
LTC står for linear timecode (historisk ”longitudinal timecode”) og er defineret i SMPTE 12M-familien af standarder. Det koder et løbende ur, timer, minutter, sekunder og frames, som et signal i lydfrekvensområdet. Fordi det bare er lyd, kan det optages på et ledigt lydspor, sendes gennem et hvilket som helst lydkabel og overleve at blive kopieret mellem systemer, der intet ved om video. Når et kamera ikke har timecode-indgang, er det klassiske trick at føre LTC ind i en af dets lydkanaler: billedfilen bærer så sit eget ur, gemt i en ledig kanal.
Tallet du ser, 14:32:07:18, er en tid på døgnet eller en vilkårlig tæller, stemplet én gang pr. frame. Alle enheder der deler samme ur, stempler de samme tal i samme øjeblik, og det er dét, der gør automatisk sync mulig bagefter: match tallene, og billede og lyd falder på plads.
Sådan virker signalet: biphase mark, i menneskesprog
LTC bruger biphase mark-kodning (også kaldet differentiel Manchester, samme idé som AES3-lyd bruger):
- Tiden deles i lige store slots, én pr. bit. Firs bit udgør én frames timecode.
- Signalet er en firkantpuls, der altid skifter polaritet ved starten af hver bit-slot. Det konstante skift er metronomen; det er derfor, en dekoder aldrig behøver en separat clock-linje.
- Et nul er en slot uden ekstra skift i midten. Et et-tal er en slot med ét ekstra skift halvvejs igennem.
Det giver LTC tre egenskaber, der har gjort det nærmest uopslideligt i praksis: det er selv-clockende (overgangene fortæller selv dekoderen, hvor hurtigt signalet løber), ufølsomt over for polaritet (et forkert forbundet balanceret kabel ødelægger det ikke) og læsbart forlæns og baglæns; sync-ordet, som vi kommer til, afslører retningen.
Ved 25 fps giver 80 bit pr. frame en bitrate på 2.000 bit i sekundet; signalets grundtoner ligger groft sagt mellem 1 og 2,4 kHz afhængigt af frame rate og bitmønster. Det er lige midt i det område, som enhver mikrofonforstærker, lyd-codec og ethvert kabel på kloden håndterer uden at kny, og det er netop pointen.
Hvad bor der i de 80 bit
Hver frame LTC bærer ét 80-bit-ord:
- 26 bit tid: frames, sekunder, minutter og timer, kodet som binary-coded decimal (hvert decimalciffer får sin egen gruppe af bit).
- 32 bit brugerdata (”user bits”): otte frie hex-cifre. Produktioner bruger dem til optagedato, reel- eller kamera-ID, eller lader dem stå på nul. Intet i standarden håndhæver en bestemt betydning, så behandl user bits som en aftale pr. produktion, ikke som data du kan stole blindt på.
- Flag-bit, heriblandt drop-frame-flaget (tæller vi 29.97 fps drop-frame?) og colour framing-flaget, plus polaritetskorrektion og binary group-flag, som de fleste workflows ignorerer.
- Et 16-bit sync-ord: det faste mønster
0011 1111 1111 1101. Den lange stribe et-taller kan ikke forekomme andre steder i et gyldigt ord, så dekoderen bruger den til at finde, hvor hvert 80-bit-ord starter, og om signalet løber forlæns eller baglæns.
Frame rates og drop-frame-krøllen
LTC tæller frames, så det skal være enigt med billedets frame rate: 23.976, 24, 25, 29.97 eller 30 fps. To detaljer bider folk igen og igen:
- Drop-frame vs. non-drop-frame findes kun ved 29.97 fps. Drop-frame springer frame-numre over (aldrig faktiske frames), så den viste tid følger uret på væggen. Blander man DF- og NDF-enheder på ét sæt, vokser forskydningen hen over dagen, cirka 3,6 sekunder i timen, og det ligner mystisk drift på en prik, indtil nogen tjekker flaget. Notationen afslører det:
01:00:00;02(semikolon) er drop-frame,01:00:00:02er ikke. - 23.976 fps har ingen egen LTC. Der findes ingen LTC-standard for fraktionelle frame rates under 29.97; en 23.976-produktion kører typisk 24-frame-tælling trukket ned, eller 29.97/30-frame-kode der konverteres. Når sync er skæv med et konsistent, bittelille forhold (cirka 0,1 %), er et 24/23.976-mismatch den første mistænkte; vores guide til sync-problemer mellem 23.976 og 25 fps viser, hvordan du stiller diagnosen og reparerer den.
Sådan kommer LTC med på en optagelse
Tre almindelige mønstre, fra mest til mindst udstyr:
- Dedikerede sync-bokse på hvert kamera og hver optager, jammet fra én master; hver enhed stempler timecode i sine egne fil-metadata, og LTC er jamme-signalet mellem boksene.
- LTC ind i en lydkanal på kameraet. Kameraer uden TC-indgang, de fleste mirrorless-huse, mange droner og actionkameraer, optager tonen på kanal 1 eller 2. Filens metadata-timecode forbliver meningsløs, men lydkanalen bærer det rigtige ur og venter bare på at blive dekodet i post.
- Optageren som master. Lydoptageren genererer timecode; alt hvad der kan lytte med, får signalet.
Derfor knækker LTC: de fem sædvanlige mistænkte
En dekoder skal se rene overgange på forudsigelige tidspunkter. Alt hvad der går galt med LTC ude i virkeligheden, er en eller anden måde at udtvære, klippe eller forvrænge de overgange på.
1. For lavt niveau
Optaget ved -50 dBFS under kameraforstærkerens støj drukner firkantpulsen, og dekoderen finder overgangene for sent eller slet ikke. Sigt efter et sundt nominelt niveau, omkring -20 til -12 dBFS, og slå al automatisk gain-styring fra; ellers ”rider” den den konstante tone nedad.
2. For varmt niveau eller auto-gain-artefakter
Clipping runder pulsen til noget med ringing og DC-offset; AGC-pumpning modulerer amplituden. Begge dele skubber enkelte overgange væk fra deres forventede positioner. Spredte fejl kan reddes (en god dekoder interpolerer hen over dårlige ord), vedvarende forvrængning kan ikke.
3. Lossy komprimering
AAC- og MP3-encodere er bygget til at bevare det, mennesker hører, og en biphase-firkantpuls er præcis den slags signal, de maltrakterer: pre-echo udtværer kanterne, og faseforholdene, som dekoderen læner sig op ad, er ikke beskyttet. LTC optaget i et AAC-kameraspor (almindeligt på forbrugerkameraer og skærmoptagere) overlever ofte, men kun lige akkurat, og endnu en genkodning slår det tit ihjel. Hold LTC i PCM (WAV), når du selv bestemmer formatet.
4. Resampling og hastighedsændringer
Samplerate-konvertering gjort ordentligt er harmløs. Gjort dårligt, eller kombineret med en skjult hastighedsændring, for eksempel 48 kHz-lyd afspillet ved 48,048 eller en variframe-optagelse, matcher bit-uret ikke længere nogen standardrate. Dekoderen kan ofte stadig låse (selv-clockingen hjælper), men de dekodede tider kryber i forhold til billedet, og det viser sig som én enhed der ”driver”, selvom de oprindelige stempler var fine.
5. Krydstale og bleed
LTC er kraftigt, konstant og ligger i mellemtonen, så det bløder: over i nabokanalen, ind i en scratch-mikrofon på samme kamera, en sjælden gang ind i produktionslyden. Bleed stopper sjældent dekodningen, men det omvendte problem er reelt: en kanal med dialog og svag LTC nedenunder kan dekode i ryk og give falske locks. Fortæl dekoderen, hvilken kanal der er TC-kanalen, i stedet for at lade den gætte på den, der låser først.
Jam-sync og drift: derfor er ”jammet ved call” ikke nok
Jam-sync betyder at sætte en enheds interne timecode-ur fra en ekstern kilde og så koble fra. Fra det øjeblik løber enheden frit på sin egen krystaloscillator, og ingen to krystaller løber præcis lige hurtigt.
Krystaller specificeres i parts per million. Et kamera på ±5 ppm vinder eller taber cirka 0,4 frames i timen ved 25 fps; billigere hardware er flere gange værre, og temperatursving (et kamera i solen, en optager i en taske) presser oscillatorerne yderligere. Dedikerede sync-bokse bruger temperaturkompenserede oscillatorer et godt stykke under 1 ppm, og det er derfor, de holder en frame i dagevis, mens et jammet kamera måske ikke holder den eftermiddagen ud. De fulde tal, ppm-ratings omsat til frames i timen, temperatureffekter og hoved/hale-målingen der skiller drift fra et rate-mismatch, står i den dedikerede guide om timecode-drift: årsager og løsninger.
De praktiske regler, der følger af det:
- Re-jam hver 4–6 timer, og altid efter frokost (strømcyklusser nulstiller TC-uret på nogle kameraer).
- Timecode giver frame-præcision, ikke sample-præcision. Selv et perfekt TC-match justerer kun til nærmeste frame-grænse; op til en halv frame (20 ms ved 25 fps) i restforskydning er normalt, og strammere justering skal komme fra selve lydbølgeformerne.
- Skriv ned, hvilken enhed der var master. Når tallene er uenige i post, skal du vide, hvilket ur du skal tro på.
Sådan læser du faktisk LTC i post
Du kan genkende LTC med øret: solo kanalen, og du hører den umiskendelige, hårde digitale summen. At bekræfte og bruge den kræver en dekoder. Det her skal dekodningen bruge:
- Den rigtige kanal. På en stereo-kamerafil ligger tonen som regel i den ene side med en scratch-mikrofon i den anden.
- Lås på bit-uret. Dekoderen måler afstanden mellem overgangene og udleder bitraten og dermed frame rate-familien. Beskadigede signaler fejler her først.
- Sync-ords-justering. At finde
0011 1111 1111 1101rammer de 80-bit-ord ind og afslører afspilningsretningen. - Kontinuitetstjek. Gode dekodere læser hele filen, verificerer at ordene tæller op med præcis én frame ad gangen, og flager spring; et spring midt i filen betyder som regel en re-jam mens der blev optaget, eller et dropout.
- Forankring. Den dekodede tid ved en kendt sample-position bliver filens reelle start-timecode og erstatter det, kamera-metadataene påstod.
Når hver fil, både kameraoriginaler med LTC i en lydkanal og lydruller med ordentlig fil-timecode, bærer et troværdigt startstempel, er sync ren aritmetik. Hvad du gør, når filerne slet ingen timecode har, står i vores guide om at synce ekstern lyd uden klaptræ; hvordan det synkede materiale skal afleveres til en klipper, står i editor-pakken.
Her passer Launchr Post ind
Launchr Post laver dekodningen ovenfor automatisk. Peg programmet på en optagedag, og det parrer lyd og billede efter fil-timecode først; hvor et kamera har LTC gemt i et lydspor, læser det LTC direkte fra optagelsen, verificerer kontinuiteten og bruger den som sync-reference, og finjusterer til sidst matchet til sample-præcision mod bølgeformerne. Alt kører på din egen maskine, og sync-rapporten fortæller pr. klip, om det var timecode eller bølgeform, der lavede matchet.
Prøv det på dine egne rushes
Smid en rigtig optagedag i Launchr Post, og hold den dekodede timecode op mod dine noter. Programmet syncer, sorterer og transskriberer og rækker derefter din klipper hele pakken.