Lanzamiento de Opus 1.5: Opus mejorado con aprendizaje automático

• Mantiene compatibilidad total con RFC 6716 al agregar funciones basadas en aprendizaje automático para ocultación de pérdida de paquetes, mejora de calidad de voz a baja tasa de bits y retransmisión redundante DRED
• Las nuevas funciones basadas en ML están desactivadas por defecto y, debido a su tamaño y costo de CPU, requieren tanto un interruptor en compilación como otro en tiempo de ejecución
• Deep PLC funciona al compilar con --enable-deep-plc y configurar la complejidad del decodificador en 5 o más; como solo afecta al decodificador, no tiene impacto en la compatibilidad
• DRED se activa con --enable-dred y también activa automáticamente --enable-deep-plc; aún no está estandarizado y el DRED de Opus 1.5 no es compatible con la versión final, pero detecta discrepancias con el número de versión experimental del bitstream e ignora la carga útil DRED
• DRED transmite hasta 1 segundo de audio redundante de una sola vez, con una sobrecarga aproximada de 12~32 kb/s, en una forma que equivale a enviar efectivamente un paquete de 20 ms unas 50 veces
• Se agregaron LACE y NoLACE para mejorar voz a baja tasa de bits; tras compilar con --enable-osce, LACE se activa con complejidad de decodificador 6 y NoLACE con 7 o más
• LACE y NoLACE actualmente solo se aplican cuando el tamaño de frame es de 20 ms y el ancho de banda es wideband o superior, y como son mejoras independientes del codificador, no afectan la compatibilidad
• El uso de DRED requiere una integración más cercana con el jitter buffer, y se puede probar con el parche webrtc-opus-ng, un fork del repositorio Google WebRTC
• En el grupo de trabajo IETF mlcodec se está avanzando en la estandarización del mecanismo de extensión de Opus, deep redundancy y mejoras de codificación de voz
• Se agregó soporte para AVX2/FMA y detección en tiempo de ejecución, de modo que el nuevo código DNN y el codificador SILK usan SIMD de 256 bits en equipos compatibles
• En AArch64 se reactivaron las optimizaciones ARMv7 Neon y, en Cortex-A75 o superior, se detecta en tiempo de ejecución la extensión Arm dot product para acelerar los productos punto enteros de 8 bits del nuevo código DNN
• Se agregó un simulador realista de pérdida de paquetes, disponible tras compilar con --enable-lossgen y usar -sim-loss <percentage> en opus_demo

[GN⁺]

Comentarios de Hacker News

• La principal limitación de este tipo de códecs es la CPU y la duración de la batería, y aquí me gusta que hayan aplicado aprendizaje automático de forma puntual en distintas partes y lo hayan combinado con algoritmos tradicionales no basados en ML para lograr un buen equilibrio entre calidad y uso de CPU
  Por ejemplo, para el soporte de bajo bitrate/LACE dicen que “partieron de ideas probadas de postfiltro y encima les echaron la cantidad justa de magia de redes neuronales profundas”
  La clave es no meter las muestras de audio crudas a la red neuronal. El enfoque es que “el audio en sí nunca pasa por la DNN. Como resultado, el modelo es pequeño incluso para estándares de DNN y su complejidad es muy baja, así que puede correr incluso en teléfonos viejos”
  Parece la dirección correcta para algoritmos embebidos, y comparado con el aprendizaje automático de extremo a extremo que está de moda hoy, se ve como un área bastante menos explorada

  • Es un caso de uso muy inteligente del aprendizaje automático. Lo dejan ayudar en los bordes, evitando que el algoritmo de ML termine inventando fonemas o palabras completas por accidente
    El reconocimiento de voz basado en ML también funciona mejor en algunos benchmarks, pero tiene un compromiso parecido al alucinar resultados

• En una biblioteca de streaming de audio P2P (https://git.iem.at/cm/aoo/ - todavía en alfa) usamos Opus como uno de los códecs principales, así que esta es una noticia muy bienvenida
  Definitivamente pienso probar yo mismo las nuevas funciones de aprendizaje automático

• Es realmente una locura lo impresionante que es obtener esta calidad de voz a 9kbps con NoLACE

  • En 1999 era el desarrollador principal en una gran startup de streaming musical. Todavía no teníamos oficina, así que trabajaba desde casa, pero se cortó la conexión por cable y el único internet que me quedaba era 9600bps por el puerto serial de un Nokia 9000
    Para poder seguir probando código de producción, tuve que volver a codificar y hacer streaming de todo el catálogo musical en WMA de 8000kbps
    La calidad dejaba algo que desear
  • Siempre quise ver cómo sonaría comparado con realaudio 1.0, un códec de streaming de audio realmente temprano
    $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
    Como puede que no sea compatible, también lo convertí otra vez a wav y lo subí aquí: http://9ol.es/female_ref-ra.wav
    Esto se consideraba audio “14.4” para conexiones telefónicas de 14.4kb/s a mediados de los 90. Es realmente impresionante cuánto ha mejorado la calidad que se puede obtener en casi 30 años con una cantidad de bytes aún menor

• Es interesante cómo los códecs de audio, la síntesis de voz y el reconocimiento de voz avanzan de forma entrelazada. Los avances en un lado normalmente llevan a avances en los otros

• Me pregunto si abordaron las preguntas éticas comunes del aprendizaje automático. En concreto, si el algoritmo funciona mejor o peor con voces masculinas o femeninas, cómo varía según el idioma o el dialecto, y si está ajustado solo para voz o si también funciona bien con música o canto de aves
  Aun así, los ejemplos son impresionantes, y ojalá este nivel de inteligibilidad se vuelva el estándar en las llamadas

  • Según el paper, el entrenamiento se hizo con “205 horas de voz a 16kHz provenientes de una combinación de datasets TTS que incluyen 34 idiomas y dialectos y más de 900 hablantes”
    Se probó sobre todo en inglés, pero como todavía no está estandarizado, una de las razones para publicarlo temprano es que la gente lo pruebe y reporte problemas por su cuenta
    La proporción de hablantes hombres y mujeres es casi igual. Dicho eso, los códecs siempre terminan teniendo cierto sesgo de calidad percibida hacia uno u otro lado según el tono de voz. Y lo que hay aquí es todo exclusivo para voz
  • Es una pregunta importante, pero sesgos parecidos pueden existir fácilmente también en algoritmos no basados en ML ajustados a mano
    Incluso en esos casos se usan conjuntos de prueba, y a veces hasta conjuntos de “entrenamiento” y “validación”, para encontrar buenos parámetros. Tanto esos datos como los oídos de los evaluadores que toman decisiones pueden ser fuentes de sesgo
    En ML estas preguntas sobre sesgo salen seguido porque, en el fondo, el algoritmo no funciona sin datos, pero todos los algoritmos son diseñados por personas y muchos usan datos para ajustar parámetros. Ambos pueden ser fuentes de sesgo
    Creo que el ML es más conocido por esto porque tiene menos sesgo inductivo que los algoritmos tradicionales, así que absorbe con más facilidad los sesgos presentes en el dataset
  • No entiendo por qué serían importantes las cuestiones éticas. Esto es una función nueva de un códec de audio, no un nuevo material para meter en el plan de estudios de los niños
  • Como alguien que usa otros idiomas y acentos, esto me pasa seguido. Para los hablantes nativos no hay problema, pero asistentes como Siri no entienden lo que quiero decir
    Antes de que UTF se usara ampliamente, también pasaba algo parecido con sitios web y apps que ignoraban los caracteres especiales de mi idioma
    Más que un problema ético, lo veo como una limitación técnica o ignorancia

• Me pregunto cómo sería incluir también un flujo de subtítulos de texto. El codificador podría convertir la voz a texto con ML, y el decodificador podría usar ese texto junto con el audio alrededor de los cortes para alimentar una DNN de texto a voz condicional
  Así la red no tendría que aprender el problema más difícil de interpolar a ciegas los tramos perdidos basándose solo en el audio. El flujo de texto tendría un bitrate bajo, así que incluso se podría meter bastante redundancia para aumentar la probabilidad de que llegue cierto mensaje de texto

  • En realidad, lo que hace DRED no está tan lejos de esa propuesta. La diferencia es que conserva mucha más información sobre la voz y la prosodia, y no necesita la latencia adicional que introduce el ASR
    Al final, la salida se sintetiza a partir de información de nivel más alto comprimida de manera eficiente

• Está muy bueno. Parece que aborda el problema de las alucinaciones. Sería interesante ver ejemplos donde las alucinaciones aparecen cuando no hay redundancia y se corrigen cuando sí la hay

  • ¿La ocultación de pérdida de paquetes (PLC) no es una especie de alucinación también? No lo digo como algo malo, pero sí es una forma de Making Shit Up™ de manera estadísticamente plausible

• Me pregunto si esta nueva versión de Opus ya cerró la brecha con xHE-AAC, que era superior en bitrates bajos

  • Depende de si estás codificando voz o música

• Está bueno que Opus 1.5 ahora sea prácticamente transparente para voz incluso a 16kbps, y que a 96kbps siga siendo mejor que un MP3 de 192kbps
  En cambio, xHE-AAC entre 96 y 256kbps en la práctica se ve peor incluso que AAC-LC (Apple, FDK) a unos 160kbps, así que todavía se siente como algo medio improvisado

• Me pregunto si no habría un perfilador o configuración que ayude a no agregar demasiados artefactos al volver a codificar formatos con pérdida ya existentes
  Las colecciones grandes se topan con este problema cuando no se puede acceder fácilmente a las fuentes originales sin pérdida
  Si supiera que la pérdida de calidad adicional es mínima, me interesaría mucho migrar varios archivos mp3, aac y vorbis a Opus