viernes, 20 de enero de 2017

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


Tras el shock inicial que supuso el artículo publicado hace unos días en este mismo espacio, Cómo (no) usar Audacity y Spek para llegar a conclusiones erróneas (I), en el que se discutía el uso incorrecto de aplicaciones de procesado y análisis de audio, vamos ahora con la no menos intrigante (espero) 2ª parte.


El Emepretés, ese formato proscrito en cualquier ambiente audiófilo que se precie y que, al mismo tiempo, tanto ha contribuido a democratizar el acceso a la cultura musical y, quizás, a hacer algún que otro descubrimiento asombroso, va a ser precisamente el protagonista de esta segunda entrega.


Fenómeno 2: Encuentros en la 3ª fase con un archivo mp3
¿Quién es ese mp3 y qué le ha hecho a mi archivo wav?

Nuestro experimento consistirá en esta ocasión en:

1. Tomar un archivo wav (pista A).
2. Convertirlo a mp3 utilizando Audacity (pista B).
3. Cargar en Audacity este archivo mp3 y exportarlo como wav (pista C).
4. Comparar los espectrogramas de B y C.

Como todos sabemos, la conversión de un archivo wav en mp3 supone una pérdida de información más o menos audible (en qué medida es algo que nos nos interesa discurtir en estos momentos). Ahora bien, dado que wav es un formato esencialmente transparente, si convertimos una pista de audio mp3 en wav no se producirá absolutamente ninguna pérdida, nos encontraremos con un archivo de un innecesario mayor tamaño pero que debe sonar, medir y pesar exactamente igual. De hecho, esgrimiendo esta certeza, las pistas ogg en mi I test de audio digital fueron recodificadas y publicadas en formato wav para que no fueran inmediatamente distinguibles unas de otras.

¿Estamos de acuerdo? Vamos a ver si es verdad.

Antes de comenzar recordemos que hay que configurar Audacity de modo correcto, tal y como comprobamos en la primera entrega de este artículo, para evitarnos disgustos:


Las pasos necesarios para realizar las 2 conversiones son análogos a los que seguimos en su momento, así que me limitaré en esta ocasión a presentaros las 3 pistas (archivos) de audio resultantes:



Veamos los espectrogramas de las pistas A, B y C que genera Spek:

Espectrograma pista A (wav original)
Clic sobre la imagen para ampliar

Espectrograma pista B (wav > mp3)
Clic sobre la imagen para ampliar

Espectrograma pista C (wav > mp3 > wav)
Clic sobre la imagen para ampliar

Nada inquietante, ¿verdad? En la pista B se aprecia el habitual recorte espectral por arriba (que en cualquier caso queda muy por encima de esos 16 o 17 Khz que algunos se empeñan en señalar, supongo que como consecuencia de utilizar compresores del siglo pasado). Por su parte los espectrogramas de B y C parecen iguales, pero... ¿Seguro que son idénticos?

Recurramos a ImageDiff para hacer una comparación más fina:

Diferencias espectrogramas B y C
Clic sobre la imagen para ampliar

¡Ya la tenemos liada! Esa marea blanca indica que, en contra de la aparentemente obvia apreciación inicial, ambas pistas son distintas. Masivamente distintas. Lo que implica que el formato de archivo wav no es transparente. Fantástico. De nuevo tenemos una brecha espacio - temporal hacia una realidad alternativa abierta ante nuestros ojos.

Superpongamos ambos espectos de las pistas B (mp3) y C (wav exportado) y pongámoslos en movimiento. 

Animación espectrogramas B (mp3) y C (wav final)
Clic sobre la imagen para ampliar

Los espectrogramas no es que sean distintos... es que parecen estar desfasados un número reducido, pero apreciable, de muestras. Para entenderlo debemos recordar en este punto que el eje horizontal del espectrograma representa el tiempo

Carguemos ahora las pistas en Audacity, B (abajo) y C (arriba), para observar sus formas de onda bajo el microscopio:


Como podéis comprobar están perfectamente alineadas. Todo un fenómeno.

Para justificar esto tendremos que sumergirnos en el maravillo mundo de los algoritmos de compresión con pérdidas. Concretamente, nos encontramos con un interesantísimo FAQ técnico en la página de LAME en Sourceforge. LAME es, probablemente, el compresor mp3 más popular en la actualidad, y también el que ofrece resultados de mayor calidad:


El FAQ responde a ciertas preguntas muy apropiadas en estos momentos de confusión:
1. Why is a decoded MP3 longer than the original .wav file?
2. Why does LAME add silence to the beginning each song?
3. Why does LAME add silence to the end of each song?
4. Why cant MP3 files be seamlessly spliced together?
5. What is the size of a MPEG1/2 frame?

Resumiendo un poco: LAME, como todos los compresores que se sirven de estrategias perceptuales para descartar elementos poco audibles y reducir así el tamaño del archivo resultante, se ve obligado a añadir muestras de relleno. Esto es así por la propia naturaleza del proceso de compresión, que debe procesar el flujo de audio en paquetes o tramas parcialmente superpuestas de tamaño fijo para hacer su magia sobre ellas (entre otras muchas cosas, aplicar una MDCT).

Sí, ya sé, es una explicación simplista. Si queréis la dura y aritmética realidad no tenéis más que leeros el FAQ. Y si con eso no os basta aquí tenéis más lectura de evasión: Audio Compression using Modified  Discrete Cosine Transform: The mp3 Coding Standard.

Los descompresores (reproductores) mp3 más avanzados son capaces de identificar, en mayor o menor medida, las muestras de relleno inyectadas en el proceso de compresión y eliminarlas en el momento de la carga o reproducción

Lo que está ocurriendo aquí, precisamente, es que Audacity y Spek decodifican de un modo ligeramente distinto los archivos mp3 que cargamos en ellos. El primero recurre a LAME, como ya sabemos. El segundo, por su parte, emplea la conocida librería FFmpeg. El resultado es el que ya conocemos: las pistas aparecen perfectamente alineadas en Audacity pero claramente desplazadas en el tiempo cuando las analizamos con Spek. Nuevamente nos encontramos con el diablo y sus detalles.

Por si fuera poco, esta particularidad de los compresores basados en MDCT nos permite entender por qué razón es tan complicado conseguir la reproducción gapless (sin cortes) con archivos mp3 a menos que comprimamos todas las pistas en un único archivo mp3 y recurramos a una hoja cue, claro. Distintos reproductores lo consiguen con mayor o menor grado de éxito (transición continua o breve micro interrupción entre pistas), pero es que incluso un codificador mp3 de baja calidad puede dificultar la consecución de este objetivo al más pintado de los reproductores.

¿Y qué pasará si comparamos la pista wav original (A) con la wav obtenida finalmente a partir del mp3 (C).

Espectrogramas:

Animación espectrogramas A (wav inicial) y C (wav final)
Clic sobre la imagen para ampliar

Formas de onda, A (arriba) y C (abajo), en su inicio. El relleno con 0's se hace patente:


Más formas de onda, A (arriba) y C (abajo), esta vez en su final. El decalaje no coincide con el detectado al comienzo del fichero y, además, las muestras finales son distintas. Esto tiene toda la pinta de ser consecuencia del solapamiento de las tramas de audio que se aplica en el ámbito matemático del proceso de compresión a mp3.


Y ya que estamos, comparemos también sus tamaños de archivo, que como era de esperar difieren, siendo ligeramente mayor el wav obtenido a partir del mp3 (pista C, a la derecha).


El archivo wav original y el obtenido como resultado de una conversión intermedia a mp3 no son iguales. Esto ya lo sabíamos. La novedad es que no solo no lo son como resultado de la mutilación espectral característica de la codificación mp3, sino que estas diferencias también proceden de sutiles cambios en el tamaño de los archivos generados causados por los algoritmos de compresión aplicados.

Para concluir, me gustaría mencionar que de repetir estas pruebas con un compresor ogg en lugar del mp3 utilizado no nos encontraríamos con ninguna de las discrepancias, inicialmente misteriosas, que hemos verificado en este artículo. Otra razón, quizás, para preferirlo a mp3 a la hora de optar por un compresor con pérdidas.

No hay comentarios :