Por quê?

A menos que você esteja lutando contra o sistema, como alguns tradutores da Crunchyroll estão fazendo, é importante entender as limitações da forma que você trabalha. Se você distribui vídeos usando arquivos MKV, por exemplo, é recomendado que você evite usar fontes pesadas (está no fim desta página): não faz sentido você aumentar o tamanho do vídeo em 10MB só porque precisa de mostrar um kanji em uma nota de tradução, certo? Por outro lado, limitações como essa limitam a capacidade dos tradutores, o que não é bom.

Como?

Haveriam soluções melhores? Proponho uma: reduzir o tamanho das fontes eliminando os caracteres que não foram usados na legenda. Não é algo difícil de ser executado pois há várias ferramentas criadas para esse propósito, basta procurar por “font subsetting”. Para aplicar esse conceito com legendas, fiz um script que recebe uma legenda e uma pasta com fontes e otimiza elas removendo os caracteres não usados. Só usar o ass-parser e o fontkit, simples.

Mas não me contentei em apenas reduzir as fontes, resolvi unir todas as fontes em um arquivo só, assim a quantidade de metadados e outras informações redundantes entre as fontes é reduzida. Isso também tem o benefício de evitar que alguém extraia as fontes do MKV (usando o mkv-extract talvez) e instale no sistema.

Pontos positivos e negativos

Há dois grandes pontos positivos para esse conceito:

1. Ele permite que tradutores possam usar quantas fontes acharem que for necessário sem se preocupar com o tamanho das fontes. Querem colocar um kanji em uma nota de tradução? Não tem problema. Querem usar dezenas de fontes para fazer algum efeito? Ótimo!
2. Ele permite reduzir o tamanho dos vídeos sem reduzir a qualidade do vídeo e de forma mais eficaz e inteligente do que outras técnicas que certos grupos usam, como compactar o vídeo usando rar ou 7z e dividir aberturas e encerramentos em arquivos separados (o que reduz a compatibilidade, o que não é inteligente).

Há um ponto que pode ser positivo ou negativo, dependendo das suas prioridades: a legenda fica ilegível se unir as fontes em uma só e elas não forem carregadas, isso é bom pois garante que ninguém vai ver uma legenda com fontes padrões erradas, mas isso pode ser ruim para os que preferem uma legenda ruim do que nenhuma.

Ainda há três pontos negativos: complexidade adicional, dificuldade para editar a legenda distribuída e problemas de licenciamento já que as licenças de certas fontes não permitem que elas sejam editadas dessa maneira. Esse último problema não afeta fansubs pois quase todas¹ usam fontes sem ter permissão de redistribuição. Fansubbers que me falaram “a gente só usa fontes gratuitas”, por favor, leiam isso e aprendam que Arial não é uma fonte gratuita.

Na prática

Testei esse conceito com um episódio de Kobayashi-san. Como disse semana passada eu tinha trabalhado nesse anime para ver a versão dublada, logo eu já tinha o karaokê que eu traduzi para português e o vídeo do BD, bastou adicionar a tradução das falas as quais peguei da fansub Aenianos. Como apenas traduzi o karaokê da DameDesuYo!, que é um que usa várias fontes, o arquivo final ficou com mais de 35 fontes, o que é perfeito para o teste.

Postei o arquivo final em uma hospedagem e perguntei para o pessoal da UO se eles conseguiam abrir o arquivo, se estava funcionando corretamente, qual era o player que usaram e o que acharam que eu tinha alterado no vídeo. Os resultados:

Como podem ver, a maioria conseguiu abrir sem problemas, mas 28% das vezes o player não carregou a fonte, deixando a legenda ilegível. Praticamente todos os players populares aparecem entre os que apresentaram problemas, como MPV, MPC-HC e VLC. Por outro lado esses players também apareceram entre os que o vídeo funcionou, então não é que o problema esteja nos players, mas na forma que eles foram configurados.

Esse dado é interessante para fansubs, pois provavelmente essas pessoas estão vendo animes com os players mal-configurados de forma que as fontes não são carregadas. Isso não é só ruim porque elas estão vendo uma tradução pior do que a que foi distribuída, mas também representa que várias pessoas nem notam o problema e acham que vários grupos usam Arial por escolha própria e não porque elas que configuraram o player delas de forma errada.

Uma ideia que ainda não coloquei em prática, mas que acho que seria boa, seria deixar no início da legenda um aviso grande de que as fontes não foram carregadas usando uma fonte que aparece nada no lugar dos caracteres (algo como essa fonte, mas com espaços no lugar de retângulos), assim se as fontes não forem carregadas o aviso aparece, se elas forem carregadas.

Essa ideia não aumenta muito o tamanho do arquivo já que a fonte adicional só precisa ter os caracteres necessários para ocultar o aviso e pode ser aplicada em qualquer legenda existente caso algum grupo queira avisar quem está vendo o vídeo de que o player dele não está configurado corretamente e, por isso, ele não estará vendo o vídeo da forma que ele foi criado.

Alternativas

Embora o teste tenha sido com as legendas reduzidas e unidas, as fontes podem ser apenas reduzidas. Dessa forma as legendas podem funcionar mesmo com as fontes erradas, caso alguém prefira isso. A redução final não vai ser tão eficiente, mas ainda é muito boa. O problema de pessoas extraindo fontes faltando caracteres e instalando no sistema pode ser mitigado renomeando as fontes.

Alguns lendo essa postagem serão rápidos para pensar que hardsub é uma solução, mas quem leu a postagem da semana passada sabe que editar um formato comprimido causa perda de qualidade, e todos os formatos usados para distribuir vídeos são comprimidos, logo usar hardsub não é uma opção para quem se preocupa com qualidade. Repito: quem usa hardsub não se preocupa com qualidade. Ponto final.

Talvez a alternativa mais inteligente e simples é usar streaming: como a distribuição de fontes via streaming ocorre separadamente do vídeo, o tamanho delas não acumula e o problema de um arquivo de 500MB virar um de 600MB simplesmente não existe. Além disso, a redução na performance é mínima pois elas podem ficar em cache.

Conclusão!

O resultado do experimento foi bem interessante. Se algum grupo não estiver preocupado se o pessoal estiver usando os players de forma errada poderia muito bem usar um script como esse para reduzir o tamanho dos vídeos.

Posso disponibilizar ele se alguém quiser. Não sei se os comentários do blog ainda estão funcionando, acho que a função que lida com ele estava marcada para parar de funcionar por causa de uma atualização no servidor e a única forma que resolver esse problema seria pagando, o que eu não vou fazer.

Se quiserem podem me enviar uma mensagem no Discord, no Twitter, os dois são igualmente bugados e não recebo notificações dos dois. Tenho conta no Signal e no Keybase, são criptografados, mas acho que ninguém usa nenhum dos dois, né? É complicado.

Eu tinha dito que daria um prêmio para quem adivinhasse qual era o objetivo do experimento e ninguém acertou, mas alguém tinha que ganhar um prêmio e esse foi o henmarcelino, que chutou que era a escolha de fontes. Não era bem a escolha das fontes, era uma forma de reduzir o tamanho delas. Os outros chutes disseram que a qualidade do vídeo era melhor, o que entendo pois a qualidade do vídeo da Aenianos é inferior pois usaram hardsub na tradução das músicas. Aparentemente o pessoal inconscientemente nota que a qualidade de quem usa hardsub é inferior.

Voltando ao assunto das fontes, acho estranho que o pessoal da Crunchyroll se recuse a usar as fontes que eles licenciaram. São 60 fontes (incluindo variações) mas parece que só querem ficar usando 15 dessas variações, desperdiçam 75% do que licenciaram! Há vários animes onde aparece texto monoespaçado e, ao invés de usarem Courier New, Andale Mono ou DejaVu LGC Sans Mono, eles usam Arial, que não é apropriada para essa situação. Embora seja um problema que eles só tenham licenciado uma única fonte cursiva, Comic Sans MS, por que desperdiçam tantas fontes por nada? É estranho, mas tenho boas notícias: não licenciaram Papyrus. Ainda bem!

Acho que há dois problemas lá, em primeiro lugar como muita gente que trabalha lá era de fansubs eles ainda têm a mentalidade de fansubbers e acham que adicionar muitas fontes é algo ruim, em segundo lugar há um grupo rebelde que não lê os memorandos e usa qualquer fonte que dá na telha. Aliás, para mim esse grupo rebelde não é um problema, é uma benção já que no último mês eu arrumei o meu player para carregar essas fontes.

Espero que o futuro seja melhor, tanto para fãs, quanto para profissionais e para quem está no meio dos dois grupos. Ainda que demore anos para o projeto sair e mais ainda para os players implementarem, acho que propostas como essa deveriam ser revistas e melhoradas por pessoas dos dois lados. Muito do que já foi proposto é ótimo, mas sempre há espaço para melhorias, como definir o estilo ao invés de definir o tipo do evento por linha e mover o tipo de evento para ser uma propriedade do estilo, o que seria mais conciso. Mas para que essas melhorias ocorram é necessário que haja participação de várias pessoas envolvidas com a produção de legendas.

Quinta vou publicar uma postagem sobre um anime muito bom que me recomendaram quando eu estava na faculdade e que é muito educativo. Até mais!

Atualizações

Descobri duas coisas após a publicação desta postagem:

1. A Crunchyroll está usando mais fontes, só não é muito comum. Em um episódio que vi faz algumas horas eles usaram oito fontes diferentes (excluindo variantes), inclusive Courier New. Espero que as equipes estejam sendo melhor informadas de quais fontes elas podem ou não usar.
2. Há algumas fansubs que usam fontes otimizadas, como a Commie, mas até agora não encontrei ninguém que tenha feito um script ou programa que automaticamente pega as fontes de uma legenda e otimiza as fontes conforme os caracteres usados. Além disso, mesmo no exemplo que encontrei da Commie, em Nagatoro-san, só otimizaram uma fonte de 4 MB para 46 KB, o que indica que devem ter feito isso manualmente. A automatização desse processo pode ser o que faltava para que isso se popularize.

¹ Se encontrar uma que só usa fontes com licenças open-source, deve ser minha.

O post Otimizando fontes apareceu primeiro em o canto do qgustavor.

O último experimento que eu fiz foi pegar o TweetNaCl.js e fazer uma versão dele que pode ser simplificada automaticamente dependendo das funções usadas: https://github.com/qgustavor/tweetnacl-js

Tive essa ideia pois eu estava desenvolvendo um projeto usando o Vite e notei que no código havia algumas funções do TweetNaCl que eu não estava usando, então resolvi reescrever parte do código que lida como as funções são exportadas e o resultado foi o código acima.

O interessante é que isso não só permite que as funções não usadas (pelo menos a maior parte delas) sejam eliminadas mas também permite que as funções sejam renomeadas, o que eu acho interessante já que.

Em termos de segurança não sei se isso é mais seguro ou não. Deve ser, mas não posso confirmar nada. É um experimento interessante, de qualquer forma.

O post Um experimento com criptografia apareceu primeiro em o canto do qgustavor.

Por outro lado uma coisa que nunca tinha parado para pensar é no uso automático de aspas, como na imagem acima onde as aspas fazem parte do modelo do site. O normal, nesse caso, seria que as aspas no texto citado fossem invertidas de duplas para simples e de simples para duplas, se estas existissem.

Nunca vi alguém comentar sobre esse assunto, talvez porque essa seja uma situação rara: talvez ficasse mais bonito se o nome do episódio ficasse escrito só em negrito, sem aspas. Por outro lado, considerando que alguém quer usar aspas no modelo de um site ou de um aplicativo, o que poderia ser feito? Fiz esse gist com uma possível implementação.

Espero que esse código sirva para alguém no futuro.

O post Aspas apareceu primeiro em o canto do qgustavor.

A maioria das respostas irá sugerir para usar o ffmpeg. Na maioria dos casos ele é realmente a melhor opção por ser simples de usar: "ffmpeg -ss tempo -i fonte.mp4 -vframes 1 destino.png", repetir isso a quantidade de vezes que for necessária e o problema está resolvido. Por outro lado esse método tem certos problemas:

• Você precisa de iniciar uma instância do ffmpeg para cada imagem, o que torna o processo muito lento, mesmo se você usar várias instâncias em paralelo;
• As legendas não aparecem nas capturas por padrão; você pode usar um filtro para isso, mas nem sempre é fácil já que é complicado configurar as fontes para funcionar com esse filtro;
• O ffmpeg não suporta certos MKVs (que são raros… exceto se você estiver trabalhando com animes);
• As capturas ficarão erradas para vídeos em que o aspect ratio mostrado (DAR) é diferente do codificado (SAR);
• Alguns vídeos podem ter problemas de compatibilidade (use “-x264_build 150” para esses casos).

Um método alternativo que eu achei bem mais interessante é usar o MPV para isso. Ele é mais complexo e consiste dos seguintes passos:

1. Abra o vídeo no MPV usando “–vo=null” para não abrir uma janela, “–audio=no” para não processar o áudio, “–pause” para pausar o vídeo (bem na lata, né?), e o argumento mais importante, “–input-ipc-server=/tmp/node-mpv.sock”;
2. Conecte ao MPV usando o IPC acima e aguarde pelo evento “playback-restart”;
3. Para cada imagem que você precisar tirar use o comando “seek [tempo] absolute+exact”, espere pelo evento “playback-restart” e então use o comando “screenshot-to-file [arquivo]”;
4. Por padrão as legendas aparecem nas capturas (o que é ótimo!). Se quiser desativar isso só adicionar “video” depois do nome do arquivo nesse último comando.

Assim como com o ffmpeg é possível usar várias instâncias em paralelo (geralmente uso uma para cada vídeo) e, apesar de toda a dificuldade envolvendo a comunicação via IPC, os resultados são surpreendentes: todos os problemas que listei acima são resolvidos e claro, é BEM mais rápido.

Só não me perguntem por que tenho tantas capturas no meu computador…

O post Capturas em massa apareceu primeiro em o canto do qgustavor.

Como no momento o Deno ainda está muito novo estou evitando ele para esse projeto e usando o Node, mas como boa parte desse clima de sair experimentando com esses módulos sem depender de Webpack, Parcel ou Rollup começou no Deno eu acabei levando uns sustos quando fui testar no Node.

Para começar eu não sabia que o import.meta.main era algo exclusivo do Deno. Achei que fosse algo "padrão", já que o Deno se valoriza tanto por isso. Acabei fazendo isso um desafio: escrever uma função que retorna se um módulo é o principal ou não:

export default function isMain (meta) {
  if (meta.main) return true
  if (typeof Deno !== 'undefined') return false
  if (typeof document !== 'undefined') {
    return Array.from(document.scripts).some(e => e.src === meta.url)
  }

  if (typeof process !== 'undefined') {
    const calledScript = process.argv[1]
    const normalize = e => e.split(/[/\]/).pop().toLowerCase().replace(/..*$/, '')
    return normalize(calledScript) === normalize(meta.url)
  }

  if (typeof WorkerGlobalScope !== 'undefined') {
    return self.location.href === meta.url
  }

  throw Error('could not find if module is main')
}

No Deno e em navegadores funciona bem mas no Node é uma gambiarra. Há um módulo no NPM que faz isso e, claro, deve fazer melhor. Espero que no futuro isso seja padronizado.

Um outro experimento que resolvi fazer foi pegar o MKV Extract e migrar ele de JavaScript para TypeScript, de CommonJS para ESM, e de Browserify para Parcel. Além disso agora ele usa GitHub Actions o que significa que não preciso ficar compilando no meu computador o site se alguém enviar um pull request corrigindo alguma coisa, é bem mais prático.

Quero terminar de arrumar esses scripts logo: as partes que dependem do MAL já estão dando problemas (mesmo com a API não oficial) e, como eu disse antes, em setembro a API que eu estava usando para gerar as estatísticas vai parar de funcionar. Na prática estou só organizando as coisas: ao invés de ter um monte de informação espalhada em uma planilha e um monte de arquivos JSON e TXT o meu plano é juntar tudo em um único ponto.

Assim que eu terminar vai ficar mais fácil gerar as estatísticas e ainda quero fazer um aplicativo para celular para poder votar nos animes sem precisar de internet. Claro, estamos na época onde todo mundo tem internet a qualquer momento, mas pelo menos nisso eu não sou todo mundo: minha internet é tão ruim que a conexão cai até dentro de casa!

Eu quero fazer um gráfico da nota de cada anime por episódio. É uma pena que só vou implementar isso depois de mais de cinco anos que comecei a coletar esses dados, mas antes tarde do que nunca. Enfim, isso é tudo por hoje, até semana que vem.

O post Experimentando com módulos apareceu primeiro em o canto do qgustavor.

O Speck é uma cifra de bloco, ou seja, é uma função que toma uma chave e uma entrada e ela retorna uma versão criptografada desta entrada. Esse processo também pode ser invertido. O resultado é tal que, mantendo a chave, uma pequena diferença na entrada resulta em uma grande diferença no bloco, em oposição uma cifra de stream onde isso não ocorre.

Em geral os dois tipos de cifras usam vetores de inicialização para evitar problemas relativos a descobrir a entrada com base em comparações das saídas, porém em situações onde as entradas são menores que o tamanho dos blocos e a entradas nunca se repetem, as cifras de bloco permitem dispensar o uso desses vetores, o que permite uma redução na quantidade de dados transmitida.

Ele não é só uma cifra, mas uma família. Se for implementada corretamente ela suporta blocos de 32, 48, 64, 96 e 128 bit, com chaves variando entre 64 bits e 256 bits. Além disso é simples de implementar: a minha implementação dele tem apenas 81 linhas (incluindo linhas em branco, comentários e funções auxiliares) e suporta todas as variações dessa família de cifras. Uma implementação mais simplificada, implementando apenas uma cifra da família, pode ser implementada em 24 linhas de JavaScript.

Agora, qual é o problema do Speck? Por que eu não uso ele em situações que precisam de segurança? São vários problemas! O primeiro problema é desde que ela foi criada pela NSA e publicada em 2013, ainda que ninguém tenha publicado um ataque completo à cifra, a reputação da cifra é péssima! Ela não conseguiu ser padronizada pela ISO, foi removida do kernel do Linux e foi alvo de várias críticas.

O outro problema é fácil de ser notado: o tamanho dos blocos é pequeno demais. Isso facilita vários tipos de ataques. Um bloco de 32 bits, por exemplo, só permite 4.2 bilhões de entradas diferentes, o que parece muito, mas não é. Um bloco de 128 bit, que é tão comum que estou usando ele exatamente agora para acessar o meu editor, é 10^28 vezes mais seguro.

Mesmo assim eu gosto do Speck! A forma que ele trabalha permite que os blocos sejam de qualquer tamanho múltiplo de 2 bits, então posso usar um bloco de 12 bits se eu quiser. Além disso o tamanho da chave é limitado apenas pelo número de ciclos da operação, então posso usar chaves de 512 bits se eu quiser. Duvido que seja seguro, mas é uma melhoria enorme.

Se não estão entendendo, eis um exemplo prático:

• A lista de erros da Crunchyroll tem milhares de imagens cadastradas, cada uma é representada internamente por um número;
• Alguns erros não são publicados seja porque não era realmente um erro ou porque cadastrei antes do episódio estar disponível para não-assinantes[^1];
• Se eu publicasse o número interno das imagens seria possível descobrir facilmente quantos erros eu já cadastrei no total, incluindo os que não foram publicados;
• Usando o Speck posso manter estes erros ocultos transformando o número da imagem – algo como "123" – em um código como “RD5JM2”;
• Esse código é o número representado como um bloco de 30 bits, processado pelo Speck e codificado em Base32. Como cada caractere nesse formato representa 5 bits o código usa 6 caracteres. Como o tamanho máximo do bloco é 30 bits, posso cadastrar até um pouco mais de um bilhão de erros.

Imagino que não seja muito difícil inverter a operação e descobrir os números originais das imagens: tentar as 10^18 chaves possíveis, considerando que o Speck é absurdamente rápido, não deve demorar muito. Se fizermos um benchmark simples a minha implementação processa 7 milhões de chaves por segundo, uma mais otimizada deve processar cem vezes isso, alguém atacando a chave provavelmente usaria umas cinquenta máquinas em paralelo, assim a chave poderá ser quebrada em menos de um ano.

É isso o que tenho para hoje, até semana que vem!

[^1]: É um exercício adicional para o leitor entender o motivo real deste problema.

O post Speck apareceu primeiro em o canto do qgustavor.

Porém me deparei com um detalhe: é comum encontrar pessoas disponibilizando vídeos pelo MEGA em MKV, porém nenhum navegador que eu conheço suporta esse formato. O que resolvi fazer? Investigar uma forma de resolver esse problema.

Comecei lendo as especificações do formato. Ainda não consegui resolver o problema, mas consegui desenvolver uma ferramenta que roda direto no navegador e consegue trabalhar com arquivos nesse formato: https://qgustavor.github.io/mkv-extract/

Essa ferramenta faz apenas o básico: ele abre o arquivo e extrai o conteúdo de algumas partes dele, no caso os anexos (geralmente fontes, embora as vezes seja possível encontrar imagens e outros conteúdos) e as fontes. Não coloquei para extrair o vídeo e o vídeo já é mais complicado, talvez eu não implemente isso já que é bem provável que eles não funcionem sem um container.

Enfim, essa é só uma etapa: quem sabe no futuro estaremos assistido vídeos MKV direto do navegador? Seria prático, não é?

O post MKV Extract apareceu primeiro em o canto do qgustavor.