Drop-frame naar non-drop
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 29,97 fps drop-frame naar 30 fps non-drop. Elke klok komt daardoor een vast bedrag vroeger te staan dat met het programma meegroeit: niets binnen de eerste minuut van een uur, 3,6 seconden na een uur en 36 seconden na tien uur. De woorden, de cuenummers, de volgorde van de blokken en de regeleinden blijven die van het bestand zelf en komen er ongemoeid uit.
Het bestand waar deze pagina voor is, is gestempeld tegen een beeldscherm of een deck dat in drop-frame telde — het gebruikelijke bij 29,97-materiaal, want drop-frame is de conventie die met de wandklok meeloopt — terwijl alles daarna klokken als non-drop leest. Zo gelezen staat elke tijdcode in het bestand te ver voor op het moment dat hij aanwijst, en de fout groeit: de ondertitels vallen vroeg en steeds vroeger naarmate het programma vordert. Na een half uur is de afwijking 1,8 seconden, en ze stopt nergens in het bestand. Daarom is de oplossing geen duwtje: het is dezelfde herlabeling op elke tijdstempel, met de grootte van de correctie bepaald door waar het blok staat.
Een klok als tijdcode lezen betekent hem op de dichtstbijzijnde tik van het 30 fps-framerooster leggen, en in drop-frame bestaan twee van die tikken niet. Drop-frame slaat aan het begin van elke minuut de labels ;00 en ;01 over, behalve elke tiende minuut — het telt 00:00:59;28, 00:00:59;29 en springt dan naar 00:01:00;02 — dus een binnenkomende 00:01:00,000 noemt een moment dat die conventie niet kan schrijven. Hij wordt teruggetrokken naar het laatste label dat wel kan, 00:00:59,933, 67 milliseconden eerder. Dat is een echte grens van de rekenkunde, geen tolerantie, en de pagina zegt het in plaats van het weg te poetsen: over twee uur zijn het er 216.
Een blok dat na die snapping korter wordt dan één frame kan helemaal niet worden geschreven, want zijn twee randen landen op dezelfde tik en een blok waarvan het einde gelijk is aan het begin is geen blok. Zulke blokken worden weggegooid en in het verliesoverzicht boven de werkruimte geteld, niet stilletjes tot een frame uitgerekt. In de praktijk raakt dit alleen materiaal dat frame voor frame is geknipt, maar de pagina rekent er niet op dat dit zeldzaam is — ze meldt het aantal, en een bestand zonder zulke blokken meldt niets.
Er wordt niets geüpload. Het bestand wordt in de browsertab gelezen en opnieuw geschreven en verlaat de machine nooit. Dat is om dezelfde reden belangrijk als op elke andere pagina hier: materiaal met een geheimhoudingsplicht kan niet aan een conversiedienst worden gegeven, en deze pagina vraagt er ook niet om.
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:04:59,667 --> 00:05:01,667
The room is dark.
2
00:09:59,400 --> 00:10:02,400
A cold night.
De correctie is niet één getal voor het hele bestand: na vijf minuten gaat de klok 333 ms terug en na tien minuten 600 ms, omdat drop-frame bij het eerste blok tien labels heeft overgeslagen en bij het tweede achttien. Elk blok houdt zijn lengte tot op de milliseconde, want beide randen schuiven even ver — dit is herlabelen, geen verschuiving.
Dezelfde correctie na een uur
Invoer
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Uitvoer
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Na een uur is drop-frame’s 01:00:03,600 wat non-drop 01:00:00,000 noemt — 108 overgeslagen labels, 3600 ms. Dit is het getal waarmee je de pagina kunt controleren: de eerste regel van de uitvoer hoort precies 3600 ms vroeger te zijn dan de eerste regel van de invoer, en een bestand dat van een drop-frame-deck komt hoort op het ronde uur uit te komen.
Een blok binnen de eerste minuut
Invoer
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Uitvoer
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:04:59,667 --> 00:05:01,667
This one does move.
Tijdens de eerste minuut van een uur wordt geen label overgeslagen, dus spellen beide conventies die zestig seconden identiek en blijft het eerste blok ongemoeid. Het tweede blok, op vijf minuten, beweegt wel. Eén blok ongewijzigd naast één blok verschoven is voor dit bestand de juiste uitvoer en geen vastgelopen run — de correctie is nul bovenaan een uur en groeit vanaf de eerste minuutgrens.
Veelgestelde vragen
Waarom komen de ondertitels vroeger uit in plaats van later?
Omdat de klokken in het bestand groter waren dan de momenten die ze aanwijzen. Non-drop telt dertig labels per seconde alsof 29,97 fps dertig frames per seconde levert, en loopt daardoor langzaam voor op de echte tijd; drop-frame slaat twee labels per minuut over om daarbij te blijven. Een klok die van een drop-frame-deck is gelezen en daarna als non-drop wordt geïnterpreteerd, wijst dus voorbij het juiste punt, en de correctie trekt dat overschot eraf: 333 ms na vijf minuten, 3600 ms na een uur, 36000 ms na tien uur. Binnen de eerste minuut van een uur is het bedrag nul, dus de kleinste correctie die de pagina ooit toepast is die op de eerste minuutgrens, en geen enkele klok wordt onder 00:00:00 geduwd.
Wat gebeurt er met een drop-frame-tijdcode die niet te schrijven is?
Hij wordt teruggetrokken naar het laatste label dat wel kan. Elke minuut waarin drop-frame labels overslaat mist zijn ;00 en ;01, dus 00:01:00,000 en 00:01:00,010 zijn geen klokken die die conventie kan tonen: ze landen op 00:00:59,933, 67 milliseconden eerder. Dit is de enige plek op deze pagina waar de uitvoer geen exacte herlabeling is, en ze is begrensd — twee labels per minuut met een sprong, 216 waarden over twee uur — dus noemt de pagina het hier in plaats van je het in de diff te laten vinden.
Kan er een blok uit mijn bestand verdwijnen?
Alleen een blok dat korter is dan één frame, 33,37 ms. Twee dingen kunnen een blok op één frame leggen: de snapping hierboven, waarbij een blok van tien milliseconden zoals 00:01:00,000 tot 00:01:00,010 beide randen naar 00:00:59,933 trekt, en een blok dat bij aankomst al korter dan een frame was. Een blok waarvan begin en einde hetzelfde moment zijn kan niet worden weggeschreven, dus wordt het weggegooid en verschijnt het aantal in het verliesoverzicht boven de werkruimte. Een bestand zonder zulke blokken meldt niets, en dat is het gebruikelijke geval.
Verandert er buiten de klokwaarden nog iets in het bestand?
Nee. Cuenummers, hun volgorde, de tekst van elke regel, de harde regeleinden binnen een blok en het totale aantal blokken zijn die van het bestand en blijven zoals ze waren. De pagina schrijft per blok dezelfde twee getallen, opnieuw gelabeld. Ze legt ook nergens vast dat de klokken nu non-drop zijn, omdat geen van de hier gelezen formaten — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON, CSV — een veld heeft dat dat zou kunnen bevatten, en het bestand dat je erin sleepte zei het ook niet.
Welke framerate moet ik in het vak invullen?
Elke snelheid die het beeldmateriaal werkelijk heeft; ze beïnvloedt deze conversie niet. De 30 en 29,97 in de naam van deze pagina zijn de telconventies die op de tijdcodereeks staan, niet de framerate van de video, dus niets hier wordt geschaald door het getal dat je invoert. Het vak is alleen verplicht omdat MicroDVD zijn tijden als framenummers opslaat in plaats van als klokken, en een MicroDVD-bestand lezen is onmogelijk zonder de framerate te kennen.
Krijg ik het originele bestand terug als ik de tegenovergestelde pagina op deze uitvoer loslaat?
Ja, byte voor byte, zolang geen tijdcode in de klasse viel die drop-frame niet kan schrijven. De twee pagina’s zijn dezelfde rekenkunde in tegengestelde richting: deze trekt een groeiend bedrag af, de andere telt het er weer bij op, en de bedragen worden bepaald door de positie van elk blok in plaats van door een vaste verschuiving. De uitzondering is het snapping-geval — 00:01:00,000 dat als 00:00:59,933 uitkwam, komt terug als 00:00:59,933 — en dat is de enige klasse tijdstempels waarvoor het paar geen rondreis is.