Napisy kończące się przed startem
Albo wklej tekst napisów
Opcje
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ść.
Blok, który kończy się przed rozpoczęciem, to znacznik czasu, który nie może być prawdziwy: 00:00:03,000 --> 00:00:03,000, a gorzej — koniec wcześniejszy niż początek. Ta strona zgłasza pliki, które go zawierały, licząc z napraw, jakich musiał dokonać czytnik, bo takiego znacznika nie da się w ogóle utrzymać w pamięci i zanim cokolwiek się stanie, zastępuje go prawdziwym. W odpowiedzi wraca raport, nigdy zmieniony plik.
Dlatego raport zaczyna od tego, co zginęło przy wczytywaniu, a dopiero potem pokazuje znalezisko. Blok, którego koniec nie wypada po początku, dostaje jedną milisekundę, żeby resztę pliku dało się wczytać, pokazać w podglądzie i wyeksportować; liczba tych napraw stoi w nagłówku raportu, a znalezisko pod nim mówi o jednym błędzie bez numeru bloku, bo naprawy są zliczane w trakcie czytania, a nie trzymane na liście. Oba wiersze opisują ten sam zepsuty znacznik z dwóch stron, dlatego należą do jednego raportu, a nie do dwóch.
Pułapka, wokół której trzeba było napisać tę stronę, polega na tym, że prawdziwy jednomilisekundowy blok wygląda dokładnie jak naprawiony. Kontrola nie patrzy więc wcale na czasy trwania — patrzy na zapis napraw — i blok, który naprawdę trwa jedną milisekundę, zostaje w spokoju. Czas ujemny i zerowy to ta sama wada i są liczone razem. Dwa formaty nie są w ogóle przyjmowane i tym razem powód jest po obu stronach ten sam: LRC wylicza koniec z następnego znacznika, więc para nie może tam wyjść na odwrót, a czysty tekst nie ma czasów bloków. Sprawdzanie któregokolwiek z nich dałoby czysty raport o polu, którego format nie ma — a to jedyny rodzaj odpowiedzi gorszy od braku odpowiedzi.
Przykłady
Blok bez czasu trwania
Napisy
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
Co znajduje raport
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Koniec równy początkowi. Czytnik daje blokowi jedną milisekundę, żeby plik dało się utrzymać, zapisuje naprawę, a raport drukuje obie połowy: wiersz o stracie w nagłówku i jeden błąd pod nim. Naprawa jest dowodem; milisekunda to tylko kształt, który ten dowód przybiera.
Blok, który naprawdę trwa jedną milisekundę
Napisy
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
Co znajduje raport
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Zapisany ręcznie jako jednomilisekundowy blok i niezgłoszony. Ta decyzja kształtuje całą kontrolę: naprawiony blok zerowej długości też wychodzi jako jedna milisekunda, więc reguła, która oznaczałaby tu krótkie czasy trwania, nazwałaby każdy plik z zepsutym znacznikiem plikiem pełnym niemożliwie krótkich bloków.
Koniec przed początkiem
Napisy
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
Co znajduje raport
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Pięć sekund do dwóch: ta sama wada co przy zerowej długości, liczona tą samą regułą i zgłaszana identycznie. Nic w pliku nie jest przepisywane — naprawione czasy istnieją w kopii czytnika, żeby resztę pliku dało się przetworzyć, i nie są poprawką, którą ta strona oferuje.
Częste pytania
Co liczy się jako blok kończący się przed rozpoczęciem?
Czas końca, który nie jest późniejszy niż czas początku: równy, jak 00:00:03,000 do 00:00:03,000, albo wcześniejszy, jak 00:00:05,000 do 00:00:02,000. To ta sama wada i jest liczona razem, a obie są liczone z naprawy czytnika, a nie z bloku, bo takiego znacznika nie da się utrzymać w pamięci.
Dlaczego raport nie nazywa bloków, których to dotyczy?
Bo te naprawy są zliczane w trakcie wczytywania pliku, a nie zbierane na listę. Raport podaje liczbę — jeden błąd, jeden element w nagłówkowym wierszu strat — i obie połowy to ten sam fakt widziany z nagłówka i ze znalezisk. Jeśli potrzebujesz dokładnego bloku, przeszukaj plik po liczbie jego znaczników czasu, a nie po numerze bloku.
Czy blok trwający jedną milisekundę jest problemem?
Nie tutaj i celowo. Ręcznie zapisany jednomilisekundowy blok jest legalny i nie jest zgłaszany; zgłaszany jest znacznik, który trzeba było naprawić, a który potem przypadkiem wygląda jak jedna milisekunda. Sprawdzanie czasów trwania zamiast napraw oznaczyłoby każdy plik z blokiem zerowej długości jako plik pełen niemożliwie krótkich bloków — czyli podwójnie złe znalezisko.
Czy ta strona naprawia znalezione znaczniki czasu?
Nie. Naprawione czasy istnieją wyłącznie w przeglądarce, żeby resztę pliku dało się wczytać i opisać. Plik, który pobrałeś lub wrzuciłeś, jest niezmieniony, a z tej strony nie da się zapisać wersji naprawionej — zastąpienie zepsutego znacznika to operacja z plikiem napisów jako produktem, a nie kontrola.
Które formaty napisów można sprawdzić pod kątem bloków kończących się przed rozpoczęciem?
Dziesięć z dwunastu: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON i CSV. Brakuje dwóch i żaden brak nie jest przeoczeniem. LRC ma jeden czas na wiersz, a czytnik wylicza koniec z następnego znacznika, więc para nie może tam wyjść na odwrót — kontrola oceniałaby pole, którego format nie ma. Czysty tekst nie ma czasów bloków w ogóle. Jeśli twój plik jest w jednym z tych dwóch formatów, najpierw go przekonwertuj.
Skąd biorą się te zepsute znaczniki czasu?
Prawie zawsze są produkowane, a nie wpisywane. Przeliczenie liczby klatek, które zaokrągla w złą stronę; przesunięcie zastosowane dwa razy do tego samego bloku; eksport z arkusza, w którym kolumnę końca zostawiono pustą i odczytano jako zero; napisy wyciągnięte z pliku z tekstem czasowanym, w którym znacznik nie miał czasu trwania od początku.
Czy można sprawdzić kilka plików w jednym przebiegu?
Tak. Wrzuć tyle, ile chcesz, a zostaną wczytane jeden po drugim, każdy z własnym raportem, i raporty pobiorą się razem jako archiwum zip. Kolejka pokazuje postęp dla każdego pliku, przebieg można przerwać w połowie, a żaden plik nie jest nigdzie wysyłany.