23,976 fps naar 29,97 fps
Of plak ondertiteltekst
Opties
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.
De beeldsnelheid van de versie waarmee je de ondertitels gaat gebruiken — de video die je daadwerkelijk afspeelt. De toegepaste factor is het eerste vak gedeeld door dit vak, dus 24 naar 25 geeft 0,96: een film loopt op PAL 4% sneller, en een speelfilm van 100 minuten past op een band van 96 minuten. Draai je de twee vakken om, dan verschuift de hele tijdlijn met hetzelfde bedrag de verkeerde kant op.
Deze pagina neemt een ondertitelbestand waarvan de tijdas in 23,976 frames per seconde is geteld en zet het op een tijdas van 29,97. Elke tijdstempel wordt met 0,8 vermenigvuldigd — precies vier vijfde — dus het bestand komt een vijfde korter uit: een blok op een minuut wordt er een op achtenveertig seconden, en een aflevering van vierentwintig minuten waarvan de ondertitels dertig minuten beweren, komt terug op vierentwintig. De twee velden zijn al ingevuld; pas ze aan als je bestand in iets anders is geteld.
De fout zit in de berekening die framenummers in seconden omzet. Leest een gereedschap framenummers die bij een 29,97-tijdas horen maar deelt het ze door 23,976, dan is elke seconde die het oplevert een kwart te groot: 29,97 gedeeld door 23,976 is 1,25, dus de hele tijdas rekt een kwart uit en de ondertitels lopen 25 procent te laat, steeds verder achter naarmate de film vordert. Vermenigvuldigen met 0,8 deelt diezelfde fout er weer uit.
Eén ding waar deze pagina niet voor mag worden gebruikt, en het is de makkelijkste fout in de groep. Een film in een NTSC-signaal krijgt 3:2 pulldown: dezelfde beelden worden herhaald om het 29,97-signaal te vullen, en pulldown laat de speelduur precies zoals hij was. Dus „mijn video is 29,97 en heeft pulldown” is geen reden om iets om te zetten: een bestand dat tegen die video is getimed, is al correct, en het met 0,8 vermenigvuldigen haalt er een vijfde af. Deze pagina is voor een bestand waarvan de framenummers tegen de verkeerde snelheid zijn geteld, niet voor een bestand dat toevallig in een 29,97-container zit.
Wat dit paar prettig maakt om mee te werken, is dat 0,8 exact is. Beide snelheden horen bij de NTSC-familie en beide dragen dezelfde deling door 1001, dus de 1001 valt weg en 23,976 gedeeld door 29,97 is simpelweg 24000 gedeeld door 30000 — vier vijfde, niets afgerond en niets over. Elk blok krijgt een vijfde minder schermtijd, wat de leessnelheid van elke regel met 25 procent verhoogt. Niets wordt geüpload, en een heel seizoen gaat in één keer door de wachtrij — SRT-, WebVTT-, ASS-, SSA-, SBV-, SAMI-, MicroDVD-, TTML-, JSON- en CSV-bestanden worden gelezen als wat ze werkelijk zijn in plaats van wat de extensie suggereert.
Voorbeelden
Een kort blok en een lang blok
Invoer
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:01:00,000 --> 00:01:02,000
One minute in.
Uitvoer
1
00:00:00,800 --> 00:00:02,400
Hello there.
2
00:00:48,000 --> 00:00:49,600
One minute in.
0,8 is 23,976 gedeeld door 29,97. Het blok op één seconde verliest 200 ms en dat op een minuut verliest 12.000 ms — zestig keer de afstand tot nul, zestig keer de beweging. Beide randen van elk blok worden vermenigvuldigd, dus een regel van twee seconden krijgt 1,6 seconde, en uit die verkorting komt de stijging van de leessnelheid.
De latheid groeit met de klok
Invoer
1
00:10:00,000 --> 00:10:02,000
Ten minutes in.
2
00:30:00,000 --> 00:30:02,000
Half an hour in.
Uitvoer
1
00:08:00,000 --> 00:08:01,600
Ten minutes in.
2
00:24:00,000 --> 00:24:01,600
Half an hour in.
Twee minuten te laat op de tien-minuutmarkering en zes minuten te laat op het half uur — in beide gevallen een kwart van de verstreken tijd, en zo ziet een verhoudingsprobleem eruit. Een vaste verschuiving kan dat nooit oplossen, een verhouding wel. De controle na het omzetten is aan het einde van het bestand: open het op de nieuwe tijdstempel van het laatste blok en de regel hoort er te staan.
Een MicroDVD-bestand verandert alleen zijn declaratieregel
Invoer
{1}{1}23.976
{240}{288}Hello
Uitvoer
{1}{1}29.97
{240}{288}Hello
MicroDVD slaat timing op als framenummers, en de frames waren niet fout — de snelheid waardoor ze werden gedeeld was dat. Frame 240 op 23,976 leest als tien seconden, dat is de latheid waarover geklaagd wordt; op 29,97 leest het als acht, en daar hoort dat blok. Dus wordt de eerste regel van het bestand aangepast en geen enkel framenummer aangeraakt: ze herschrijven zou de 25 procent twee keer toepassen.
Veelgestelde vragen
Waarom is de factor voor 23,976 naar 29,97 precies 0,8?
Omdat beide snelheden NTSC-snelheden zijn en beide een rond getal gedeeld door 1001: 23,976 is 24000/1001 en 29,97 is 30000/1001. De een door de ander delen schrapt de 1001 aan beide kanten en laat 24000 boven 30000 over, dat is vier vijfde. Er wordt hier dus niets afgerond en niets benaderd — het blok op een minuut landt op precies achtenveertig seconden.
Lost dit een film op waarop 3:2 pulldown is toegepast?
Nee, en dat is de val waar deze pagina een naam aan geeft. Pulldown vult een 29,97-signaal met herhaalde frames en laat de speelduur precies zoals hij was, dus een ondertitelbestand dat tegen de gepulldownde video is getimed, is al goed — het omzetten haalt een vijfde van de tijdas af en maakt een correct bestand fout. De pagina is voor timings die zijn gemaakt door framenummers door 23,976 te delen terwijl de frames bij een 29,97-tijdas hoorden.
Mijn ondertitels lopen een kwart van de tijd achter en steeds verder — is dit het paar?
Controleer of de latheid een kwart van de verstreken tijd is. Twee minuten te laat op de tien-minuutmarkering, zes op het half uur, en een half uur te laat in een film van twee uur is precies dit paar. De verwanten in deze groep zijn makkelijk uit elkaar te houden aan hun grootte: 0,95904 is een fout van 4 procent, 1,0427094 is 4,271 procent, en een factor twee verdubbelt de lengte van het bestand.
Kan ik 24 en 30 in de velden zetten in plaats van 23,976 en 29,97?
Voor dit paar wel, en het resultaat is identiek — 24 gedeeld door 30 is vier vijfde, hetzelfde als 23,976 boven 29,97, omdat de gedeelde deling door 1001 in beide gevallen wegvalt. Dat is een eigenschap van dit paar en niet van de groep: op de film-naar-PAL-pagina laat 24 en 25 gebruiken waar het bestand echt 23,976 was een fout van 3,5 seconde per uur achter.
Elk blok krijgt een vijfde minder tijd — breekt dat de leessnelheidslimieten?
Het is de moeite waard te controleren, want de woorden worden niet korter om dat te compenseren: een regel die ruim binnen een limiet voor tekens per seconde zat, kan er door een stijging van 25 procent overheen worden geduwd. De toegankelijkheidspagina’s op deze site meten leessnelheid tegen de drempels die de normen stellen, en dat is het getal om naar te kijken in plaats van naar een gevoel dat de ondertitels nu gehaast lijken.
Moet ik dit paar gebruiken om filmondertitels op een NTSC-dvd te zetten?
Nee. Een film op een NTSC-schijf staat op 23,976 en de speler past bij het afspelen pulldown toe, dus een bestand dat tegen de film is getimed hoeft helemaal niet te veranderen en 0,8 zou het verpesten. Is je bestand getimed tegen een PAL-kopie van die film en ga je terug naar de schijf, dan is het paar 25 naar 23,976 en de factor 1,0427094 — een kleine correctie in de andere richting.