Achar blocos com fim antes do início
Ou cole o texto da legenda
Opções
A taxa de quadros em que os tempos são contados. Nas páginas de formato é o que o MicroDVD precisa, porque ele guarda os tempos como números de quadro. Nas páginas de taxa de quadros é a taxa com que o arquivo foi cronometrado — a versão para a qual as legendas foram feitas — e a segunda caixa da página recebe a taxa do vídeo com que você vai usá-las. 23,976, 24, 25, 29,97, 30, 50, 59,94 e 60 são as comuns. Errar isso desloca toda a linha do tempo e, nas páginas de taxa de quadros, desloca por uma proporção em vez de por uma quantidade fixa.
Um bloco que termina antes de começar é um código de tempo impossível: 00:00:03,000 --> 00:00:03,000, ou pior, um fim anterior ao início. Esta página reporta arquivos que continham um, contando a partir dos consertos que o leitor precisou fazer, porque um código de tempo com esse formato não pode ser mantido em memória e é substituído por um real antes de qualquer outra coisa acontecer. O que volta é um relatório, nunca um arquivo modificado.
É por isso que o relatório começa pelo que se perdeu na leitura e só então mostra o achado. Um bloco cujo fim não é posterior ao início recebe um milissegundo, para que o resto do arquivo possa ser lido, pré-visualizado e exportado; a contagem desses consertos fica no cabeçalho do relatório, e o achado abaixo diz um erro sem número de bloco, porque os consertos são contados enquanto o arquivo é lido, não guardados em lista. As duas linhas descrevem o mesmo código de tempo quebrado por dois lados, e é por isso que pertencem ao mesmo relatório e não a dois.
A armadilha em torno da qual esta página teve de ser escrita é que um bloco legítimo de um milissegundo parece exatamente um bloco corrigido. Por isso a verificação não olha durações — olha o registro dos consertos —, e um bloco que realmente dura um milissegundo é deixado em paz. Duração negativa e duração zero são o mesmo defeito e são contadas juntas. Dois formatos não são aceitos, e desta vez o motivo é o mesmo dos dois lados: o LRC deriva cada fim do carimbo seguinte, então um par ali nunca pode sair ao contrário, e texto puro não tem tempos de bloco. Verificar qualquer um dos dois produziria um relatório limpo sobre um campo que o formato não tem, que é o único tipo de resposta pior que nenhuma resposta.
Exemplos
Um bloco sem duração
Legendas
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.
O que o relatório encontra
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Um fim igual ao início. O leitor dá ao bloco um milissegundo para que o arquivo possa ser mantido, registra o conserto, e o relatório imprime as duas metades: a linha de perda no cabeçalho e um erro abaixo dela. O conserto é a evidência; o milissegundo é apenas a forma que a evidência assume.
Um bloco que realmente dura um milissegundo
Legendas
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.
O que o relatório encontra
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Escrito à mão como um bloco de um milissegundo e não reportado. Essa decisão é a que molda a verificação: um bloco de duração zero corrigido também sai como um milissegundo, então uma regra que marcasse durações curtas aqui chamaria todo arquivo com código de tempo quebrado de arquivo cheio de blocos impossivelmente curtos.
O fim está antes do início
Legendas
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.
O que o relatório encontra
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Cinco segundos até dois segundos: o mesmo defeito do caso de duração zero, contado pela mesma regra e reportado de forma idêntica. Nada no arquivo é reescrito — os tempos corrigidos existem na cópia do leitor para que o resto do arquivo possa ser processado, e não são um conserto que a página esteja oferecendo.
Perguntas frequentes
O que conta como bloco que termina antes de começar?
Um fim que não é posterior ao início: ou igual a ele, como em 00:00:03,000 a 00:00:03,000, ou anterior, como em 00:00:05,000 a 00:00:02,000. Os dois são o mesmo defeito e são contados juntos, e ambos são contados a partir do conserto que o leitor faz, não do bloco, porque um código de tempo com esse formato não pode ser mantido em memória.
Por que o relatório não nomeia os blocos envolvidos?
Porque esses consertos são contados enquanto o arquivo está sendo lido, não reunidos numa lista. O relatório dá a contagem — um erro, um item na linha de perdas do cabeçalho — e as duas metades são o mesmo fato visto do cabeçalho e dos achados. Se você precisa do bloco exato, procure no arquivo pela contagem de códigos de tempo, não por um número de bloco.
Um bloco que dura um milissegundo é um problema?
Aqui não, e deliberadamente. Um bloco de um milissegundo escrito à mão é legal e não é reportado; o que é reportado é um código de tempo que precisou ser corrigido, e que por acaso fica guardado como um milissegundo depois. Verificar durações em vez de consertos marcaria todo arquivo com um bloco de duração zero como arquivo cheio de blocos impossivelmente curtos, que é o achado errado duas vezes.
Esta página conserta os códigos de tempo que encontra?
Não. Os tempos corrigidos existem apenas dentro do navegador para que o resto do arquivo possa ser lido e reportado. O arquivo que você baixou ou arrastou está inalterado, e não há como salvar a versão corrigida a partir desta página — substituir um código de tempo quebrado é uma operação com um arquivo de legendas como saída, não uma verificação.
Quais formatos de legenda podem ser verificados quanto a blocos que terminam antes de começar?
Dez dos doze: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON e CSV. Faltam dois, e nenhum é esquecimento. O LRC guarda um horário por linha e o leitor deriva cada fim do carimbo seguinte, então um par ali nunca pode ficar ao contrário — a verificação estaria julgando um campo que o formato não tem. Texto puro não tem tempos de bloco. Se o seu arquivo estiver num desses dois, converta primeiro.
Esses códigos de tempo quebrados vêm de algum lugar em especial?
Quase sempre são produzidos, não digitados. Uma conversão de taxa de quadros que arredonda para o lado errado, um deslocamento aplicado duas vezes ao mesmo bloco, uma exportação de planilha em que a coluna de fim ficou vazia e foi lida como zero, e uma legenda extraída de um arquivo de texto cronometrado com um marcador que não tinha duração alguma.
Vários arquivos podem ser verificados numa execução?
Sim. Solte quantos quiser e eles são lidos um após o outro, cada um produzindo seu relatório, e os relatórios são baixados juntos num zip. A fila mostra o progresso por arquivo, a execução pode ser cancelada no meio e nenhum arquivo é enviado em momento algum.