Non-drop naar drop-frame
Of plak ondertiteltekst
Opties
30 fps non-drop en 29,97 drop-frame schrijven dezelfde klok anders, en dit vak kiest in welke richting het bestand wordt gelezen en in welke het wordt teruggeschreven. Een blok een uur verder leest onder de ene als 01:00:00,000 en onder de andere als 01:00:03,600 — de twee liggen 3,6 seconden per uur uit elkaar, geen afrondingsfout. De titel van de pagina noemt één richting, en dit vak biedt alleen die aan, dus het bestand dat je krijgt is het bestand waar de pagina over gaat. Aan de tekst verandert niets: geen blok wordt opnieuw getimed ten opzichte van de video, geen beeldsnelheid wordt omgerekend, en een blok binnen de eerste minuut van een uur komt precies terug zoals het erin ging, omdat daar geen framelabel wordt overgeslagen.
In welke beeldsnelheid de tijden worden geteld. Op de formaatpagina’s is dit wat MicroDVD nodig heeft, want het slaat tijden op als framenummers. Op de beeldsnelheidspagina’s is het de snelheid waartegen het bestand getimed is — de versie waarvoor de ondertitels gemaakt zijn — en het tweede vak op de pagina neemt de snelheid van de video die je gaat gebruiken. 23,976, 24, 25, 29,97, 30, 50, 59,94 en 60 zijn de gebruikelijke. Een verkeerde waarde verschuift de hele tijdlijn, en op de beeldsnelheidspagina’s verschuift ze die met een verhouding in plaats van met een vast bedrag.
Deze pagina schrijft elke tijdcode in een ondertitelbestand opnieuw, van 30 fps non-drop naar 29,97 fps drop-frame. Je sleept het bestand erin, laat de pagina lopen, en het begin en einde van elk blok komen er anders geschreven uit. De woorden, de cuenummers, de volgorde van de blokken en de regeleinden zijn die van het bestand en blijven precies zoals ze waren.
De twee conventies spellen dezelfde klok verschillend, en een bestand moet in de conventie staan die de rest van de keten gebruikt. Drop-frame telt dertig labels per seconde maar slaat er elke minuut twee over, behalve elke tiende minuut; zo blijft het bij de wandklok terwijl non-drop er langzaam achterop raakt. Na een uur schelen ze 3,6 seconden: 01:00:00,000 onder non-drop is 01:00:03,600 onder drop-frame. Dat gat is geen afrondingsfout en wordt niet weggerond — het groeit met het programma mee en bedraagt na tien uur 36 seconden.
In de eerste minuut van een uur beweegt niets, want daar wordt geen label overgeslagen en spellen beide conventies dat stuk identiek. Dat geldt voor klokken die al op een tik van het 30 fps-rooster liggen — 00:00:02,000 is er zo een — en een klok tussen twee tikken wordt naar de dichtstbijzijnde verplaatst, met maximaal 17 milliseconden. Een klok als tijdcode lezen betekent hem overal in het bestand op het framerooster leggen; binnen de eerste minuut is die snapping het enige dat beweegt. De tijden van een ondertitelbestand komen meestal uit een framenauwkeurig programma en liggen al op het rooster, en daarom komt dat stuk vaak byte voor byte terug.
Geen enkel ondertitelformaat dat hier wordt gelezen heeft een veld dat vastlegt in welke conventie een klok staat — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON en CSV schrijven allemaal alleen een tijd. Deze pagina verandert dus de getallen, en welke conventie ze betekenen blijft een eigenschap van jouw keten, precies zoals die was voordat het bestand aankwam. Wat niet in het bestand staat, kan er niet in worden geschreven, en doen alsof dat wel kan is erger dan het zeggen.
Dit is geen framerateconversie. Een bestand dat op 25 fps-video is getimed wordt hier niet opnieuw getimed, en er wordt niets tegen een video uitgerekt of samengedrukt: de onderlinge afstand van de tijden blijft en alleen de spelling verandert. Heb je de andere klus nodig — een ondertitelbestand waarvan de spreiding een andere framerate volgt — dan heeft die een eigen pagina. Ook hier wordt niets geüpload: het bestand wordt in de browsertab gelezen en geschreven, dus materiaal dat de machine niet mag verlaten blijft erop.
Voorbeelden
Een bestand vijf minuten in
Invoer
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.
Uitvoer
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 twee blokken verschuiven niet even ver, en dat is de hele bewerking: na vijf minuten heeft drop-frame tien labels overgeslagen, dus leest de klok 333 ms later; na tien minuten zijn het achttien, dus 600 ms later. De tekst en de cuenummers zijn die van het bestand — alleen de twee klokwaarden per blok worden herschreven.
Hetzelfde bestand na een uur
Invoer
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Uitvoer
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Op één uur schelen de twee conventies 3,6 seconden, ofwel 108 overgeslagen labels. Dit is het getal om tegen de pagina te leggen: lees de eerste regel van de uitvoer en die hoort precies 3600 ms later te zijn dan de eerste regel van de invoer. Beide randen van het blok verschuiven, dus het blok houdt zijn lengte.
Een blok binnen de eerste minuut
Invoer
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.
Uitvoer
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.
Het eerste blok komt byte voor byte terug en het tweede verschuift, in dezelfde run. Tijdens de eerste minuut van een uur wordt geen label overgeslagen, dus spellen beide conventies die zestig seconden identiek — en 00:00:02,000 ligt al op een tik van het 30 fps-rooster, dus daaraan verandert niets. Een klok tussen twee tikken zou juist naar de dichtstbijzijnde worden verschoven, met maximaal 17 ms; dat is dezelfde snapping die de pagina overal in het bestand toepast. Eén blok ongewijzigd naast één verschoven blok is hier het verwachte resultaat, geen half afgemaakte run.
Veelgestelde vragen
Wat is het verschil tussen drop-frame en non-drop tijdcode?
Beide tellen dertig labels per seconde, maar 29,97 fps levert geen dertig frames per seconde — het levert er ongeveer 29,97, dus een klok die dertig labels per seconde telt verliest langzaam terrein op de echte tijd. Drop-frame lost dat op door aan het begin van elke minuut twee labels over te slaan, behalve elke tiende minuut: de labels verdwijnen terwijl de frames blijven. Non-drop houdt elk label en loopt weg. Op papier lijken de twee op hetzelfde soort getal; tegen hetzelfde frame gelezen schelen ze na een uur 3,6 seconden en steeds meer naarmate het programma langer duurt.
Waarom komt een blok na een uur 3,6 seconden later uit dan het erin ging?
Omdat 3,6 seconden is waar een uur overgeslagen labels op uitkomt: twee labels per minuut gedurende 54 van elke 60 minuten, tegen 33,37 ms per label, ofwel 108 labels en 3600 ms per uur. De pagina voegt geen vertraging toe — ze schrijft dezelfde frames onder de andere conventie, en die andere conventie leest op dat punt in het programma later. Een blok op 01:00:00,000 gaat erin en 01:00:03,600 komt eruit; beide randen verschuiven, dus het blok houdt zijn lengte tot op de milliseconde.
Waarom kwam de eerste minuut van mijn bestand onveranderd terug?
Omdat tijdens de eerste minuut van een uur geen label wordt overgeslagen, dus spellen drop-frame en non-drop dat stuk identiek — 00:00:02,000 betekent onder beide conventies 60 frames, en 60 frames worden hoe dan ook hetzelfde geschreven. De drift begint bij de eerste minuutgrens en groeit daarna. Er is nog één ding dat een tijd in dat stuk kan verplaatsen: een klok als tijdcode lezen legt hem op de dichtstbijzijnde tik van het 30 fps-rooster, dus een waarde tussen twee tikken, zoals 00:00:02,010, komt terug als 00:00:02,000. Tijden uit een framenauwkeurig programma liggen al op het rooster en bewegen helemaal niet.
Welke richting heb ik nodig — non-drop naar drop-frame, of andersom?
Dat hangt af van waar de tijdcodes in je bestand zijn gelezen. Heb je de tijden uit een speler of editor op non-drop gehaald en werkt de keten waarin je levert in drop-frame, dan is dit de pagina. Is je bestand tegen een drop-frame-beeldscherm gestempeld en verwacht het programma stroomafwaarts non-drop, dan wil je de andere pagina, die de klokken de andere kant op en met dezelfde 3,6 seconden per uur verplaatst. Een snelle manier om ze uit elkaar te houden: laat het bestand hier lopen en vergelijk één blok — leest de klok in de uitvoer later dan in de invoer, dan had het deze richting nodig.
Verandert deze pagina de framerate van mijn ondertitels?
Nee. Niets wordt geschaald en niets wordt uitgerekt: een blok dat twee seconden duurde is nog steeds twee seconden, en de afstand tussen blokken blijft gelijk, omdat elk blok verschuift met een bedrag dat van zijn positie afhangt en niet van een verhouding. Een bestand dat op 25 fps-video is getimed wordt hier ook niet naar 29,97 omgezet — het vak voor een framerate bestaat omdat MicroDVD zijn tijden als framenummers opslaat en zonder die snelheid niet te lezen is. De spreiding van een bestand van de ene framerate naar de andere omzetten is een andere bewerking met een eigen pagina.
Staat er ergens in het bestand dat de tijdcodes nu drop-frame zijn?
Nee, en geen formaat dat hier wordt gelezen zou dat kunnen: SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON en CSV bewaren een tijd en niets over hoe die is geteld. Dat gold al voor het bestand dat je erin sleepte. De pagina verandert dus de getallen, en welke conventie ze betekenen blijft wat jouw keten zegt dat het is — dezelfde afspraak als voorheen, nu met getallen die erbij passen. Heeft een programma stroomafwaarts een eigen drop-frame-instelling, dan is die instelling wat deze waarden leest.