Konverter non-drop til drop-frame
Eller indsæt underteksttekst
Indstillinger
30 fps non-drop og 29,97 drop-frame skriver den samme klokke forskelligt, og denne boks vælger, hvilken vej filen læses, og hvilken vej den skrives tilbage. En tekstblok en time inde læses som 01:00:00,000 under den ene og 01:00:03,600 under den anden – de to er 3,6 sekunder fra hinanden pr. time, ikke en afrundingsfejl. Sidens titel nævner én retning, og denne boks tilbyder kun den ene, så den fil, du får, er den fil, siden handler om. Intet ved teksten ændres: ingen tekstblok re-times mod videoen, ingen billedhastighed konverteres, og en tekstblok inden for det første minut af en time kommer tilbage præcis, som den kom ind, fordi intet billedmærke droppes der.
Hvilken billedhastighed tiderne tælles i. På formatsiderne er det, hvad MicroDVD har brug for, fordi formatet gemmer tider som billednummer. På siderne om billedhastighed er det den hastighed, filen blev timet efter – den version, underteksterne blev lavet til – og sidens anden boks tager hastigheden for den video, du skal bruge dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 og 60 er de almindelige. Tager man fejl, forskydes hele tidslinjen, og på siderne om billedhastighed forskydes den med et forhold i stedet for et fast beløb.
Denne side skriver en undertekstfil om fra non-drop til drop-frame. Det er en ændring af, hvordan tiden læses og skrives, ikke en flytning af tidslinjen: de samme billeder bliver de samme billednumre, men de får nye labels. Efter en time læser den samme sekvens 01:00:03,600 i drop-frame, hvor non-drop skriver 01:00:00,000 – forskellen på 3,6 sekunder er selve operationen og ikke en fejl.
Drop-frame findes, fordi 29,97 fps ikke er præcis 30. Et ur, der tæller 30 billeder i sekundet, løber langsommere end den virkelige tid, og for at holde timecode nogenlunde på plads springer drop-frame to labels over ved begyndelsen af hver minut undtagen hvert tiende. Det er de labels, der giver de 108 sprang i timen, og de 3,6 sekunder er deres navn, ikke en unøjagtighed. Non-drop gør ikke det og tæller alle labels med; derfor er de to strenge forskellige, selv om de beskriver de samme billeder.
Vær opmærksom på, hvad der ikke er sandt: drop-frame følger ikke det virkelige ur præcist. Det er en tilnærmelse, der løber omkring 0,108 billede for hurtigt i timen, hvilket over et døgn bliver omkring 2,6 billeder. Siden skriver derfor ikke, at drop-frame »er« vægurets tid, men at det holder timecode tæt på den med en kendt, lille afvigelse. Det er den samme afvigelse, som gør, at en fil, der er skrevet i drop-frame, stadig skal kontrolleres mod billedet.
Den første minut af hver time er identisk i de to konventioner, fordi der ikke springes noget over der. En cue, der ligger der, kommer derfor byte for byte tilbage. En cue, der er kortere end et billede, kan få begge sine grænser lagt på samme label og fjernes, fordi en blok uden varighed ikke kan skrives. SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON og CSV læses som det, de er, og alt kører lokalt i browseren.
Eksempler
En fil fem minutter inde
Input
1
00:05:00,000 --> 00:05:02,000
The room is dark.
2
00:10:00,000 --> 00:10:03,000
A cold night.
Resultat
1
00:05:00,333 --> 00:05:02,333
The room is dark.
2
00:10:00,600 --> 00:10:03,600
A cold night.
De to tekstblokke flytter sig ikke lige meget, og det er hele operationen: efter fem minutter har drop-frame sprunget ti labels over, så uret læser 333 ms senere; efter ti minutter er der sprunget atten over, og forskellen er 600 ms. Det er ikke en fast forskydning, men en optælling, der vokser med antallet af overståede minutter.
Den samme fil en time inde
Input
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Resultat
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Ved en time er de to konventioner 3,6 sekunder fra hinanden, hvilket svarer til 108 sprangte labels. Det er det tal, du kan kontrollere siden imod: læs den første linje i resultatet, og den skal være præcis 3,6 sekunder senere end i input. Forskellen er ikke en fejl, men det navn, drop-frame giver de samme billeder.
En tekstblok inde i det første minut
Input
1
00:00:02,000 --> 00:00:04,000
Nothing to re-label yet.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Resultat
1
00:00:02,000 --> 00:00:04,000
Nothing to re-label yet.
2
00:05:00,333 --> 00:05:02,333
This one does move.
I løbet af det første minut af en time springes ingen labels over, så de to konventioner staver de tres sekunder ens, og den første blok lades urørt. Den anden blok, der ligger på fem minutter, flytter sig. En blok uden for det første minut kommer altså tilbage uændret, mens resten af filen ikke gør.
Ofte stillede spørgsmål
Hvorfor bliver min fil 3,6 sekunder længere, når jeg konverterer til drop-frame?
Fordi drop-frame springer 108 labels over i timen, og de labels er navnet på de samme billeder i den anden konvention. Forskellen er ikke en flytning af tiden, men en forskel i, hvordan den samme sekvens tælles. Ved en time læser den samme sekvens 01:00:03,600 i drop-frame, hvor non-drop skriver 01:00:00,000, og de 3,6 sekunder er selve konverteringens definition.
Er drop-frame det samme som det virkelige ur?
Nej, det er en tilnærmelse. Drop-frame holder timecode tæt på uret, men løber omkring 0,108 billede for hurtigt i timen, hvilket bliver omkring 2,6 billeder over et døgn. Det er tæt nok til, at det er den accepterede standard, men det er ikke præcist, og derfor bør du stadig kontrollere en fil mod billedet i stedet for at gå ud fra, at tiden er eksakt.
Hvorfor står den første tekstblok stille, når resten flytter sig?
Fordi drop-frame ikke springer nogen labels over i det første minut af hver time. Der er de to konventioner identiske, og en blok, der ligger der, kommer byte for byte tilbage. Det er ikke en fejl i konverteringen, men en egenskab ved standarden – og det er derfor, en testfil bør have mindst én cue efter det første minut, hvis du vil se en forskel.
Kan en tekstblok forsvinde, når drop-frame-labels skrives om?
Kun hvis en blok er kortere end et billede, altså omkring 33 ms, hvor begge grænser kan lande på samme label og efterlade en blok uden varighed. Det tælles med i resultatet. En normal undertekst er aldrig så kort, men reglen findes, fordi en fil med beskadigede tider ellers kunne producere en blok, der ikke kan skrives.
Hvorfor ændrer de to tekstblokke sig ikke lige meget?
Fordi forskellen er en optælling af sprangte labels og ikke en fast forskydning. Den vokser med antallet af overståede minutter: efter fem minutter er der sprunget ti labels over, efter ti minutter atten, og efter en time 108. Det er derfor, du ikke kan konvertere med et enkelt millisekundtal – konverteringen læser hver tid som en label og skriver den om efter reglen.