Drop-frame til non-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 29,97 fps drop-frame tilbake til 30 fps non-drop-frame, så hver klokke teller ned med et fast beløp som vokser med programmet: ingenting innenfor det første minuttet av en time, 3,6 sekunder en time inn, 36 sekunder etter ti timer. Ordene, tekstblokknumrene, rekkefølgen og linjeskiftene er filens egne og kommer ut urørt.
Filen denne siden er for, ble stemplet mot en skjerm eller en spiller som telte i drop-frame — som er det vanlige på 29,97-materiale, fordi drop-frame er konvensjonen som holder seg til veggklokken — og alt nedstrøms for den leser klokker som non-drop. Lest slik er hver tidskode i filen for stor med et beløp som bare vokser, så undertekstene lander for tidlig, og senere og senere utover i programmet. En halvtime inn er feilen 1,8 sekunder, og den slutter ikke å vokse noe sted i filen. Derfor er rettelsen ikke et dytt: det er samme ommerking brukt på hvert tidsstempel, med rettelsens størrelse satt av hvor tekstblokken sitter.
Å lese en klokke som en tidskode betyr å snappe den til nærmeste 30 fps-bildetik, og i drop-frame finnes to av de tikene ikke. Drop-frame hopper over etikettene ;00 og ;01 i starten av hvert minutt unntatt hvert tiende minutt — den teller 00:00:59;28, 00:00:59;29 og hopper så til 00:01:00;02 — så en innkommende 00:01:00,000 navngir et øyeblikk den konvensjonen ikke kan skrive. Den trekkes tilbake til den siste etiketten den kan skrive, 00:00:59,933, 67 millisekunder tidligere. Det er en reell grense i aritmetikken og ikke en toleranse, og den står på siden i stedet for å glattes over: over to timer er det 216 av dem.
En tekstblokk som ender opp kortere enn ett bilde etter snappingen, kan ikke skrives i det hele tatt, fordi de to kantene lander på samme tik og en tekstblokk der slutten er lik starten, ikke er en tekstblokk. De droppes og telles i taprapporten over i stedet for stille å strekkes til ett bilde. I praksis rammer dette bare materiale klippet bilde for bilde, men siden stoler ikke på at det er sjeldent — den rapporterer tallet, og en fil uten slike tekstblokker rapporterer ingenting.
Ingenting lastes opp. Filen leses og skrives på nytt inne i nettleserfanen og forlater aldri maskinen, som betyr noe av samme grunn som på alle andre sider her: materiale under taushetsplikt kan ikke overlates til en konverteringstjeneste, og denne ber ikke om det.
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:04:59,667 --> 00:05:01,667
The room is dark.
2
00:09:59,400 --> 00:10:02,400
A cold night.
Rettelsen er ikke ett tall brukt på hele filen: fem minutter inn flytter klokken seg 333 ms tilbake, og ti minutter inn flytter den seg 600 ms tilbake, fordi drop-frame har kastet ti etiketter ved den første tekstblokken og atten ved den andre. Hver tekstblokk beholder lengden sin til millisekundet, siden begge kantene flytter seg like mye — dette er en ommerking og ikke en forskyvning.
Samme rettelse ved én time
Inndata
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Resultat
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
En time inn er det drop-frame kaller 01:00:03,600 det non-drop kaller 01:00:00,000 — 108 hoppede etiketter, 3600 ms. Dette er tallet å sjekke siden mot: den første linjen i utdataene skal ligge nøyaktig 3600 ms før den første linjen i inndataene, og en fil som kom fra en drop-frame-spiller, skal lande på den runde timen.
En tekstblokk innenfor det første minuttet
Inndata
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.
Resultat
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.
I løpet av det første minuttet av en time droppes ingen etikett, så de to konvensjonene skriver de seksti sekundene identisk, og den første tekstblokken får stå. Den andre, ved fem minutter, flytter seg. Én tekstblokk uendret ved siden av én som flyttet seg, er riktig utdata for denne filen og ikke en kjøring som stoppet — rettelsen er null på toppen av en time og vokser fra den første minuttgrensen og utover.
Ofte stilte spørsmål
Hvorfor kommer undertekstene tidligere ut i stedet for senere?
Fordi filens klokker var større enn øyeblikkene de navngir. Non-drop-frame teller 30 etiketter i sekundet som om 29,97 fps leverte 30 bilder i sekundet, så den løper sakte foran virkelig tid; drop-frame hopper over to etiketter i minuttet for å holde seg til den. En klokke lest av fra en drop-frame-spiller og så tolket som non-drop, peker derfor forbi der den skulle, og rettelsen trekker fra det overskuddet: 333 ms ved fem minutter, 3600 ms ved en time, 36000 ms ved ti timer. Beløpet er null for hver klokke innenfor det første minuttet av en time, så den minste rettelsen siden noen gang bruker, er den ved den første minuttgrensen, og ingen klokke skyves under 00:00:00.
Hva skjer med en drop-frame-tidskode som ikke kan skrives?
Den trekkes tilbake til den siste etiketten som kan skrives. Hvert droppende minutt i drop-frame mangler etikettene ;00 og ;01, så 00:01:00,000 og 00:01:00,010 er ikke klokker den konvensjonen kan vise: de lander på 00:00:59,933, 67 millisekunder tidligere. Dette er det ene stedet på siden der utdataene ikke er en nøyaktig ommerking, og det er avgrenset — to etiketter per droppende minutt, 216 verdier over to timer — så siden navngir det her i stedet for å la deg finne det i differansen.
Kan en tekstblokk forsvinne fra filen min?
Bare en tekstblokk kortere enn ett bilde, 33,37 ms. To ting kan presse en tekstblokk ned på ett enkelt bilde: snappingen beskrevet over, der en tekstblokk på ti millisekunder som 00:01:00,000 til 00:01:00,010 får begge kantene trukket til 00:00:59,933, og en tekstblokk som allerede var under ett bilde da den kom. En tekstblokk der start og slutt er samme øyeblikk, kan ikke skrives ut, så den droppes, og tallet vises i taprapporten over arbeidsområdet. En fil uten slike rapporterer ingenting, som er det vanlige tilfellet.
Endres noe annet enn klokkeverdiene i filen?
Nei. Tekstblokknumre, rekkefølgen deres, teksten på hver linje, harde linjeskift inne i en tekstblokk og det totale antallet tekstblokker er filens egne og står som de var. Siden skriver de samme to tallene per tekstblokk, merket på nytt. Den registrerer heller ingen steder at klokkene nå er non-drop, fordi ingen av formatene som leses her — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON, CSV — har et felt som kan holde det, og filen du slapp inn, sa det heller ikke.
Hvilken bilderate skal jeg legge i boksen?
Enhver rate materialet faktisk har; den påvirker ikke denne konverteringen. 30 og 29,97 i sidens navn er tellekonvensjonene skrevet på tidskodestrengen, ikke bilderaten i videoen, så ingenting her skaleres av tallet du oppgir. Boksen kreves bare fordi MicroDVD lagrer tider som bildenumre og ikke som klokker, og å lese en MicroDVD-fil er umulig uten å kjenne bilderaten.
Får jeg originalfilen tilbake hvis jeg kjører motsatt side på disse utdataene?
Ja, byte for byte, så lenge ingen tidskode falt i klassen drop-frame ikke kan skrive. De to sidene er samme aritmetikk lest i motsatte retninger: denne trekker fra et voksende beløp, den andre legger det tilbake, og beløpene settes av posisjonen til hver tekstblokk og ikke av en fast forskyvning. Unntaket er snappings-tilfellet — 00:01:00,000 som kom ut som 00:00:59,933, kommer tilbake som 00:00:59,933 — og det er den eneste klassen tidsstempler der paret ikke er en runde.