Lançamento do Opus 1.5: Opus aprimorado com machine learning

• Mantém compatibilidade total com a RFC 6716 ao adicionar recursos baseados em machine learning para ocultação de perda de pacotes, melhoria da qualidade de voz em baixa taxa de bits e transmissão redundante DRED
• Os novos recursos baseados em ML vêm desativados por padrão e exigem tanto uma opção de compilação quanto uma opção em tempo de execução devido ao tamanho e ao custo de CPU
• O Deep PLC precisa ser compilado com --enable-deep-plc e requer complexidade do decodificador 5 ou superior para funcionar; como afeta apenas o decodificador, não há impacto de compatibilidade
• O DRED é ativado com --enable-dred e também ativa automaticamente --enable-deep-plc; ainda não foi padronizado, e o DRED do Opus 1.5 não é compatível com a versão final, mas detecta incompatibilidades pela versão experimental do bitstream e ignora o payload DRED
• O DRED transmite até 1 segundo de áudio redundante de uma só vez, com sobrecarga de cerca de 12~32 kb/s, funcionando na prática como enviar um pacote de 20 ms cerca de 50 vezes
• Para melhorar voz em baixa taxa de bits, foram adicionados LACE e NoLACE; após compilar com --enable-osce, o LACE é ativado na complexidade 6 do decodificador e o NoLACE na 7 ou superior
• LACE e NoLACE atualmente se aplicam apenas quando o tamanho do frame é 20 ms e a largura de banda é wideband ou superior; como são melhorias independentes do codificador, não há impacto de compatibilidade
• O uso de DRED exige integração mais próxima com o buffer de jitter, e é possível testá-lo com o patch webrtc-opus-ng, um fork do repositório Google WebRTC
• O grupo de trabalho IETF mlcodec está avançando na padronização do mecanismo de extensão do Opus, deep redundancy e aprimoramento de codificação de fala
• Foi adicionado suporte a AVX2/FMA e detecção em tempo de execução, permitindo que o novo código DNN e o codificador SILK usem SIMD de 256 bits em equipamentos compatíveis
• No AArch64, as otimizações ARMv7 Neon foram reativadas, e a extensão Arm dot product é detectada em tempo de execução em Cortex-A75 ou superior para acelerar os produtos internos inteiros de 8 bits do novo código DNN
• Foi adicionado um simulador realista de perda de pacotes, disponível no opus_demo com -sim-loss <percentage> após compilar com --enable-lossgen

[GN⁺]

Comentários do Hacker News

• A principal limitação de codecs como este é CPU e duração da bateria, e gostei do fato de que aqui aplicaram aprendizado de máquina de forma pontual em várias partes e o combinaram com algoritmos tradicionais não baseados em ML, encontrando um bom equilíbrio entre qualidade e uso de CPU
  Por exemplo, no suporte a low bitrate/LACE, dizem que “começaram com ideias comprovadas de post-filter e por cima disso espalharam só a quantidade necessária de magia de rede neural profunda”
  O ponto principal é não colocar amostras de áudio brutas na rede neural. “O áudio em si nunca passa por uma DNN. Como resultado, o modelo fica pequeno para os padrões de DNN e com complexidade muito baixa, podendo rodar até em celulares antigos”
  Parece a direção certa para algoritmos embarcados e, comparado ao atual modismo de aprendizado de máquina de ponta a ponta, isso parece uma área bem menos explorada

  • É um caso de uso muito inteligente de aprendizado de máquina. Ele fica na periferia, ajudando, e evita que algoritmos de ML acabem inventando fonemas ou palavras inteiras por acidente
    Reconhecimento de fala baseado em ML também vai melhor em alguns benchmarks, mas tem um trade-off parecido de alucinar resultados

• Uso Opus como um dos principais codecs na biblioteca de streaming de áudio P2P (https://git.iem.at/cm/aoo/ - ainda em alpha), então é uma notícia muito bem-vinda
  Com certeza pretendo testar pessoalmente os novos recursos de aprendizado de máquina

• É realmente absurdo o quão impressionante é conseguir essa qualidade de voz com NoLACE a 9kbps

  • Em 1999, eu era o desenvolvedor líder de uma grande startup de streaming de música. Ainda nem tínhamos escritório, então eu trabalhava de casa, mas a conexão a cabo caiu e minha internet restante era só 9600bps via porta serial de um Nokia 9000
    Para continuar testando o código de produção, eu precisava reencodar e transmitir todo o catálogo musical em WMA de 8000kbps
    A qualidade deixava um pouco a desejar
  • Eu queria muito ver como isso soaria em comparação com um codec de streaming de áudio realmente inicial, o realaudio 1.0
    $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
    Como talvez não seja suportado, deixei também reconvertido para wav: http://9ol.es/female_ref-ra.wav
    Isso era considerado áudio “14.4” para conexão discada de 14.4kb/s em meados dos anos 90. É realmente impressionante o quanto a qualidade que se consegue com, na prática, ainda menos bytes melhorou em quase 30 anos

• É interessante como codecs de áudio, síntese de voz e reconhecimento de fala evoluem de forma interligada. O avanço em uma área normalmente leva a avanços nas outras

• Minha curiosidade é se abordaram as questões éticas de aprendizado de máquina mais comuns. Especificamente, se o algoritmo funciona melhor ou pior com vozes masculinas e femininas, como ele se sai em diferentes idiomas e dialetos, e se foi ajustado apenas para fala ou se também funciona bem com música ou canto de pássaros
  Ainda assim, os exemplos são impressionantes, e espero que esse nível de inteligibilidade vire padrão em chamadas telefônicas

  • Segundo o artigo, o treinamento foi feito com “205 horas de fala em 16kHz vindas de uma combinação de conjuntos de dados TTS com 34 idiomas e dialetos e mais de 900 falantes”
    Eles testaram principalmente em inglês, mas, como isso ainda não é padronizado, um dos motivos para divulgar cedo foi justamente fazer as pessoas testarem por conta própria e relatarem problemas
    A proporção entre falantes homens e mulheres é quase igual. Ainda assim, codecs sempre acabam tendo algum pequeno viés de qualidade perceptiva para um lado ou para o outro dependendo da altura da voz. E tudo isso aqui é voltado exclusivamente para fala
  • É uma pergunta importante, mas viés parecido também pode existir facilmente em algoritmos ajustados manualmente e não baseados em ML
    Nesses casos também se usam conjuntos de teste e, às vezes, até conjuntos de “treinamento” e “validação” para encontrar bons parâmetros. Esses dados, ou mesmo os ouvidos dos avaliadores que tomam decisões, podem ser fontes de viés
    Em aprendizado de máquina essa questão surge com frequência porque, fundamentalmente, o algoritmo não funciona sem dados, mas todos os algoritmos são projetados por pessoas e muitos usam dados para definir parâmetros. Ambos podem ser fontes de viés
    Acho que o motivo de ML ficar mais em evidência é que ele tem menos viés indutivo do que algoritmos tradicionais, então absorve com mais facilidade os vieses presentes no conjunto de dados
  • Não entendo por que a questão ética seria importante. Isto é um novo recurso de codec de áudio, não um novo material para colocar no currículo escolar das crianças
  • Como alguém que usa outros idiomas e sotaques, passo por isso com frequência. O falante nativo não tem problema, mas assistentes como a Siri simplesmente não entendem o que eu quero dizer
    Antes de UTF se tornar amplamente usado, sites e apps também ignoravam caracteres especiais do meu idioma, algo parecido
    Eu vejo isso mais como limitação técnica ou ignorância do que como uma questão ética

• Fiquei pensando em incluir junto um fluxo de legendas em texto. O encoder poderia converter a fala em texto com ML, e o decoder poderia usar esse texto junto com o áudio ao redor das falhas para alimentar uma DNN de conversão condicional de texto em fala
  Assim, a rede não precisaria aprender o problema mais difícil de interpolar cegamente os trechos perdidos olhando apenas para o áudio. O fluxo de texto tem bitrate baixo, então daria até para colocar uma redundância considerável para aumentar a chance de uma determinada mensagem de texto ser recebida

  • Na prática, o que o DRED faz não é tão distante assim dessa proposta. A diferença é que ele preserva mais informações sobre a voz/prosódia e não precisa da latência extra introduzida por ASR
    No fim, a saída é sintetizada a partir de informação de nível mais alto e comprimida de forma eficiente

• Muito legal. Parece que trataram do problema de alucinação. Seria interessante ver exemplos em que a alucinação aparece quando não há redundância e é corrigida pela redundância

  • O concealment de perda de pacotes (PLC) não é uma forma de alucinação? Não no sentido de ser ruim, mas no sentido de inventar coisa de forma estatisticamente plausível, tipo Making Shit Up™

• Fico curioso se esta nova versão do Opus reduziu a diferença para o xHE-AAC, que era superior em bitrates baixos

  • Depende se você está codificando fala ou música

• É bom ver que o Opus 1.5 agora é praticamente transparente para voz até em 16kbps e que, a 96kbps, ainda continua melhor que MP3 a 192kbps
  Já o xHE-AAC, na faixa de 96~256kbps, ainda parece meio mal acabado, porque na prática soa pior até do que AAC-LC em cerca de 160kbps (Apple, FDK)

• Fico imaginando se não seria útil algum profiler ou configuração que ajudasse a evitar adicionar artefatos demais ao reencodar formatos com perdas já existentes
  Coleções grandes esbarram nesse problema quando não é fácil acessar os originais sem perda
  Se desse para saber que a perda adicional de qualidade é mínima, eu teria bastante interesse em migrar vários arquivos mp3, aac e vorbis para Opus