Cues die eindigen voor hun start
Of plak ondertiteltekst
Opties
In welke beeldsnelheid de tijden worden geteld. Op de formaatpagina’s is dit wat MicroDVD nodig heeft, want het slaat tijden op als framenummers. Op de beeldsnelheidspagina’s is het de snelheid waartegen het bestand getimed is — de versie waarvoor de ondertitels gemaakt zijn — en het tweede vak op de pagina neemt de snelheid van de video die je gaat gebruiken. 23,976, 24, 25, 29,97, 30, 50, 59,94 en 60 zijn de gebruikelijke. Een verkeerde waarde verschuift de hele tijdlijn, en op de beeldsnelheidspagina’s verschuift ze die met een verhouding in plaats van met een vast bedrag.
Een blok dat eindigt voordat het begint, is een tijdcode die niet kan kloppen: 00:00:03,000 --> 00:00:03,000, of erger, een einde dat vóór de start ligt. Deze pagina meldt bestanden die er een bevatten, en telt daarvoor de reparaties die de lezer moest uitvoeren. Een tijdcode van die vorm kan namelijk helemaal niet in het geheugen blijven staan en wordt vervangen door een echte voordat er iets anders gebeurt. Wat terugkomt is een rapport, nooit een aangepast bestand.
Daarom begint het rapport met wat er tijdens het lezen verloren ging en pas daarna met de bevinding. Een blok waarvan het einde niet na het begin ligt, krijgt één milliseconde, zodat de rest van het bestand gelezen, bekeken en geëxporteerd kan worden; het aantal van die reparaties staat in de kop, en de bevinding eronder noemt één fout zonder bloknummer, omdat de reparaties worden geteld terwijl het bestand wordt gelezen en niet in een lijst worden bewaard. Beide regels beschrijven dezelfde kapotte tijdcode van twee kanten, en daarom horen ze in hetzelfde rapport.
De val waar deze pagina omheen is geschreven, is dat een geldig blok van één milliseconde precies op een gerepareerd blok lijkt. Daarom kijkt de controle helemaal niet naar duur — ze kijkt naar het spoor van reparaties — en een blok dat werkelijk één milliseconde duurt, blijft ongemoeid. Een negatieve duur en een duur van nul zijn hetzelfde gebrek en worden samen geteld. Twee formaten worden niet geaccepteerd, en deze keer is de reden aan beide kanten dezelfde: LRC leidt elk einde af uit de volgende tijdcode, dus een paar kan daar nooit achterstevoren uitkomen, en platte tekst heeft helemaal geen bloktijden. Een van beide controleren zou een schone uitslag opleveren over een veld dat het formaat niet heeft, en dat is de enige soort antwoord die slechter is dan geen antwoord.
Voorbeelden
Een blok zonder duur
Ondertitels
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.
Wat het rapport vindt
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Een einde dat gelijk is aan de start. De lezer geeft het blok één milliseconde zodat het bestand kan worden vastgehouden, legt de reparatie vast, en het rapport drukt beide helften af: de verliesregel in de kop en één fout eronder. De reparatie is het bewijs; de milliseconde is alleen de vorm die het bewijs aanneemt.
Een blok dat echt één milliseconde duurt
Ondertitels
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.
Wat het rapport vindt
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Met de hand geschreven als een blok van één milliseconde en niet gemeld. Die beslissing bepaalt de hele controle: een gerepareerd blok van nul lengte komt er ook als één milliseconde uit, dus een regel die hier korte duren zou melden, zou elk bestand met een kapotte tijdcode afschilderen als een bestand vol onmogelijk korte blokken.
Het einde ligt vóór de start
Ondertitels
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.
Wat het rapport vindt
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Vijf seconden naar twee seconden: hetzelfde gebrek als het geval van nul lengte, door dezelfde regel geteld en identiek gemeld. Niets in het bestand wordt herschreven — de gerepareerde tijden bestaan in de kopie van de lezer zodat de rest van het bestand verwerkt kan worden, en ze zijn geen oplossing die deze pagina aanbiedt.
Veelgestelde vragen
Wat geldt op deze pagina als een blok dat eindigt voordat het begint?
Een eindtijd die niet later is dan de starttijd: gelijk, zoals 00:00:03,000 tot 00:00:03,000, of eerder, zoals 00:00:05,000 tot 00:00:02,000. Beide zijn hetzelfde gebrek en worden samen geteld, en beide worden geteld uit de reparatie die de lezer uitvoert en niet uit het blok, omdat een tijdcode van die vorm niet in het geheugen kan blijven staan.
Waarom noemt het rapport de betrokken blokken niet?
Omdat deze reparaties worden geteld terwijl het bestand wordt gelezen en niet in een lijst worden bewaard. Het rapport geeft het aantal — één fout, één item in de verliesregel van de kop — en de twee helften zijn hetzelfde feit vanuit de kop en vanuit de bevindingen. Heb je het exacte blok nodig, zoek dan in het bestand op het aantal tijdcodes van die vorm, niet op een bloknummer.
Is een blok van één milliseconde een probleem?
Hier niet, en dat is met opzet. Een met de hand geschreven blok van één milliseconde is geldig en wordt niet gemeld; gemeld wordt een tijdcode die gerepareerd moest worden en die daarna toevallig als één milliseconde wordt bewaard. Op duur controleren in plaats van op reparaties zou elk bestand met een blok van nul lengte afschilderen als vol onmogelijk korte blokken, en dat is twee keer de verkeerde bevinding.
Repareert deze pagina de tijdcodes die ze vindt?
Nee. De gerepareerde tijden bestaan alleen in de browser zodat de rest van het bestand kan worden gelezen en gerapporteerd. Het bestand dat je hebt neergezet of gedownload is ongewijzigd, en je kunt de gerepareerde versie vanaf deze pagina niet opslaan — een kapotte tijdcode vervangen is een bewerking met een ondertitelbestand als uitvoer, geen controle.
Voor welke formaten werkt deze controle?
Tien van de twaalf: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON en CSV. Twee ontbreken en geen van beide per ongeluk. LRC bewaart één tijd per regel en de lezer leidt elk einde af uit de volgende tijdcode, dus een paar kan daar nooit achterstevoren staan — de controle zou een veld beoordelen dat het formaat niet heeft. Platte tekst heeft helemaal geen bloktijden. Zet zo’n bestand eerst om.
Waar komen zulke kapotte tijdcodes vandaan?
Ze worden bijna altijd gemaakt en niet getypt. Een framerateomzetting die de verkeerde kant op afrondt, een verschuiving die twee keer op hetzelfde blok is toegepast, een spreadsheetexport waarbij de eindkolom leeg bleef en als nul werd gelezen, en een ondertitel uit een timed-text-bestand met een marker die vanaf het begin geen duur had.
Kunnen meerdere bestanden in één run worden gecontroleerd?
Ja. Sleep er zoveel in als je wilt; ze worden na elkaar gelezen, elk met een eigen rapport, en de rapporten komen samen als zip binnen. De wachtrij toont de voortgang per bestand, de run kan halverwege worden geannuleerd, en er wordt op geen enkel moment iets geüpload.