Timecode non-drop na drop-frame
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 non-drop 30 fps na drop frame 29,97. Wrzuć plik, uruchom, a początek i koniec każdego bloku wrócą zapisane w drugi sposób. Słowa, numery bloków, kolejność bloków i złamania linii pochodzą z pliku i zostają dokładnie takie, jakie były.
Obie konwencje zapisują ten sam zegar inaczej, a plik musi być w tej, w której jest reszta procesu. Drop frame liczy 30 etykiet na sekundę, ale pomija dwie z nich co minutę z wyjątkiem co dziesiątej, i tak trzyma się zegara ściennego, podczas gdy non-drop powoli zostaje z tyłu. Na godzinie obie różnią się o 3,6 sekundy: 01:00:00,000 w non-drop to 01:00:03,600 w drop frame. Ta różnica nie jest błędem zaokrąglenia i nie znika przez zaokrąglenie — rośnie razem z programem, osiągając 36 sekund po dziesięciu godzinach.
W pierwszej minucie godziny nic się nie rusza, bo nie pomija się tam żadnej etykiety i obie konwencje zapisują ten odcinek identycznie. Dotyczy to zegarów, które już siedzą na takcie klatki 30 fps — 00:00:02,000 jest jednym z nich — a zegar, który leży między dwoma taktami, jest przesuwany do najbliższego, o maksymalnie 17 milisekund. Odczytanie zegara jako timecode'u zawsze dociąga go do siatki klatek w całym pliku; w pierwszej minucie to dociągnięcie jest jedyną rzeczą, która się rusza. Czasy w pliku napisów zwykle pochodzą z narzędzia dokładnego do klatki i już leżą na siatce, dlatego ten odcinek często wraca co do bajtu.
Żaden z czytanych tu formatów napisów nie ma pola, które zapisuje, w jakiej konwencji jest zegar — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON i CSV po prostu zapisują czas. Ta strona zmienia więc liczby, a to, którą konwencję znaczą, pozostaje właściwością Twojego procesu, dokładnie tak jak przed przybyciem pliku. Tego, czego nie ma w pliku, nie da się w nim zapisać, a udawanie, że jest inaczej, byłoby gorsze niż powiedzenie tego wprost.
To nie jest przeliczenie liczby klatek. Plik ustawiony do wideo 25 fps nie jest tu przestawiany i nic nie jest rozciągane ani ściskane wobec wideo: czasy zachowują odstępy, a zmienia się tylko sposób ich zapisu. Jeśli potrzebujesz drugiej roboty — pliku napisów, którego odstępy idą za inną liczbą klatek — ma ona własną stronę. Nic nie jest też wysyłane: plik jest czytany i zapisywany w karcie przeglądarki, więc materiał, który nie może opuścić maszyny, zostaje na niej.
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:05:00,333 --> 00:05:02,333
The room is dark.
2
00:10:00,600 --> 00:10:03,600
A cold night.
Dwa bloki nie ruszają się o tę samą wartość i to jest cała operacja: na piątej minucie drop frame pominął dziesięć etykiet, więc zegar czyta się o 333 ms później; na dziesiątej pominął osiemnaście, więc czyta się o 600 ms później. Tekst i numery bloków pochodzą z pliku — przepisywane są tylko dwie wartości zegara na blok.
Ten sam plik na godzinie
Wejście
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Wynik
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Na godzinie obie konwencje różnią się o 3,6 sekundy, czyli 108 pominiętych etykiet. To liczba, wobec której warto porównać, jeśli sprawdzasz stronę: pierwsza linia wyniku powinna być dokładnie 3600 ms późniejsza niż pierwsza linia wejścia. Oba brzegi bloku się ruszają, więc blok zachowuje swoją długość.
Blok w pierwszej minucie
Wejście
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.
Wynik
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.
Pierwszy blok wraca co do bajtu, a drugi się rusza, w tym samym przebiegu. W pierwszej minucie godziny nie pomija się żadnej etykiety, więc obie konwencje zapisują te sześćdziesiąt sekund identycznie — a 00:00:02,000 już leży na takcie klatki 30 fps, więc nic w nim się nie zmienia. Zegar leżący między dwoma taktami byłby zamiast tego dociągnięty do najbliższego, o maksymalnie 17 ms, i to jest to samo dociągnięcie, które strona stosuje w całym pliku. Widok jednego bloku bez zmian obok jednego przesuniętego to tutaj oczekiwany wynik, a nie przerwany przebieg.
Częste pytania
Jaka jest różnica między timecode'em drop frame a non-drop?
Obie liczą 30 etykiet na sekundę, ale 29,97 fps nie dostarcza 30 klatek na sekundę — dostarcza około 29,97, więc zegar liczący 30 etykiet na sekundę powoli traci grunt wobec rzeczywistego czasu. Drop frame naprawia to, pomijając dwie etykiety na początku każdej minuty z wyjątkiem co dziesiątej: etykiety są wyrzucane, choć klatki nie. Non-drop zachowuje każdą etykietę i dryfuje. Zapisane wyglądają jak ten sam rodzaj liczby; odczytane wobec tej samej klatki różnią się o 3,6 sekundy po godzinie i rozjeżdżają się dalej, im dłużej trwa program.
Dlaczego blok na godzinie wychodzi 3,6 sekundy później, niż wszedł?
Bo 3,6 sekundy to suma pominiętych etykiet w ciągu godziny: dwie etykiety na minutę przez 54 minuty z każdych 60, po 33,37 ms na etykietę, czyli 108 etykiet albo 3600 ms na godzinę. Strona nie dodaje opóźnienia — zapisuje te same klatki w drugiej konwencji, a druga konwencja czyta się później w tym punkcie programu. Blok 01:00:00,000 wchodzi, a 01:00:03,600 wychodzi; oba jego brzegi się ruszają, więc blok zachowuje długość co do milisekundy.
Dlaczego pierwsza minuta mojego pliku wróciła bez zmian?
Bo w pierwszej minucie godziny nie pomija się żadnej etykiety, więc drop frame i non-drop zapisują ten odcinek identycznie — 00:00:02,000 znaczy 60 klatek w obu, a 60 klatek zapisuje się tak samo w obie strony. Dryf zaczyna się na pierwszej granicy minuty i potem rośnie. Jest jeszcze jedna rzecz, która może ruszyć czas w tym odcinku: odczytanie zegara jako timecode'u dociąga go do najbliższego taktu klatki 30 fps, więc wartość leżąca między dwoma taktami, na przykład 00:00:02,010, wraca jako 00:00:02,000. Czasy skopiowane z narzędzia dokładnego do klatki już leżą na siatce i nie ruszają się wcale.
Którego kierunku potrzebuję — non-drop na drop frame, czy odwrotnie?
To zależy od tego, z czego odczytano timecode'y w pliku. Jeśli wziąłeś czasy z odtwarzacza albo edytora ustawionego na non-drop, a proces, do którego dostarczasz, pracuje w drop frame, to jest ta strona. Jeśli Twój plik był oznaczony wobec wyświetlacza drop frame, a narzędzie za nim oczekuje non-drop, chcesz drugiej strony, która przesuwa zegary w drugą stronę o te same 3,6 sekundy na godzinę. Szybki sposób ich odróżnienia: uruchom plik tutaj i porównaj jeden blok — jeśli zegar wyniku czyta się później niż wejście, ten kierunek był tym, którego potrzebował.
Czy ta strona zmienia liczbę klatek moich napisów?
Nie. Nic nie jest skalowane ani rozciągane: blok, który miał dwie sekundy, nadal ma dwie sekundy, a odstępy między blokami się nie zmieniają, bo każdy blok rusza się o wartość zależną od tego, gdzie leży, a nie o proporcję. Plik ustawiony do wideo 25 fps też nie jest tu przeliczany na 29,97 — pole na liczbę klatek istnieje, bo MicroDVD przechowuje czasy jako numery klatek i nie da się go odczytać bez niej. Przeliczenie odstępów pliku z jednej liczby klatek na inną to inna operacja, z własną stroną.
Czy plik mówi gdziekolwiek, że jego timecode'y są teraz drop frame?
Nie, i żaden czytany tu format nie mógłby: SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON i CSV przechowują czas i nic o tym, jak został policzony. To było prawdą już o pliku, który wrzuciłeś. Strona zmienia więc liczby, a to, którą konwencję znaczą, pozostaje tym, co mówi Twój proces — ten sam układ, który miałeś wcześniej, teraz z pasującymi do niego liczbami. Jeśli narzędzie za nim ma własne ustawienie drop frame, to to ustawienie czyta te wartości.