100% digital. Comparativa Reproductores - Sistemas operativos, etc.

Hace unos meses Kapton abrió un hilo con el tema “Best PC music player”. En él Jazz se preguntaba también por la influencia de diferentes sistemas operativos en la calidad de la reproducción.

Pablopi aportó, como siempre, abundante documentación, entre ellas una serie de gráficas relativas a Ruido, distorsión etc., pero HiFi argumentaba que es complicado discriminar visualmente los diferentes resultados en gráficas muy parecidas, con líneas que se superponen, etc. También se plantearon algunos interrogantes metodológicos.

Estamos hablando en el terreno estrictamente digital (diferencias entre reproductores, diferencias entre Sistemas Operativos), como paso previo a la conversión a audio. En este sentido, hace tiempo que me venía rondando por la cabeza la idea que, en este terreno estrictamente digital, lo ideal sería comparar los “dígitus”, es decir los archivos directamente, es decir, el código fuente.

Hay programas para detectar diferencias entre 2 textos: Incluso realizan estadísticas de las diferencias entre ambos. Además son capaces de abrir directamente una gran cantidad de archivos, entre ellos los FLAC, WAV o AIFF, que son los que yo he usado.

Dicho esto, y a modo de declaración de intenciones, señalar que mi interés ha sido despertado por la curiosidad, no por motivaciones audiófilas. Estoy de acuerdo con las objeciones que se han vertido sobre los límites de nuestra capacidad de audición, y sobre todo con el hecho que hay muchas fuentes de interferencias de un grado mucho mayor - y más probable – que pueden alterar la reproducción (Dr. Funk dixit). Pero me fui “metiendo” en el proceso, como el egiptólogo de adentra en el descifrado de los jeroglíficos, y la motivación por encontrar resultados con sentido ha pasado a ser un objetivo en sí mismo.

Las conclusiones avalan la versión más hard de los planteaminetos digitales, y dejan poco margen para sutilezas y controversias audiófilas.
Describo en un Thread aparte el desarrollo metodológico de la comparativa. Es un coñazo para quien no le interesen estas cuestiones, y se lo puede saltar directamente.

Las conclusiones las incluyo en un tercer thread.

METODOLOGÍA
En el anterior hilo apareció también la cuestión metodológica: Hay que comparar moviendo una sola variable entre comparación y comparación. El entorno de pruebas se ha hecho usando un solo equipo, con una placa base Intel Q77 y un procesador i5. Los sistemas operativos han sido Windows7 64 bits y Windows8 64 bits, alojados en dos SDD.

Los reproductores usados han sido Foobar, Aimp3, y JRiver. Para capturar el audio he usado Audacity. Se da la circunstancia que Foobar, Aimp3 y Audacity tienen versión portable, con lo cual los he instalado en un pendrive, por USB3. Los archivos también estaban alojados en el pendrive, con lo cual la única variable ha sido el arranque desde uno de los 2 discos duros. (Excepto JRiver, que estaba instalado en los 2 sist. Operativos)



El programa para comparar archivos ha sido Araxis merge, del cual se puede obtener una versión de prueba durante 30 días.
El procedimiento ha sido el siguiente:
- A partir de un archivo FLAC de se han generado las muestras de 15 segundos, cortando el fragmento con Audacity.  
- El archivo resultante ha sido guardado y convertido a WAV o AIFF con DbPowerAmp, para obtener el archivo sin comprimir de referencia.
- Se ha reproducido el archivo FLAC en el player y se ha grabado en Audacity.
- El resultado se ha exportado a WAV o AIFF. Se ha comparado el resultado de la exportación con el archivo WAV / AIFF de referencia.
Audacity tienen la posibilidad de usar el host Wasapi, y ésta es la configuración usada en toda la prueba:



Tiene, además, la ventaja que bajo esta configuración no empieza a grabar hasta que no detecta señal de audio, de forma que uno puede darle al REC, cambiar de pantalla para ir al Player de turno e iniciar la reproducción. La grabación empezará siempre en el mismo momento, tardes lo que tardes en darle el PLAY en el reproductor.
La única precaución es tener los sonidos de Windows desactivados.
Al usar Wasapi en el grabador, los reproductores funcionaran bajo Direct Sound, pues Wasapi es exclusivo para un solo dispositivo: El primero que toma el control.
Esto en principio es una desventaja, pues solemos usar los reproductores en configuración Bit Perfect (ASIO o WASAPI), pero supone la ventaja que en solo equipo se  hace todo el proceso y se eliminan las variables derivadas de añadir un segundo dispositivo para la grabación.
Podremos ver también como afecta la configuración de audio de Windows en este sentido.

Al principio de las pruebas, usaba Notepad ++ como comparador de textos, pero con muestas de 2 segundos ya se colgaba. Trasteando por Internet encontré el ya mencionado programa Araxis Merge. Con él puedo manejar muestras de 15 segundos, que es una fracción de tiempo mucho más significativa.

La comparación de archivos detecta ”líneas de texto iguales” y “líneas de texto diferentes”. También es capaz de detectar (usando algoritmos inteligentes) “bloques de texto”, es decir, conjuntos de líneas que, aunque tengan alguna diferencia, se pueden interpretar como bloques “que hablan de lo mismo”.

…….Después de varios intentos de redacción, abandono la idea de explicar el baremo que he usado para realizar una serie de tablas. Sería un coñazo y, por suerte, los resultados (como se verá) no necesitan tanto desarrollo.
Sólo decir que, si bien 2 líneas diferentes no sabemos cuán diferentes son, sí que sabemos que 2 líneas iguales son iguales. Por tanto, con este método no podemos “explicar” el contenido de las diferencias, pero podemos, con toda seguridad, constatar las igualdades.
He usado varios archivos, grabados a diferentes resoluciones/profundidad de bits, para tener una muestra de diferentes configuraciones. He escogido archivos con elevada dinámica, y de ellos he recortado fragmentos de 15 segundos que recogieran esta amplitud de rango dinámico, pensando que un registro amplio ayudaría a manifestar posibles diferencias.

Los archivos son:
Lou Reed. Dirty boulevard.flac – 44.4 Khz / 16 bits
Pink Floyd. Wish you were here – 48 Khz / 16 bits
Pink Floyd. Wish you were here – 48 Khz / 24 bits
You'd Be So Nice To Come Home To (Keith Poon .Audiophile Jazz Prologue) 96 Khz / 24 bits
El baile de Don Luis (Rafael Frübeck de Burgos) 192 Khz / 24 bits

Finalmente diré que he tenido bastante lío en todo el proceso, fundamentalmente porque se puede actuar sobre la frecuencia de muestreo / profundidad de bits tanto en el Player, como en el Grabador como en la configuración de Audio del sistema, con lo cual al principio obtenia resultados muy inconsistentes y a veces contradictorios. (Y siempre me equivocaba / despistaba yo)

Con el tiempo, y con más método, los archivos han acabado llamándose nombres como éste:
You'd 96-24 - FOO - FLAC - Auda 96-24 - Sist 96 – 24.AIFF
Es decir, You’d 96/24 en formato FLAC, reproducido en Foobar, grabado con Audacity a 96 Khz/24 bits, con las propiedades de audio de sistema a 96 Khz/24 bits, exportado a AIFF.

Generando tablas como ésta:

RESULTADOS

La idea, lo hemos dicho al principio, era comparar diferencias entre sistemas operativos. Pero viendo que podía comparar archivos de 50.000 líneas (millones de caracteres) “punto por punto”, pensé que lo primero sería comprobar si este sistema es consistente en un mismo sistema operativo, comprobando diferentes variables. Me parecía increíble que una grabación “en el tiempo” pudiera replicar millones de caracteres exactamente, sin fallo alguno, como sucede con la transcodificación de archivos, donde el proceso se hace en forma numérica.
Pues la verdad es que eso se consigue en varias situaciones: Dos archivos iguales, línea a línea, carácter a carácter. Sólo varían las 1-2 primeras y últimas líneas, que contienen datos referentes al propio archivo (tipo de archivo, fecha creación etc.)

Ahí van los resultados:

COMPRESIÓN/DESCOMPRESIÓN DE ARCHIVOS: Como cabe esperar, las operaciones de compresión / descompresión de archivos, WAV a FLAC, FLAC a WAV, no generan ningún tipo de pérdida. Se pueden hacer sucesivamente, usando diferentes programas para ello, y siempre volvemos al archivo original. 100% de igualdad.

INFLUENCIA DE PROCESOS: No he encontrado en ningún caso que realizar diferentes tareas simultáneas altere en grado alguno la reproducción de los archivos. He realizado pruebas exprofeso, teniendo activado Bittorrent con downloads y uploads simultáneos, transcodificando series de archivos de audio, con 10 programas abiertos etc. y los resultados no han variado en lo más mínimo. Usando la salida Direct Sound, simplemente tenemos que desactivar los sonidos del sistema para que la reproducción no se vea alterada. El cambio de Sistema Operativo o el uso de programas como Fidelizer no tiene nigún efecto. 100% de igualdad.

INFLUENCIA DE LA UBICACIÓN DEL ARCHIVO: No he encontrado diferencias en la reproducción con el mismo archivo ubicado en USB, SSD (sistema) o HDD. Parece no tener sentido la carga previa en RAM que tienen como opción algunos reproductores. 100% de igualdad.

CONFIGURACIÓN DEL SISTEMA DE AUDIO EN DIRECT SOUND: La configuración del sistema de audio en Direct Sound tiene una influencia decisiva en la calidad de reproducción. Sólo se reproducen correctamente los archivos si ajustamos la frecuencia de muestreo del sistema con la frecuencia a la que está grabado el archivo. En este caso, la reproducción también es bit-perfect. 100 % de igualdad.

Yo pensaba que si la frecuencia de muestreo del sistema era múltiplo de la frecuencia del archivo (por ejemplo: archivo a 96 Khz frecuencia del sistema 192 Khz) conservaríamos la igualdad del archivo resultante, (exportado a 96 Khz, como el archivo original) pero no ha sido así, al menos en mi caso. Siempre recojo alteraciones en el archivo resultante. ¿Serà un problema del grabador? ¿Pasará lo mismo si upsampleamos los archivos en el reproductor? No tengo respuesta para eso.

INFLUENCIA DEL PLAYER: FOOBAR – AIMP – JRIVER: Ninguna. Los tres players probados reproducen los archivos con la misma perfección. La elección de un u otro player dependerá de que sus posibilidades de configuración se adapten a las preferencias de cada usuario en concreto, pero que nadie pretenda escuchar mayor “detalle en las zonas medias” o “aumento del rango dinámico”, porque devuelven siempre el mismo archivo, idéntico al original. 100 % de igualdad.

INFLUENCIA DE LAS PROPIEDADES DEL ARCHIVO: Si ajustamos las propiedades de audio del sistema con las propiedades del archivo, el sistema es capaz de devolver, en el proceso de grabación, un archivo 100% igual al archivo de muestra, tanto si es a 44.1 – 48 – 96 – 192 KHz siempre que sea a 24 bits de profundidad. Con 16 bits pasa una cosa que no sé cómo interpretar. A ver si alguno de los pozos de ciencia del foro me ayudan.

Al principio, los archivos de 41,1 KHz/16 bits me daban siempre diferencias respecto del original, con todo (reproductor – grabador – sistema alineado a 41,1 Kz/16bits). Yo tenía entendido que la frecuencia por defecto del reloj de Windows era de 48 KHz y para trabajar con cualquier otra frecuencia no divisible se efectuaba un redondeo. ….Pero hice una prieba, por curiosidad con un archivo a 48 KHZ/16 bits, y me devolvía también diferencias, de una magnitud similar a los 41,1 KHz.
Esta diferencia me desaparece si la grabación la realizo con una profundidad de 24 bits. Configurado Audacity a 24 bits, puedo exportar la grabación a 16 bits y me devuelve el archivo original (tanto a 41,1 como a 48 KHz). ????????

En fin, me quedan varias curiosidades por resolver, como la de usar un reproductor “no audiófilo” a ver qué resultados me da, o usar un capturador externo, para poder medir la salida Wasapi, a ver qué tal se porta.

Encomiable esfuerzo Ignasi, aunque yo escucho música, no archivos de texto, con lo queal final es a mis oidos a quien hago caso   .

¿Este método considera variables tan críticas como el jitter? Si no estoy equivocado con el jitter los datos llegan, pero más tarde, lo que es crítico para una reproducción musical realista.

Y ya que vives en Barcelona cuando quieras pasa por casa y comprobamos si a oido tus conclusiones son correctas.

Saludos

Bueno, la única conclusión de este estudio si lo entiendo bien es que da igual "cómo" reproduzcas/guardes/uses tu música digital, que los archivos no cambian.

Me quedo más tranquilo.

Porque lo contrario sería un desastre y podría implicar que otro tipo de archivos también se corrompieran en el "trajín" de discos duros, redes o/y ordenadores.

Sin embargo no (me) aclara (nada) cuál será el resultado cuando ese archivo, que no cambia, se convierte en sonido y se escucha.

Por ejemplo: si la máquina va justa de recursos y tenemos muchos procesos abiertos, sabemos que habrá cortes temporales en la reproducción. Lo que se reproduzca será 100% idéntico al original, pero francamente a mí no me sonará igual si cada 10 segundos tengo una pausa...

O quizás entiendo mal qué ha hecho/querido demostrar Ignasi.

Saludos!

Hola a todos, buenos días:
En primer lugar quiero hacer constar un enorme agradecimiento por el trabajo exhaustivo realizado y por supuesto, también por compartirlo con todos.
Esta es una de las grandes ventajas que proporciona un Foro.
Después de este comentario, entiendo; y hablo desde la humildad de un simple usuario del sonido, que los procesos realizados para codificar/decodificar archivos partiendo de un formato concreto, guardándolo en otro y recomponíéndolo al original, SIEMPRE llegan a un archivo igual, idéntico o exacto al primero.
Esa es una buena noticia, por lo menos entiendo yo, desde el punto de vista del almacenaje, envío, movimiento, etc.... de archivos. Ya que el archivo original y el final serán los mismos. Y mientras tanto lo he podido guardar, transportar, mover, etc...
en archivos de menor tamaño.
Efectivamente coincido con Azazel en el hecho de que para reproducir el archivo de sonido, está claro que cuanto mas limpio de trabajo esté el procesador, meno se verá influenciado en los posibles cortes o interrupciones de los procesos mientras el archivo se reproduce.

Esto anterior es lo que yo he creído entender de lo que habeis explicado.
Si esto no es así, o yo estoy equivocado, despistado, liado, o algo peor, .... os agradecería que lo aclaráseis, y no solamente por mí, sino por todos los poco entendidos en el tema informático.
Muchas gracias.
Eduardo, o sea Lord-ka

Yo he entendido otra cosa, seré entonces yo el que está equivocado. Yo entiendo que lo que se ha examinado es lo que sale, no lo que entra. Tal vez lo que habría que preguntarse es cómo sale. Lo que me pregunto es si esa comparación sirve de algo a los efectos de una comparativa de sonido donde seguramente la interferencia más importante, a nivel de reproducción, es el jitter. Me explico, un mp3 comprimido reproducido con una importante reducción de va jitter a sonar mejor que un archivo dsd con un importante jitter. Al menos esa es mi experiencia.

Jazz escribió:

¿Este método considera variables tan críticas como el jitter? Si no estoy equivocado con el jitter los datos llegan, pero más tarde, lo que es crítico para una reproducción musical realista.

La pregunta no sería ésta sino ¿Este mètodo es capaz de registrar variables tan críticas como el jitter ?

Mi respuesta es: Pues no te sabría decir. Efectivamente el jitter es una alteración “en el tiempo” de la llegada de los datos.

Lo único que he probado respecto al tiempo es que si “alargo” una grabación 0,01 segundo (transformándola con el propio Audacity), el archivo resultante tiene grandes diferencias respecto al original. Tienes que pensar que alargar un archivo de unos 15 segundos 0,01 segundo equivale a menos de una millonésima de segundo por ciclo de reloj, o sea que las variaciones de velocidad quedan registradas con gran precisión.
¿Usa Audacity un buffer que minimiza (suprime) cualquier efecto de jitter?
¿Puede ser que mi equipo tenga jitter = 0 ?
¿Puede ser que no queden registradas alteraciones menores de 1 millonésima de segundo?
La única respuesta segura que tengo es que mis oído no son capaces, ni de lejos, de detectar alteraciones de esta microscòpica magnitud.

Azazel escribió:
Bueno, la única conclusión de este estudio si lo entiendo bien es que da igual "cómo" reproduzcas/guardes/uses tu música digital, que los archivos no cambian.

Bueno, no cambian si usas salida BitPerfect. Si por medio se mete el mezclador de Windows (Direct Sound) sí que cambian. En este caso tienes que ajustar sempre manualmente la configuración del reproductor de sonido de Windows a la frecuencia de muestreo del archivo.

Sin embargo no (me) aclara (nada) cuál será el resultado cuando ese archivo, que no cambia, se convierte en sonido y se escucha.

Correcto. Eso està fuera del ámbito de la prueba. El archivo se convierte en sonido a través de un DAC, pasa a la amplificación, etc. etc. però aquí solo he intentado encontrar las alteraciones en el ámbito digital.

Lord-ka escribió:

los procesos realizados para codificar/decodificar archivos partiendo de un formato concreto, guardándolo en otro y recomponíéndolo al original, SIEMPRE llegan a un archivo igual, idéntico o exacto al primero

Sí, sin duda ninguna y siempre que trabajemos con formatos sin pérdida.

si la máquina va justa de recursos y tenemos muchos procesos abiertos, sabemos que habrá cortes temporales en la reproducción

está claro que cuanto mas limpio de trabajo esté el procesador, meno se verá influenciado en los posibles cortes o interrupciones de los procesos mientras el archivo se reproduce.

Es curioso lo arraigado que està este concepto y cómo permanece anclado en el tiempo, porque las conclusions de las pruebas son justamente las contrarias. O bueno, quizás es que me he explicado mal.
Lo diré de otra forma: Es imposible escuchar música (decentemente) y efectuar todas las perrerías que yo le he hecho hacer a mi PC simultáneamente. Así y todo, el archivo que se reproducía no se ha allterado en lo más mínimo. En un equipo medio moderno, los Componentes van más que sobrados, però que más más más que sobrados para escuchar música sin preocuparse de que el sistema se “atasque”.

Jazz escribió:
Yo entiendo que lo que se ha examinado es lo que sale, no lo que entra. Tal vez lo que habría que preguntarse es cómo sale.

Ja,ja,ja,ja,  Ay, lo que sale y lo que entra .... !!!!

Efectivamente se ha examinado lo que “sale” y cómo (o con qué calidad) sale.
Es decir, la hipòtesis de Trabajo era:
¿ En qué medida un Player  o un Sistema Operativo altera la integridad de un archivo de audio durante la reproducción?
Y la respuesta, para mí sorprendente, ha sido que en niguna medida. Todas las pruebas han dado una concordancia absoluta entre el archivo de origen y el archivo obtenido.

Jazz escribió:
Y ya que vives en Barcelona cuando quieras pasa por casa y comprobamos si a oído tus conclusiones son correctas

Por supuesto que acepto la invitación. Pero no pienso hacer ningún dictamen basado en mis oídos, Válgame Dios ! Como he dicho en la introducción, he hecho esto por simple curiosidad intelectual.

Muy buen trabajo Ignasi, me parece que el metodo y los resultados son irrefutables.

Sin embargo sospecho que los resultados ya los intuías... o no ?   Es que trabajar sobre el dominio digital como comentas, haciendo las previsiones de "bitferpectismo" adecuadas debieran garantizar el resultado.

En conclusion Windows y los players que has probados son totalmente honestos en el tratamiento del audio.

 

Buenas tardes a todos.

En primer lugar, Ignasi, muchísimas gracias por tu concienzudo análisis  .  Me imagino el cacaomaravillao que te habrán supuesto unas pruebas como las que nos presentas aquí.

En mi opinión lo que queda demostrado es que el "diabólico" sistema de audio de Windows no le toca un pelo a la señal cuando los parámetros relativos a frecuencia de muestreo y profundidad de bits de la muestra reproducida y capturada son coincidentes (poltergeist que menciona Ignasi al usar archivos a 44/16 y 48/16 aparte).

El bucle de prueba se mantiene aquí en el interior del propio subsistema de audio del SO. En este caso si solo emite audio una aplicación (el reproductor), no habiendo por tanto que mezclar varios flujos de audio, y se dan las condiciones mencionadas en el apartado anterior, lo que entra es lo que sale, tal cual. Pero es que realmente entonces no se está produciendo un proceso de muestreo de la señal, sino que simplemente las muestras que emite el reproductor pasan del buffer de reproducción al de captura de modo secuencial.

Dicho de otro modo, lo preocupante hubiera sido que se hubieran detectado diferencias. Eso implicaría la existencia de algún fallo en el propio software. El hecho de que incluso tratando de cargar el procesador se obtengan resultados 1:1 dice bastante acerca de la robustez del SO y de que, como dice Ignasi, un ordenador moderno va mucho más que sobrado para reproducir audio (dejemos fuera de esta afirmación algunos procesos, digamos avanzados, que ponen en práctica reproductores como HQPlayer, procesos que casi siempre tienen que ver con la reproducción o recodificación de audio en DSD).

En este escenario de prueba, el jitter, entendido como una perturbación que alteraría las muestras de sonido correspondiente a cada uno de los periodos de muestreo, es 0. Es decir, el jitter de transporte dentro del SO es un invento para que algunos nos vendan aplicaciones que resuelven un problema que no existe.

Para poder extraer conclusiones más generales con respecto al jitter global creo que es necesario llevar el bucle de prueba más allá de donde está, de modo que el audio sea reproducido y capturado en digital por un dispositivo externo capaz de funcionar en full-duplex a nivel de hardware y más allá de las propias capas del sistema operativo que atraviesan los flujos de audio hasta que llegan al DAC.

O mejor aún, incorporar sendas conversiones DA y AD en el mencionado bucle de prueba para que la señal capturada sea esa misma en la que algunas personas captáis diferencias cuando una mariposa aletea en Birmania  .

Esto es precisamente lo que hace Audio DiffMaker, aunque el proceso es realmente mucho más complicado para que los resultados sean válidos:



Lo ideal, en cualquier caso, tanto si se hace la comparación dentro del ámbito digital como si se incorpora una fase de conversión de dominio, es que reproductor y grabador utilicen una base de tiempos que no sea común. De este modo el proceso de captura de audio, implique este una conversión de dominio (bucle con AD y DA) o no (captura DD) debería permitir detectar la presencia de anomalías inducidas por el jitter, quizás generadas por el DAC, el propio cable que lo conecta al PC o tal vez alguna interferencia de índole electromagnético.

Que un software reproductor / optimizador (tipo jplay, audiophile optimizer, etc.) determinado pueda actuar sobre este jitter para reducirlo es algo que, simplemente, yo no me creo.

Jaime2010 escribió:Muy buen trabajo Ignasi, me parece que el metodo y los resultados son irrefutables.

Sin embargo sospecho que los resultados ya los intuías... o no ?

Pues la verdad, Jaime, yo pensaba encontrar alguna diferencia (aunque fuera ínfima) entre las mediciones.
Fíjate que ya empiezo por poner los Players y los archivos en un USB, para que el recorrido de la señal sea tortuoso. De hecho están conectados a un HUB USB externo, junto con algún otro pendrive.

Una idea que tenía es que no sería raro que en el proceso de reproducción / grabación se produjera algún tipo de interferencia, no sé, incluso de carácter aleatorio, algún tipo de “ruido” que alterara la señal.

Entonces el proceso hubiera sido mucho más divertido, porque puedes jugar a detectives e ir descartando variables, “afinando” el sistema (esto que tanto nos gusta hacer por aquí) y llegar a algún tipo de configuración ideal, o al menos, mejor que algunas otras.
Pues no. Los resultados han sido de una sosería espectacular. Es lo que hay.

Pablopi escribió:

O mejor aún, incorporar sendas conversiones DA y AD en el mencionado bucle de prueba para que la señal capturada sea esa misma

Pablo, estoy de acuerdo contigo, pero mi idea era hacer la comparativa lo más restringida posible. Si encomendamos a un DAC externo la conversión digital/analógica, el tratamiento de la señal del equipo será estrictamente digital, por tanto  es a éste dominio al que me he circunscrito, y manejar 1 sola variable con rigor ya ha sido suficientemente trabajoso:
Mismo equipo – Mismo archivo – Mismo Player - Misma ubicación del archivo – Misma configuración del hardware de audio - Distintos Sistemas Operativos
Mismo equipo – Mismo archivo – Distinto Player Player - Misma ubicación del archivo – Misma configuración del hardware de audio - Mismo Sistemas Operativos
Etc.
Lograr hacer las cosas en este entorno tan concreto con un poco de método ha sido para mí bastante cacaomaravillao. Es que no doy pa más.
Si incorporas algo externo, y además intruduces de la conversión Digital/Analógica, estás tratando con más variables. Los resultados tienen más alcance pero la localización de “donde” se produce la posible alteración no es tan precisa. De hecho tú mismo lo dices:
Esto es precisamente lo que hace Audio DiffMaker, aunque el proceso es realmente mucho más complicado para que los resultados sean válidos

Ignasi L escribió:
Pablo, estoy de acuerdo contigo, pero mi idea era hacer la comparativa lo más restringida posible. Si encomendamos a un DAC externo la conversión digital/analógica, el tratamiento de la señal del equipo será estrictamente digital, por tanto  es a éste dominio al que me he circunscrito, y manejar 1 sola variable con rigor ya ha sido suficientemente trabajoso

Pues sí, y la comparativa como está es estupenda y creo que deja meridianamente claras unas cuantas cosas.

Lo que te propongo es utilizar una tarjeta externa con entradas y salidas digitales para conectarla en bucle y repetir el experimento... o mejor, sacar en digital desde el reproductor y capturar desde otro PC también en digital. De ese modo no se va a tratar de llevar bytes de un buffer a otro dentro del SO, sino que se introduce un proceso de captura en un dispositivo hw, por lo que las conclusiones serán más amplias y dejarán únicamente fuera la influencia del DAC.

Tengo por aquí una Edirol UA25 en un cajón, si te hace papel te la mando.

http://www.roland.com/products/en/UA-25/

Si mal no recuerdo puede funcionar en full duplex a 48Khz y en captura o reproducción a 96Khz.

Gracias por el ofrecimiento de la Edirol, Pablo.
Ya tenía en mente lo de hacer la captura desde otro PC, y en un momento u otro lo voy a hacer, pero con la llegada del agosto quizá me demore un poco