Vídeo e legendas · Kit de ferramentas de legendas
Por que tags perdidas em um arquivo de legenda podem interromper o upload de uma legenda na plataforma
· Por que é importante
legendas processamento de texto webvtt
As plataformas analisam os uploads de legendas de forma estrita e muitas vezes silenciosa. Esta postagem explica os motivos comuns pelos quais um arquivo de legenda é rejeitado ou exibido de maneira estranha, por que tags e códigos de formatação são os culpados comuns e como um arquivo padrão e limpo evita o problema.
O upload foi aceito e as legendas mostram tags literais – a falha silenciosa de um arquivo impuro
O pior resultado não é a rejeição. Um upload rejeitado indica que algo está errado enquanto você ainda está visualizando o formulário. O resultado comum é a aceitação seguida de legendas que exibem sua própria marcação para os visualizadores, porque a verificação de upload e o caminho de renderização são softwares diferentes que fazem perguntas diferentes.
A verificação de upload geralmente pergunta se o arquivo é analisado em sugestões. A renderização pergunta o que fazer com o conteúdo de cada sugestão, e um analisador que ignora uma tag desconhecida a desenha como texto. Ambas as etapas fizeram o que foram projetadas para fazer.
O que as plataformas realmente aceitam — SRT simples e WebVTT com estrutura previsível e pouca tolerância para extras
O que as plataformas aceitam é mais restrito do que as ferramentas emitem. Na prática, isso significa SRT simples ou WebVTT com um formato previsível: blocos separados por linhas em branco, uma linha de timecode, linhas de texto e pouco mais. A tolerância para extras é baixa e, mais importante ainda, não documentada, por isso a suposição segura é que qualquer coisa além dessa forma é um risco e não uma característica.
Isto não é conservadorismo por si só. Uma plataforma que aceitasse marcação arbitrária teria que decidir como renderizá-la de forma consistente em clientes web, móveis e de televisão, o que representa um compromisso muito maior do que aceitar um arquivo de legenda.
Os culpados usuais - tags do tipo HTML, códigos do estilo ASS, BOMs, finais de linha mistos e dicas em branco
Os culpados recorrentes são poucos. Tags de colchetes angulares para itálico, vozes de alto-falante e classes de sinalização sobrevivem à conversão de formatos que os suportam. Os códigos de substituição delimitados por chaves chegam dos formatos SubStation e não significam nada fora deles. Uma marca de ordem de bytes no início do arquivo é anexada ao primeiro número de índice. Terminações de linha mistas da divisão de blocos de quebra de edição multiplataforma. As dicas cujo texto ficou vazio após a marcação ter sido removida permanecem como espaços em branco com carimbo de data/hora.
Nada disso é exótico. Eles são o resultado normal de uma cadeia de conversão onde cada etapa foi individualmente razoável, e é por isso que aparecem em arquivos que ficam bem em um editor.
Por que uma plataforma tolera o que outra rejeita – analisadores diferentes por trás de formulários de upload semelhantes
Plataformas diferentes toleram subconjuntos diferentes, e é isso que torna o diagnóstico da falha confuso. O mesmo arquivo pode ser carregado de forma limpa e renderizado corretamente em um serviço, carregar e renderizar marcação em um segundo e ser recusado por um terceiro, sem nenhuma mensagem de erro que identifique a causa real. O arquivo não mudou entre as tentativas; três analisadores discordaram.
Tratar uma plataforma como referência é, portanto, um instinto errado. Um arquivo que funciona no serviço mais permissivo não informa nada sobre os outros, e o analisador mais rigoroso é aquele que define se um arquivo é portátil.
Exemplo resolvido: um arquivo, três uploads — como a mesma desordem aparece de forma diferente e desaparece após a limpeza
Faça uma exportação carregando um código de substituição no topo do quadro em sessenta sugestões, tags de ênfase em quarenta e uma marca de ordem de byte. Carregado em três serviços, pode ser aceito em todos os lugares. No primeiro, as tags são respeitadas e o código de substituição é desenhado literalmente. No segundo ambos aparecem como texto. Na terceira a marca representa a primeira deixa, que simplesmente nunca aparece, e ninguém percebe porque a linha de abertura costuma ser um título.
A limpeza uma vez remove todas as três classes na origem. As tags de colchetes angulares e os códigos de colchetes são substituídos, o espaço em branco deixado para trás é recolhido, as dicas esvaziadas pelas remoções são descartadas em vez de emitidas como espaços em branco com carimbo de data e hora, e o arquivo é reescrito com dicas renumeradas contiguamente de um. A mesma saída vai para todos os três serviços.
O que isso não cobre – guias de estilo específicos da plataforma, limites de caracteres por linha e legendas gravadas
Isto cobre a portabilidade estrutural, não a conformidade editorial. Guias de estilo de plataforma sobre comprimento de linha, máximo de caracteres, posicionamento de rótulos de alto-falantes e manuseio de efeitos sonoros são requisitos separados que um arquivo limpo não satisfaz automaticamente. Um arquivo de legenda estruturalmente perfeito ainda pode violar um guia de estilo.
As legendas gravadas são um mecanismo totalmente diferente. O texto renderizado nos quadros de vídeo não é um arquivo de legenda, não pode ser desativado e não é afetado por nada descrito aqui.
Conclusão: limpe uma vez, carregue em qualquer lugar — como os recursos de limpeza e conversão do Subtitle Toolkit produzem um arquivo compatível com a plataforma
Limpe uma vez e carregue o mesmo arquivo em qualquer lugar. A alternativa, manter uma exportação separada por plataforma, multiplica o número de arquivos que podem ficar fora de sincronia com o mestre e não remove a confusão subjacente de nenhum deles.
Execute a limpeza e a conversão juntos e leia os problemas relatados antes de fazer o upload, e não depois. Os problemas nomeiam as dicas por número, que é a diferença entre saber que um arquivo tem um problema e saber qual linha examinar.