Vídeo e legendas · Kit de ferramentas de legendas
Como um navegador analisa um arquivo SRT: blocos, índices, códigos de tempo e texto
· Como funciona
legendas Srt formatos de arquivo
SRT parece trivial até você encontrar arquivos reais. Esta postagem explica como um analisador divide blocos, lê índices e códigos de tempo, lida com texto multilinha e se recupera de blocos malformados contidos em arquivos do mundo real.
O arquivo 'parece bom', mas faltam metade das dicas - como um formato de aparência tolerante esconde expectativas estritas
SRT não possui órgão de especificação, nenhum registro MIME e nenhum validador enviado com os jogadores. Em vez disso, o que existe é uma forma com a qual a maioria dos softwares concorda: um número, uma linha de timecode, uma ou mais linhas de texto e, em seguida, uma linha em branco. Como a forma é convencional e não especificada, dois arquivos podem parecer corretos em um editor de texto enquanto apenas um deles é carregado, e a falha geralmente é silenciosa. Um jogador que não consegue ler uma sugestão tende a ignorá-la em vez de reportá-la, portanto, um arquivo com um bloco quebrado é reproduzido com uma lacuna em vez de um erro.
Um analisador, portanto, tem duas tarefas que seguem direções opostas. Ele tem que aceitar as variações que os arquivos reais contêm, porque os arquivos são produzidos por serviços de transcrição, edição manual e conversores de formato, cada um com suposições diferentes. Ele também tem que recusar leituras que colocariam uma dica na hora errada, porque um carimbo de data e hora silenciosamente errado é pior do que uma falha relatada.
Divisão em blocos – linhas em branco como separadores e o problema com espaços em branco perdidos e CRLF
A divisão ocorre nas linhas em branco, não nos números de índice. O analisador normaliza os finais de linha primeiro, substituindo o par CRLF e um CR solitário por uma única nova linha, porque um arquivo criado no Windows e editado no Unix pode conter ambos. Em seguida, ele se divide em duas ou mais novas linhas, corta cada bloco resultante e descarta os vazios. Essa ordem é importante: a divisão antes da normalização deixaria um retorno de carro perdido no final de uma linha do timecode, e o timecode falharia na correspondência.
Uma marca de ordem de bytes é removida antes de tudo isso. Um UTF-8 BOM no início de um arquivo tem três bytes que um analisador ingênuo vê como parte do primeiro número de índice, o que é suficiente para tornar a primeira sugestão ilegível enquanto cada sugestão posterior é analisada. Os espaços finais em uma linha separadora em branco são manipulados pelo corte, portanto, um arquivo cujas linhas em branco contêm um espaço ainda é dividido corretamente.
A linha do índice — por que os números costumam estar errados, duplicados ou ausentes e por que os analisadores não devem confiar neles
O número do índice é lido e depois ignorado. Os arquivos reais numeram sugestões a partir de zero, reiniciam a numeração após uma mesclagem, duplicam um número após uma edição manual ou omitem totalmente a linha quando um conversor gravou o arquivo. Confiar nesses números significa herdar cada uma dessas falhas, então o analisador atribui seu próprio número sequencial, contando as pistas que construiu com sucesso até agora.
Essa escolha também explica por que o analisador nunca exige que a linha do índice esteja presente. Ele localiza a linha do timecode pesquisando no bloco a primeira linha que contém a seta, em vez de assumir que o timecode é a segunda linha. Um bloco sem linha de índice é analisado normalmente, e um bloco com duas linhas perdidas antes do timecode ainda é analisado, porque a posição não é o que identifica o timecode.
A linha do timecode — HH:MM:SS,mmm --> HH:MM:SS,mmm, variações toleradas e aquelas que quebram os jogadores
A linha do timecode é comparada com uma única expressão regular e as tolerâncias nela são deliberadas. As horas são opcionais, pois o WebVTT permite a leitura de dois campos e os conversores a emitem. Uma vírgula ou um ponto final são aceitos como separador de milissegundos, independentemente do formato que o arquivo afirma ter, porque os separadores mistos são comuns o suficiente para que rejeitá-los causaria falha em mais arquivos bons do que ruins. Os dígitos fracionários são preenchidos à direita, portanto, uma sugestão que termina em um único dígito é lida como centenas de milissegundos em vez de unidades.
Duas leituras são recusadas. Um campo de minutos ou segundos acima de cinquenta e nove é rejeitado em vez de transportado, porque noventa segundos não é uma leitura de relógio e geralmente indica um arquivo corrompido ou mal convertido; normalizá-lo silenciosamente moveria a deixa. Uma linha cujo início ou fim não é analisado produz um problema registrado nomeando o texto incorreto e a forma esperada, e o bloco é ignorado em vez de adivinhado.
Linhas de texto — sugestões de múltiplas linhas, tags de formatação e onde um bloco realmente termina
Tudo após a linha do timecode é o texto de sinalização, unido novamente com novas linhas. Não há limite de linhas e nenhuma tentativa de refluxo, portanto, uma sugestão de três linhas sobrevive como três linhas. Esta é a razão pela qual a linha em branco suporta carga: é a única coisa que informa ao analisador que o texto terminou, e é por isso que uma sugestão cujo próprio texto contém uma linha em branco será lida como dois blocos e a segunda metade será relatada como não tendo código de tempo.
As configurações de cue são separadas do carimbo de data/hora final por uma sequência de dois ou mais espaços. O WebVTT permite que diretivas de posicionamento, como alinhamento e posicionamento de linha, sigam o horário de término na mesma linha, de modo que o analisador as divida antes que o carimbo de data/hora seja analisado e as mantenha ao lado da sugestão. Um único espaço não é um separador, o que evita que uma linha de timecode meramente desordenada perca seu horário de término.
Exemplo resolvido: análise de um arquivo de cinco pistas com duas falhas deliberadas — o que um analisador robusto recupera e o que ele sinaliza
Pegue um arquivo de cinco blocos em que o bloco três teve sua linha de timecode danificada para ler 00:01:75,000 --> 00:01:78,000, e o bloco quatro perdeu sua linha de timecode inteiramente durante uma cópia e colagem. O analisador lê os blocos um e dois normalmente e os numera como um e dois. O bloco três corresponde ao formato de um código de tempo, mas carrega um campo de segundos de setenta e cinco, por isso é recusado e registrado como um carimbo de data/hora incorreto, nomeando a linha que não pôde ser lida.
O bloco quatro não contém nenhuma seta, portanto é registrado como sem carimbo de data/hora, citando os primeiros quarenta caracteres do bloco para que a linha possa ser encontrada no arquivo original. Bloqueie cinco análises e se tornará a sugestão três, e não a sugestão cinco, porque a numeração conta as dicas bem-sucedidas. O resultado são três pistas utilizáveis e duas reclamações específicas localizadas, em vez de uma exceção na primeira falha e nenhuma informação sobre a segunda.
O que isso não cobre — estilo ASS/SSA, códigos de posicionamento e texto sem legenda despejados em SRT
Isto descreve SRT e as partes do WebVTT que compartilham seu formato de sugestão. Não cobre ASS e SSA, que carregam um cabeçalho de script, definições de estilo e referências de estilo por evento e que não podem ser lidos por divisão em linhas em branco. O tempo de karaokê, os comandos de desenho e as tags de substituição inline que esses formatos usam estão fora dos modelos de analisador cue-and-timecode.
Também não repara texto. Uma transcrição colada em um arquivo sem códigos de tempo produz uma lista de blocos sem carimbo de data/hora, que é relatada com precisão, mas não pode ser transformada em legendas sem informações de tempo que não estão presentes. Falhas de codificação são uma preocupação separada: um arquivo decodificado com o conjunto de caracteres errado é analisado em pistas perfeitamente válidas cujo texto está errado, e nenhuma verificação estrutural detectará isso.
Conclusão: analise com lentidão, escreva com rigor - como o Subtitle Toolkit lê SRT confuso e escreve de volta um texto limpo
A regra de trabalho é analisar com tolerância e escrever com rigor. Ao entrar, aceite horas opcionais, separador, linhas de índice ausentes, finais de linha mistos e uma marca de ordem de byte inicial, e registre cada falha como um problema localizado em vez de lançar no primeiro, para que um arquivo possa ser corrigido em uma única passagem. Na saída, emita uma forma canônica.
Isso é o que o Subtitle Toolkit faz quando converte. As dicas são renumeradas de um e mantidas contíguas, os carimbos de data e hora são reemitidos com uma vírgula para SRT e um ponto final para WebVTT, e o arquivo que retorna é a forma que os jogadores esperam, independentemente de quão irregular foi a entrada. Cole um arquivo que um jogador rejeitou no conversor e leia primeiro os problemas relatados; eles nomeiam a deixa e citam a linha, o que geralmente é suficiente para encontrar a falha no original.