Snäpp undertexter till bilder
Eller klistra in undertexttext
Inställningar
Varje tidsgräns för ett textblock flyttas till närmaste bildruta vid den här frekvensen, så vid 25 fps blir 00:00:02,010 till 00:00:02,000 och 00:00:02,030 blir 00:00:02,040. En gräns exakt mitt emellan två bildrutor avrundas uppåt, så 00:00:02,020 blir 00:00:02,040. Inget skalas: tidslinjen behåller sin längd och gränserna landar bara på bildrutor, så varje textblocks längd kan ändras med upp till en halv bildruta åt endera hållet. Det här är inte filens deklarerade bildfrekvens – den avgör bara var gränserna hamnar i resultatet.
Vilken bildfrekvens tiderna räknas i. På formatsidorna är det här vad MicroDVD behöver, eftersom formatet lagrar tider som bildnummer. På bildfrekvenssidorna är det den frekvens som filens tider byggdes för – den version som undertexterna gjordes för – och sidans andra fält tar frekvensen för den video du ska använda dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 och 60 är de vanligaste. Blir det fel förskjuts hela tidslinjen, och på bildfrekvenssidorna förskjuts den med ett förhållande i stället för med ett fast belopp.
Den här sidan snäpper varje tidsgräns i en undertextfil till närmaste bildruta. Ange bildfrekvensen – 25 fps är standard – och varje start- och sluttid flyttas till den bild som ligger närmast. Vid 25 fps hamnar gränserna på multiplar av 40 ms, så 02,020 blir 02,040, 04,030 blir 04,040 och 07,010 blir 07,000. Inget skalas: varje gräns flyttas för sig, och ett block kan därför bli en aning längre eller kortare.
Poängen är att en spelare och en redigerare arbetar i bilder, inte i millisekunder. En undertext som börjar mitt i en bild kan hamna på olika rutor i olika spelare, och i en professionell kedja där undertexter kontrolleras bild för bild är en tid som inte ligger på en bild helt enkelt inte en tid. Efter snäppningen går varje gräns att peka ut på tidslinjen utan att avrunda.
Vid en bildfrekvens som inte går jämnt upp i millisekunder kan ingen rund sekund vara en bildgräns. Vid 23,976 fps flyttas därför båda kanterna på ett block som var exakt två sekunder långt, och resultatet blir 2 002 ms. Det är inte ett fel utan själva innebörden av att snäppa: gränserna hamnar på bilder, men de runda tal som filen skrevs med försvinner.
Ett block som är kortare än en bild kan förlora båda sina gränser till samma ruta. Då finns det ingen tid kvar mellan start och slut, och blocket tas bort i stället för att sträckas ut till en bild – att hitta på en längd vore att sätta en undertext på skärmen som filen aldrig bad om. SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON och CSV tas emot, och inget laddas upp.
Exempel
Varje gräns landar på en bild
Indata
1
00:00:02,020 --> 00:00:04,030
Hello there.
2
00:00:07,010 --> 00:00:09,040
Second line.
Resultat
1
00:00:02,040 --> 00:00:04,040
Hello there.
2
00:00:07,000 --> 00:00:09,040
Second line.
Vid 25 bilder i sekunden hör gränserna till multiplar av 40 ms. 02,020 ligger exakt mitt emellan två och avrundas uppåt till 02,040; 04,030 flyttas fram till 04,040; 07,010 flyttas tillbaka till 07,000. Inget skalades – varje gräns flyttades för sig.
Ett block kortare än en bild
Indata
1
00:00:04,000 --> 00:00:04,010
Squeezed.
2
00:00:06,010 --> 00:00:08,010
A normal one.
Resultat
2
00:00:06,000 --> 00:00:08,000
A normal one.
Det 10 ms långa blocket får båda sina gränser avrundade till bild 100, så snäppningen skulle lämna det med samma tid i båda ändar. Det tas bort och räknas i stället för att sträckas ut till en bild. Vid 25 fps krävs ett block kortare än 20 ms för att hamna här.
En bråkdel bildfrekvens kan inte lämna längderna orörda
Indata
1
00:00:01,000 --> 00:00:03,000
Hello there.
Resultat
1
00:00:01,001 --> 00:00:03,003
Hello there.
23,976 bilder i sekunden är inte ett helt antal millisekunder per bild, så ingen rund sekund är en bildgräns och båda kanterna flyttas: ett block som var exakt 2 000 ms blir 2 002 ms. Varje gräns ligger fortfarande på en bild, men de runda talen är borta.
Vanliga frågor
Vad innebär det att snäppa undertexter till bilder?
Att varje start- och sluttid flyttas till den bildruta som ligger närmast, utifrån den bildfrekvens du anger. Vid 25 fps ligger bilderna 40 ms isär, så varje gräns hamnar på en multipel av 40. Gränserna flyttas var för sig, och ett block kan därför ändra längd även om det aldrig skalas.
Varför flyttas båda kanterna på ett tvåsekundersblock vid 23,976 fps?
Därför att 23,976 bilder i sekunden inte ger ett helt antal millisekunder per bild. Ingen rund sekund sammanfaller med en bildgräns, så både starten och slutet måste flyttas för att hamna på en bild. Resultatet blir 2 002 ms i stället för 2 000, vilket är väntat och inte en avrundningsmiss.
Varför tas ett block kortare än en bild bort i stället för att förlängas?
Därför att båda dess gränser avrundas till samma bild, och ett block som slutar där det börjar inte kan visas. Att sträcka ut det till en bild skulle sätta en undertext på skärmen i en längd som filen aldrig bad om. Borttagningen räknas i rapporten, så du ser exakt vilket block som försvann.
Vilken bildfrekvens ska jag välja när jag snäpper undertexter?
Samma frekvens som videon faktiskt spelas i – 23,976, 24, 25, 29,97 eller 50 – och inte den avrundade etiketten. Vid 25 fps är steget 40 ms, vid 23,976 ungefär 41,7 ms. En felaktig frekvens lägger gränserna på bilder som inte finns i videon, även om varje tid ser rimlig ut för sig.
Ändras texten i undertextfilen när gränserna snäpps?
Nej, bara tidsstämplarna rörs. Varje textblock behåller sin text, sin stil och sitt nummer, och filens ordning är oförändrad. Det enda som kan försvinna är ett block som är kortare än en bild, och det rapporteras. Därför är förhandsvisningen efter snäppningen en bra kontroll av att inget oväntat försvann.