Jriver media center, menudo reproductor

Vía Asio y wasapi es expectacular el sonido que ofrece, para mi gusto mejor que foobar, de hecho mucho mejor, y no solo porque suene más fuerte y porque no tengas que configurar tantos aspectos visuales, sino sobre todo por el detalle que ofrece, he hecho la comparariva subjetiva a ciegas y mejor jriver, de hecho hay detalles que a foobar se le escapan. En general me sonaban mejor los instrumentos con jriver, más realistas, pero no me fío mucho de mi oido, lo que me hizo convencerme que no era una apreciación subjetiva es que oía detalles que en foobar no estaban, por ejemplo Melody gardot tragando saliva o separando la lengua del paladar, son claramente perceptibles. No oímos uns disco para notar esto, solo es un síntoma objetivo del detalle que recoge jriver.

Saludos

Jazz escribió:Vía Asio y wasapi es expectacular el sonido que ofrece, para mi gusto mejor que foobar, de hecho mucho mejor, y no solo porque suene más fuerte y porque no tengas que configurar tantos aspectos visuales, sino sobre todo por el detalle que ofrece, he hecho la comparariva subjetiva a ciegas y mejor jriver, de hecho hay detalles que a foobar se le escapan. En general me sonaban mejor los instrumentos con jriver, más realistas, pero no me fío mucho de mi oido, lo que me hizo convencerme que no era una apreciación subjetiva es que oía detalles que en foobar no estaban, por ejemplo Melody gardot tragando saliva o separando la lengua del paladar, son claramente perceptibles. No oímos uns disco para notar esto, solo es un síntoma objetivo del detalle que recoge jriver.

Saludos

Es probable que el mayor detalle que aprecias venga de ahí.

Saludos.

Chordeater escribió:

Jazz escribió:Vía Asio y wasapi es expectacular el sonido que ofrece, para mi gusto mejor que foobar, de hecho mucho mejor, y no solo porque suene más fuerte y porque no tengas que configurar tantos aspectos visuales, sino sobre todo por el detalle que ofrece, he hecho la comparariva subjetiva a ciegas y mejor jriver, de hecho hay detalles que a foobar se le escapan. En general me sonaban mejor los instrumentos con jriver, más realistas, pero no me fío mucho de mi oido, lo que me hizo convencerme que no era una apreciación subjetiva es que oía detalles que en foobar no estaban, por ejemplo Melody gardot tragando saliva o separando la lengua del paladar, son claramente perceptibles. No oímos uns disco para notar esto, solo es un síntoma objetivo del detalle que recoge jriver.

Saludos

Es probable que el mayor detalle que aprecias venga de ahí.

Saludos.

No es así, es lo primero que he comprobado, porque bastaría subir el volumen con el foobar hasta encontrar ese detalle, y no está, por mucho que suba el volumen. Creeme, no me hace gracia en los tiempos que corren gastarme 35 euros en software, pero lo voy a hacer, eso sí, después de valorar si vale la pena, teniendo en cuenta que solo voy a utilizarlo como reproductor de audio, no de video, y para mí la vale, una lástima que el jukebox que es solo audio no soporte api ni wasapi.

Jazz escribió:Vía Asio y wasapi es expectacular el sonido que ofrece, para mi gusto mejor que foobar, de hecho mucho mejor, y no solo porque suene más fuerte y porque no tengas que configurar tantos aspectos visuales, sino sobre todo por el detalle que ofrece, he hecho la comparariva subjetiva a ciegas y mejor jriver, de hecho hay detalles que a foobar se le escapan. En general me sonaban mejor los instrumentos con jriver, más realistas, pero no me fío mucho de mi oido, lo que me hizo convencerme que no era una apreciación subjetiva es que oía detalles que en foobar no estaban, por ejemplo Melody gardot tragando saliva o separando la lengua del paladar, son claramente perceptibles. No oímos uns disco para notar esto, solo es un síntoma objetivo del detalle que recoge jriver.

Saludos

Puede ser que la diferencia es que el jrviver, si no me equivoco, carga el tema en memoria antes de reproducirlo y eso dicen que repercute en una mejora del sonido. Te animo a que pruebes el pureplayer, creo que se oye incluso mejor aunque su interfaz...en fín, de lo mas minimalista

Kugel escribió:

Jazz escribió:Vía Asio y wasapi es expectacular el sonido que ofrece, para mi gusto mejor que foobar, de hecho mucho mejor, y no solo porque suene más fuerte y porque no tengas que configurar tantos aspectos visuales, sino sobre todo por el detalle que ofrece, he hecho la comparariva subjetiva a ciegas y mejor jriver, de hecho hay detalles que a foobar se le escapan. En general me sonaban mejor los instrumentos con jriver, más realistas, pero no me fío mucho de mi oido, lo que me hizo convencerme que no era una apreciación subjetiva es que oía detalles que en foobar no estaban, por ejemplo Melody gardot tragando saliva o separando la lengua del paladar, son claramente perceptibles. No oímos uns disco para notar esto, solo es un síntoma objetivo del detalle que recoge jriver.

Saludos

Puede ser que la diferencia es que el jrviver, si no me equivoco, carga el tema en memoria antes de reproducirlo y eso dicen que repercute en una mejora del sonido. Te animo a que pruebes el pureplayer, creo que se oye incluso mejor aunque su interfaz...en fín, de lo mas minimalista

La organización de la biblioteca es un factor muy a tener en cuenta en mi caso, con más de 6.000 discos si no la organizo al final siempre oigo lo mismo. La probaré, también se habla bien en otro hilo de Seatlh Audioplayer

saludos

Jazz escribió:
gastarme 35 euros en software, .

moco2.com

Saludos

Hola:
Yo he probado a contrastar el jriver y foobar con kernel streaming y no noto gran diferencia. Los detalles son tan sutiles que tengo mis dudas de que los haya, aunque sí es cierto que en algunos momentos parece que no suenan igual. Pero hay que ir tan al detalle que después de una hora probando he acabado cazando moscas. No sé, seguiré probando.
Quizás los módulos de wasapi y asio de foobar no son todo lo buenos que deberían y con esas configuraciones se aprecia más. Hay que tener en cuenta que con wasapi hay que tocar los datos, ya que se tienen que convertir a como flotante para pasarlos a wasapi, y después a coma fija para mandarlos al dac. Es una modificación que debería ser irrelevante, pero se puede hacer mal, y por tanto el sonido puede cambiar. Asio lo desconozco por completo, no sé cómo va.
Con ks, funciona como un transporte puro y duro: se leen datos y se mandan al dac sin hacer nada más. Las variaciones de sonido en este caso no son evidentes. Al menos para mí.

Salud.

ferac66 escribió:Hola:
Yo he probado a contrastar el jriver y foobar con kernel streaming y no noto gran diferencia. Los detalles son tan sutiles que tengo mis dudas de que los haya, aunque sí es cierto que en algunos momentos parece que no suenan igual. Pero hay que ir tan al detalle que después de una hora probando he acabado cazando moscas. No sé, seguiré probando.
Quizás los módulos de wasapi y asio de foobar no son todo lo buenos que deberían y con esas configuraciones se aprecia más. Hay que tener en cuenta que con wasapi hay que tocar los datos, ya que se tienen que convertir a como flotante para pasarlos a wasapi, y después a coma fija para mandarlos al dac. Es una modificación que debería ser irrelevante, pero se puede hacer mal, y por tanto el sonido puede cambiar. Asio lo desconozco por completo, no sé cómo va.
Con ks, funciona como un transporte puro y duro: se leen datos y se mandan al dac sin hacer nada más. Las variaciones de sonido en este caso no son evidentes. Al menos para mí.

Salud.

Yo con el segundo equipo (altavoces autoamplificados adam audio a7 y como conversor d/a Roland Edirol FA66) no noto gran diferencia, por no decir casi ninguna solo el tema del volumen ya comentado, pero con el primer equipo (Etapa Krell Kav 3250, Previo Melody P1688 signature y cajas Monitor Audio PL300) de mucha más calidad se nota bastante más diferencia, creo que puede tener algo que ver, al menos en mi caso.

Hola chicos.

Leo con muchísimo interés los hilos en los que se habla de la superioridad manifiesta de unos y otros reproductores software por lo que hace única y exclusivamente a su calidad sonora. Lo cierto es que sin haber realizado las pertinentes pruebas hay cosas que me llenan de cierta perplejidad. Vaya por delante que no niego en absoluto que existan esas diferencias, solo que me cuesta encontrar una justificación para ellas. Me explico:

Cualquier reproductor software que utilice kernel streaming / asio / wasapi o un driver propietario para conseguir una salida que se salte el perverso mezclador de Windows debería ser bitperfect. Pasa con iTunes en Mac al poner el volumen al 100% y desactivar las mejoras de audio, pasa en foobar@W7 con wasapi y por supuesto con muchos otros reproductores. Mi experiencia se centra fundamentalmente en foobar, así que me centraré en él, dado que parece ser el rasero con el que se comparan el resto de reproductores, tanto los muy populares como jriver como los más esotéricos y aún en fase prácticamente alfa, como sería el caso de stealthmedia player.

Hay 2 cosas que desde mi punto de vista pueden afectar a la calidad de un flujo de bits de audio: los errores aritméticos cometidos al realizar algún tipo de DSP sobre él y el jitter procedente de pequeños (y cuando digo pequeños hablo de decenas, cientos o miles de ps) desajustes en la perfecta sincronización de la reproducción con respecto a la frecuencia de reproducción.

Vayamos con lo primero, la transparencia o no del reproductor: foobar con wasapi es transparente. Totalmente. Bit a bit. No hay errores aritméticos de ningún tipo, lo que se lee del archivo se envía al deco tal cual. Eso se comprueba fácilmente cuando se reproduce algún formato que no es PCM puro sino un bitstream en, por ejemplo, DTS y la decodificación no se realiza en el propio foobar sino en un receptor externo. Como sabréis DTS es un formato de codificación en el que el flujo de bits debe mantenerse en crudo desde el transporte al decodificador. DTS transporta el audio comprimido en una serie de tramas o paquetes de datos con una longitud determinada y con una serie de campos de control, metadatos en definitiva, que no son audio pero deben preservarse con la misma diligencia con la que se almacena un archivo binario ejecutable en un HD para que los cacharros a ambos lados del cable se puedan entender. Podéis echar un vistazo por ejempo aquí. Esto quiere decir que si el reproductor le "toca un pelo" (esto es, no es totalmente transparente) a la secuencia de bits nuestro decodificador será incapaz de identificar el flujo entrante como DTS y realizar la correspondiente decodificación y reproducción.

Pues bien, al menos en mi sistema, PC con salida HDMI hacia Denon 2308 (antes) o Pioneer LX81 (ahora), foobar + wasapi emite correctamente DTS hacia el deco, que lo identifica como tal (en pantalla aparece DTS) y lo reproduce perfectamente. Basta con tocar ligéramente el control de volumen de foobar o activar el EQ y la cosa se va a la porra: el deco pierde el sincronismo con el flujo DTS y por los altavoces solo se emite ruido. Puesto que foobar no tiene forma de saber que lo que está leyendo y enviando al receptor es DTS o simplemente PCM (lo envía a ciegas), creo que este punto queda demostrado claramente.

Con respecto al jitter, la cosa es mucho más complicada de valorar sin herramientas de medición de las que de desde luego carezco. Aquí se habla a menudo de cosas convenientes, como que el reproductor mantenga en memoria todos los datos del archivo a reproducir, que se desactiven otras tareas o servicios no necesarios del sistema operativo, etc. La idea es un poco la misma que inspira al tal Klauss de Soundcheck con su toolkit para el Squeezebox Touch: reducir la carga del sistema que realiza la reproducción y eliminar posibles fuentes de retrasos a la hora de que los bits lleguen al dispositivo de audio para minimizar cuanto sea posible la aparición de pérdidas de sincronismo que hagan que las muestras de sonido no se reproduzcan todas y cada una de ellas exactamente con la frecuencia que marca la frecuencia de muestreo del propio archivo.

Evidentemente los sistemas operativos modernos corren multitud de tareas y procesos de un modo preemptivo, existe una vida intensísima en las capas más bajas del sistema operativo, especialmente en las que se ocupan de la gestión de las operaciones de entrada / salida desde y hacia los dispositivo conectados (HD, tarjeta de sonido, etc.) y la propia memoria RAM, muchas de ellas dirigidas por interrupciones. El proceso responsable de leer el audio del archivo, no tocarle un pelo y emitirlo hacia el dispositivo de salida puede verse interrumpido mucho más de lo deseado por otras tareas de más bajo nivel pero con mayor prioridad que efectivamente podrían incrementar la latencia del sistema y hacer que la perfecta sincronización requerida en reproducción se viera afectada por pequeños retrasos que aumentaran el jitter total de la cadena de reproducción hasta el punto de convertirse en un problema.

Se han hecho experimentos para determinar hasta qué punto el jitter (y otros elementos de distorsión) puede suponer una perturbación claramente perceptible por el ser humano. En ese sentido me gustaría recomendaros este vídeo (desgraciadamente está en inglés):



Ahora bien, todo esto puede tener sentido en sistemas con escasa potencia de procesamiento (como puede ser un Sbox Touch)... pero ¿hasta qué punto pueden afectar estas interrupciones a equipos con procesadores potentes, RAM para regalar y rápidos discos duros? Estoy seguro de que si lanzáis cualquiera de los reproductores y abrís el administrador de tareas veréis que el uso de la CPU normalmente es muy bajo, a pesar de que puede haber cientos de tareas en ejecución. Evidentemente la mayor parte de SO que utilizamos no disponen de núcleos optimizados para aplicaciones en tiempo real pero, a pesar de eso, me cuesta mucho aceptar que el efecto del jitter sea tan claramente audible cuando comparamos jriver con foobar o con stealth.

Creo que sería muy importante para todos, cuando comentamos que un reproductor suena mejor o peor que aquel, que se mencionaran las características del sistema de reproducción para poder hacer una mejor valoración de los resultados obtenidos:

- Procesador, memoria, disco duro, sistema operativo.
- Localización de los archivos de audio (disco interno, externo, red, etc.) y características (frecuencia de muestreo y bits / muestra).
- Software empleado y configuración relevante
- Uso medio de la CPU o de la red (si se accede al archivo reproducido a través de ella) durante las pruebas.
- Tipo de salida (DAC USB, HDMI, analógica...) y marca y modelo del hardware de reproducción.

En fin, pretendían ser estas unas pequeñas reflexiones y me ha salido un ladrillo de cuidado .

Pablopi imtroduce un elemento muy interesante y en mi caso crítico, cómo afectan el resto de procesos a la reproducción en mo caso con foobar de forma nefasta, no doy con la causa pero windows 7 y wasapi meten mucho ruido e interferencias en el previo a válvulas y en windows xp a foobar le mete ruido, hablo de chasquidos, utorrent, no tengo conocimientos de informática, pero algo huele a podrido en el hardware de mi pc y creo que jriver lo soluciona, foobar no, esta podría ser una causa, no obstante en breve voy a cambiar la fuente, por una pasiva de más calidad, a ver qué pasa.

pablopi escribió:Hola chicos.

Leo con muchísimo interés los hilos en los que se habla de la superioridad manifiesta de unos y otros reproductores software por lo que hace única y exclusivamente a su calidad sonora. Lo cierto es que sin haber realizado las pertinentes pruebas hay cosas que me llenan de cierta perplejidad. Vaya por delante que no niego en absoluto que existan esas diferencias, solo que me cuesta encontrar una justificación para ellas. Me explico:

Cualquier reproductor software que utilice kernel streaming / asio / wasapi o un driver propietario para conseguir una salida que se salte el perverso mezclador de Windows debería ser bitperfect. Pasa con iTunes en Mac al poner el volumen al 100% y desactivar las mejoras de audio, pasa en foobar@W7 con wasapi y por supuesto con muchos otros reproductores. Me experiencia se centra fundamentalmente en foobar, así que me centraré en él, dado que parece ser el rasero con el que se comparan el resto de reproductores, tanto los muy populares como jriver como los más esotéricos y aún en fase prácticamente alfa, como sería el caso de stealthmedia player.

Hay 2 cosas que desde mi punto de vista pueden afectar a la calidad de un flujo de bits de audio: los errores aritméticos cometidos al realizar algún tipo de DSP sobre él y el jitter procedente de pequeños (y cuando digo pequeños hablo de decenas, cientos o miles de ps) desajustes en la perfecta sincronización de la reproducción con respecto a la frecuencia de reproducción.

Vayamos con lo primero, la transparencia o no del reproductor: foobar con wasapi es transparente. Totalmente. Bit a bit. No hay errores aritméticos de ningún tipo, lo que se lee del archivo se envía al deco tal cual. Eso se comprueba fácilmente cuando se reproduce algún formato que no es PCM puro sino un bitstream en, por ejemplo, DTS y la decodificación no se realiza en el propio foobar sino en un receptor externo. Como sabréis DTS es un formato de codificación en el que el flujo de bits debe mantenerse en crudo desde el transporte al decodificador. DTS transporta el audio comprimido en una serie de tramas o paquetes de datos con una longitud determinada y con una serie de campos de control, metadatos en definitiva, que no son audio pero deben preservarse con la misma diligencia con la que se almacena un archivo binario ejecutable en un HD para que los cacharros a ambos lados del cable se puedan entender. Podéis echar un vistazo por ejempo aquí. Esto quiere decir que si el reproductor le "toca un pelo" (esto es, no es totalmente transparente) a la secuencia de bits nuestro decodificador será incapaz de identificar el flujo entrante como DTS y realizar la correspondiente decodificación y reproducción.

Pues bien, al menos en mi sistema, PC con salida HDMI hacia Denon 2308 (antes) o Pioneer LX81 (ahora), foobar + wasapi emite correctamente DTS hacia el deco, que lo identifica como tal (en pantalla aparece DTS) y lo reproduce perfectamente. Basta con tocar ligéramente el control de volumen de foobar o activar el EQ y la cosa se va a la porra: el deco pierde el sincronismo con el flujo DTS y por los altavoces solo se emite ruido. Puesto que foobar no tiene forma de saber que lo que está leyendo y enviando al receptor es DTS o simplemente PCM (lo envía a ciegas), creo que este punto queda demostrado claramente.

Con respecto al jitter, la cosa es mucho más complicada de valorar sin herramientas de medición de las que de desde luego carezco. Aquí se habla a menudo de cosas convenientes, como que el reproductor mantenga en memoria todos los datos del archivo a reproducir, que se desactiven otras tareas o servicios no necesarios del sistema operativo, etc. La idea es un poco la misma que inspira al tal Klauss de Soundcheck con su toolkit para el Squeezebox Touch: reducir la carga del sistema que realiza la reproducción y eliminar posibles fuentes de retrasos a la hora de que los bits lleguen al dispositivo de audio para minimizar cuanto sea posible la aparición de pérdidas de sincronismo que hagan que las muestras de sonido no se reproduzcan todas y cada una de ellas exactamente con la frecuencia que marca la frecuencia de muestreo del propio archivo.

Evidentemente los sistemas operativos modernos corren multitud de tareas y procesos de un modo preemptivo, existe una vida intensísima en las capas más bajas del sistema operativo, especialmente en las que se ocupan de la gestión de las operaciones de entrada / salida desde y hacia los dispositivo conectados (HD, tarjeta de sonido, etc.) y la propia memoria RAM, muchas de ellas dirigidas por interrupciones. El proceso responsable de leer el audio del archivo, no tocarle un pelo y emitirlo hacia el dispositivo de salida puede verse interrumpido mucho más de lo deseado por otras tareas de más bajo nivel pero con mayor prioridad que efectivamente podrían incrementar la latencia del sistema y hacer que la perfecta sincronización requerida en reproducción se viera afectada por pequeños retrasos que aumentaran el jitter total de la cadena de reproducción hasta el punto de convertirse en un problema.

Se han hecho experimentos para determinar hasta qué punto el jitter (y otros elementos de distorsión) puede suponer una perturbación claramente perceptible por el ser humano. En ese sentido me gustaría recomendaros este vídeo (desgraciadamente está en inglés):



Ahora bien, todo esto puede tener sentido en sistemas con escasa potencia de procesamiento (como puede ser un Sbox Touch)... pero ¿hasta qué punto pueden afectar estas interrupciones a equipos con procesadores potentes, RAM para regalar y rápidos discos duros? Estoy seguro de que si lanzáis cualquiera de los reproductores y abrís el administrador de tareas veréis que el uso de la CPU normalmente es muy bajo, a pesar de que puede haber cientos de tareas en ejecución. Evidentemente la mayor parte de SO que utilizamos no disponen de núcleos optimizados para aplicaciones en tiempo real pero, a pesar de eso, me cuesta mucho aceptar que el efecto del jitter sea tan claramente audible cuando comparamos jriver con foobar o con stealth.

Creo que sería muy importante para todos, cuando comentamos que un reproductor suena mejor o peor que aquel, que se mencionaran las características del sistema de reproducción para poder hacer una mejor valoración de los resultados obtenidos:

- Procesador, memoria, disco duro, sistema operativo.
- Localización de los archivos de audio (disco interno, externo, red, etc.) y características (frecuencia de muestreo y bits / muestra).
- Software empleado y configuración relevante
- Uso medio de la CPU o de la red (si se accede al archivo reproducido a través de ella) durante las pruebas.
- Tipo de salida (DAC USB, HDMI, analógica...) y marca y modelo.

En fin, pretendían ser estas unas pequeñas reflexiones y me ha salido un ladrillo de cuidado .

Pues si. Básicamente es como dices. Yo siempre lo digo: los bits, si no se tocan, no suenan. En teoría, todos los reproductores bitperfect deben sonar exactamente igual. Incluso deben sonal al mismo volúmen. Pero los cambios en el sonido pueden venir por multitud de factores que acaben tocando los bits, por ejemplo:

- Un mal desarrollo en el módulo ks, wasapi.
- Una mala configuración (o configuración no deseada) del reproductor.
- La imposibilidad de desactivar por completo el procesador de sonido del reproductor. Por ejemplo: un sistema básico de dsp es el control de volumen. En foobar no se puede quitar y en jriver tiene varias opciones, pero creo que tampoco se puede desactivar.
- El mejor rendimiento del hardware con un reproductor específico.
- Fallos en el hardware que afecten a un reproductor concreto pero que sean transparentes para otro.
- Limitanciones de recursos y porcesamiento. Esto puede generar jitter fácilmente.

En fin, que las posibilidades existen. No obstante, en idénticas condiciones y sin limitaciones o errores de configuración, deben sonar clavaditos.

Por cierto, wasapi sí que puede generar errores aritméticos puesto que realiza una conversión de formato binario. Aunque dicha conversión es tan trivial que debería ser totalmente transparente.

Salud.

Salud

ferac66 escribió:

Pues si. Básicamente es como dices. Yo siempre lo digo: los bits, si no se tocan, no suenan. En teoría, todos los reproductores bitperfect deben sonar exactamente igual. Incluso deben sonal al mismo volúmen. Pero los cambios en el sonido pueden venir por multitud de factores que acaben tocando los bits, por ejemplo:

- Un mal desarrollo en el módulo ks, wasapi.
- Una mala configuración (o configuración no deseada) del reproductor.
- La imposibilidad de desactivar por completo el procesador de sonido del reproductor. Por ejemplo: un sistema básico de dsp es el control de volumen. En foobar no se puede quitar y en jriver tiene varias opciones, pero creo que tampoco se puede desactivar.
- El mejor rendimiento del hardware con un reproductor específico.
- Fallos en el hardware que afecten a un reproductor concreto pero que sean transparentes para otro.
- Limitanciones de recursos y porcesamiento. Esto puede generar jitter fácilmente.

Estamos de acuerdo, aunque en el caso de foobar si lo dejas al 100% (al igual que en el control de volumen del squeezebox touch) no debería modificar absolutamente nada, o al menos es lo que yo concluyo a raíz del experimento con audio en DTS.

ferac66 escribió:
Por cierto, wasapi sí que puede generar errores aritméticos puesto que realiza una conversión de formato binario. Aunque dicha conversión es tan trivial que debería ser totalmente transparente.

Esto no lo acabo de entender, ferac... me imagino que querrás decir que se pueden producir errores de redondeo pero que en todo caso no son suficientemente importantes como para modificar el valor binario de 1 bit ¿no es así? (siempre estoy hablando de reproducción con wasapi). Lo contrario implicaría que en una reproducción de un flujo bitstream en algún momento el receptor podría perder el hilo a la hora decodificarlo, lo que claramente no ocurre ¿A qué conversión te refieres?

pablopi escribió:
Esto no lo acabo de entender, ferac... me imagino que querrás decir que se pueden producir errores de redondeo pero que en todo caso no son suficientemente importantes como para modificar el valor binario de 1 bit ¿no es así? (siempre estoy hablando de reproducción con wasapi). Lo contrario implicaría que en una reproducción de un flujo bitstream en algún momento el receptor podría perder el hilo a la hora decodificarlo, lo que claramente no ocurre ¿A qué conversión te refieres?

Bueno, ciertamente no se trata de un error aritmético en sí mismo. Lo que ocurre es que en un archivo de un CD, wav, flac, etc., los datos de la digitalización del audio se guardan como números enteros. El problema de wasapi es que sólo funciona con números decimales. Por tanto, para que wasapi pueda enviar datos al dac o tarjeta de sonido, primero tiene que convertir los números enteros que lee del archivo a decimales, y posteriormente volver a convertirlos a números enteros para que el dac los pueda procesar y pasar a analógico. Por ejemplo, y pensando en decimal: supongamos que leemos del archivo el valor 27. Wasapi lo divide por 100 y tenemos 0,27. Con ese valor ya puede hacer lo que sea que hace, pero antes de pasarlo al dac ha de dejarlo como estaba, es decir, multiplicarlo por 100. Por eso, wasapi genera más carga de cpu que kernel streaming que sí trabaja con enteros. Esta conversión es trivial y el resultado final debería ser idéntico, pero un error en el desarrollo del módulo wasapi de un reproductor concreto puede producir un cambio en los datos y el sonido final se vería afectado.

Salud.

ferac66 escribió:Por ejemplo, y pensando en decimal: supongamos que leemos del archivo el valor 27. Wasapi lo divide por 100 y tenemos 0,27. Con ese valor ya puede hacer lo que sea que hace, pero antes de pasarlo al dac ha de dejarlo como estaba, es decir, multiplicarlo por 100. Por eso, wasapi genera más carga de cpu que kernel streaming que sí trabaja con enteros. Esta conversión es trivial y el resultado final debería ser idéntico, pero un error en el desarrollo del módulo wasapi de un reproductor concreto puede producir un cambio en los datos y el sonido final se vería afectado.

Ahora sí lo entiendo, muchas gracias por la aclaración ¿Sabes dónde se puede encontrar documentación acerca del funcionamiento interno de este complemento? Me gustaría saber exáctamente qué es lo que hace.

Efectivamente cuando hay diferencias tan claras entre reproductores con este tipo de salida directas creo que, como tú dices, hay que buscarlas más bien en errores en la implementación o circunstancias relacionadas con componentes específicos.

pablopi escribió:Hola chicos.

Creo que sería muy importante para todos, cuando comentamos que un reproductor suena mejor o peor que aquel, que se mencionaran las características del sistema de reproducción para poder hacer una mejor valoración de los resultados obtenidos:

- Procesador, memoria, disco duro, sistema operativo.
- Localización de los archivos de audio (disco interno, externo, red, etc.) y características (frecuencia de muestreo y bits / muestra).
- Software empleado y configuración relevante
- Uso medio de la CPU o de la red (si se accede al archivo reproducido a través de ella) durante las pruebas.
- Tipo de salida (DAC USB, HDMI, analógica...) y marca y modelo del hardware de reproducción.

En fin, pretendían ser estas unas pequeñas reflexiones y me ha salido un ladrillo de cuidado .

Interesantisimas reflexiones, sin duda. La teoría dice que el reproductor no debería influir para nada. No obstante creo que se aprecian diferencias entre unos y otros. Voy a hacer una comparativa con mi equipo mas a fondo. Me centraré en los siguientes:

Winamp (me interesa porque tego una aplicación llamada AWaremote que va de maravilla para usarlo con un móvil con android)
Foobar
Pureplayer

Usaré música ripeada en FLAC desde el disco duro interno (nada de discos externos, ni USB de por medio), con el programa fidelizer que se encarga de anular procesos que puedan interferir. Todo ello en el PC que tengo con tarjeta ASUS XONAR ESSENCE STX conectada directamente al ampli por RCA.

Para mi lo perfecto sería que el que mejor sonara fuera el Winamp por la comodidad antes citada (si tiene que manejarte entre 5000 temas...). En fín, lo que falta es tiempo para meterse con ello, ya os contaré

pablopi escribió:

ferac66 escribió:Por ejemplo, y pensando en decimal: supongamos que leemos del archivo el valor 27. Wasapi lo divide por 100 y tenemos 0,27. Con ese valor ya puede hacer lo que sea que hace, pero antes de pasarlo al dac ha de dejarlo como estaba, es decir, multiplicarlo por 100. Por eso, wasapi genera más carga de cpu que kernel streaming que sí trabaja con enteros. Esta conversión es trivial y el resultado final debería ser idéntico, pero un error en el desarrollo del módulo wasapi de un reproductor concreto puede producir un cambio en los datos y el sonido final se vería afectado.

Ahora sí lo entiendo, muchas gracias por la aclaración ¿Sabes dónde se puede encontrar documentación acerca del funcionamiento interno de este complemento? Me gustaría saber exáctamente qué es lo que hace.

Efectivamente cuando hay diferencias tan claras entre reproductores con este tipo de salida directas creo que, como tú dices, hay que buscarlas más bien en errores en la implementación o circunstancias relacionadas con componentes específicos.

Pues supongo que en la web de Microsoft. Es un desarrollo de windows. Yo no he profundizado más allá de lo que os he contado.

Saludos.

Anoche estuve probando la última versión de jriver en mi htpc. Se me hicieron más de las 2 de la madrugada... Entre instalarlo, importar toda mi mediateca, revisar y configurar las docenas de funciones que tiene y probar diferentes tipos de archivo, etc. Increíble que una aplicación tan pequeña haga taaaaantas cosas y tan bien como las hace .

No puedo emitir ningún juicio sobre su calidad comparada con otros reproductores (foobar, audirvana, xbmc) pero tiene papeletas para sustituir al tándem xbmc + foobar que uso en el equipo del salón. De 10. Si hasta reproduce sin despeinarse blurays originales (sin los menús) con el audio en dtsma o truehd en bitstreaming.

En el único aspecto en que lo situaría ligeramente por detrás de foobar como reproductor de sonido es en el soporte de sacd.

Por lo demás una pasada, la verdad.

Lo mejor para mí es la biblioteca y la facilidad para up o downsampler. Pero sigo diciendo que con el el buffalo me suena mucho mejor foobar, pero con la asus me sonaba algo mejor jriver.

Pablo, ya que sacas a Audirvana, corriendo en una máquina virtual (vmware) en windows 7 una imgen de mac os ¿Quién tiene el control sobre el sistema, windows o mac? Lo digo porque me gustaría probar audirvana en mi máquina virtual pero no estoy seguro que sea mac 100% y lo que oiga sea realmemte audirvana en su salsa.

Explico el motivo, dado que he notado una diferencia con el foobar donde antes es dudoso que la hubiese, noto diferencias con cables, quiero probar cosas que he probado antes y ni fu ni fa, como Jplay o audirvana.


Saludos

Jazz escribió:Lo mejor para mí es la biblioteca y la facilidad para up o downsampler.

Si, la gestión del resampleo es cojonuda, aunque lo cierto es que foobar tiene también esa posibilidad.

Me llama la atención lo bien pensado e implementado y sólido que se ve todo, a pesar de que es una auténtica navaja suiza (catalogador, ripeador, conversor, reproductor de audio y de vídeo).

Me han gustado mucho:

- El panel que indica en todo momento la cadena de proceso de audio que tienes activa y la info relativa el modo de reproducción.
- Los perfiles dlna con los que es compatible y los ajustes de transcodificación integrados.
- La posibilidad de realizar una gestión completa de altavoces, convolución incluida, al estilo de un AVR. Te enchufas un DAC con salidas de previo y a atacar directamente unas etapas, pero con todas las ventajas del DSP.
- Lo bien que reproduce vídeo de cualquier tipo (aunque tengo que decir que aquí me sigue gustando más el modo en que gestiona esto XBMC, los controles y ajustes son más y más claros).
- y efectivamente, la gestión de la biblioteca, tanto de audio como de vídeo. Aquí tengo un problema, porque no quiero que le toque un pelo a los tags de mis archivos de música, pero sí a los de vídeo. Ya veremos cómo me lo monto.
- El aspecto visual, especialmente en modo "teatro".
- Las posibilidades de personalización de un montón de aspectos.

Y encima el precio es de lo más económico.

Las ventajas de foobar creo que pasan por 2:

a) Que es freeware.
b) La mayor compatibilidad con formatos como DVD-A, SACD y algunos otros más esotéricos.

... y alguna otra cosilla como el stream capture del componente upnp de foobar, que es una idea simplemente brillante para manejar a ciegas cosas como el Oppo 93.

Por cierto que me volví loco hasta conseguir sacar bitstream en DTS-MA y TrueHD por HDMI con wasapi ¿La culpa? Yo mismo, que subí un poco el tamaño de buffer wasap (manías adquiridas con foobar) y eso j*día la reproducción. Con el valor por defecto de 50ms, como la seda. Destacable también la atención que han dedicado los desarrolladores a este aspecto, es posible decidir qué formato queremos enviar en bitstream y cuál en pcm . Magnífico.

Jazz escribió:
Pero sigo diciendo que con el el buffalo me suena mucho mejor foobar, pero con la asus me sonaba algo mejor jriver.

Pues no sé qué decirte, comparar uno con otro resulta complicado porque no es fácil conmutar rápidamente, pero bueno... prueba y ya nos cuentas.

Jazz escribió:
Pablo, ya que sacas a Audirvana, corriendo en una máquina virtual (vmware) en windows 7 una imgen de mac os ¿Quién tiene el control sobre el sistema, windows o mac? Lo digo porque me gustaría probar audirvana en mi máquina virtual pero no estoy seguro que sea mac 100% y lo que oiga sea realmemte audirvana en su salsa.

Definitivamente no estará en su salsa. Precisamente lo que intentamos es emplear modos de audio directos que se salten cuantas más capas de software sea posible en la reproducción. Si metes una capa de virtualización por medio no creo que te puedas hacer una idea del comportamiento real de la aplicación. Como mínimo pasará por el mezclador de tu Windows 7, porque que yo sepa ningún software de virtualización tiene salida wasapi o similar.

Jazz escribió:
Explico el motivo, dado que he notado una diferencia con el foobar donde antes es dudoso que la hubiese, noto diferencias con cables, quiero probar cosas que he probado antes y ni fu ni fa, como Jplay o audirvana.

Si mi HTPC fuera realmente un Mac yo usaría iTunes con Audirvana para el audio, sin dudarlo.

pablopi escribió:

Jazz escribió:Lo mejor para mí es la biblioteca y la facilidad para up o downsampler.

Si, la gestión del resampleo es cojonuda, aunque lo cierto es que foobar tiene también esa posibilidad.

Me llama la atención lo bien pensado e implementado y sólido que se ve todo, a pesar de que es una auténtica navaja suiza (catalogador, ripeador, conversor, reproductor de audio y de vídeo).

Me han gustado mucho:

- El panel que indica en todo momento la cadena de proceso de audio que tienes activa y la info relativa el modo de reproducción.
- Los perfiles dlna con los que es compatible.
- La posibilidad de realizar una gestión completa de altavoces, convolución incluida, al estilo de un AVR. Te enchufas un DAC con salidas de previo y a atacar directamente unas etapas, pero con todas las ventajas del DSP.
- Lo bien que reproduce vídeo de cualquier tipo (aunque tengo que decir que aquí me sigue gustando más el modo en que gestiona esto XBMC, los controles y ajustes son más y más claros).
- y efectivamente, la gestión de la biblioteca, tanto de audio como de vídeo. Aquí tengo un problema, porque no quiero que le toque un pelo a los tags de mis archivos de música, pero sí a los de vídeo. Ya veremos cómo me lo monto.
- El aspecto visual, especialmente en modo "teatro".
- Las posibilidades de personalización de un montón de aspectos.

Y encima el precio es de lo más económico.

Las ventajas de foobar creo que pasan por 2:

a) Que es freeware.
b) La mayor compatibilidad con formatos como DVD-A, SACD y algunos otros más esotéricos.

... y alguna otra cosilla como el stream capture del componente upnp de foobar, que es una idea simplemente brillante para manejar a ciegas cosas como el Oppo 93.

Por cierto que me volví loco hasta conseguir sacar bitstream en DTS-MA y TrueHD por HDMI con wasapi ¿La culpa? Yo mismo, que subí un poco el tamaño de buffer wasap (manías adquiridas con foobar) y eso j*día la reproducción. Con el valor por defecto de 50ms, como la seda. Destacable también la atención que han dedicado los desarrolladores a este aspecto, es posible decidir qué formato queremos enviar en bitstream y cual en pcm . Magnífico.

Jazz escribió:
Pero sigo diciendo que con el el buffalo me suena mucho mejor foobar, pero con la asus me sonaba algo mejor jriver.

Pues no sé qué decirte, comparar uno con otro resulta complicado porque no es fácil conmutar rápidamente, pero bueno... prueba y ya nos cuentas.

Jazz escribió:
Pablo, ya que sacas a Audirvana, corriendo en una máquina virtual (vmware) en windows 7 una imgen de mac os ¿Quién tiene el control sobre el sistema, windows o mac? Lo digo porque me gustaría probar audirvana en mi máquina virtual pero no estoy seguro que sea mac 100% y lo que oiga sea realmemte audirvana en su salsa.

Definitivamente no estará en su salsa. Precisamente lo que intentamos es emplear modos de audio directos que se salten cuantas más capas de software sea posible en la reproducción. Si metes una capa de virtualización por medio no creo que te puedas hacer una idea del comportamiento real de la aplicación. Como mínimo pasará por el mezclador de tu Windows 7, porque que yo sepa ningún software de virtualización tiene salida wasapi o similar.

Jazz escribió:
Explico el motivo, dado que he notado una diferencia con el foobar donde antes es dudoso que la hubiese, noto diferencias con cables, quiero probar cosas que he probado antes y ni fu ni fa, como Jplay o audirvana.

Si mi HTPC fuera realmente un Mac yo usaría iTunes con Audirvana para el audio, sin dudarlo.

¿Tan bueno es audirvana? Aún me voy a arrepentir de no haber comprado aquéllo que me recomendaste, el precio era realmemte bueno, pero ya lo ha vendido.

En cuato a los tags jriver no te los toca, los tiemes que editar tú con la opción correspondiente.

Saludos

Este fin de semana voy a probar alguna de las aplicaciones de control remoto específicas.

Me llaman la atención Jremote y Myriver, este último muy económico ¿Alguna sugerencia?

Me he editado ates para los tags. A mí para el ipad me gustaba monkey mote, pero encuentro más útil usar un escritorio remoto para acceder a todas las funciones, uso jump desktop

Jazz escribió:
¿Tan bueno es audirvana? Aún me voy a arrepentir de no haber comprado aquéllo que me recomendaste, el precio era realmemte bueno, pero ya lo ha vendido.

Audirvana por sí mismo no. Pero si lo unes a iTunes como catalogador tienes una combinación que en mi opinión es ganadora.

Jazz escribió:
En cuato a los tags jriver no te los toca, los tiemes que editar tú con la opción correspondiente.

¿Seguro? Cuando le dije que "vigilara" mi carpeta de mediateca, y tras el proceso de análisis, aparecieron mensajes de error indicando fallo al acceder a ella en escritura para incluir metainformación. Parece que intentó añadir carátulas y quizás algo más, pero puede que solo de los discos que no la tenían. Habrá que investigar.

pablopi escribió:

Jazz escribió:
¿Tan bueno es audirvana? Aún me voy a arrepentir de no haber comprado aquéllo que me recomendaste, el precio era realmemte bueno, pero ya lo ha vendido.

Audirvana por sí mismo no. Pero si lo unes a iTunes como catalogador tienes una combinación que en mi opinión es ganadora.

Jazz escribió:
En cuato a los tags jriver no te los toca, los tiemes que editar tú con la opción correspondiente.

¿Seguro? Cuando le dije que "vigilara" mi carpeta de mediateca, y tras el proceso de análisis, aparecieron mensajes de error indicando fallo al acceder a ella en escritura para incluir metainformación. Parece que intentó añadir carátulas y quizás algo más, pero puede que solo de los discos que no la tenían. Habrá que investigar.

Mira a ver las opciones de importación, cuando yo importé no me tocó nada, por desgracias, muchos de mis discos no tienen tags, están organizados por carpetas al estilo rústico.

Estuve anoche poniendo a prueba Jriver como reproductor de vídeo comparando con XBMC, que me conozco bastante bien, y lo cierto es que me gustaría poner en común algunas cosillas con vosotros.

En principio mi configuración era:

- Salida wasapi / event por HDMI con una ATI 5570.
- Buffer 50ms
- Motor de vídeo: Red October HQ (el que utiliza el tremendo motor MadVR), que no debería funcionar bien en mi Dual Core pero tira que da gusto ayudado por la aceleración de la GPU.
- Aceleración de vídeo por HW activada.
- Bitstreaming: HDMI (todos los Dolbys y DTS).
- Modos de vídeo 1080p de 23.976, 24, 59.94 y 50 fps activados. Tanto el receptor (que simplemente deja pasar la señal HDMI) como la tele los soportan, aunque mejor no nos metamos en temas de decimales porque en NTSC la cosa se complica hasta el punto de la pesadilla más absoluta.

Todo correcto en general, pero al reproducir vídeo a 24p (bueno, realmente 23,976) detecto pequeños micro tirones (no es judder), claramente visibles en travellings de cámara (inicio de Wall-E > vuelo sobre los edificios, inicio de Acero Puro > travelling inicial en el que un rotor eólico pasa en primer plano). He de decir que soy especialmente sensible a este problema, veo "cosas" que amigos míos en casa no ven, pero no es sugestión porque cuando utilizo los profilers de los distintos reproductores efectivamente se miden pérdidas de frames o desviaciones en la tasa de cuadros / segundo... hasta el punto de que no soporto pelis a 24p sin interpolador, aunque no haya altereraciones en la tasa de cuadros / segundo, simplemente por la falta de suavidad en el movimiento.

No sé hasta qué punto pasa lo mismo con material a 50 o 60 fotogramas porque tampoco probé tantas cosas, pero desde luego el problema era evidente en los 24p que reproduje.

La solución pasa por habilitar el motor de resincronización de vídeo (videoclock) disponible en los ajustes de vídeo. Esto es similar al conocido reclock disponible como aplicación independiente para PC y lo que hace es, según jriver, reducir el jitter de reloj hasta en un 5% aplicando correcciones pequeñas de modo continuado sobre el stream AV.

http://wiki.jriver.com/index.php/VideoClock

Aunque es posible activar esta opción en cualquier caso, solo toma efecto si el audio se envía siempre por PCM, es decir, hay que desactivar el envío por bitstream.

Una vez hecho eso el vídeo fluye con suavidad total.

XBMC tiene un ajuste similar, allí se denomina AV Sync Method y ofrece 3 métodos distintos de actuación:

http://wiki.xbmc.org/index.php?title=Settings/Videos#Playback

En este caso es posible conseguir una reproducción totalmente suave manteniendo la salida de audio por bitstream.

Lo cierto es que como reproductor de vídeo XBMC le planta cara totalmente a Jriver. Es más, el control e información de reproducción es mucho más completo y "chulo" en el primero. El único problema de XBMC es que oficialmente aún no soporta flujos de audio DTS-MA y Dolby TrueHD.

¿Tenéis alguna experiencia al respecto?