Sobre la calidad

[Asincrono]

Hablando del mundo digital, lo que yo he entendido de lo que ha dicho Raul (corrígeme si me equivoco), es que ningún sistema hardware +  software, por ejemplo un ordenador, podrá reproducir un fichero digital como lo haría un sistema hardware, como un reproductor de CDs.

Un ordenador, por muy rápido que sea, realiza un montón de tareas simultáneamente, es decir que mientras reproduce un fichero de audio, por ejemplo un wav sin ningún tipo de compresión, esta haciendo otra muchas cosas. Y como los sistemas operativos que usamos no son en tiempo real el jitter asociado a una reproducción con un ordenador será mayor que la generada por un reproductor de CD.

Otro tema es que esto sea inapreciable a nivel sonoro en nuestra escala humana. Bien porque no tengamos las herramientas para verlo o porque nuestro equipo no tenga la suficiente resolución para oirlo.

Pero desde el punto de vista melómano, vas a disfrutar igual, tanto un CD, como una reproducción de la misma pieza con un ordenador.

A mi personalmente me gusta más como suena el CD a como lo hace el ordenador. Eso no me impide disfrutar de la música que tengo en el ordenador, por supuesto.

Por partes. Un reproductor de CDs es un sistema software + hardware. El el software sea menos vistoso o esté almacenado de forma distinta no significa que no exista.

El jitter (retardo) no se debe al software ni a la lectura del los datos del CD. Cuando se leen datos de audio, de un CD o de un archivo, la tarea se realiza a tal velocidad que se leen datos mucho más rápido de lo que se necesita para la reproducción. Estos datos se almacenan en un buffer (una memoria intermedia), y van saliendo de este buffer a la velocidad "adecuada", según dicta un reloj asociado al sistema donde se encuentra el buffer. De la precisión de este reloj y el camino que siga a partir de ahí la señal (que representa valores digitales) depende que se produzca más o menos jitter (así como del sistema de conversión de digital a analógico, y de transmisión de la señal analógica hasta el elemento que transforma la señal en sonido). El buffer funciona como un colchón, de modo que se si produce un error de lectura (y el correspondiente retardo debido ha que hay que releer el dato), el buffer se irá vaciando, y cuando se solvente el error se rellenará otra vez.
(Esta es una explicación simplificada de jitter)

Si la velocidad del ordenador es suficiente para mantener el buffer "lleno", entonces no hay problema. Aunque parezca que el sistema operativo y el procesador están haciendo muchas cosas a la vez... salvo casos raros se pasan la mayor parte del tiempo ociosos 

Buenas de nuevo. Creo que debido a mi natural torpeza a la hora de expresarme  he generado una polémica no deseada. Lo que he querido decir simplemente es que cuando escucho un CD16/44 (de ahí mi mal usada expresión de formato) en el lector de cds y una copia exacta de este en el ordenador siempre me suena mejor la primera, independientemente de que las dos señales luego pasen por el mismo dac (de ahí mi otro error en usar el termino fuente). Creo que no he sabido transmitir adecuadamente mi pensamiento. Lo de dudar de mis oidos se refiere precisamente a que "teóricamente", si es una copia exacta debería sonar igual con los dos medios de reproducción y no es así. Siento mi torpeza y prometo elaborar un poco más mis enrevesados pensamientos.

Saludos
PD Es que estos días estoy probando soft de reproducción de archivos flac en mac y estoy como las maracas de machín.

Estoy hablando de cuestiones técnicas generales, relacionadas con los formatos de archivo y la transmisión de datos digitales. No me refiero a tu caso particular. Mis conocimientos de limitan a esto, desconozco como funciona la transmisión de datos desde un lector de CD o un ordenador a un DAC externo y las posibles fuentes de problemas que se le aplican a este proceso. Contesto a las afirmaciones, también generales, que se han hecho respecto a los ordenadores y a los formatos de compresión sin pérdidas. Y no lo hago por llevar la contraria, si no porque considero que son erróneas y podrían llevar a confusión.

Saludos.

[Asincrono]

Audirvana, Fidelia, Decibel, Vox. La verdad es que últimamente más que escuchar música pongo el mismo tema 10 veces al día con distintos reproductores, auriculares, amplis etc.  Acabo loco todas las noches, y lo peor es que cuando creo que he decidido un soft irremediablemente vuelvo a cambiar. Amarra y puremusic no los he probado.
Por ahora me gustan audirvana (cuando funciona), y fidelia (este es un trial de 15 dias), pero es una mera cuestión de gustos.

Saludos

¿Y es imprescindible que uses flac? Quizás, tratándose de mac, el soporte para alac sea mejor. Respecto a las diferencias de sonido entre distintos reproductores, salvo que tengan que hacer conversiones (16/44 -> 24/96) y o apliquen filtros parece raro que puedan sonar distintos. ¿Notas mucha diferencia de un reproductor a otro?

Saludos.

[Howard Wolowitz]

Si noto bastante diferencia entre unos y otros. El hecho de utilizar flac es que porque no sólo uso mac, también tengo windows 7 y reproductores portátiles y me parece más cómodo que el alac.

Saludos

[Eferbel]

¿Pero notas cambios respecto a la calidad o es simplemente a nivel de manejo de la librería?

[Howard Wolowitz]

Suenan distintos independientemente del manejo de la librería, imagino (por lógica más que por conocimiento) que por las opciones que cada uno tiene.

Saludos

[Jose]

Desde la total ignorancia; ¿Y no es posible que todos esos programas tengan una ecualización predeterminada ? 

Saludos

[Howard Wolowitz]

Esta claro que tratan la señal de distinta manera, algunos tienen plugins etc, pero el hecho es que me suenan distintos. Para mi se trata de una simple cuestión de elección y no pretendo en modo alguno que todos suenen siquiera parecidos.

Saludos

[Eferbel]

Muchas gracias, habrá que trastear a ver que tal.

[Asincrono]

Esta claro que tratan la señal de distinta manera, algunos tienen plugins etc, pero el hecho es que me suenan distintos. Para mi se trata de una simple cuestión de elección y no pretendo en modo alguno que todos suenen siquiera parecidos.

Saludos

Pero es que en principio el mismo archivo debería sonar igual desde cualquier programa, si no se le aplican ningún efecto/plugin/ecualización y en caso de que tengan la misma configuración. En caso de que suene distinto, como bien dices, es que tienen que estar haciendo algún procesamiento sobre la señal (bueno, en realidad sobre los datos que la representan), y si desconoces qué es lo que hacen, elegir entre ellos parece más peliagudo.

Saludos y suerte  .

[Howard Wolowitz]

Ahí lo llevas, estoy loco probando configuraciones en cada programa.

Saludos

[azelais]

Asincrono. Quizás me expliqué mal. Lo que qiuero decir es que una copia, jamás puede ser superior al original por una cuestión de lógica pura:
Sí tiene más infromación, la ha "creado".
Sí tiene menos, la ha omitido.
Si la tiene diferente, la ha variado.
Sí la tiene igual, es idéntica.

No puedo entrar en consideraciones tecnícas porque no las domino. Pero sinceramente; sí algo es capaza de eliminar los "errores" de un original, puedo asegurarte que algo de magia hay.
Por otro lado "haberlas hailas".

Un saludo

[Asincrono]

Completamente de acuerdo Azelais.

Respecto a lo de "eliminar" errores intentaré explicarlo un poco.
Cuando hablo de errores en el original no me refiero a cosas que "se pueden considerar erróneas", si no a ERRORES  Como cuando no se puede leer algo porque el original está manchando, rayado o es defectuoso. O cuando se produce un error en la transmisión de datos y se cambia algún dato.

Los códigos correctores de errores funcionan de la siguiente manera (esto es un poco a lo bruto, que no tengo la cosa fresca pero la idea es la siguiente):
Imagina que tienes un libro, y que sabes que al copiarlo puedes liarla parda y cambiar, de vez en cuando, alguna letra. Pues para curarte en salud, y como te sobra papel, en vez de codificar las palabras tal cual, las codificas repitiendo tres veces cada letra: "hola mundo" pasaría a ser "hhhooolllaaammmuuunnndddooo___mmmuuunnndddooo".
Ahora estás salvado:

• Por un lado puedes detectar si se han producido errores en la copia, ya que si lees un grupo de tres caracteres y no son idénticos, es que se ha producido un error: Si lees "hhi" sabes que algo está mal. Pues las tres letras que decidiste que siempre ibas a repetir, no coinciden.
• Por otro lado, si se ha producido un error en, como máximo, una letra de cada tres, puedes corregirlo (tomas las dos que son iguales como las correctas): Sabes que si en "hhi" sólo hay un error , tendrá que ser en la "i" y el original tendría que ser "hhh".
  

Esto solo vale para detectar errores si se producen, como máximo, en dos letras de cada tres, y corregirlos si se producen en una de cada tres. Si se produjese en dos de cada tres letras, podría pasar lo siguiente: original: "hhh", se producen dos errores "ihi", el algoritmo de corrección detecta un error pues los tres caracteres no coinciden, los dos caracteres que se repiten son las "i", por lo que concluye (erroneamente en este caso) que el mensaje original era "iii". Si el error se produjese en tres caracteres no podríamos asegurar siquiera que se detecte: "hhh" podría haberse transformado en "jjj" y al procesarlo no detectaríamos ningún error.

Por lo tanto, puede diseñarse un código con corrección (y detección) de errores que corrija cierto tipo de errores. El "truco" está, como puedes ver, en incluir información extra (en nuestro ejemplo, se repiten letras). Así que analizando el medio por el que se transmiten los datos y determinando que errores se pueden producir, puedes diseñar un código que permita transmitir datos que corrija las deficiencias del medio. Otra cosa es que sea rentable (en tiempo y espacio) 

Espero no ser pesado o aburrido, pero es que a mi me pareció muy interesante el tema en su momento. Y no es difícil hacerse una idea de como funciona.

Como anécdota, cuando se estaba implantando el sistema de numeración de teléfonos en España, se contempló la idea de aplicar las técnicas de códigos con corrección de errores para distribuir los números de teléfono de tal modo que si al marcar cometieses un error en una única cifra, te conectase igualmente al número correcto... pero por algún motivo esa idea finalmente se rechazó 

Saludos.

[Torpedo]

Muy buena explicación Asíncrono. Ahora te falta contar por qué el algoritmo de corrección de errores en los lectores de CDs no es tan infalible como mucha gente piensa

[Asincrono]

Muy buena explicación Asíncrono. Ahora te falta contar por qué el algoritmo de corrección de errores en los lectores de CDs no es tan infalible como mucha gente piensa

... que cabrón... para eso mejor 

Por lo que veo (wikipedia al rescate) los compas dic, si aceptamos que se rigen por el estándar (el famoso Red Book), emplean cross-interleaved Reed-Solomon coding (CIRC para los amigos).

• Lo de Reed-Solomon coding hace referencia a un sistema de construcción de códigos mediante el cual se asegura que añadiendo t símbolos de control se podrán detectar errores de tipo t (hasta t símbolos erróneos) y corregir errores de tipo t/2.
  Es decir, añadiendo 6 símbolos de control se podrá detectar errores en hasta 6 símbolos y corregir errores que se produzcan en, como máximo 3 símbolos. Y sirve tanto para errores que impliquen un cambio de símbolos como la ausencia de los mismos.
• Lo de cross-interleaved es una técnica que se aplica a mayores para distribuir la información de corrección entre varias "zonas", de modo que si le metes un tajo a un disco no te cepilles toda la información de corrección de las "zonas" afectadas. También se usa en algunos niveles de RAID si no recuerdo mal.

Mala pinta no tiene. Por lo que leo (me niego a profundizar más, repasar teoría de códigos y hacer las cuentas  ) pueden corregir una mezcla de errores aleatorios y de ráfaga (errores consecutivos), con secuencias de hasta  3.500 bits, lo que se corresponde (2,4 mm de longitud en la superficie del CD).

No se cuan infalible cree la gente que es el algoritmo de corrección (infalible, salvo YO, no hay nada), no es un tema recurrente de conversación con mis amigos  ; pero en mi opinión, como dicen en mi tierra: chégalle ben.

En todo caso, parece que es bastante mejor que el algoritmo de corrección de errores que se emplea en los vinilos  , ¿no? 

Bueno, Torpedo, ahora no te me vayas de rositas, te toca a ti mostrar las pegas. Que no dudo que las hay. Así que toma el relevo.

Saludos.

P.D.: Hice alguna corrección en la redacción, añadí algún link y me enteré de que existe el VinilDisc (un CD por un lado y un disco de vinilo por el otro) si es que la gente no sabe ya que inventar  parece que ya no lo fabrican (siempre se nos van los mejores) 

[Torpedo]

Jajaja, no, si yo de estas cosas no tengo ni idea, bastante tengo con lo mío Según tengo entendido, el "problema" es que en el año 82, cuando inventaron esto del CD, de corrección de errores y de audio digital, como que no tenían ni pajolera. Claro, si tenemos en cuenta que la solución para masterizar audio era usar cintas de VHS porque un disco duro valía una millonada... El caso es que el Reed-Solomon es una adaptación simplificada de un algoritmo que se usaba creo que para las comunicaciones con satélites  y eso con la información de las ondas de audio y de los errores probables, posibles, esperables, frecuentes o imposibles, como que tenía poca relación. Vamos, que es un sistema que se lleva usando casi 30 años pero que no tiene relación directa con el tipo de problema que pretende prevenir y resolver. Resumiendo, que corrige los errores para que la señal no se corte, pero no los corrige con información que se ajuste con una alta probabilidad a lo que debería haber, sino a lo que matemáticamente se espera, que teniendo en cuenta que esto de la música es una parida bastante arbitraria, variable y muchas veces imprevisible, no tiene por qué ser lo más adecuado.