El nuevo codificador AAC de FFmpeg 9.1

 (hydrogenaudio.org)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El codificador AAC nativo de FFmpeg fue reescrito por completo, incluyendo rate control, RDO y PNS·TNS·I/S·M/S, con el objetivo de alcanzar una calidad comparable directamente con codificadores AAC externos
  • La nueva implementación funciona de forma cercana a un CBR estricto, y no se recomienda usar un modo VBR real basado en -q:a
  • En comparaciones con Zimtohrli y ViSQOL, el nuevo codificador nmr mostró en general mejores resultados que fdk-aac y Apple AAC en el rango de 64~256 kbps, pero Opus siguió manteniendo ventaja en comparaciones aparte
  • PNS·TNS·I/S·M/S se seleccionan dentro del bucle RDO, y si se espera un downmix se recomienda usar -aac_is 0 -aac_pns 0 para preservar la fase
  • Aunque hubo muchas evaluaciones positivas a partir de 128 kbps, el estéreo a 64 kbps, algunas muestras con TNS y el contenido de voz siguen siendo áreas que requieren validación adicional

Reescritura completa del codificador AAC de FFmpeg

  • El codificador AAC de FFmpeg fue reescrito por completo, incluyendo rate control, RDO, PNS, TNS, I/S y M/S
  • El PR de la reescritura se compartió como candidato a integración, y en el hilo posterior se confirmó la fusión real
  • Ya se puede probar compilando desde el código fuente o después de la actualización de BtbN nightly builds
  • El nuevo codificador puede usarse con el códec aac
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • Desactivar I/S: -aac_is 0
    • Desactivar PNS: -aac_pns 0

Métricas de calidad y comparativas

  • En la comparación se usaron Zimtohrli y ViSQOL de Google, además de pruebas auditivas
    • En Zimtohrli, cuanto más bajo, mejor
    • En ViSQOL, cuanto más alto, mejor
  • En la tabla, el nuevo codificador aparece como nmr, y se compara con el FFmpeg 8.1 anterior fast·twoloop, fdk-aac, Apple AAC y libopus
  • Resultados representativos:
    • 64 kbps: nmr 0.00309 / 3.83, fdk-aac 0.00322 / 3.69, Apple 0.00612 / 3.29, libopus 0.00100 / 4.59
    • 128 kbps: nmr 0.00072 / 4.47, fdk-aac 0.00143 / 4.27, Apple 0.00081 / 4.44, libopus 0.00020 / 4.68
    • 256 kbps: nmr 0.00031 / 4.61, fdk-aac 0.00103 / 4.45, Apple 0.00067 / 4.63, libopus 0.00002 / 4.73
  • En bitrates altos, Zimtohrli se satura, así que ViSQOL se usó como desempate, y con ese criterio el nuevo codificador quedó por delante en todas las comparaciones excepto frente a Opus

Diseño centrado en CBR y herramientas de codificación

  • El nuevo codificador fue diseñado casi exclusivamente para CBR, y la variación del bitrate es muy pequeña
    • El objetivo de presupuesto de bits ayuda a la calidad de codificación
    • No se recomienda usar un modo VBR real basado en -q:a
  • En la comparación, otros codificadores casi no usan herramientas de codificación aparte de TNS, y el nuevo codificador primero se comparó usando solo TNS antes de reimplementar PNS, I/S y M/S
  • Según resultados de ingeniería inversa, qaac no aplica optimización perceptual y usa una curva de asignación de bits que favorece las altas frecuencias junto con energía por banda
    • El nuevo codificador usa una curva similar con masked band energy dentro del RDO
  • Todas las herramientas de codificación, PNS, TNS, I/S y M/S, se seleccionan dentro del bucle RDO
    • No se usan heurísticas fijas ni cortes arbitrarios por bitrate
    • Las herramientas disponibles se aplican según la decisión del RDO
  • En bitrates altos, si el propio codificador ya funciona lo suficientemente bien, herramientas como I/S y PNS se desactivan solas para mantener el bitrate

Compatibilidad con decodificadores y precauciones con downmix

  • El decodificador AAC de FFmpeg tiene problemas al procesar stereo PNS, y el mismo bug podría existir en otros decodificadores AAC, por lo que se evita desde el codificador
    • Como los codificadores anteriores no usaban PNS, este problema no había salido a la luz hasta ahora
  • Si se planea hacer downmix, o existe la posibilidad de que la salida termine con downmix, se recomienda usar -aac_is 0 -aac_pns 0
    • El objetivo es preservar la fase de la señal original
  • Que en el espectrograma aparezcan muchos huecos es un comportamiento intencional
    • Las bandas enmascaradas se ponen en 0 o se procesan con PNS
    • Si las bandas vecinas son lo bastante fuertes como para que la banda faltante sea difícil de percibir, se prefiere codificar mejor las bandas audibles en vez de codificar mal todas las bandas

Frecuencia de muestreo y política de cutoff

  • El codificador está optimizado principalmente para audio de 48 kHz
    • También funciona con 44.1 kHz y 96 kHz
    • Si se busca la mejor calidad, se recomienda usar 48 kHz
  • Los benchmarks publicados se hicieron mayormente en 44.1 kHz, y los datos ajustados al oído fueron de 48 kHz
    • Parte de la lógica de windowing/transient está ligada a 48 kHz
    • Como la diferencia de timing en 44.1 kHz no es grande, se dejó así
  • Después se ajustó la política de ancho de banda
    • 128 kbps se limita a 16 kHz
    • 160 kbps o más se limita a 18 kHz
    • En 192 kbps por canal se cambió para codificar todo el espectro por encima de 20 kHz
  • En estéreo a 64 kbps no hay mucho margen de maniobra, y aumentar más el PNS puede arruinar la imagen estéreo
    • A 64 kbps, incluso 15 kHz podría ser demasiado alto, por lo que se pidió volver a probar un cutoff de 12 kHz
    • En mono se puede usar mucho más PNS porque no hace falta evitar el bug del decodificador

Alcance de las pruebas y estadísticas de depuración

  • Las pruebas del desarrollo se realizaron sobre una colección musical de 3000 pistas
    • El contenido de voz se probó muy poco, así que podría requerir optimización adicional
  • El codificador imprime estadísticas adicionales al terminar
    • Ejemplo: Qavg: 207.975 Tr: 5.3% TNS(L): 4.8% TNS(S): 36.9% M/S: 3.9% I/S: 10.0% PNS: 5.1%
  • Significado de las estadísticas:
    • Qavg: valor lambda promedio; cuanto más alto, más difícil es mantener la tasa
    • Tr: short blocks
    • TNS(L): tasa de uso de TNS en frames largos
    • TNS(S): tasa de uso de TNS en frames cortos
    • M/S: tasa de uso de codificación Mid/Side
    • I/S: tasa de uso de codificación intensity stereo
    • PNS: tasa de uso de perceptual noise substitution
  • Si se detectan artefactos molestos, se puede analizar si se entrega la muestra de entrada original junto con esta línea de estadísticas

Pruebas iniciales de usuarios y problemas pendientes

  • Un usuario probó una sola canción, Burn the Boats, a 64 kbps, 134 kbps y 200 kbps
    • 64 kbps suena bien, pero tiene algunos artefactos leves
    • 134 kbps y 200 kbps suenan muy bien
  • En otra prueba, hubo comentarios de que en la muestra The Tower a 64 kbps el nuevo codificador nmr se siente más smeary y metálico que el twoloop anterior
    • El twoloop anterior también tiene problemas de colapso al inicio, además de ruido y aspereza general
  • En la muestra fatboy_30sec, a 192 kbps se escucharon ticking sounds en 6.836 s y 10.480 s, y después de remuestrear a 48 kHz apareció además un tick en 14.125 s
    • Si se desactiva TNS con -aac_tns 0, desaparecen esos ticks
    • Luego siguió la petición de comprobarlo subiendo el valor TNS_PG_C1_SHORT de libavcodec/aacenc_tns.c a 3.2, 4.2 y 5.0
  • Un usuario opinó que, a 64 kbps y con cutoff de 16 kHz, Fraunhofer AAC suena mejor, mientras que el nuevo codificador suena metálico
    • El mismo usuario evaluó que el nuevo codificador funciona bien por encima de 128 kbps
    • También comentó que ya existe por fin un codificador AAC suficientemente usable y ampliamente accesible dentro del FFmpeg nativo

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News

  • Un caso que muestra lo fuerte que es Opus
    Este tipo de trabajo en sí mismo tiene valor, y que mejoren los codificadores para códecs antiguos claramente es una ventaja, pero viendo las cifras de Opus en este benchmark, incluso a 64 kbps aplasta a todos los codificadores AAC

    • La mayor ventaja de un buen codificador AAC no es la eficiencia, sino la compatibilidad
      Durante casi 20 años, el estándar de facto para video en streaming en tiempo real fue RTMP con video H.264 y audio AAC, y casi no había soporte para otros códecs
      Si quieres enviar un stream a YouTube o Twitch, al final terminas mandando H.264 y AAC, y OBS ni siquiera permite elegir otros códecs de video o audio en modo streaming, asumiendo que el streamer va a usar H.264 y AAC
    • Hasta antes de entrar al artículo, por un momento me confundí y pensé que Opus se refería a un modelo y no a un codificador
    • Elegir un códec de audio con pérdida ya casi no requiere pensarlo
      Simplemente usas Opus y listo, y si por alguna razón no puedes usar Opus, entonces usas AAC con un bitrate muy alto por compatibilidad
      Ya no hace falta investigar qué codificador y qué modo escoger para obtener buena calidad
      Aun así, está genial que exista un codificador AAC predeterminado de buena calidad, aunque no entiendo bien por qué es principalmente de bitrate constante
    • [https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/Fil...](https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/File:Opus_bitrate+latency_comparison.svg)
    • Creo que el mayor problema de Opus es la falta de especificación: https://nothings.org/stb/stb_opus.html
      Por eso casi no se usa Opus en juegos o distribuciones para tiendas donde podrían surgir ciertos problemas de licencia

  • Tengo curiosidad por ver cuál será el rendimiento real
    El codificador AAC anterior de FFmpeg tenía mala calidad de salida y a menudo producía artefactos molestos como chirridos, así que para obtener un sonido decente había que instalar el codificador Apple Core Audio en cada computadora usada para grabación de video
    Si hacías una comparación A/B/X, un MP3 a 320 kbps sonaba mejor que un AAC a 320 kbps codificado con FFmpeg, y se parecía a un AAC a 256 kbps codificado con Core Audio
    Si ahora ya no hace falta instalar Core Audio, sería una gran mejora, y la gente que hace grabación de pantalla o streaming con herramientas como OBS podría notar una mejora importante en la calidad de audio en la próxima actualización

    • Respecto a Apple Core Audio, qaac es útil
      Envuelve las DLL de iTunes para Windows y las convierte en una herramienta de codificación independiente con CLI, y según entiendo también funciona en Wine sobre Linux: https://web.archive.org/web/20250814194428/https://www.andre...
      No necesitas necesariamente una Mac ni una instalación completa de iTunes para codificar AAC de alta calidad
    • Yo estaba usando el codificador FDK AAC, y no sabía que el codificador de Apple podía usarse también fuera de sistemas Apple
      Cuando comparé FDK AAC y Apple AAC a 192 kbps hace tiempo, no noté diferencia, pero el codificador AAC anterior de FFmpeg se venía abajo a ese bitrate
    • En la tabla de métricas del hilo de discusión de Hydrogenaudio, el nuevo codificador obtiene mejor puntuación que Core Audio
      Pero eso es con bitrate constante
      Core Audio también tiene TVBR, un modo de bitrate variable que el nuevo codificador no tiene
      Así que, en situaciones donde se pueda usar TVBR, Core Audio podría seguir siendo el mejor, pero espero que si más gente encuentra muestras problemáticas y contribuye, el nuevo codificador de FFmpeg también termine quedando bastante bien ajustado
    • Si te importa la calidad, me pregunto por qué no usar un códec sin pérdida
      O simplemente usar Opus; también va bien para voz y hoy en día funciona casi en todas partes
    • No entiendo por qué Apple sigue aferrándose a códecs privativos
      Si Apple no hubiera adoptado H.265, quizá estaríamos viviendo en una utopía de AV1

  • Me pareció interesante la parte que dice: “El decodificador AAC de FFmpeg tiene un bug en el manejo de PNS estéreo, y puede que otros decodificadores AAC también lo tengan, así que el codificador lo esquiva. Como otros codificadores no usaban PNS, no se había descubierto hasta ahora”
    No sé qué es PNS, pero suena a algo que seguramente ha estado fastidiando durante 20 años el caso de uso ultraespecífico de alguien

    • Había dos problemas
      Uno era que, si usabas TNS sobre PNS, el ruido insertado quedaba moldeado por TNS, lo cual no tiene sentido porque quien genera el ruido no es el codificador sino el decodificador
      Eso rompía PNS, y el problema mayor era que, al usar PNS junto con ciertas herramientas estéreo, el ruido se filtraba de forma idéntica en ambos canales y arruinaba la imagen estéreo
      Por eso, lo mejor es activar PNS solo cuando la banda correspondiente en ambos canales sea ruido, o sea lo bastante no tonal como para quedar enmascarada
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • Una excelente actualización con los detalles muy bien organizados
    Opus es excelente y tiene su lugar, pero AAC no va a desaparecer

  • Hay una parte que dice: “El codificador está optimizado principalmente para audio de 48 kHz. Acéptalo. Es 2026, el remuestreo es gratis y 48 kHz es el estándar. 44.1 kHz funciona y 96 kHz también, pero si quieres la mejor calidad, usa 48 kHz”; ¿de verdad 48 kHz es el estándar hoy en día?

    • Lo más cercano a un “estándar” real sería AES5-2018, “prácticas recomendadas para audio digital profesional”
      En el resumen dice que para la producción, procesamiento e intercambio de programas de audio que usan PCM se recomienda una frecuencia de muestreo de 48 kHz; también reconoce 44.1 kHz para algunas aplicaciones digitales de consumo, 32 kHz para aplicaciones relacionadas con transmisión y 96 kHz para aplicaciones que requieren mayor ancho de banda o filtros antialiasing más relajados
      Personalmente, siento que 44.1 kHz es una pequeña molestia heredada del pasado
    • AAC tiene una característica rara donde el tamaño de ventana cambia según la frecuencia de muestreo
      Por eso, ventanas de 20 ms y 60 ms suenan muy distinto para el oído humano, así que hay que volver a optimizar por completo todos los parámetros psicoacústicos del codificador para cada frecuencia de muestreo
      En Opus, por supuesto, este problema ya está resuelto
    • 48 kHz hace mucho más fácil alinear video y audio
      Por ejemplo, facilita la sincronización labial después de la edición
    • Entiendo que el códec Opus asume que toda entrada es de 48 kHz y la remuestrea hacia ahí
    • Casi todos los DAC funcionan por defecto a 48 kHz porque el sistema operativo lo elige como un valor predeterminado razonable

  • Se agradece un nuevo y mejor codificador AAC en FFmpeg, pero hay dos advertencias bastante importantes en los detalles
    Solo soporta tasa de bits constante y solo está optimizado para muestreo de 48 kHz
    No poder hacer codificación con tasa de bits variable basada en calidad es una gran carencia, y considerando que el audio de CD en todo el mundo es de 44.1 kHz, esto también parece una omisión importante

    • No entiendo por qué se necesitaría tasa de bits variable para codificación de audio
      El audio con tasa de bits variable suena horrible y tampoco ahorra demasiada tasa de bits
    • Si usas -q:a, puedes usar VBR “de verdad”, pero las métricas salen unos cuantos puntos porcentuales más bajas
      Aun así, creo que es difícil de percibir y que igual sigue ganando
      Los benchmarks se hicieron principalmente en 44.1 kHz, y los datos ajustados de oído eran de 48 kHz, así que parte de la lógica de ventanas y transitorios está atada a 48 kHz
      Aun así, se trasladó bastante bien a 44.1 kHz y la diferencia de temporización no es grande, así que se dejó tal cual

  • Es interesante que tanto de esto dependa del propio oído del desarrollador
    Al mismo tiempo da algo de inquietud y también es bastante genial; la evaluación de calidad de audio es así de subjetiva

    • Para las tablas y comparaciones se usaron “el nuevo Zimtohrli de Google, ViSQOL y mi audición”
    • En audio suele ser así
      Musepack también fue popular en un nicho durante un tiempo; era un códec simple, pero muy bien ajustado
      Con bocinas y audífonos pasa lo mismo: la gente cree que todo depende de la calidad de los componentes, pero en realidad lo que más pesa es la comprensión general de la física del audio y la capacidad de ajustar bien el sistema

  • Es una adición muy bienvenida
    Ojalá ahora pueda reemplazar a fdk-aac

  • Alguien ha estado creando el que podría ser el mejor codificador AAC de todos los tiempos, y la primera reacción es que los administradores se pongan a discutir si es 48 kHz o 44 kHz; muy internet clásico

    • Tampoco hay que verlo con tanto cinismo
      El autor en realidad no lo probó en la frecuencia de muestreo más usada, así que para cualquier proyecto serio sería absurdo tirar a la basura de golpe una canalización en funcionamiento de hace décadas
      Es totalmente razonable esperar hasta que haya validación suficiente

  • Antes, cuando codificaba canciones para un iPod nano con ffmpeg, los archivos salían corruptos
    Durante la reproducción se metían pops y clics cada pocos segundos; me pregunto si eso ya se arregló