domingo, 29 de enero de 2017

SACD... ¿DSD o PCM? Husmeando en HRAudio.net (aka SA-CD.net)

Una de las discusiones más frecuente en foros audiófilos es la que trata de demostrar la superioridad universal de determinados formatos de grabación y distribución de audio.

Aunque para muchos aficionados esta es una cuestión superada (lo importante no es tanto el formato como el modo en que se ha realizado la toma de sonido, la mezcla y la producción en el estudio), no resulta infrecuente que surjan encendidas y recurrentes discusiones en las que se dan cita partidarios de soportes analógicos, defensores a ultranza de lo digital, adalides de los formatos PCM de alta resolución y, cómo no, abanderados del SACD, ese formato inventado por Sony y Philips a finales del siglo pasado y que, a pesar de su escasa popularidad (poco más de 11.000 discos editados en total a lo largo de 20 años de historia), parece resistirse a morir.

A diferencia del audio codificado en PCM, que emplea un número de bits que típicamente oscila entre 16 y 32 para representar cada muestra de sonido, los discos SACD se sirven de un formato denominado DSD basado en el uso de una modulación digital por densidad de impulsos (PDM). En esencia, se trata de codificar la magnitud de cada una de las muestras de sonido utilizando una señal cuadrada de amplitud máxima constante pero anchura variable, lo que en el ámbito digital, en definitiva, no es otra cosa que un rápido flujo de bits {0,1} colocados en fila india.

Me permitiréis que utilice un fragmento extraído de un artículo ya publicado anteriormente en este blog para profundizar un poquito en esta, en principio, peculiar estrategia de codificación digital.

El formato DSD se caracteriza por emplear una representación basada en muestras de 1 solo bit y una frecuencia de muestreo muy alta, 2,8224 Mhz en el caso de un disco SACD estándar. A esto se le llama también DSD64 porque la frecuencia de muestreo es 64 veces la empleada en un CD adherido al estándar del Libro Rojo (44,1 Khz) o DSDx1 (simplemente DSD). El resultado es por tanto una señal de muy alta frecuencia pero 1 solo bit de resolución.


La codificación DSD presenta una ventaja fundamental con respecto a la PCM. Tanto el proceso de captura de audio (A/D) como el de conversión de digital a analógico (D/A), en el DAC, son mucho más simples, lo que en teoría permite preservar en mayor medida la integridad del fenómeno musical. De hecho, el segundo proceso (D/A) emplea poco más que un filtro paso bajo para reconstruir la señal analógica original. Esto supone una menor distorsión en el proceso de extremo a extremo y permite, en teoría, conservar de mejor modo la naturaleza analógica del audio capturado. El formato ofrece, además, un rango dinámico de unos 120dB (en la banda de 20 Hz a 20 Khz) y una respuesta en frecuencia que se extiende hasta los 100 Khz.

El problema es que la codificación empleada introduce cantidades industriales de ruido, que se empujan, empleando técnicas de conformación, fuera del espectro audible para que no molesten. Este ruido ultrasónico debe ser filtrado en algún punto de la reproducción (reproductor o DAC) para evitar daños en los equipos.

En este gráfico, cortesía de Stereophile, podéis comparar el espectro de un tono de prueba codificado en DSD (arriba) y PCM de 24 bits (abajo). El ruido (la joroba en la línea superior) crece mucho a partir de 20Khz:


Sí, lo habéis leído bien: el ancho de banda del formato DSD es elevado, pero más tarde, en el momento de la reproducción, es necesario aplicar un filtro para eliminar el ruido ultrasónico que lo reduce notablemente, filtro que además debe ser lo suficientemente abrupto para hacer su trabajo rápidamente, es decir, en el ancho de banda que separa la señal audible de la banda a partir de la cual comienza el ruido. Y a mayor pendiente del corte, normalmente mayor distorsión de fase que sufre la señal, distorsión que también afecta al área por debajo de los 20 Khz.

Ironías de la vida, o del formato DSD, debería decir.

Para tratar de paliar el problema anterior, recientemente han surgido codificaciones que elevan aún más la frecuencia de muestreo, hasta los 5,6448 Mhz (DSD128 o DSDx2), 11,2896 Mhz (DSD256 o DSDx4) y 22,5792 Mhz (DSD512 o DSDx8). De este modo el ruido producido por la modulación Delta - Sigma empleada para generar la señal de 1 bit se mueve aún más arriba y por tanto los filtros de reconstrucción pueden comenzar a trabajar en una zona más alejada del espectro audible y forzar una pendiente de atenuación más suave. No existe un estándar de discos físicos SACD de, vamos a denominar, super alta resolución, pero sí hay sellos que ofrecen descargas en DSDx128 y DSDx256.

A partir de esta breve introducción técnica podríamos enfangarnos en un interminable debate acerca de si realmente, como Philips y especialmente Sony nos contaron hace más de 20 años, la codificación DSD es más cercana al fenómeno sonoro (analógico) y por tanto suena mejor (más natural) que las estrategias basadas en PCM multibit más convencionales. Pero este artículo no va de esto, así que pasemos sobre esta cuestión sin mayor comentario admitiendo tentativamente que la codificación DSD sea efectivamente superior a la PCM multibit convencional (que ya es mucho suponer).

El problema son los detalles (últimamente no me puedo quitar esa idea de la cabeza). Y esos detalles están extraordinariamente bien explicados en este artículo técnico de Grimm Audio, en el que se hace un repaso histórico del formato y de una serie de circunstancias que han rodeado su uso en el mundo real:


Resumamos el artículo en 3 ideas:
  • Cuando los SACD comenzaron a gozar de cierta popularidad, los conversores A/D utilizados en los estudios de grabación no operaban  en un formato idéntico al DSD (1 bit / 2,8 Mhz). Por esta razón era necesario procesar digitalmente la señal capturada para recodificarla en el formato estandarizado por Sony y Philips, que no tuvieron margen de maniobra para escoger otro de mayor calidad... simplemente porque las grabaciones no hubieran cabido en el disco físico adoptado por el estándar SACD, que no olvidemos, es un simple DVD.
  • El proceso de mezcla y producción en el estudio no podía realizarse directamente sobre la señal DSD, siendo necesario convertirla a PCM para después transformarla nuevamente a DSD. Aunque con el tiempo han surgido estaciones de procesamiento de audio capaces de operar directamente sobre el flujo DSD, estas capacidades son, incluso en el momento actual, incompletas y distan mucho de lo que se puede hacer en PCM. Por ello, la gran mayoría de SACD, según el artículo, han sido editados realmente en PCM. De hecho, incluso Philips en su momento comenzó a utilizar como formato preferido el PCM a 384 Khz y 24 bits para edición en estudio, formato posteriormente rebautizado como DXD.
  • Por último, los DACs presentes en la inmensa mayoría de reproductores allá por el 1997, incluso los utilizados en los reproductores de SACD, utilizaban internamente una representación sigma - delta de tipo multibit, por lo que necesariamente se producía una recodificación digital previa a la propia conversión D/A. Aunque en estos momentos existen DACs que, supuestamente, disponen de una ruta "pura" para el tratamiento de la señal DSD, en muchos casos incluso los diagramas técnicos resultan lo suficientemente confusos como para que no resulte fácil asegurarlo, en tanto que en otros simplemente se sigue practicando una recodificación de tipo multibit en las entrañas del DAC.
En definitiva, lo que nos cuentan los chicos de Grimm es que la cadena de audio, que Sony y Philips pretendían preservar tan natural y cercana al sonido analógico original...


...se transforma habitualmente, como resultado de la recodificación practicada en algún punto desde la toma de sonido hasta nuestro amplificador, en las etapas de grabación, masterización o reproducción, en algo ya no tan simple y notablemente alejado de la, reconozcámoslo, encomiable idea original:



Pero dejemos de lado lo que pueda pasar en las tripas del DAC de un reproductor y centrémonos no obstante en otro de los aspectos de todo este asunto que el artículo nos hace cuestionar: ¿Tenemos la seguridad de que en los SACD disponibles en el mercado se ha respetado la cadena de producción, manteniendo la señal DSD íntegra, al menos hasta la estampación del policarbonato plástico del disco SACD físico? ¿Cuántos han sido creados de modo que este principio permanezca escrupulosamente inviolado?

De entrada he examinado los libretos que acompañan a la treintena larga de SACD que tengo en casa, cosa que os invito a hacer con los vuestros. De entre ellos, solo 2 contienen alguna mención del proceso de producción:



Así es, ambos han sufrido una conversión a PCM de 96/24 en el proceso de producción.

Intrigado por esta cuestión, me dirigí hace unos días a SA-CD.net. Como algunos probablemente ya sepáis, se trata de una página web de carácter enciclopédico dedicada a la catalogación de todos y cada uno de los discos SACD editados hasta el momento (y algún que otro Blu-ray Audio). En ella podemos encontrar, en forma de fichas específicas para cada disco publicado, información extremadamente relevante: sellos, obras, músicos participantes, fecha de edición, comentarios sobre su calidad e incluso detalles relativos a su grabación y al modo en que ha sido realizada.


Existe además una nueva versión del portal, con exactamente la misma información, pero un aspecto actualizado, más moderno, en HRaudio.net.

Ninguno de los dos sitios web ofrece información de resumen que permita conocer qué porcentaje de discos son realmente DSD y, lógicamente, ir abriendo una por una las fichas de cada uno de ellos no es una opción aceptable.

Por ello, he confeccionado un pequeño script en Python que, en unas pocas horas, es capaz de analizar (parsear, en jerga de informáticos) las más de 11.000 páginas asociadas a cada uno de los trabajos catalogados en SA-CD.net (realmente interroga al nuevo sitio web en HRAudio.net) y generar información de resumen en formato de texto:

C:\Users\pablo\PycharmProjects\ParseoSACD\ParseoSACDnet.py
# Librerías necesarias
from bs4 import BeautifulSoup
import requests
import random
import time

inicio = 1 # 1
fin = 12054 # 12054 a 17/01/17

# URL base de parseo
url_base = 'www.hraudio.net/showmusic.php?title='

# Contadores de tipo de grabación
tgrabacion =    ['PCM','PCM 24/48','PCM 24/96','PCM 24/192','PCM 24/44','PCM 24/88','PCM 24/176',
                'DXD','DSD','Analogue','DESCONOCIDO','NOINFO']
ntipos = len(tgrabacion) - 2
ngrabacion = (ntipos+2)*[0]

# SACD parseados
ndiscos = 0

print()

# Introducir rango de parseo
#inicio = int(input('ID PRIMER disco en la base de datos: '))
#fin = int(input('ID ÚLTIMO disco en la base de datos: '))

print()

# Bucle de parseo
for id in range(inicio, fin+1):
    # URL base para parseo
    url = url_base + str(id)

    # Pausa en el parseo para no agobiar al servidor
    time.sleep(random.randint(1,2))

    # Capturar el hml de la pagina web y crear un objeto Response
    r = requests.get("http://" + url)
    data = r.text
    soup = BeautifulSoup(data, 'lxml')

    # Obtener título de la página, tratar de obtener título del álbum (tras "-" )
    titulo = soup.title.text[soup.title.text.index('-')+2:]

    # Obtener sección con información de la grabación
    grabacion = soup.find(id='recording_text')

    # Tratar de localizar logo SACD
    logoSACD = soup.find(alt='SACD')

    # Detectar si el URL redirige a página de inicio
    if titulo != 'High Resolution Audio':

        # ID contiene disco
        if logoSACD != None:

            # ID corresponde a disco SACD
            ndiscos = ndiscos + 1
            if grabacion != None:

                # Hay sección "Grabación", tomar primera palabra
                info = grabacion.text.split()[0]

                # Determinar si hay más información sobre resolución PCM,
                # aparece en 3er lugar
                if len(grabacion.text.split()) >= 3:
                    info2 = grabacion.text.split()[2]
                    if info2[0:3] in ['16/','24/','32/']:
                        info = info + ' ' + info2

                # Clasificar SACD en categoría
                if info in tgrabacion[0:ntipos]:

                    # Es un tipo conocido
                    i = tgrabacion.index(info)
                    ngrabacion[i] = ngrabacion[i] + 1
                else:
                    # Es un tipo desconocido
                    ngrabacion[ntipos] = ngrabacion[ntipos] + 1
            else:

                # No hay sección "Grabación"
                info ="NOINFO"

                # Conteo
                ngrabacion[ntipos+1] = ngrabacion[ntipos+1] + 1

            print(format(id,'5d'), '\t',format(url,'<41'),'\t', format(info,'<12'), '\t', titulo)
        else:

            # El disco no es SACD
            print(format(id,'5d'), '\t',format(url,'<41'),'\t','No es SACD')
    else:

        # ID vacio
        print(format(id,'5d'), '\t',format(url,'<41'),'\t','No existe')

# Imprimir resultados
print ('\nSACD:',ndiscos,'->')
for i in range(0,ntipos+2):
 print ('\t\t\t',format(tgrabacion[i]+':','<13'),format(ngrabacion[i],'5d'),'['+format(100*ngrabacion[i]/ndiscos,'0.2f')+'%]')

print()


Aquí el script en acción:


Tanto SA-CD.net como HRAudio.net están construidos utilizando HTML no demasiado bien estructurado, lo que dificulta un poquito la recogida de datos. La información relativa a la grabación aparece amontonada (si es que aparece) junto a otros detalles en una determinada sección de la página (ficha) de cada trabajo existente en el repositorio. Aunque el script intenta localizar la información relevante en las tripas del código HTML de la página, no siempre consigue interpretarla al 100%. Por ello, una vez volcada la información obtenida de modo automático en una hoja de cálculo de Google, ha sido necesario un pequeño trabajo adicional con su herramienta de filtros para refinar al máximo los datos cosechados.

Podéis consultar en línea esta hoja de calculo:

Parseo SA-CD.net (a 29/01/17)

Veréis que hay 3 pestañas en el documento:
  • Original parseado: son los datos en bruto recogidos por el script ParseoSACDnet.py. Cada fila representa un disco, cuya ficha podéis consultar en HRAudio.net sin más que hacer clic en el enlace de la columna B.
  • Refinado: Aquí se han eliminado los discos Blu-ray Audio catalogados, se han corregido algunos errores menores de parseo, etc.
  • Resumen: En esta hoja está lo interesante: una tabla dinámica y un gráfico asociado que resumen estadísticamente las características de los SACD analizados.



¿Y qué es lo que averiguamos? Pues que de la mayor parte de los SACD editados, al igual que ocurría con la pequeña muestra constituida por mis propios SACD, no hay información acerca del tipo de grabación (62,71%), lo que personalmente me resulta sospechoso. Después de todo, si la razón que da sentido a la existencia de los SACD es precisamente el uso de una estrategia de codificación superior, ¿por qué el sello discográfico obvia esta información?

Por otro lado, algo más de un 8% de los SACD han sufrido un proceso declarado de conversión a PCM (recordemos que DXD es PCM) en algún punto de su proceso de creación. Llama la atención que en algunos casos incluso a 44/24.

Algo más de un 13,5% se declaran como "analogicos". Y esto ¿qué significa? ¿Que la digitalización se ha realizado a partir de un master original analógico? Pero ¿con un conversor A/D DSD puro o no?  ¿Y cómo se ha realizado la edición en el estudio? No hay forma de saberlo.

Por último, solo en algo más de un 15% de los discos SACD contenidos en HRAudio.net se menciona el escueto término "DSD" en el área destinada a mostrar información acerca del tipo de grabación ¿Quiere decir que todo el proceso se ha mantenido en estos casos en el ámbito de la codificación DSD? Personalmente, no me atrevería a asegurarlo.

Bien, estos son los hechos. A partir de ellos cada cual extraerá sus propias conclusiones.

¿Es el SACD un formato revolucionario? En mi opinión, en absoluto, lo que no me impide reconocer que en una gran cantidad de discos editados en formato SACD (quizás en la mayoría) se ha puesto un enorme cuidado en la grabación y producción, siendo el resultado, desde un punto de vista sonoro, incuestionablemente brillante.

¿Sonarían igual de bien en PCM, incluso de 44/16, o en PCM transcodificado al vuelo a DSD64/128/256 por un reproductor capaz de hacerlo como Foobar, JRiver o HQPlayer? Probablemente... pero esto ya es cosa de cada uno.

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.

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 editcomor 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 > PreferenciasCalidad


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: