CD > WAV > CDR ¿nos estamos perdiendo algo?

Respecto a los errores y por alusiones.

Teniendo en cuenta que si se usara el CD para datos, se añadirían como mínimo 8 bytes por cada 24 de datos  para correccion de errores, y así garantizar la integridad del contenido.... y si a eso uno le suma que leyendo un CD-ROM se pueden repetir lecturas, pero cuando lees AUDIO se hace en tiempo real, y por tanto sujeto a errores no solo del disco y de su legibilidad, sino propios de lectura (vibraciones, golpes, EMI, etc) yo diría que si, que hay errores al leer un AUDIO CD.

Léase de la wiki:

Both Mode 1 and 2 sectors use the first 16 bytes for header information, but differ in the remaining 2,336 bytes due to the use of error correction bytes. Unlike an audio CD, a CD-ROM cannot rely on error concealment by interpolation; a higher reliability of the retrieved data is required. To achieve improved error correction and detection, Mode 1, used mostly for digital data, adds a 32-bit cyclic redundancy check (CRC) code for error detection, and a third layer of Reed–Solomon error correction^[5] using a Reed-Solomon Product-like Code (RSPC)....

http://en.wikipedia.org/wiki/CD-ROM

Ala, a tirar los CD's y a comprar vinilos todos.

Saludos.

Leer audio en tiempo real?
si mi teac Pd-h500 de mas de 15 años hace '8 times oversampling',... que lectores tenéis en el equipo?

felix_gt escribió:Leer audio en tiempo real?
si mi teac Pd-h500 de mas de 15 años hace '8 times oversampling',... que lectores tenéis en el equipo?

'8 times oversampling' es un proceso que se aplica tras la lectura del disco. No quiere decir que lea 8 veces el disco.

Saludos.

Flick4 escribió:Respecto a los errores y por alusiones.

Es un hecho conocido que la lectura de un cd de datos se realiza con una serie de mecanismos de detección y corrección de errores adicionales a los disponibles en un cd en red book audio.

Lo que digo es que si un lector de pc de lo más "tirao" puede leer las pistas de un cd audio en soporte grabable sin errores y a velocidades de vértigo ¿dónde está la complicacion en que un reproductor de cd haga exactamente lo mismo pero a una velocidad mucho menor (tiempo real es muuucho más lento que 20x)? A ver si al final va a resultar que los rips reproducidos desde el HD van a sonar mejor y todo .

Con los vinilos casi que prefiero no racionalizar tanto y simplemente dejarlos rodar  .

pablopi escribió:
Lo que digo es que si un lector de pc de lo más "tirao" puede leer las pistas de un cd audio en soporte grabable sin errores y a velocidades de vértigo ¿dónde está la complicacion en que un reproductor de cd haga exactamente lo mismo pero a una velocidad mucho menor (tiempo real es muuucho más lento que 20x)? A ver si al final va a resultar que los rips reproducidos desde el HD van a sonar mejor y todo .

No pierdas de vista que mucho lectores "hifi" (incluso "high end") usan transportes... "tiraos" (incluso mucho más tiraos que el que hayas usado... son frecuentes dvd-rom de generaciones pasadas muy mediocres).
Y sí, con alguno de esos también he apreciado (para mi "disgusto" porque preferiría lo contrario) diferencias.
+saludos

pablopi escribió:

Flick4 escribió:Respecto a los errores y por alusiones.

Es un hecho conocido que la lectura de un cd de datos se realiza con una serie de mecanismos de detección y corrección de errores adicionales a los disponibles en un cd en red book audio.

Lo que digo es que si un lector de pc de lo más "tirao" puede leer las pistas de un cd audio en soporte grabable sin errores y a velocidades de vértigo ¿dónde está la complicacion en que un reproductor de cd haga exactamente lo mismo pero a una velocidad mucho menor (tiempo real es muuucho más lento que 20x)? A ver si al final va a resultar que los rips reproducidos desde el HD van a sonar mejor y todo .

Con los vinilos casi que prefiero no racionalizar tanto y simplemente dejarlos rodar  .

Yo entiendo que es por las repeticiones, si no cuadra el código de redundancia, vuelta a leer y andando. Leer y ripear son procesos diferentes, es como ejecutar una obra de teatro o filmar una peli, en el primer caso si hay un error se disimula (interpolación), en el segundo se repite la escena (otra lectura). No se qué tiene de raro que haya cierto número de errores en la lectura, algo ya previsto y medio subsanado,  también hay veces que el lector de CD se cuelga y no hace puto caso al mando.  

Saludos.

Flick4 escribió:Leer y ripear son procesos diferentes, es como ejecutar una obra de teatro o filmar una peli, en el primer caso si hay un error se disimula (interpolación), en el segundo se repite la escena (otra lectura). No se qué tiene de raro que haya cierto número de errores en la lectura, algo ya previsto y medio subsanado

Yo sigo creyendo que no está tan claro. A ver si me consigo explicar:

Los CD-Audio, creados de acuerdo al estándar Red Book Audio, emplean un sistema Reed Solomon (red CIRC) para corregir automáticamente los errores producidos en lectura. Los entresijos no creo que sean de interés, pero básicamente se trata de trocear el flujo de datos y añadir paridades de forma entrelazada para que se puedan corregir errores tanto aleatorios como en ráfaga (secuenciales) de múltiples bits. Esta corrección se realiza dentro del propio hardware de la unidad, el software de lectura o el microcontrolador de la unidad puede que ni se enteren de que se han producido y corregido errores. No hay controles de paridad o CRC adicionales de ningún tipo.

Los CD que contienen datos (Yellow book) puedes ser creados utilizando los así llamados modo 1 o modo 2. Realmente el modo 2 como tal no añade nada a la gestión de errores de un CD-A, pero normalmente no se crean cedés de datos en modo 2, sino en modo 2/XA, es decir, con unas extensiones adicionales que permiten grabar en un CD una sesión con datos y otra con pistas de audio en Red Book. Dentro de la especificación XA hay a su vez 2 modos adicionales, el 1 y el 2 (no tienen nada que ver con los anteriores). El modo 2/XA-2 no añade ningún control adicional. Se suele (solía) utilizar para pistas en CD-A o para registrar vídeo en los (extintos) Video CD y Super Video CD (aunque nada impide almacenar datos o programas) ¿La razón? Al existir menos bits dedicados a la gestión de errores es posible almacenar más minutos de audio y vídeo, considerando que si se producen errores estos no serán fatales y puede que incluso pasen desapercibidos dentro de un fotograma de un vídeo a 50 cuadros /s o un tema musical (quien pensó en esto no conocía a los audiófilos hardcore ).

Pues bien, cuando se crea un CD de datos en modo 1 o en modo 2/XA se añade a la gestión de errores de los CD-A (recordemos, únicamente un sistema Reed Solomon) 2 controles adiciones:

a) Una verificación CRC que permite detectar errores.
b) Un control Reed - Solomon adicional de nivel 2 de corrección de errores.

Esto es así porque un simple bit que "patine" cuando se leen datos que pueden corresponder a las instrucciones de un programa desde un CD puede ser fatal.

Pero es que un reproductor de CD-Audio dispone *además* de mecanismos adicionales de gestión de los errores de lectura de disco que *no tienen* las unidades ópticas que usamos en nuestros ordenadores. Como citaba Flick4 más arriba, cuando la red CIRC no puede corregir todos los errores que se están produciendo en un instante dado, se adoptan 3 comportamientos:

a) Se produce una interpolación de los bits que no se pueden leer a partir de los inmediatamente anteriores y posteriores. La idea es que el sonido no se corte y tenga sentido en el contexto temporal de reproducción.
b) Si el número de errores es excesivo, se comienza a arrastrar el último bit o bloque leído correctamente durante un cierto tiempo (el cd parece patinar, se oyen como clics).
c) Si el tiempo de arrastre es demasiado grande, el reproductor simplemente corta el audio, introduciendo silencios, y/o detiene la reproducción.

Dicho de otro modo, un reproductor de CD de sobremesa pueden llegar a "inventarse" las muestras de audio, aunque solo hasta cierto grado. Supongo que por aquí justificáis algunos (la unidad se inventa la información) la diferencia en la calidad percibida en reproducción en función del soporte de grabación empleado.

Ahora bien, cuando empleamos un lector óptico asociado a un PC o Mac para extraer digitalmente el audio de un CD-A, no se produce esta invención de la información ante errores repetidos. Pero dado que el CD que estamos ripeando es de tipo red book, no modo 1 o 2/XA, solo nos beneficiamos en el proceso de la red CIRC de primer nivel. No hay CRC. No hay CIRC de 2º nivel.

En el experimento que he realizado, la extracción con XLD, tanto del audio del disco original como del CD-R, se ha desarrollado sin errores a juzgar por los logs que crea la aplicación. Veamos por ejemplo el obtenido al extraer la pista 4 del CD-R previamente grabado:

Código:

Track 04
    Filename : /Users/pablo/Desktop/04 Naked Raven - Benediction.wav
    Pre-gap length : 00:02:00

    CRC32 hash               : 235A48A3
    CRC32 hash (skip zero)   : 94738D8B
    AccurateRip v1 signature : 6C873A2D
    AccurateRip v2 signature : D87398C0
        ->Track not present in AccurateRip database.
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

No hay errores de lectura (Read error). No hay reintentos de lectura de sectores (Retry sector count). No hay sectores dañados (Damaged sector). No hay error de jitter ¿?

El hecho de que aparezcan al final del log una serie de CRC no permite en absoluto verificar el resultado comparándolos con un CRC previamente grabado en el propio disco óptico para cada pista, simplemente porque esta referencia no existe en un CD-A. Solo podemos emplear los CRC calculados por XLD para comparar diferentes extracciones, propias o disponibles en Internet como buenas si se usa AccurateRip.

Pensaréis: claro, has extraído el audio usando el modo seguro de XLD, normal que no haya errores. Pero ¿cómo funciona este modo? Es similar a EAC. Como no hay un CRC o un hash fiable almacenado en el disco para cada pista, los sectores se leen varias veces (creo que 2, en principio). Si ambas lecturas son idénticas, los datos se dan por buenos. En caso contrario se realizan más lecturas y se da por buena la más frecuente (probablemente la solución menos mala). En *ninguno* de los 2 logs de XLD que recogen la extracción en modo seguro del CD original y del CD-R aparece error alguno. Eso quiere decir que la primera lectura realizada por la unidad para cada sector se da por buena. Repito, tanto en el CD original como en el CD-R. Por tanto XLD no ha hecho ninguna "magia" que no pueda hacer un reproductor de CD convencional.

Para tratar de dar respuesta a esta objeción, no obstante, he ripeado nuevamente la pista 4 del CD-R usando XLD, pero ahora en modo Burst, modo en el que no se realizan múltiples lecturas:



Este es el log del resultado:

Código:

AccurateRip Summary
    Disc not found in AccurateRip DB.

Track 04
    Filename : /Users/pablo/Desktop/04 Naked Raven - Benediction.wav
    Pre-gap length : 00:02:00

    CRC32 hash               : 235A48A3
    CRC32 hash (skip zero)   : 94738D8B
    AccurateRip v1 signature : 6C873A2D
    AccurateRip v2 signature : D87398C0
        ->Track not present in AccurateRip database.

End of status report

Ahora no hay una sección dedicada a recoger los errores encontrados porque no hemos usado el modo seguro.

Fijaos en los CRC32 (saltando 0's) y las firmas (signature). Son idénticas a las obtenidas en los rips seguros que XLD ha hecho a partir del CD original y de la copia. Además, el CRC32 (sin más) también es igual en ambas extracciones, segura y rápida, a partir del CD-R (recordad que este valor era distinto al obtenido al ripear del CD original por el tema del pregap de 2 segundos).

Osea, que el resultado es nuevamente idéntico.

Si usamos Audio DiffMaker para comparar esta pista extraída "a lo bruto" con la extraída sin errores del CD original (en ese caso en modo seguro y con AccurateRip) obtenemos esto:

Código:

parameters: 0sec, 0,000dB (L),  0,000dB (R)..Corr Depth: 300,0 dB (L), 300,0 dB (R)

Coincidentes al 100%.

En resumen:

• Una unidad óptica de PC lee un CD-Audio del mismo modo que un reproductor de CD, solo que mucho más rápido.
  
• De hecho, un reproductor de CD dispone de mecanismos adicionales para tratar de sobreponerse a los errores que el sistema de corrección de errores integrado no puede tratar.
  
• Una unidad óptica de PC no dispone de estos mecanismos adicionales.
  
• Existe software específico para PC o Mac capaz extraer el audio de un CD con mayores garantías que un reproductor de CD (modos seguros).
  
• Una extracción digital realizada con un software de PC en modo *no seguro* ha sido capaz de leer la pista de prueba de un CD-R en buen estado con la misma calidad que en modo seguro, obteniendo un resultado idéntico bit a bit.
  

Mi conclusión: o esas diferencias que escucháis se deben a otros motivos distintos o los fabricantes de reproductores se están cubriendo de gloria por lo que hace a la calidad de los bloques de lectura de sus reproductores y/o sus firmwares de control.

Nuevo experimento:

Supervitaminado Pablopi´s Version mode ON

Anonadado me hallo. A sus pies

Qué currada pablopi !!!  

hifiliberator escribió: Los errores de lectura digital se traducen en pérdida de información,

Dicho así...

Los sistema de detección y correción de errores, bit de paridad, CIRC, EFM, IED, ECC...  son robustos y altamente fiables, no hay pérdida de información detectable, si el error es demasiado largo la interpolación es, igualmente, un sistema de garantía, se inventa bits, es cierto, pero lo hace en base a algoritmos de probada eficacia y si aún sigue habiendo grandes errores se silencian hasta niveles inaudibles, los chasquido solo llegan en casos en donde el proceso es claramente truncado por mal funcionamiento del sistema de extracción.

Saludos.

Eres la leche Pablo

Anda... anímate y compara Spotify/Tidal hombre...

Muy buenas pruebas Pablo, me has convencido de que en condiciones digamos....  óptimas pueden darse lecturas con cero errores. Sólo quedaría probar con CD-R de cierta antigüedad, o grabados en una máquina distinta, o ambas cosas, para ver si dicha fiabilidad puede hacerse extensiva.

Un saludo.

Azazel escribió:Eres la leche Pablo

Anda... anímate y compara Spotify/Tidal hombre...

Demasiado tarde... nuestro Pablo compara todo lo que se mueve. Ya en el hilo de marras aparecían cosas "raras"

https://www.audioplanet.biz/t58483p60-tidal-nuevo-servicio-de-streaming-en-alta-calidad-1411kbps#501196

Flick4 escribió:Sólo quedaría probar con CD-R de cierta antigüedad, o grabados en una máquina distinta, o ambas cosas, para ver si dicha fiabilidad puede hacerse extensiva.

Pues sí, es probable que con cedés en peores condiciones la cosa no resulte tan bien. Eso es algo que también me gustaría probar, pero primero tengo que sacar un rato para ver si la captura de audio a través de una salida SPDIF es realmente transparente y liarme a comparar lo ripeado desde el ordenador con lo leído por un reproductor.

La cosa esta clara, siguiendo la metodología has llegado a una conclusión, y a tenor de los resultados, vuelve a reafirmar lo que sospechamos los no creyentes. No llego al nivel técnico que manejáis por aqui en temas de audio, pero llevo muchos años trabajando con servidores y sistemas de almacenamiento. Siempre he tenido claro que el mundo digital al final se reduce a cadenas de unos y ceros. Cuando imagino los servidores de una base de datos, conectados con cientos de metros de cable de red, infinidad de circuitos, switches, adaptadores, conversores de fibra ... infinidad de hardware que pese a emplear cables de "ferretería" (como tanto gusta decir por aqui) son capaces de enviar cantidades increibles de información (me rio del ancho de banda necesario para enviar audio) y pese a todo son capaces de hacerlo sin errores
¿Os imaginais que en función del cable utilizado las escrituras en los sistemas de almacenamiento de nuestros discos fueran "mejores"? ¿No, verdad? Pues más o menos es lo que se proclama aqui cada dos por tres.

Ya tengo claro que un ripeo de un CD de Audio es 100% idéntico al original. Ahora me gustaría saber como es posible que aun y todo, ciertas personas sean capaces de encontrar diferencias. ¿Si se alterna un bit en la copia, sonarían mejor los clarinetes?

Bueno, pues llegó el momento de la verdad. Todo preparado para ver si:

a) Los cables / conexiones toslink son tan malos como se cuenta.
b) Los reproductores de CD reproducen peor un CD-R que un CD prensado.

Este es el reproductor empleado, un Pioneer DV-LX50, un bicho que hace unos cuantos años era gama alta en cuanto a reproductores multiformato del fabricante japonés Pioneer:



Lo he conectado a un módulo USB Edirol (Roland) UA25, una sencilla tarjeta de sonido externa que en su momento fue bastante popular debido a que era una de las pocas totalmente compatibles con DrCop. Aunque es capaz de reproducir y grabar hasta 96Khz / 24 bits lógicamente la he configurado a 44/16 para que no se reproduzca ningún tipo de manipulación sobre la señal de audio digital emitida por el reproductor de CD:



Para interconectar el reproductor y la capturadora he empleado un un cable Toslink de Monster Audio. Pelín por encima de un cable "de ferretería", que también pienso introducir en las pruebas, aunque probablemente en otro hilo en el que quiero comparar transportes (digitales), reproductores software y cables digitales:



Por último, el cable USB empleado para conectar la Edirol con el PC es uno simple (ahora sí) de ferretería con el único lujo de contar con sendas ferritas en sus extremos:



Os recuerdo que el objetivo es comparar el audio extraído digitalmente empleando de un CD original usando XLD en un ordenador con el reproducido por el reproductor de CD desde a) el CD original b) una copia en CD-R:



Me muero de curiosidad por obtener resultados...

Quedo a la espera. Interesantisimo experimento, y a priori suficientemente aséptico para que los resultados puedan considerarse concluyentes en uno u otro sentido.

Un cordial saludo

Esperando resultados.
Como siempre, un excelente diseño metodológico, expuesto de forma clara y didáctica

Lo mismo digo...

Me acomodo, hago palomitas y espero atento tus conclusiones

Cojo asiento yo también.

Un saludo.

Me temo que de momento no hay conclusiones.

La primera comparativa entre el audio ripeado de un CD con XLD y el capturado a partir de la salida Toslink de un reproductor de CD indica que hay grandes diferencias entre ambas secuencias digitales:

Código:

parameters: -67,19msec, 0,019dB (L),  0,018dB (R)..Corr Depth: 53,5 dB (L), 54,6 dB (R)

Ese resultado para la correlación es similar al que se obtiene al comparar un flac y un mp3 (y uno de bitrate no demasiado alto) y está muy lejos de los valores que yo esperaba.

Las diferencias son audibles escuchando el archivo diferencia (que debería ser silencio absoluto si ambas muestras fueran iguales) a volumen casi máximo. Es más, lo subí ayer a Soundcloud para colgarlo aquí pero el sistema de detección de infracciones de copyright identifica la canción, a pesar de que se trata de una diferencia de 2 cosas que deberían ser muy similares si no idénticas , que de hecho se puede escuchar y seguir perfectamente, letra incluída, "a oreja".

La comparación entre el audio capturado cuando se reproduce el CD original y el CD-R anda algo mejor, pero tampoco es para tirar cohetes:

Código:

parameters: -242,6msec, -0,001dB (L),  -0,001dB (R)..Corr Depth: 80,1 dB (L), 81,3 dB (R)

Mosqueado por estos resultados, he empezado a sospechar que el proceso de captura de audio en digital no estaba funcionando correctamente .

Para verificarlo he probado a reproducir la pista de audio empleada a lo largo de todas las pruebas a través de la salida de audio digital integrada en la placa base de mi ordenador (manteniendo la captura con el módulo USB Edirol) con mejores resultados pero lejos de ser  "bitperfect".

Código:

parameters: -1,139sec, 1,358dB (L),  1,358dB (R)..Corr Depth: 131,2 dB (L), 131,3 dB (R)

He repetido la prueba con otro cable Toslink, por si el empleado tuviera algún problema, con idénticos resultados.

El modulo de sonido Edirol UA25 que estoy empleando dispone de un bucle interno digital. Cuando se activa, el audio que llega en digital a la tarjeta vuelve al PC a través del cable USB sin pasar por los DACs. Digamos que es lo más lejos que se puede llegar en el circuito de reproducción sin salir a analógico:



Lo siguiente ha sido, por tanto, volver a repetir el experimento pero esta vez reproduciendo y grabando con la Edirol, en ambos casos a través de USB.

Código:

parameters: 344,1msec, -0,700dB (L),  -0,701dB (R)..Corr Depth: 71,8 dB (L), 81,4 dB (R)

De nuevo, mal  . Cambio de cable USB... y exactamente el mismo resultado. Si una captura "en bucle" como esta falla, ya no me puedo fiar de nada.

La Edirol tiene además 2 modos de funcionamiento, uno básico limitado a 44/16, que es el que en principio he empleado por considerar que se ajustaba mejor a la naturaleza de la señal a capturar, y otro avanzado que permite 44, 48 o 96Khz en captura y reproducción pero con una profundidad de 24 bits. Este último es el que se recomienda emplear puesto que según la documentación es el más "preciso".

He tratado de profundizar en el tema, leyendo por aquí y allá...

http://www.soundonsound.com/sos/jul99/articles/pcmusician.htm
http://www.baudline.com/solutions/full_duplex/edirol_ua25/
http://www.hydrogenaud.io/forums/index.php?showtopic=98983
http://www.hydrogenaud.io/forums/index.php?showtopic=91655
http://forum.videohelp.com/threads/136256-TOSLink-or-S-PDIF-Capture
http://originaltrilogy.com/forum/topic.cfm/SUCCESS-Bit-Perfect-Audio-Capture/topic/15988/page/1/

...y este último, interesantísimo:

https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html

...Y parece que lo de conseguir una captura totalmente transparente a través de una conexión SPDIF no es algo en absoluto inmediato: entran en juego el propio dispositivo de captura, sistema operativo y drivers, aplicación de audio empleada, etc. etc. Sospecho que la Edirol aplica algún tipo de conversión de frecuencia y/o dithering sobre la señal de entrada digital en hardware.

En resumidas cuentas, la captura de audio en la Edirol UA25 no parece ser "bitperfect". Por tanto, por el momento no tengo más remedio que a concentrarme en perfeccionar el proceso de captura digital antes de tratar de hacer más comparaciones. Voy a tener que hacer más pruebas utilizando otro sistema operativo (los resultados anteriores se han obtenido usando OS X). Además, en lugar de utilizar señales PCM voy a pasar a emitir y capturar audio codificado en AC3 o DTS, para ver si el capturado sigue siendo reconocido como tal al ser reproducido por un receptor multicanal. Esto me parece garantía de transparencia en el proceso de captura.

En caso de que no consiga resolver el problema y ante la imposibilidad de hacer una comparación a nivel de muestra digital no tendré más remedio que capturar a partir de las salidas analógicas y ver qué sale.

Pablo:
En primer lugar gracias por exponer con tanta claridad unas pruebas… que no ofrecen el resultado esperado. Muchas veces parece que las pruebas que uno lee parecen sólo destinadas  a corroborar las hipótesis preconcebidas. Sólo por eso, bravo !

Del conjunto de ensayos que haces, una conclusión es que tú querías averiguar sobre el comportamiento de una variable (la salida TosLink) y parece que surgen más elementos distorsionadores. Es decir, manejas diversas variables y desconoces el factor de alteración de varias de ellas, por lo cual es imposible atribuir los resultados  a tal o cual elemento. Si todas las pruebas hubieran arrojado resultados diferentes pero relativamente (o muy) iguales entre sí, las diferencias podrían haber sido atribuidas únicamente a la Edirol. Como no es el caso, habrá que delimitar dónde se producen los cambios.

A mi entender, en la prueba en la que se manejan menos variables es en la 2ª. Si he entendido bien en esta prueba se realiza la comparación entre:
CD original → Reproductor Pioneer → TosLink → Edirol → AudioDiff Maker
CD original → Ripeado a Wav → Tostado a CD-R → Reproductor Pioneer → TosLink → Edirol → AudioDiff Maker

Si se encuentran diferencias entre los resultados, los únicos elementos que varían son los señalados en rojo… suponiendo que los demás componentes no tengas un rendimiento aleatorio.

Podrías ripear este fragmento en un ordenador con Windows y  EAC, a ver que pasa…

Otra cosa, que quizás has hecho y quizás parezca una bobada pero que nunca está de más es comprobar la estabilidad del sistema en el tiempo: Comparar dos muestras de la misma prueba (por ejemplo el CD original) tomadas en diferentes momentos. Si no se logra una exactitud absoluta es que el sistema no es fiable y con él no se pueden llevar a cabo pruebas de ningún tipo.

Si encuentro tiempo, introduciré en mis pruebas comparativas de archivos de audio (diferentes sistemas operativos, diferentes reproductores) una versión de los mismos archivos ripeados a CD.
Me ha picado la curiosidad. A ver que sale

Hola,

Enhorabuena y gracias por el trabajo tan sistemático que estas haciendo.

Supongo que si no se tiene un equipamiento muy sofisticado, una buena forma de comparar fuentes digitales es precisamente la que comentabas en el último párrafo, digitalizar las salidas analógicas del dac o lector y comparar los archivos resultantes.
Digo esto porque así se compara el trabajo que hace el dac o lector con el stream digital que le llega, en definitiva lo que escucharemos después. Hace algún tiempo utilicé el programa Audio Rightmark y una tarjeta de sonido M-Audio para comparar así algunos CD's y DAC que tenía entonces.

Mi opinión (y mi experiencia subjetiva) es que no debería haber diferencias entre un cd-r y cd original, siempre que la copia se haya hecho bien, partiendo de un ripeo correcto y que el lector se lleve bien con la velocidad de grabación utilizada, la calidad del cd-r, etc.

Como ya se ha dicho por aquí, el formato de cd-audio es mucho más delicado que el cd de datos, con mucho menos datos para corrección de errores y con derecho a interpolar. Además el soporte CD-R puede tener una vida dramáticamente corta según su calidad, cómo se maneje y almacene, etc. Para colmo algunos lectores de CD son (sobre todo eran) tremendamente quisquillosos con los CD-R. Quizás todo ello haya creado una especie de leyenda negra audiofila alrededor del formato.

Con ganas y tiempo, sería también muy interesante comparar con la misma metodología fuentes de ordenador, interfaces USB, entradas digitales de DACs, drivers de audio, etc.

Saludos !

Ignasi L escribió:
Del conjunto de ensayos que haces, una conclusión es que tú querías averiguar sobre el comportamiento de una variable (la salida TosLink) y parece que surgen más elementos distorsionadores. Es decir, manejas diversas variables y desconoces el factor de alteración de varias de ellas, por lo cual es imposible atribuir los resultados  a tal o cual elemento. Si todas las pruebas hubieran arrojado resultados diferentes pero relativamente (o muy) iguales entre sí, las diferencias podrían haber sido atribuidas únicamente a la Edirol. Como no es el caso, habrá que delimitar dónde se producen los cambios.

Bueno, más bien lo que yo quería determinar en este segundo experimento era el grado de similitud del flujo de bits que:

a) Se extrae de un CD empleando un procedimiento de alta calidad (XLD con ripeo seguro, ajuste de corrección de desplazamiento de lectura, etc.)
b) Un reproductor de CD que lee un CD original.
c) Un reproductor de CD que lee un CD-R generado con el audio extraído en (a).

Lo que me he encontrado es que el proceso de captura de audio necesario para (b) y (c) no parece ser transparente.

Ignasi L escribió:
Otra cosa, que quizás has hecho y quizás parezca una bobada pero que nunca está de más es comprobar la estabilidad del sistema en el tiempo: Comparar dos muestras de la misma prueba (por ejemplo el CD original) tomadas en diferentes momentos. Si no se logra una exactitud absoluta es que el sistema no es fiable y con él no se pueden llevar a cabo pruebas de ningún tipo.

Sí, eso sí lo he probado. El audio extraído con XLD a partir del CD es idéntico bit a bit en diferentes extracciones.

De momento tengo que "afinar" el asunto de la captura.

yasduit escribió:Quizás todo ello haya creado una especie de leyenda negra audiofila alrededor del formato.

Sí, estoy de acuerdo. En este mundillo me parece que hay mucho más de leyenda que de realidad.

yasduit escribió:
Con ganas y tiempo, sería también muy interesante comparar con la misma metodología fuentes de ordenador, interfaces USB, entradas digitales de DACs,  drivers de audio, etc.

En estas pruebas y de rebote he probado a emplear 2 cables USB y 2 ópticos distintos (por si los empleados inicialmente estaban defectuosos). Los resultados que proporcionaba Audio DiffMaker en cuanto al valor de la correlación eran idénticos hasta la centésima.

De momento estoy liado con esto, pero más adelante y en la medida de mis posibilidades me gustaría hacer una pequeña comparativa enfrentando reproductores bitperfect, a ver qué sale.