23.976 vs. 25 fps: derfor glider din sync. Frame rate-mismatch forklaret

Symptomet: perfekt i starten, forkert i slutningen

Den klassiske melding fra klipperummet lyder sådan her: syncpunktet sidder præcist. Læberne passer det første minut eller to. Ved minut fem er lyden synligt for tidlig eller for sen, og når et interview på 20 minutter slutter, er den mere end et sekund forkert. Syncer man om i slutningen, brækker starten. Intet blev skubbet, intet faldt ud. Forskydningen vokser bare, jævnt og lineært.

Den lineære vækst er det fingeraftryk, der tæller. Tilfældige dropouts hopper; et forkert syncpunkt giver en konstant forskydning; oscillator-drift vandrer let med temperaturen. En fejl, der vokser i et fuldkommen stabilt tempo, betyder at to ure løber med forskellig hastighed. Og når hastighedsforskellen rammer et af to magiske tal, 0,1 % eller 4,1 %, er årsagen et frame rate-mismatch, ikke hardware.

Hvor 23.976 kommer fra, og hvorfor det nægter at dø

Film kører 24 fps. Europæisk tv kører 25 fps, historisk låst til 50 Hz netfrekvens. Amerikansk farve-tv kører 29,97 fps, fordi NTSC-farvebærebølgen i 1953 skulle undgå interferens med lydbærebølgen, og løsningen var at sænke de 30 fps fra sort-hvid-tiden med forholdet 1000/1001. Hver eneste “skæve” rate, du møder, er det samme forhold brugt et nyt sted: 30 → 29,97, 60 → 59,94 og 24 → 23.976 (præcist 24.000/1001 = 23,976023… fps), opfundet så filmoptaget materiale kunne ligge rent i 29,97-broadcastkæden via 2:3-pulldown.

Broadcast-begrundelsen er væk; raten er her stadig. Kameramenuer kalder det “24p”, selv om sensoren reelt kører 23.976, streamingplatformene tager imod det, og enorme mængder footage fra mirrorless- og cinema-kameraer bliver optaget i det som standard. Samtidig er 25 fps stadig normen i Europa til broadcast og det meste corporate-arbejde. Enhver produktion, der blander amerikanske standardindstillinger med europæiske, eller ægte 24 med “24p”, har plantet et syncproblem, som først viser sig i post.

De tre mismatch og deres reelle drift-tal

1. 23.976 mod ægte 24: pulldownets 0,1 %

Forholdet 1001/1000 betyder, at den ene enhed tæller 0,1 % langsommere end den anden. Helt konkret:

• 1 ms drift pr. sekund spilletid.
• En hel frame (41,7 ms ved 24 fps) hvert ~42. sekund.
• 60 ms pr. minut, altså synligt ude af læbesync (broadcast-tolerancen er cirka 40 ms) inden for det første halvandet minut.
• 3,6 sekunder pr. time, samme tal som kendes fra drop-frame-timecode, for det er det samme forhold.

Det er fælden, der gemmer sig i ordet “24”. Et kamera, der optager “24p” (reelt 23.976), sammen med en lydoptager, der genererer ægte 24-frames timecode, eller en lydoptager sat til “24”, mens kameramenuen siger “23.98”, giver præcis denne drift. Begge enheder fejler intet. Begge ure går rigtigt. De tæller bare forskellige sekunder.

2. 25 mod 23.976 (eller 24): en hastighedskløft på 4,1 til 4,2 %

Mellem 25 og 23.976 er forskellen ikke subtil: 25/23,976 ≈ 1,0427. Intet “glider” ved et uheld 4 %; det her mismatch brækker tingene kategorisk. Timecode-baseret sync fejler med det samme, fordi de to enheder ikke engang er enige om, hvad et framenummer betyder. Frame 12 i et sekund findes på begge, men lander på forskellige tidspunkter i virkelig tid, og tællingerne skilles midt i sekundet. Et 25 fps-B-kamera eller en drone, der smides ind i en 23.976-timeline, bliver enten retimet af NLE'et (med 4,2 % slow-down og et pitch-skift på næsten en halvtone, hvis lyden følger med) eller afspillet i forkert hastighed med duplikerede eller oversprungne frames. Den gode nyhed: fordi fejlen er kæmpestor, bliver den fanget tidligt. Den dårlige: den gængse “løsning”, at lade NLE'et conforme hastigheden i stilhed, ødelægger ubemærket enhver timecode-relation, klippet havde.

3. 48 kHz mod 48.048: pulldown på lydsiden

Forholdet 1000/1001 findes også på lydsiden. Nogle feltoptagere og workflows fra DSLR-æraen optager ved 48.048 kHz (48 kHz × 1001/1000), så filen, når den senere afspilles ved 48 kHz, sænkes med præcis 0,1 % og passer til pulled-down billede. Importeres en 48.048-fil, som om den var 48 kHz, eller omvendt, får du samme 1 ms/s-drift som i tilfælde 1, bare fra lydsiden. Tjek den faktiske sample rate i filens header, ikke etiketten på optageren. Og bemærk at nogle optagere skriver 48.048 samples, men stempler headeren 48000 med vilje, hvilket er usynligt, indtil du måler varighed op mod timecode.

Diagnose: mismatch eller clock-drift?

Ægte oscillator-drift, to krystaller der løber frit efter en jam-sync, ligger typisk på få parts per million: tiendedele af en frame i timen (den fejltype går guiden om timecode-drift i dybden med). Et pulldown-mismatch er 1.000 ppm, to størrelsesordener større. At skille dem ad kræver to målinger og én division:

1. Mål forskydningen i starten. Sync på en klap, et slate eller en transient i waveformen nær begyndelsen. Notér restforskydningen (ideelt nul).
2. Mål forskydningen i slutningen. Find en transient nær enden af samme take, en dør, en plosiv, og mål hvor meget lyden ligger foran eller bagefter billedet dér.
3. Dividér drift med varighed. Voksede forskydningen 600 ms over 10 minutter? 600 ms / 600 s = 0,1 %. Pulldown-mismatch, sagen er lukket. Voksede den 15 ms over 10 minutter? Det er 25 ppm, altså et frit løbende ur, som rettes ved at jamme om på settet, ikke ved at conforme.

To tjek, der bekræfter diagnosen: et rate-mismatch giver samme forhold på hvert eneste klip-par fra de samme to enheder, hele dagen. Oscillator-drift varierer med temperaturen og nulstilles ved sluk og tænd. Og filens metadata tilstår som regel: sammenlign videostreamens præcise frame rate (23.976 mod 24.000 mod 25.000) og lydfilens sande sample rate med det, produktionen troede den optog i. På materiale med timecode er en 23.976-fil, hvis timecode tæller 24 frames pr. mærket sekund, helt forventelig. Sådan fungerer 23.976-timecode. Men dens “sekunder” er 0,1 % for lange i virkelig tid, og det er præcis den afvigelse, du målte.

Løsningerne, fra set til timeline

På settet (gratis): vælg én frame rate-familie, og få hver eneste enhed med på den. 25 fps-produktioner: kameraer på 25, optagerens timecode på 25, ingen “24p”-B-roll fra nogens private kamera. 23.976-produktioner: sørg for at enheder, der tilbyder både “24” og “23.98”, alle siger det samme. Det er forskellige rater, 0,1 % fra hinanden, og at blande dem er denne artikels tilfælde 1. Lyd på rene 48 kHz, medmindre workflowet udtrykkeligt kræver 48.048.

I NLE'et (bagefter): reparationen er en 0,1 %-retime af den ene side, lagt på før sync, ikke et håndsk-slip i slutningen:

• Premiere Pro: højreklik på klippet → Modify → Interpret Footage. For billede i forkert rate: fortæl Premiere den rigtige frame rate. For lyd der glider: en konstant hastighedsjustering på 100,1 % (eller 99,9 %) på lydklippet, eller resample WAV'en eksternt, så den kommer over på billedets ur. Interpret Footage er ikke-destruktiv og overlever relink.
• DaVinci Resolve: clip attributes → Video → frame rate for billede; for lyd retime-kontrollerne eller en conformet kopi. Grupperer du vinkler, så ret raterne før du bygger multicam'en. Resolves sync-kort forudsætter et fælles ur, som multicam-sync-guiden gennemgår.
• Conform på lydsiden: sample rate-konvertér optagelsen med 1000/1001 (48.000 → 47.952 afspilning eller omvendt) i et hvilket som helst ordentligt lydværktøj. Gør det én gang, i fuld kvalitet, og gem originalen.

Hvad du ikke skal gøre: strække lyden på gehør, til slutningen ser rigtig ud (forholdet bliver næsten-men-ikke-helt 0,1 %, og hvert eneste andet klip kræver sit eget gæt), eller klippe taket i bidder og synce hver bid for sig (det klassiske tegn på, at et mismatch aldrig blev diagnosticeret, og en senere conform-pass spreder de håndlavede fix for alle vinde).

Fejlmønstre der holder problemet i live

• “24” der betyder 23.976. Kameramenuer, NLE-etiketter og lejepapirer runder det væk. Behandl ethvert “24” eller “23.98”, du ikke selv har verificeret, som ukendt, indtil filen siger noget andet.
• Kits fra blandede markeder. En europæisk 25 fps-optagelse med et actionkamera eller en drone på amerikanske standardindstillinger, 29,97/23.976, i tasken. Hver eneste af de filer skal conformes eller retimes. Budgettér med det, eller forbyd dem.
• Timecode der “matcher”, men ikke gør det. To enheder kan vise de samme tal ved klappen og stadig tælle i forskellige hastigheder; ens start-stempler garanterer kun sync i ét øjeblik. Derfor verificerer timecode-først-workflows stadig op mod waveformen.
• Tavse NLE-conforms. At smide et mismatchet klip i en timeline “virker” ofte, fordi NLE'et retimer det uden at spørge. Indtil lyden fra det klip eksporteres, eller projektet flytter til et andet system, der tolker raten anderledes.
• 48.048-headerløgnen. Audio pulldown-workflows, der med vilje skriver forkerte sample rate-headere. Hvis en fils varighed × sample rate ikke matcher dens sample-antal, så tro på samples'ene.

Her passer Launchr Post ind

Launchr Post læser de faktiske rater ud af hver eneste fil, den ingester: videostreamens præcise frame rate, lydens sande sample rate og timecodens tællerate, i stedet for at stole på etiketter. Når den syncer en optagedag, matcher den på timecode først og finjusterer mod waveformen, så et klip-par, der sidder i starten og vandrer af sted med stabile 0,1 %, straks træder frem i sync-rapporten, navngivet som et rate-mismatch i stedet for at ligge og vente på, at klipperen opdager det ved minut fem. Alt kører lokalt på din Mac, og rapporten oplyser pr. klip, hvilket ur der blev stolet på.