Non-drop-frame til drop-frame
Eller lim inn underteksttekst
Innstillinger
30 fps non-drop og 29,97 drop-frame skriver den samme klokken forskjellig, og denne boksen velger hvilken vei filen leses og hvilken vei den skrives tilbake. En tekstblokk én time inn leser 01:00:00,000 under den ene og 01:00:03,600 under den andre — de to er 3,6 sekunder fra hverandre per time, ikke en avrundingsfeil. Sidens tittel navngir én retning, og denne boksen tilbyr bare den, så filen du får, er filen siden handler om. Ingenting ved teksten endres: ingen tekstblokk tidsstyres på nytt mot videoen, ingen bildefrekvens konverteres, og en tekstblokk innenfor det første minuttet av en time kommer tilbake nøyaktig som den gikk inn, fordi ingen bildeetikett hoppes over der.
Hvilken bildefrekvens tidene telles i. På formatsidene er det dette MicroDVD trenger, fordi det lagrer tid som bildenummer. På sidene for bildefrekvens er det frekvensen filen ble tidsstyrt mot — versjonen undertekstene ble laget for — og sidens andre boks tar frekvensen til videoen du skal bruke dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 og 60 er de vanlige. Tar du feil, forskyves hele tidslinjen, og på bildefrekvenssidene forskyves den med et forhold i stedet for et fast beløp.
Denne siden merker hver tidskode i en undertekstfil på nytt fra 30 fps non-drop-frame til 29,97 fps drop-frame. Slipp filen inn, kjør den, og hver tekstblokks start og slutt kommer tilbake skrevet på den andre måten. Ordene, tekstblokknumrene, rekkefølgen og linjeskiftene er filens egne og står nøyaktig som de var.
De to konvensjonene skriver samme klokke ulikt, og en fil må være i den resten av kjeden er i. Drop-frame teller 30 etiketter i sekundet men hopper over to av dem hvert minutt unntatt hvert tiende, som er hvordan den holder seg til veggklokken mens non-drop sakte havner bak den. En time inn er de to 3,6 sekunder fra hverandre: 01:00:00,000 i non-drop er 01:00:03,600 i drop-frame. Det gapet er ikke en avrundingsfeil og blir ikke avrundet bort — det vokser med programmet og når 36 sekunder ved ti timer.
Ingenting i det første minuttet av en time flytter seg, fordi ingen etikett droppes der og begge konvensjonene skriver den strekningen identisk. Det gjelder klokker som allerede sitter på et 30 fps-bildetik — 00:00:02,000 er ett — og en klokke som sitter mellom to tik flyttes til det nærmeste, med opptil 17 millisekunder. Å lese en klokke som en tidskode snapper den alltid til bilderutenettet, overalt i filen; innenfor det første minuttet er snappingen det eneste som flytter noe. Tidene i en undertekstfil kommer vanligvis fra et bilde-nøyaktig verktøy og ligger allerede på nettet, som er hvorfor den strekningen ofte kommer tilbake byte for byte.
Ingen undertekstformat som leses her, har et felt som registrerer hvilken konvensjon en klokke er i — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON og CSV skriver alle bare en tid. Så denne siden endrer tallene, og hvilken konvensjon de betyr, forblir en egenskap ved kjeden din, nøyaktig som før filen kom. Det som ikke står i filen, kan ikke skrives inn i den, og å late som noe annet ville være verre enn å si det.
Dette er ikke en bilderatekonvertering. En fil tidfestet for 25 fps-video blir ikke tidfestet på nytt her, og ingenting strekkes eller klemmes mot en video: tidene beholder avstanden sin, og bare måten de skrives på endres. Trenger du den andre jobben — en undertekstfil der avstanden følger en annen bilderate — har den sin egen side. Ingenting lastes opp heller: filen leses og skrives inne i nettleserfanen, så materiale som ikke kan forlate maskinen, blir på den.
Eksempler
En fil fem minutter inn
Inndata
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 tekstblokkene flytter seg ikke like mye, og det er hele operasjonen: fem minutter inn har drop-frame hoppet over ti etiketter, så klokken leses 333 ms senere; ti minutter inn har den hoppet over atten, så den leses 600 ms senere. Teksten og tekstblokknumrene er filens egne — bare de to klokkeverdiene per tekstblokk skrives om.
Samme fil en time inn
Inndata
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 én time er de to konvensjonene 3,6 sekunder fra hverandre, som er 108 hoppede etiketter. Dette er tallet å sammenligne mot hvis du sjekker siden: les den første linjen i utdataene, og den skal ligge nøyaktig 3600 ms etter den første linjen i inndataene. Begge kantene i tekstblokken flytter seg, så tekstblokken beholder lengden sin.
En tekstblokk innenfor det første minuttet
Inndata
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.
Den første tekstblokken kommer tilbake byte for byte, og den andre flytter seg, i samme kjøring. I løpet av det første minuttet av en time droppes ingen etikett, så begge konvensjonene skriver de seksti sekundene identisk — og 00:00:02,000 sitter allerede på et 30 fps-bildetik, så ingenting ved den endres. En klokke mellom to tik ville blitt dyttet til det nærmeste i stedet, med opptil 17 ms, som er samme snapping som siden bruker overalt i filen. Å se én tekstblokk uendret ved siden av én som flyttet seg, er det forventede resultatet her, ikke en halvferdig kjøring.
Ofte stilte spørsmål
Hva er forskjellen mellom drop-frame og non-drop-frame-tidskode?
Begge teller 30 etiketter i sekundet, men 29,97 fps leverer ikke 30 bilder i sekundet — den leverer omtrent 29,97, så en klokke som teller 30 etiketter i sekundet, taper sakte terreng mot virkelig tid. Drop-frame retter det ved å hoppe over to etiketter i starten av hvert minutt unntatt hvert tiende minutt: etikettene kastes selv om bildene ikke gjør det. Non-drop beholder hver etikett og driver. Skrevet ned ser de to like ut; lest mot samme bilde er de 3,6 sekunder fra hverandre etter en time og lenger fra hverandre jo lenger programmet varer.
Hvorfor kommer en tekstblokk en time inn 3,6 sekunder senere ut enn den kom inn?
Fordi 3,6 sekunder er hva en time med hoppede etiketter blir: 2 etiketter i minuttet i 54 minutter av hver 60, til 33,37 ms per etikett, som er 108 etiketter eller 3600 ms i timen. Siden legger ikke til en forsinkelse — den skriver de samme bildene under den andre konvensjonen, og den andre konvensjonen leses senere på det punktet i programmet. En tekstblokk på 01:00:00,000 går inn, og 01:00:03,600 kommer ut; begge kantene flytter seg, så tekstblokken beholder lengden til millisekundet.
Hvorfor kom det første minuttet av filen min tilbake uendret?
Fordi ingen etikett droppes i løpet av det første minuttet av en time, så drop-frame og non-drop-frame skriver den strekningen identisk — 00:00:02,000 betyr 60 bilder under begge, og 60 bilder skrives likt uansett. Driften starter ved den første minuttgrensen og vokser så. Én annen ting kan flytte en tid i den strekningen: å lese en klokke som en tidskode snapper den til nærmeste 30 fps-bildetik, så en verdi mellom to tik, som 00:00:02,010, kommer tilbake som 00:00:02,000. Tider kopiert fra et bilde-nøyaktig verktøy ligger allerede på nettet og flytter seg ikke i det hele tatt.
Hvilken retning trenger jeg — non-drop til drop-frame, eller motsatt?
Det avhenger av hva tidskodene i filen din ble lest av fra. Tok du tidene fra en avspiller eller et redigeringsprogram satt til non-drop, og kjeden du leverer inn i, arbeider i drop-frame, er dette siden. Ble filen din stemplet mot en drop-frame-skjerm og verktøyet nedstrøms forventer non-drop, vil du ha den andre siden, som flytter klokkene motsatt vei med de samme 3,6 sekundene i timen. En rask måte å skille dem: kjør filen her og sammenlign én tekstblokk — leses utdata-klokken senere enn inndata-klokken, var dette retningen den trengte.
Endrer denne siden bilderaten i undertekstene mine?
Nei. Ingenting skaleres og ingenting strekkes: en tekstblokk som var to sekunder lang, er fortsatt to sekunder lang, og avstanden mellom tekstblokkene er uendret, fordi hver tekstblokk flytter seg et beløp som avhenger av hvor den sitter og ikke av et forhold. En fil tidfestet for 25 fps-video blir heller ikke konvertert til 29,97 her — boksen som tar en bilderate, finnes fordi MicroDVD lagrer tidene som bildenumre og ikke kan leses uten en. Å konvertere avstanden i en fil fra én bilderate til en annen er en annen operasjon med sin egen side.
Sier filen noe steds at tidskodene nå er drop-frame?
Nei, og ingen format som leses her, kunne gjøre det: SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON og CSV lagrer alle en tid og ingenting om hvordan den ble talt. Det var allerede sant for filen du slapp inn. Så siden endrer tallene, og hvilken konvensjon de betyr, forblir det kjeden din sier den er — samme ordning du hadde før, nå med tallene som passer til den. Har et verktøy nedstrøms sin egen drop-frame-innstilling, er det innstillingen som leser disse verdiene.