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

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.

Darko escribió: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

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. La tierra 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

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


Diferencias espectrogramas A y C2

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.

Tras el shock inicial que supuso el artículo publicado hace unos días, 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)


Espectrograma pista B (wav > mp3)


Espectrograma pista C (wav > mp3 > wav)

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

¡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)

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:

http://lame.sourceforge.net/tech-FAQ.txt

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)

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.

Brillante.... Como siempre
No me pierdo tus explicaciones, aunque me pierda a menudo en los detalles tecnicos
Muchas gracias por enseñarnos estas cosas a ls ignorantes en estos temas.
Saludos

Interesante informe.
Parece que la conclusión, es que Flac, que es comprimido, tiene la misma calidad que Wav. Y logicamente tiene menos peso.

Estoy intentando bajarme el programa Audacity.
La cuestión, es que hay un monton de sitios para bajarlo y no me fio de que en alguno metan bichos de cualquier tipo.
¿De donde deberia bajarlo?.

Gracias
Antonio

Honoris causa

Antoniolópez escribió:Interesante informe.
Parece que la conclusión, es que Flac, que es comprimido, tiene la misma calidad que Wav.  Y logicamente tiene menos peso.

Estoy intentando bajarme el programa Audacity.
La cuestión, es que hay un monton de sitios para bajarlo y no me fio de que en alguno metan bichos de cualquier tipo.
¿De donde deberia bajarlo?.

Gracias
Antonio

De la web propia de Audacity

Pablopi, como no tengo palabras para describir lo que pienso de tus hilos, recurro a uno de mis emoticonos favoritos:


Saludos!!

Ya no es sólo el interés de lo que comentas, o la profundidad técnica a la que llegas, sino la claridad de exposición que demuestras ...

Eres el cuñado que cualquier audiófilo quisiera tener

Capacidad didáctica, claridad, humor, lenguaje accesible... ¿qué más se puede pedir?.
Gracias por el artículo compañero

Fantástico ;-)

Muchas gracias por compartir este pedazo de analisis.

Saludos.

Yo uso Spek y Audiochecker para averiguar si los flacs son realmente flacs o escalados de un mp3.

Sublime, excelso, como de costumbre. ¡Joder, Pablo, me dejas sin palabras!.
Un saludo.

Gracias, compañeros.

Me quedo con lo de "cuñado de audiófilo".

nickcave escribió:Yo uso Spek y Audiochecker para averiguar si los flacs son realmente flacs o escalados de un mp3.

No lo he utilizado nunca, lo añado a mi kit, gracias. No obstante, según el "paper" en que se basa por el momento solo es capaz de identificar una conversión a partir de un archivo original AAC. La detección de cambios de frecuencia de muestro o resolución sí parece general, no obstante.

pablopi escribió:Gracias, compañeros.

Me quedo con lo de "cuñado de audiófilo".

nickcave escribió:Yo uso Spek y Audiochecker para averiguar si los flacs son realmente flacs o escalados de un mp3.

No lo he utilizado nunca, lo añado a mi kit, gracias. No obstante, según el "paper" en que se basa por el momento solo es capaz de identificar una conversión a partir de un archivo original AAC. La detección de cambios de frecuencia de muestro o resolución sí parece general, no obstante.

Y ojo también, hay casos muy particulares. Si los db no llegan lo suficientemente alto (una balada o slgo de clásica relajado) el Audiochecker te puede decir que ed un Flac falso. En Rutracker tienen una pelea con este tema tremenda. Como sabes te banean si descubren que has subido un mp3 como flac. Y se ha dado algún caso por polémica por lo que te comento.

Pues sí, efectivamente los wav obtenidos a partir de mp3 no los pilla, tampoco si se mete dither:



No obstante la capacidad de detectar que se ha practicado remuestreo es muy interesante.

pablopi escribió:Pues sí, efectivamente los wav obtenidos a partir de mp3 no los pilla, tampoco si se mete dither:



No obstante la capacidad de detectar que se ha practicado remuestreo es muy interesante.

Cierto. En Spek si se ve un corte muy pronunciado si el wav procede de un mp3, incluso la aplicación dibuja la línea.

2ª parte en el aire:

https://www.audioplanet.biz/t81823-como-no-usar-audacity-y-spek-para-llegar-a-conclusiones-erroneas#616722

Hola. Respecto al comentario: " (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)". Yo no tengo mucho conocimiento pero quiero guardar unos mp3 y por todos lados indican que usando spek si el espectro termina en 20khz es 320, en 16khz 128 ¿Es erróneo lo que dicen? Me pasa que un tema que hasta otros programas indican es de 192 termina en 16khz y en algunas partes del espectro continúa ¿Como tomo esto? Nadie explica que significan los colores (Si bien marca a que db corresponde) ¿Que pasa si un audio esta en su mayoría azul y los picos verdes llegan sólo a 12khz? Espero alguien pueda tomarse el tiempo en responder estas dudas. Gracias