Timecode drop-frame na non-drop
Albo wklej tekst napisów
Opcje
30 fps non-drop i 29.97 drop-frame zapisują ten sam zegar inaczej, a to pole wybiera, w którą stronę plik jest czytany i w którą zapisywany z powrotem. Blok leżący godzinę od początku ma 01:00:00,000 w jednym i 01:00:03,600 w drugim — te dwa różnią się o 3,6 sekundy na godzinę, a nie o błąd zaokrąglenia. Tytuł strony nazywa jeden kierunek, a to pole oferuje tylko ten jeden, więc plik, który dostajesz, jest tym, o czym jest strona. W tekście nic się nie zmienia: żaden blok nie jest przeliczany względem wideo, żadna liczba klatek nie jest konwertowana, a blok w pierwszej minucie godziny wraca dokładnie taki, jaki przyszedł, bo tam żadna etykieta klatki nie jest pomijana.
W jakiej liczbie klatek na sekundę liczone są czasy. Na stronach formatów tego wymaga MicroDVD, bo zapisuje czasy jako numery klatek. Na stronach poświęconych liczbie klatek jest to stawka, według której zgrany był plik — wersja, dla której powstały napisy — a drugie pole na stronie przyjmuje liczbę klatek wideo, z którym napisy będą używane. Najczęstsze wartości to 23,976, 24, 25, 29,97, 30, 50, 59,94 i 60. Pomyłka przesuwa całą oś czasu, a na stronach poświęconych liczbie klatek przesuwa ją o współczynnik, a nie o stałą wartość.
Ta strona przepisuje każdy timecode w pliku napisów z konwencji drop frame 29,97 na non-drop 30 fps, więc każdy zegar cofa się o stałą wartość, która rośnie razem z programem: nic w pierwszej minucie godziny, 3,6 sekundy na godzinę, 36 sekund po dziesięciu godzinach. Słowa, numery bloków, kolejność bloków i złamania linii pochodzą z pliku i wychodzą nietknięte.
Plik, dla którego istnieje ta strona, został oznaczony wobec wyświetlacza albo decka liczącego w drop frame — co jest zwykłą rzeczą w materiale 29,97, bo drop frame to konwencja, która trzyma się zegara ściennego — a wszystko za nim czyta zegary jako non-drop. Czytane w ten sposób, każdy timecode w pliku jest za duży o wartość, która stale rośnie, więc napisy lądują za wcześnie i coraz wcześniej w miarę trwania programu. Po pół godzinie błąd wynosi 1,8 sekundy i nie przestaje rosnąć nigdzie w pliku. Dlatego poprawka nie jest szturchnięciem: to to samo przepisanie zastosowane do każdego znacznika, z rozmiarem korekty ustalonym przez to, gdzie blok leży.
Odczytanie zegara jako timecode'u oznacza dociągnięcie go do najbliższego taktu klatki 30 fps, a w drop frame dwa z tych taktów nie istnieją. Drop frame pomija etykiety ;00 i ;01 na początku każdej minuty z wyjątkiem co dziesiątej — liczy 00:00:59;28, 00:00:59;29 i przeskakuje do 00:01:00;02 — więc przychodzące 00:01:00,000 nazywa moment, którego ta konwencja nie umie zapisać. Jest cofane do ostatniej etykiety, którą umie zapisać, 00:00:59,933, czyli 67 milisekund wcześniej. To prawdziwa granica arytmetyki, a nie tolerancja, i jest tu nazwana, zamiast wygładzona: przez dwie godziny jest ich 216.
Blok, który po dociągnięciu staje się krótszy niż jedna klatka, nie może zostać zapisany, bo jego oba brzegi lądują na tym samym takcie, a blok, którego koniec równa się początkowi, nie jest blokiem. Takie bloki są odrzucane i liczone w raporcie strat powyżej, zamiast po cichu rozciągane do klatki. W praktyce dotyczy to tylko materiału ciętego klatka po klatce, ale strona nie zakłada, że to rzadkie — raportuje liczbę, a plik bez takich bloków nie raportuje niczego.
Nic nie jest wysyłane. Plik jest czytany i zapisywany w karcie przeglądarki i nigdy nie opuszcza maszyny, co ma znaczenie z tego samego powodu co na każdej innej stronie tutaj: materiał objęty obowiązkiem poufności nie może trafić do usługi konwersji, a ta strona o nic nie prosi.
Przykłady
Plik pięć minut w środku
Wejście
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.
Wynik
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.
Korekta nie jest jedną liczbą zastosowaną do pliku: na piątej minucie zegar cofa się o 333 ms, a na dziesiątej o 600 ms, bo drop frame wyrzucił dziesięć etykiet do pierwszego bloku i osiemnaście do drugiego. Każdy blok zachowuje długość co do milisekundy, ponieważ oba jego brzegi ruszają się o tę samą wartość — to przepisanie, a nie przesunięcie.
Ta sama korekta na godzinie
Wejście
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Wynik
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Na godzinie drop frame'owe 01:00:03,600 to dla non-drop 01:00:00,000 — 108 pominiętych etykiet, 3600 ms. To liczba, wobec której warto sprawdzić stronę: pierwsza linia wyniku powinna być dokładnie 3600 ms wcześniejsza niż pierwsza linia wejścia, a plik zdjęty z decka drop frame powinien wylądować na równej godzinie.
Blok w pierwszej minucie
Wejście
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.
Wynik
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.
W pierwszej minucie godziny nie pomija się żadnej etykiety, więc obie konwencje zapisują te sześćdziesiąt sekund identycznie i pierwszy blok zostaje nietknięty. Drugi blok, na piątej minucie, rusza się. Jeden blok bez zmian obok jednego przesuniętego to poprawny wynik dla tego pliku, a nie zatrzymany przebieg — korekta wynosi zero na początku godziny i rośnie od pierwszej granicy minuty.
Częste pytania
Dlaczego napisy wychodzą wcześniej, a nie później?
Bo zegary w pliku były większe niż momenty, które nazywają. Non-drop liczy 30 etykiet na sekundę tak, jakby 29,97 fps dostarczało 30 klatek na sekundę, więc powoli wyprzedza rzeczywisty czas; drop frame pomija dwie etykiety na minutę, żeby się go trzymać. Zegar odczytany z decka drop frame i zinterpretowany jako non-drop wskazuje więc dalej, niż powinien, a poprawka odejmuje ten nadmiar: 333 ms na piątej minucie, 3600 ms na godzinie, 36 000 ms po dziesięciu godzinach. Wartość wynosi zero dla każdego zegara w pierwszej minucie godziny, więc najmniejsza korekta, jaką strona kiedykolwiek stosuje, to ta na pierwszej granicy minuty, i żaden zegar nie schodzi poniżej 00:00:00.
Co dzieje się z timecode'em drop frame, którego nie da się zapisać?
Jest cofany do ostatniej etykiety, którą da się zapisać. Każda pomijająca minuta w drop frame nie ma swoich etykiet ;00 i ;01, więc 00:01:00,000 i 00:01:00,010 to nie zegary, które ta konwencja potrafi wyświetlić: lądują na 00:00:59,933, czyli 67 milisekund wcześniej. To jedyne miejsce na tej stronie, w którym wynik nie jest dokładnym przepisaniem, i jest ograniczone — dwie etykiety na pomijającą minutę, 216 wartości przez dwie godziny — więc strona je tu nazywa, zamiast zostawiać Ci szukanie go w diffie.
Czy blok może zniknąć z mojego pliku?
Tylko blok krótszy niż jedna klatka, 33,37 ms. Dwie rzeczy mogą wepchnąć blok na pojedynczą klatkę: opisane wyżej dociągnięcie, gdzie dziesięciomilisekundowy blok od 00:01:00,000 do 00:01:00,010 ma oba brzegi ściągnięte do 00:00:59,933, oraz blok, który był krótszy niż klatka już na wejściu. Blok, którego początek i koniec to ten sam moment, nie może zostać zapisany, więc jest odrzucany, a jego liczba pojawia się w raporcie strat nad obszarem roboczym. Plik bez takich bloków nie raportuje niczego, co jest zwykłym przypadkiem.
Czy poza wartościami zegarów zmienia się coś w pliku?
Nie. Numery bloków, ich kolejność, tekst każdej linii, twarde złamania linii wewnątrz bloku i całkowita liczba bloków pochodzą z pliku i zostają takie, jakie były. Strona zapisuje te same dwie liczby na blok, tylko przepisane. Nie zapisuje też nigdzie, że zegary są teraz non-drop, bo żaden z czytanych tu formatów — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON, CSV — nie ma pola, które mogłoby to pomieścić, a plik, który wrzuciłeś, też tego nie mówił.
Jaką liczbę klatek wpisać w polu?
Taką, jaką materiał naprawdę ma; nie wpływa na to przeliczenie. 30 i 29,97 w nazwie tej strony to konwencje liczenia zapisane w łańcuchu timecode'u, a nie liczba klatek wideo, więc nic tutaj nie jest skalowane przez wpisaną liczbę. Pole jest wymagane tylko dlatego, że MicroDVD przechowuje czasy jako numery klatek, a odczytanie pliku MicroDVD jest niemożliwe bez znajomości jego liczby klatek.
Czy uruchomienie przeciwnej strony na tym wyniku zwróci mi oryginalny plik?
Tak, co do bajtu, o ile żaden timecode nie wpadł w klasę, której drop frame nie umie zapisać. Obie strony to ta sama arytmetyka czytana w przeciwnych kierunkach: ta odejmuje rosnącą wartość, tamta dodaje ją z powrotem, a wartości są ustalane przez położenie każdego bloku, a nie przez stały offset. Wyjątkiem jest przypadek dociągania — 00:01:00,000, które wyszło jako 00:00:59,933, wraca jako 00:00:59,933 — i to jedyna klasa znaczników, dla której ta para nie jest pełnym obiegiem.