jueves, 12 de enero de 2017

Cómo (no) usar Audacity y Spek para llegar a conclusiones erróneas (I)

Audacity y Spek son dos aplicaciones, gratuitas y multiplataforma (Windows, OS X, Linux), frecuentemente utilizadas para analizar todo tipo de archivos de audio, cosa a la que como sabéis soy bastante aficionado.


Audacity es un editor de audio multipista, compatible con una enorme variedad de formatos de audio, que además incorpora interesantes funciones de conversión y análisis.


Por su parte, Spek es un analizador de espectro capaz de trazar un gráfico en el que se representa el contenido en frecuencia de una muestra de audio a lo largo del tiempo. Esta herramienta se utiliza a menudo para comparar cuantitativamente la fidelidad de distintos formatos de audio (por ejemplo wav y mp3), reconociendo visualmente las diferencias en los gráficos generados por el programa: si tomo un archivo wav, lo convierto a mp3 (por ejemplo con Audacity) y comparo los espectrogramas de ambos es fácil detectar diferencias en los gráficos que denoten alteraciones en las muestras.


No obstante, pertrechado con tales armas no resulta difícil llegar a conclusiones erróneas, del tipo que desafían la lógica, cuestionan la naturaleza determinista de los algoritmos que ejecuta un ordenador e incluso ponen en duda la naturaleza esencial del universo audiófilo.

Veamos 2 ejemplos y, aprovechando la ocasión, introduzcamos también otras herramientas para enriquecer nuestro kit de de análisis digital.

Fenómeno 1: ¿Seguro que los bits son bits?
Los algoritmos de compresión sin pérdidas realmente sí pierden cosas (a veces)

Esta es una de las cuestiones más discutidas en foros como AudioPlanet. Es más, posiblemente a estas alturas muchos aficionados sigan creyendo a pies juntillas (o por el rabillo del ojo, que viene a ser lo mismo) que en la conversión de un archivo de tipo wav (recordemos, sin compresión de ningún tipo) a flac o alac (compresión sin pérdidas) se alteran a peor, de algún modo sutil e inaprensible, las muestras de audio presentes en el archivo original.

Los lectores más atentos habrán captado que en ningún momento estoy revoloteando alrededor de la afirmación (también recurrente) de que los archivos wav o aiff suenan mejor que los flac o alac.

Me quedo un par de pasos más atrás en la cadena de reproducción, en las intrincadas profundidades de los bits almacenados en los archivos de audio. Es más, me voy a cuidar muy mucho de dar un paso más allá, lo que por otra parte sería probablemente innecesario puesto que reputados gurús del mundillo, que en los últimos años han abrazado la nueva realidad digital que ha invadido esta afición, tales como John Darko, han encontrado ya una certera explicación a este singular fenómeno.

Less obvious to casual observers or computer audio newcomers is how software coders can elevate their app’s sound quality by reducing its thirst for CPU cycles and RAM, in turn reducing the amount of electrical noise generated.

Nada más que decir por mi parte, por tanto, sobre tan espinosa cuestión.

Volvamos a la afirmación inicial, que cuestiona la transparencia de una codificación con compresión pero sin pérdidas como es flac y vamos a ver qué nos cuentan Audacity y Spek. Para ello cualquier aficionado puede plantearse un sencillo experimento:

1. Descargar e instalar tanto Audacity como Spek en el ordenador.
2. Cargar un archivo de tipo wav en Audacity (pista A).
3. Exportar el archivo en formato flac (pista B).
4. Cargar el archivo flac en Audacity y re-exportarlo en formato wav (pista C).
5. Obtener y comparar la representación espectral de las pistas A y C.

Tomamos un archivo wav y lo recodificamos en flac. En este punto se habrán producido (o no) pérdidas. Dando un salto mortal, lo volvemos a convertir a wav y obtenemos los espectrogramas de ambos archivos, wav de partida (A) y final (C). Si ambos gráficos presentan discrepancias es que efectivamente la codificación en flac no es transparente (no respeta la integridad de la información presente en el wav original), lo que reforzaría incuestionablemente la postura de aquellos que perciben diferencias audibles cuando se codifica un archivo de audio empleando un formato de compresión sin pérdidas como flac.

El caso es que la constatación experimental de este hecho sería, en mi opinión, equivalente a la existencia de un glitch en nuestro espacio - tiempo, claro. Pero no nos dejemos llevar por este despreciable sesgo cognitivo. Procedamos con el experimento.

Para llevar a la práctica la prueba propuesta he tomado uno de los fragmentos codificados en formato wav utilizados en mi I test de audio digital, concretamente la pista 4, y la he sometido al proceso descrito, que vosotros mismos podéis verificar examinado los archivos de audio implicados y que del mismo modo os invito a reproducir si os apetece.

Aquí las pistas de audio en cuestión:



Aquí un vídeo del proceso seguido (no ajustéis el volumen, no tiene sonido). Probablemente querréis verlo en pantalla completa para apreciar mejor los espectrogramas que se muestran al final:


Quizás apreciaremos mejor el resultado superponiendo las gráficas que representan el contenido espectral de ambas pistas A y C que se ven en los últimos instantes del vídeo:

Animación espectrogramas A y C
Clic sobre la imagen para ampliar

Pero... ¿qué es esto? El archivo wav resultante de esta secuencia de conversiones wav > flac > wav es sutil pero claramente distinto al original ¿Podéis ver cómo los píxeles de la imagen parecen moverse en la zona superior del gráfico? Esto indica que se han producido cambios (pérdidas) que afectan a la parte alta del espectro, en la banda de 20 a 22 Khz. Puesto que las diferencias son evidentes no es necesario practicar una análisis más concienzudo.

Podéis repetir la prueba con cualquier archivo wav que tengáis en vuestro disco duro. El resultado será el mismo.

Después de todo resulta que la codificación en flac, que debería preservar totalmente la integridad de la señal, no lo hace. El mundo se abre bajo mis pies.

La explicación es, afortunadamente, otra. Para encontrarla deberemos bucear en las profundidades de las opciones de configuración de Audacity. Concretamente deberemos dirigirnos a:

Editar > Preferencias > Calidad


Este panel parece controlar algunos parámetros relacionados con el modo en que Audacity transforma la frecuencia de muestreo de las pistas de audio cargadas en la aplicación en determinadas circunstancias (conversión en tiempo real o transformaciones que dan lugar a una nueva pista definitiva). Es posible ajustar la calidad de la conversión y, además, decidir si se aplica dither o una críptica corrección con ruido blanco.

La aplicación de dither (o dithering) es una fascinante técnica empleada habitualmente en procesos de masterización para disminuir el efecto que sobre la calidad percibida tiene la distorsión de cuantización generada por una reducción del número de bits destinados a codificar las muestras, por ejemplo, al convertir audio de 24 a 16 bits. El fundamento matemático es durillo, pero en esencia se trata de sumarle a la pista a recodificar una señal aleatoria de muy pequeña amplitud. Esto hace que la correlación entre el error de cuantización y la muestra original disminuya, lo que se ha demostrado que es percibido como un sonido más natural puesto que el oído es menos sensible a un ruido impredecible que afecte a todas las frecuencias por igual que a las distorsión armónicas causadas por una recuantización a la baja sin dither. Casi nada.

Audacity solo menciona el término dither en los ajustes de conversión en tiempo real. No obstante, el sentido común nos dice que eso de la corrección con ruido blanco que se muestra en las opciones específicas de la conversión de alta calidad no debe ser otra cosa que una forma de dither ¿Una traducción incompleta? Quizás.

Vamos a desactivar este ajuste misterioso, a ver qué pasa.


Y ahora repitamos el experimento de conversión wav > flac > wav...



Veamos qué aspecto tienen ahora los espectrogramas de las pistas A y C2:

Animación espectrogramas A y C2
Clic sobre la imagen para ampliar

Mucho más tranquilizador, ¿no os parece?

Ahora bien... activemos el modo paranoico: Quizás nos estemos perdiendo algo. Quizás haya diferencias aún más sutiles en la imagen que escapan a nuestra vista, por más zoom sobre la animación que hagamos ¿Podemos mejorar este test para estar seguros de que, ahora sí, el formato flac es realmente sin pérdidas?

Por supuesto. Si los ojos nos engañan, recurramos a los algoritmos. Os presento una nueva herramienta denominada Image Diff.


Esta aplicación, que también está disponible para Windows, OS X y Linux, compara pixel a pixel dos imágenes dadas para identificar cualquier diferencia existente entre ellas. Vamos a ver qué pasa cuando la utilizamos para analizar comparativamente las gráficas de los espectrogramas correspondientes a los dos pares de pistas: A/C y A/C2:

 Diferencias espectrogramas A y C
Clic sobre la imagen para ampliar

Diferencias espectrogramas A y C2
Clic sobre la imagen para ampliar

Los puntos blancos en el panel superior de la primera captura representan todos los píxeles que diferencian ambos espectrogramas. Hay muchos más de los que creímos apreciar hace solo un momento al compararlos de un vistazo en la primera de las animaciones. La segunda captura, en cambio, es totalmente oscura. Ni un solo punto blanco se atreve a iluminarse. Esto parece confirmar que, efectivamente, los espectrogramas de las pistas A y C2 son idénticas y, por tanto, flac sí es un códec transparente.

¿Alguien tiene alguna objeción? ¿No? Pues yo sí.

Un espectrograma no es otra cosa que un diagrama bidimensional que representa en el eje horizontal el tiempo y en el vertical la frecuencia. Cada punto del gráfico por tanto se puede denotar mediante sus coordenadas (t,f), calculándose su color a partir de la cantidad de información codificada en la pista de audio en el instante t y para la frecuencia f. Aunque esto no es exactamente así, lo asumiremos como cierto para no complicar en exceso este razonamiento, aceptando por tanto que la vaca es una esfera (mejor os cuento el chiste otro día). Cuando se representa un espectrograma en la ventana de una aplicación hay que encajar los intervalos de tiempo y frecuencia que caracterizan al primero dentro de los límites del área gráfica donde se dibujan, área que lógicamente tiene unas dimensiones limitadas. Lo que quiero poner con esto de manifiesto es que si los algoritmos de cálculo y representación en pantalla no están correctamente diseñados, podría suceder que ciertos detalles espectrales pasaran desapercibidos. Es raro que algo así ocurra con una aplicación, digamos, respetable. Pero no imposible, claro.

Llegados a este punto de locura existencial audiófila, por tanto, solo nos queda una alternativa posible: destripar los archivos y comprobar sus contenido, byte a byte. Y eso es precisamente lo que vamos a hacer.

Me gustaría añadir por tanto a nuestro kit de análisis una nueva aplicación: VBinDiff (Visual Binary Diff). VBinDiff es grande por varios motivos. Uno de ellos tiene que ver con el hecho de que funciona bien incluso con archivos de hasta 4 GB. Afortunadamente los nuestros no van a ser tan voluminosos. Por lo demás se trata de una herramienta sencilla, no dispone de interfaz gráfica ni tampoco de un bonito icono o logotipo que hubieran aportado algo más de vistosidad a esta sección del artículo.

A VBinDiff debemos indicarle qué 2 archivos queremos comparar invocándola mediante un comando como este desde una terminal de comandos:

VBinDiff.exe "Pista A.wav" "Pista C.wav"


Y esto es lo que veremos en pantalla:


En la parte superior tenemos el contenido de la pista A, en la inferior el de la pista B. Las 2 columnas de números a la izquierda representan la posición dentro de los archivos. Cada byte (0 - 255) está representado en notación hexadecimal (0x00 - 0xFF), que como todo el mundo sabe es el sistema de numeración preferido por replicantes y otros seres sintéticos.

De acuerdo con las especificaciones del formato wav, los primeros 44 bytes (que he coloreado de amarillo) son la cabecera y no contienen datos de audio. Los últimos 4 bytes de la cabecera (D4 C1 56 00) indican el número de bytes de datos que siguen a continuación. Como se emplea una ordenación de tipo Little Endian, los bytes deben ser leídos al reves (0x0056C1D4), es decir, 5.685.716 bytes, que sumados a la cabecera de 44 bytes nos da un tamaño total de 5.685.760 bytes. Justo lo que nos indica el explorador de archivos.


Comprobamos que ambas cabeceras son idénticas.

A partir de la posición 0x2C (44 en decimal) se almacenan las muestras de sonido en una representación en complemento a 2 (otra rareza propia de replicantes). Como se trata de audio redbook se emplean 16 bits (2 bytes) para codificar cada una de ellas, esto es, 2 numeritos hexadecimales que, recordemos, deben leerse de derecha a izquierda.

Y ahora sí, lo habéis adivinado, VBinDiff representa en rojo los bytes que difieren de un archivo al otro. Las discrepancias comienzan a partir de la 5ª muestra (posición 0x34 o 52 en decimal). Casi a continuación nos encontramos con un curioso patrón: los bytes que ocupan una posición par difieren habitualmente en muy pequeña medida y los que se encuentran en posición impar son siempre iguales. Recordemos aquello de la ordenación Little Endian y comparemos las muestras una a una:

Pista A: ... 0x0419 0xF2C7 0x05D7 0xF0D6 0x033B 0xEFE0 0x04C0 0xF171 ...
Pista C: ... 0x041A 0xF2C7 0x05D6 0xF0D7 0x033C 0xEFDD 0x04BF 0xF175 ...

La herramienta, con su esplendorosa interfaz de texto, permite el desplazamiento a lo largo y ancho del archivo utilizando los cursores y las teclas de AvPag, RePag, Inicio y Fin. También podemos presionar la tecla Intro para que VBinDiff salte al siguiente byte que difiere en la secuencia del archivo. Obviamente no vamos a comprobarlo porque hasta para un replicante, especialmente para los que son amantes de la música, es francamente aburrido ver cómo interminables secuencias de números hexadecimales se desplazan por la pantalla. Pero creedme cuando os digo que este patrón byte probablemente distinto, byte igual se repite hasta el fin de los tiempos o, lo que es lo mismo, el final de ambos archivos.

Las muestras que se diferencian siempre lo hacen en su byte menos significativo, y además esa diferencia suele ser muy pequeña,  de una magnitud de apenas 3 o 4 unidades en valor absoluto ¿Recordáis en que consistía el dither? Sí, esa señal aleatoria de pequeña magnitud que se sumaba a la original para reducir los errores de cuantización. Acabamos de encontrar a ese señor bajito en las entrañas binarias de nuestras pistas de audio. Por fin todo cuadra.

Como era de esperar, si comparamos ahora la pista A con la C2, obtenida tras desactivar la corrección con ruido blanco en Audacity, nos vamos a encontrar con el resultado esperado (y tranquilizador, añadiría):

VBinDiff.exe "Pista A.wav" "Pista C2.wav"


Ambos archivos, tanto el wav inicial como el obtenido a partir de la conversión intermedia en formato flac, son exactamente idénticos, sin asomo alguno de duda.

Esto demuestra que, contrariamente a las impresiones iniciales, flac (al igual que cualquier otro formato que recurra a la compresión sin pérdidas) es absolutamente transparente y preserva totalmente la integridad de los archivos de audio codificados.

No acabo de entender por qué Audacity, en su configuración predeterminada, inyecta una señal de ruido blanco a modo de dither cuando realiza una conversión de formato, máxime cuando este proceso no lleva parejo necesariamente un reajuste de la frecuencia de muestreo. Pero el caso es que lo hace... y los resultados pueden confundir al más pintado.

Mucho cuidado con los detalles, el diablo suele estar en ellos.


Y aquí la 2ª parte de este artículo:


1 comentario :

Unknown dijo...

Excelente artículo,notable. Vamos a cambiar la configuración de audicity.