JRiver Media Center: configuración de los dispositivos de audio

Hablando de JRiver Media Center (JRMC) y de sus numerosos ajustes, resulta complicado proponer una configuración general apropiada para todos los casos, máxime cuando nos podemos encontrar con DACs con distintas capacidades y, además, JRMC está disponible para Windows, OS X y Linux (parece que una versión simplificada para Android también está en camino).

No obstante, lo que sí podemos hacer es recorrer los ajustes más relevantes y comentar algunas cosillas. Vamos a ello.


Opciones de audio

Para comenzar, podemos hacer clic en el menú

Herramientas :: Opciones :: Audio

o, directamente haremos clic en el botón de ajustes de JRMC y, a continuación:

Opciones de Reproducción




Audio Device (dispositivo de audio)

Lo primero será seleccionar el dispositivo de audio de salida que empleará JRMC.

En Windows podremos utilizar cada dispositivo instalado en el sistema en hasta 4 modalidades distintas, dependiendo de sus controladores (drivers):

• DirectSound (DS): El audio pasará por el mezclador del sistema, por lo que no vamos a conseguir una reproducción de tipo bitperfect. Esto quiere decir, entre otras cosas, que con independencia de las características del audio reproducido (nº de bits y frecuencia de muestreo), Windows siempre lo remuestrará a los ajustes establecidos en el panel de control de audio. Además, el flujo de audio emitido por JRMC se mezclará con los procedentes del resto de aplicaciones del sistema. Por tanto, no usaremos esta modalidad salvo que no tengamos otra opción puesto que potencialmente es la que respeta en menor medida la integridad del audio contenido en los archivos reproducidos. También hay que decir que es la más compatible y la que menos problemas suele ocasionar.
  
• WASAPI (Windows Audio Session API): Se trata de un modo de uso del dispositivo de audio caracterizado por que sí es posible conseguir una reproducción bitperfect. Además, JRMC puede tomar control total sobre el disposivo de audio, enmudeciendo en la práctica el resto de sonidos del sistema.  Esta es la modalidad que actualmente se suele recomendar en sistemas Windows.
  
• ASIO (Audio Stream Input / Output): Se trata de un protocolo para la transmisión de audio digital creado por Steinberg que se ha convertido casi casi en un estándar adoptado por gran cantidad de fabricantes. Algunos DACs solo funcionan de modo óptimo cuando se emplea ASIO, especialmente por lo que hace a conseguir una baja latencia, que resulta crucial en trabajos de grabación y mezcla de audio. Por lo demás, es funcionalmente idéntico a WASAPI y comparte con él su naturaleza bitperfect.
  
• Kernel Streaming (KS): Se trata de otra modalidad capaz de funcionar en modo bitperfect, aunque su uso tenía sentido cuando ASIO no estaba tan difundido y WASAPI simplemente no existía. Hoy en día se utiliza en aquellas situaciones en las que no es posible recurrir a ASIO o WASAPI, bien porque no están disponibles, bien porque los drivers del dispositivo de audio presentan algún problema que impida su uso.
  

Aquí podéis ver los dispositivos disponibles en mi sistema, que corre Windows 10. Fijaos en que algunos se muestran en varias posiciones de la lista, apareciendo entre corchetes "[..]" la modalidad de funcionamiento correspondiente.



Aunque WASAPI y ASIO son funcionalmente equivalentes (dejamos de lado KS por considerarlo obsoleto), en ocasiones nos encontraremos con que uno funcionará mejor que el otro (estabilidad, cortes, problemas al reproducir ciertos tipos de audio, etc.). Algunas personas incluso detectan diferencias en el sonido que se obtiene al emplear uno u otro, a pesar de ser ambos bitperfect. Por ello conviene probar ambos antes de seleccionar uno de modo definitivo.

En OS X, WASAPI y Kernel Streaming no están disponibles por tratarse de tecnologías propias del entorno Windows. Además, a diferencia de Windows (incluido Windows 10), tanto OS X, a través de su arquitectura de audio, denominada Core Audio, como Linux soportan de modo nativo la especificación USB Audio de clase 2. Esto hace que, en principio, no necesiten drivers para entenderse perfectamente con el DAC que usemos, aunque en ocasiones el fabricante del mismo puede suministrarlos para incrementar o mejorar las prestaciones o permitir un ajuste más fino de su funcionamiento.

Por ejemplo, aquí podéis ver el panel de control que los drivers de la Edirol UA25 instalan en OS X. Desde ellos se puede hacer un ajuste de bajo nivel de latencia, buffers, etc.



En OS X, por tanto, seleccionaremos el dispositivo de reproducción en la modalidad de uso Core Audio, a menos que aparezca alguna otra habilitada por los drivers del fabricante de nuestro DAC.


Device settings (ajustes de dispositivo)

Justo debajo del desplegable que permite seleccionar el dispositivo nos encontramos con otra opción que da paso a una venta de ajustes, ajustes que variarán en mayor o menor medida en función del dispositivo seleccionado.

Por ejemplo, aquí tenéis la ventana de configuración de una Asus Xonar STX en modo WASAPI:



Y aquí la de un módulo Edirol UA25 en OS X. Fijaos en que no es exactamente igual que la anterior:



Por último, aquí podéis ver la correspondiente a la Asus Xonar STX, pero esta vez en modo ASIO:



Cosas importantes:

• Hay que activar la opción que permite a JRMC tomar control exclusivo del dispositivo, de modo que la reproducción no se vea afectada por los ajustes del mezclador del sistema ni por otros flujos de audio (Abrir el dispositivo para acceso exclusivo / Open device with exclusive access). Cuando se emplea ASIO este ajuste no suele aparecer puesto que, por defecto, el modo de acceso es exclusivo.
  
• Si usamos una versión de OS X y un DAC que lo soporte, es buena idea probar a activar el modo entero (Integer mode). Esto elimina una conversión numérica interna, aunque personalmente dudo mucho que suponga una diferencia sónica significativa.
  
• En la parte inferior de la venta de configuración suele haber algún que otro control para ajustar el tamaño de los buffers de reproducción (Almacenando). Conviene mantenerlos en los valores sugeridos a menos que experimentemos problemas de cortes en la reproducción.
  
• El resto de ajustes (Offset de canal, velocidad de bits, etc.) que pueden aparecer los dejaremos de entrada como están.
  
• Es posible que aparezca alguna mención relativa al audio en DSD (DSD bitstream in DoP format en la última captura, aunque el texto exacto puede variar). De esto nos ocuparemos en el último apartado del artículo.
  
• Cuando se está configurando un dispositivo ASIO suele aparecer otro botoncito para abrir un panel de control de más bajo nivel (en la captura anterior, Open Driver Control Panel). Aquí nos encontraremos con ajustes todavía más... digamos "intimos" de nuestro dispositivo de reproducción. En nuestro caso, Bit-Depth (bits / muestra) y Latency (latencia). De nuevo, inicialmente no deberíamos tocar nada.
  

Bitstreaming (emisión en crudo)

Bitstreaming. Bonito palabro ¿verdad?  

Existen una serie de formatos de audio que pueden ser decodificados por el propio JRMC, de forma que lo que se enviará al DAC será audio en PCM, o bien transmitidos en crudo (esto es, sin procesar) para que sea el DAC quien se ocupe de su decodificación. JRMC es capaz de gestionar estos:



Con la excepción de DSD, el resto tienen una cosa en común: todos portan audio PCM mondo y lirondo. A diferentes resoluciones y frecuencias, comprimidos con pérdidas o sin ellas, pero en todos los casos se trata de PCM. Esto quiero decir que es irrelevante que la decodificación la realice JRMC o el DAC (o receptor multicanal) de turno. El algoritmo de decodificación obtendrá exáctamente el mismo flujo de bits PCM en ambos casos.

DSD es otra historia, de la que hablaremos más adelante, como decía en el apartado anterior. Por el momento nos contentaremos con marcar la casilla DSD si nuestro DAC soporta este formato:




Prebuffering (prelectura de audio)

Con este ajuste podemos indicarle a JRMC que lea por adelantado un fragmento de audio, cuya duración se indica en segundos.



Podríamos pensar que este ajuste está repetido puesto que en los correspondientes al dispositivo de reproducción ya se podía tocar el tamaño del buffer. En realidad se trata de un buffer de prelectura adicional al que opera a bajo nivel.

Si almacenamos los archivos de audio en una ubicación de red y experimentamos cortes, incrementar este buffer puede solucionar el problema, pero de poco servirá si los cortes son debidos a retenciones localizadas en las capas más bajas del sistema operativo.


Reproducción desde memoria

Si activamos esta opción, JRMC intentará cargar totalmente en memoria RAM cada archivo antes de comenzar la reproducción. Aunque es un parámetro potencialmente variable con cada versión, este buffer en RAM tiene una capacidad de 1GB.



Algunas personas afirman que el audio reproducido desde RAM suena mejor que el leído del disco o de una ubicación de red remota, así que ya sabéis, probad a ver.


Volumen

JRCM puede controlar el volumen de reproducción de varios modos. Los más relevantes son:

1. Volumen del Sistema: Es equivalente a actuar sobre el volumen global del sistema.
   
2. Volumen interno: Utiliza el motor de reproducción de JRMC, que opera con una resolución de 64 bits, para ajustar el volumen. A menos que el dispositivo de reproducción disponga de volumen por hardware, en mi opinión es la mejor opción.
   

Cuando se reproduce en bitstream, por ejemplo DSD, el control de volumen no funcionará.

Podéis encontrar más información sobre las modalidades de gestión de volumen en el wiki de JRiver.


Avanzado

En Configure input plug-in tenemos un ajuste importante si pensamos reproducir audio DSD pero nuestro DAC no lo soporta y por tanto debe ser convertido previamente a PCM por JRMC:



La codificación en DSD genera cantidades importantes de ruido en bandas ultrasónicas. Ese ruido puede dañar los equipos de audio especialmente sensibles (amplificadores, altavoces) si no están diseñados para soportarlo. Por ello es aconsejable aplicar un filtro paso bajo que elimine este ruido de alta frecuencia.

JRMC sugiere el uso de un filtro paso - bajo de corte a 24 Khz y pendiente de 48dB / octava.




Estudio DSP

Podemos acceder al módulo de procesado digital de JRMC (DSP) bien a través de la opción correspondiente en la ventana de configuración:



...bien utilizando el botón Estudio DSP:



Antes de continuar, me gustaría mencionar que el módulo DSP está también disponible para configurar zonas de audio remotas (dispositivos con perfil renderer DLNA) a partir de la versión de JRMC 20.0.27. Mas sobre las zonas de JRMC y DLNA aquí y aquí.

Lo primero es establecer el formato de salida: codificación, frecuencia y mezcla de canales.



JRMC es capaz de recodificar al vuelo el audio reproducido a Dolby Digital o a DSD (hasta quad DSD de 22,4Mhz ).

Podemos utilizar la recodificación a Dolby Digital para disfrutar de las pistas multicanal de un SACD o de un FLAC multicanal en un viejo receptor AV.

Con respecto a DSD, fijaos en la captura, existen 2 posibilidades:

1. DSD en formato DoP (DSD y DSDx2).
   
2. DSD nativo, en cuyo caso podemos alcanzar DSDx4.
   

La razón por la querríamos transformar el PCM en DSD la discutiremos en la sección final de este artículo.

Si queremos preservar la naturaleza del audio reproducido seleccionaremos Nada.

También podemos escoger una frecuencia de muestreo de salida para el audio en PCM (o DSD convertido a PCM si nuestro DAC no soporta DSD). En la lista que veréis a continuación aparecen distintas frecuencias, desde menos de 44100 Hz hasta más de 384000 Hz. Iremos haciendo clic en la columna Salida para establecer la conversión correspondiente a cada una de las frecuencias relacionadas. Si hacemos clic con el botón derecho del ratón el cambio será global para todas las frecuencias.



Este ajuste tiene utilidad cuando nuestro DAC no admite determinadas frecuencias de muestreo o, simplemente, cuando deseamos aplicar un remuestreo incondicional, quizás a la máxima frecuencia soportada por el dispositivo de salida, utilizando el motor de reproducción de alta calidad de JRiver.

Por último, estableceremos la mezcla de canales para adecuarla a las capacidades de nuestro dispositivo de audio.



El ajuste funciona hacia abajo y hacia arriba. Podemos escuchar, por ejemplo, un CD en 5.1. JRMC además es capaz de identificar pistas de audio estéreo con audio multicanal codificado matricialmente (Dolby Pro Logic II y similares).

Como veis los ajustes de salida son extraordinariamente flexibles. No obstante la cosa no acaba aquí. Disponemos de varios módulos DSP adicionales para ecualizar, aplicar efectos, corrección de sala (a través de convolución), normalizar el volumen, hacer la escucha con auriculares un poco más abierta, etc. etc.:



Por ejemplo, en mi sistema he tenido que recurrir al módulo de ecualización parámetrica para solucionar un problema que mi Xonar STX manifiesta actualmente con Windows 10. Al funcionar en modo WASAPI y reproducir audio a más de 88 Khz se cuela un ruido de alta frecuencia muy molesto. La solución es tan simple como aplicar un filtro paso bajo para eliminarlo:



Filtro que, además, me sirve para limpiar de ruido ultrasónico la señal DSD convertida a PCM.


A vueltas con el DSD

DSD, el formato de moda. Vamos a hablar ahora de algunas de sus particularidades para tratar de entender las distintas opciones de configuración de JRMC que hemos recorrido arriba.

Como seguramente sepáis, el formato DSD se caracteriza por emplear una codificación basada en muestras de 1 solo bit y una frecuencia de muestreo muy alta, 2,8224 Mhz en el caso de un disco SACD estándar. A esto se le llama también DSDx64 (porque la frecuencia de muestreo es 64 veces la empleada en un CD, 44,1 Khz x 64) o DSDx1.



La codificación DSD presenta una ventaja fundamental con respecto a la PCM. Tanto el proceso de captura de audio (A/D) como el de conversión de digital a a analógico (D/A), en el DAC, son mucho más simples, lo que en teoría permite preservar en mayor medida la integridad del fenómeno musical. De hecho, el segundo proceso (D/A) emplea poco más que un filtro paso bajo para reconstruir la señal analógica original. Esto supone una menor distorsión en proceso de extremo a extremo y permite, en teoría, conservar de mejor modo la naturaleza analógica del audio capturado. El formato ofrece, además, un rango dinámico de unos 120dB (en la banda de 20 Hz a 20 Khz) y una respuesta en frecuencia que se extiende hasta los 100 Khz.

El problema es que la codificación empleada introduce cantidades industriales de ruido, que se empujan, empleando técnicas de conformación, fuera del espectro audible para que no molesten. Como hemos visto anteriormente en la configuración, este ruido ultrasónico debe ser filtrado en algún punto de la reproducción (reproductor o DAC) para evitar daños en los equipos.

En este gráfico, cortesía de Stereophile, podéis comparar el espectro de un tono de prueba codificado en DSD (arriba) y PCM de 24 bits (abajo). El ruido crece mucho a partir de 20Khz:



Sí, lo habéis leído bien: el ancho de banda del formato es elevado pero más tarde, en el momento de la reproducción, es necesario aplicar un filtro para eliminar el ruido ultrasónico que lo reduce notablemente, filtro que además debe ser lo suficientemente abrupto para hacer su trabajo rápidamente, es decir, en el ancho de banda que separa la señal audible de la banda a partir de la cual comienza el ruido. Y a mayor pendiente, normalmente mayor distorsión de fase que sufre la señal, distorsión que también afecta al área por debajo de los 20 Khz.

Ironías de la vida, o del formato DSD, debería decir.

Para tratar de paliar el problema anterior, recientemente han surgido codificaciones que elevan aún más la frecuencia de muestreo, hasta los 5,6448 Mhz (DSDx128 o DSDx2), 11,2896 Mhz (DSDx256 o DSDx4) y 22,5792 Mhz (DSDx512 o DSDx8). De este modo el ruido producido por la modulación Delta - Sigma empleada para generar la señal de 1 bit se mueve aún más arriba y por tanto los filtros de reconstrucción pueden comenzar a trabajar en una zona más alejada del espectro audible y forzar una pendiente de atenuación más suave.

No existe un estándar de discos físicos SACD de, vamos a denominar, super alta resolución, pero sí hay sellos que ofrecen descargas en DSDx128 y DSDx256.

Además, como hemos visto algunos reproductores como JRMC (o Foobar), son capaces de recodificar al vuelo el audio PCM en DSD, incluso de super alta resolución, para entregarle al DAC un bonito flujo indistinguible de un archivo originalmente en este formato ¿Suena mejor? Pues no sabría decirlo, aunque incluso los escépticos reconocen que el resultado ofrece matices sonoros ligeramente distintos.

Por otro lado, existen 4 modos de reproducir audio en DSD, todos ellos soportados por JRMC. Vamos a comentarlos:

1. Conversión a PCM: El audio DSD se transforma en PCM de una frecuencia y resolución dadas. JRMC lo hace a PCM 384/32, que luego se remuestrea según lo indicado en los ajustes de salida que establezcamos. Esta es la única opción si nuestro DAC no soporta DSD. Pero aún si lo hace, quizás sea la adecuada puesto que, en la práctica, no es posible aplicar procesado digital sobre una señal DSD. Nada de ecualización, mezcla de canales, ajuste de volumen, corrección de sala o convolución. Quizás lo que perdamos al pasar a PCM se vea compensado por lo que nos aporta una buena corrección de sala a través de la ecualización.
   
2. Reproducción DSD nativa: El audio DSD se envía tal cual al DAC para que este se las vea con él. Este modo solo está disponible, hasta donde yo sé, en Windows y únicamente cuando se emplea ASIO como modalidad de uso del dispositivo de salida. Core Audio en OS X no soporta por tanto esta posibilidad, a menos que drivers específicos del correspondiente fabricante lo permitan.
   
3. Empaquetado DoP: DoP es el acrónimo de DSD over PCM. Se trata de una codificación, surgida al amparo de la proliferación de DACs conectados por USB, que empaqueta un flujo de datos DSD dentro de un paquete que tiene toda la pinta de ser audio en PCM. Desde un punto de vista operativo, por tanto, esto es igual a (2), aunque como veremos hay sutiles diferencias.
   
4. Empaquetado DoPE: Análogo a DoP, pero se aplica en escenarios en los que el audio se emite por DLNA hacia un reproductor. Se trata de un estándar relativamente reciente cuyo soporte no está aún muy difundido.
   

A grandes rasgos, por lo tanto, podemos convertir el audio a PCM o escoger alguno de los modos que nos proporcionan reproducción DSD sin conversión. Pero puesto que aún contando con un DAC DSD no siempre es posible emitir hacia él DSD puro, ya que esto depende en última instancia del sistema operativo empleado y del modo de uso del dispositivo de audio, tenemos que hacernos la siguiente pregunta:

¿Son realmente DoP y DoPE equivalentes al envío de DSD puro?

No exactamente. Veamos por qué.

Decíamos más arriba que cuando se emplea DoP (o DoPE), el audio DSD se empaqueta dentro de un contenedor PCM. Concretamente, el flujo de bits se agrupa en bloques de 16 (2 bytes). A cada uno de estos bloques se le debe agregar una cabecera indentificativa, lo que se conoce como un marcador DoP, para que el DAC sepa que lo que realmente está recibiendo es DSD, lo extraiga descartando el marcador, y lo reproduzca de modo adecuado. Mirad este gráfico tomado de The Well-Tempered Computer:



En rojo se aprecia el marcador, de 8 bits, y en azul la carga DSD de 16 bits de cada paquete. Esto hace que cada bloque transmitido al DAC (o al reproductor DLNA compatible con DoPE) tenga una longitud de 24 bits, 8 de los cuales no portan datos.

Seguro que ya os habéis dado cuenta . El problema con DoP / DoPE es que se introduce una sobrecarga de un 33%. Dicho de otro modo, es necesario transmitir más información hacia el DAC de la que sería estrictamente necesaria de ser posible la transmisión de audio DSD nativo.

La frecuencia de 2,8 Mhz del DSDx64 parece muy elevada, pero desde un punto de vista estrictamente numérico es equivalente a PCM a poco más de 117 Khz y 24 bits. Al usar DoP, sin embargo, es necesario transmitir audio PCM a 176 Khz y 24 bits para que "nos quepan" los marcadores DoP de cada paquete de 16 bits. Parece poca cosa, pero en sistemas que vayan justitos de potencia, sufran de problemas de latencia o de un acceso de baja o inestable velocidad a los archivos a reproducir esto dificulta las cosas y puede llegar a ser el factor diferencial que posibilite una experiencia de audio sin cortes o no. Lógicamente lo dicho cobra mayor importancia cuando estamos hablando de DSDx2 o de frecuencias superiores.

De hecho, si volvéis a la captura en la que se mostraban los ajustes de codificación de JRMC, DoP solo está soportado hasta DSDx2. Si queremos alcanzar DSDx4 ya tiene que ser a través de reproducción nativa (DSDx2 en DoP ya requiere la transmisión de PCM a 352,8 Khz).



Es por ello que, siempre que sea posible, configuraremos preferiblemente JRMC de modo que la transmisión de audio en DSD se produzca de forma nativa.

Para terminar, recordaros que de optar por la conversión del DSD a PCM no os debéis olvidar de activar el filtro correspondiente para eliminar el ruido de alta frecuencia característico de esta codificación en:

Herramientas :: Opciones :: Audio :: Avanzado :: DSD input plug-in

Esto es que no tiene precio, mil gracias Pablo, eternamente agradecido.

Gracias mil Pablo

Que grande eres Pablo!!!!!!!!!!!!!!!! Eres un crack!
Siempre pensando en los demas, en ayudar y facilitar las cosas, gracias mil por tus impagables aportaciones.


Un saludo.

Hay que activar la opción que permite a JRMC tomar control exclusivo del dispositivo, de modo que la reproducción no se vea afectada por los ajustes del mezclador del sistema ni por otros flujos de audio (Abrir el dispositivo para acceso exclusivo / Open device with exclusive access). Cuando se emplea ASIO este ajuste no suele aparecer puesto que, por defecto, el modo de acceso es exclusivo.

Esta es la razón por la que al abrir un vídeo, mientras reproducía audio en foobar, no se oía el vídeo. Ignoraba dicha característica del api ASIO.

La codificación en DSD genera cantidades importantes de ruido en bandas ultrasónicas. Ese ruido puede dañar los equipos de audio especialmente sensibles (amplificadores, altavoces) si no están diseñados para soportarlo. Por ello es aconsejable aplicar un filtro paso bajo que elimine este ruido de alta frecuencia.

JRMC sugiere el uso de un filtro paso - bajo de corte a 24 Khz y pendiente de 48dB / octava.

Este concepto filtro paso bajo 24Khz y pendiente de 48dB, entiendo que permite pasar todas las señales menores o iguales a 24Khz hacía el amplificador y los monitores. Pero no entiendo el valor "48dB / octava"

En general y una vez más un gran artículo Pablo. Pero para mi especialmente interesante la última parte dedicada a DSD. Por ejemplo ahora me queda más claro lo que es un empaquetado DoP y que consecuencias tiene. Que alguien se tome la molestía de explicar estos conceptos lo considero algo valioso.

Este post está pidiendo una chincheta.

Gracias de nuevo, Miguel.

Efectivamente, un filtro paso - bajo actua como una "puerta" que deja pasar la señal por debajo de una frecuencia umbral (frecuencia de corte) y atenúa las que se encuentran por encima. Lo que ocurre es que el comportamiento de un filtro ideal, que operaría según lo descrito de un modo perfecto, es inalcanzable en el mundo real. Lo que realmente pasa es que existe una zona de transición desde la frecuencia de corte prefijada y hasta aquella en la que se considera que el filtro ya está atenuando la señal tanto como puede:



La atenuación del filtro en esta zona de transición se suele representar como una recta de determinada pendiente, expresada en dB (amplitud) / frecuencia (octavas). Una octava es el intervalo entre las frecuencias (f1, f2) tal que f2=2*f1.

En la gráfica puedes ver que el filtro tiene una pendiente de 6dB / octava, por lo que necesita un "espacio" de 14 Khz para atenuar totalmente una señal de 18dB, aunque esto no deja de ser otra aproximación.

A mayor pendiente, antes (entendido como "en una banda de frecuencias más estrecha") hará el filtro su trabajo. Como contrapartida, filtros más "abruptos" suelen introducir una mayor distosión de fase, así que, como en casi todo en la vida, hay que valorar qué interesa en casa caso.

Eomer escribió:

Cuando se emplea ASIO este ajuste no suele aparecer puesto que, por defecto, el modo de acceso es exclusivo.

Esta es la razón por la que al abrir un vídeo, mientras reproducía audio en foobar, no se oía el vídeo. Ignoraba dicha característica del api ASIO.

Bueno, realmente hay formas de hacer que ASIO  permita la mezcla de diferentes flujos de audio, de hecho los drivers ASIO de algunos dispositivos lo admiten. También se puede emplear un proxy multi - asio.

Lo que ocurre en ese caso es que el primer flujo que se reproduce suele fijar la frecuencia de reproducción y resolución con las suyas propias. Los que llegan más tarde se remuestrean a la establecida y el audio de todas se mezcla para que pueda escucharse simultáneamente.

http://www.steinberg.net/forums/viewtopic.php?f=34&t=48

No obstante para reproducir musiquita, que es lo nuestro, creo que no es relevante.

pablopi escribió:Gracias de nuevo, Miguel.

Efectivamente, un filtro paso - bajo actua como una "puerta" que deja pasar la señal por debajo de una frecuencia umbral (frecuencia de corte) y atenúa las que se encuentran por encima. Lo que ocurre es que el comportamiento de un filtro ideal, que operaría según lo descrito de un modo perfecto, es inalcanzable en el mundo real. Lo que realmente pasa es que existe una zona de transición desde la frecuencia de corte prefijada y hasta aquella en la que se considera que el filtro ya está atenuando la señal tanto como puede:



La atenuación del filtro en esta zona de transición se suele representar como una recta de determinada pendiente, expresada en dB (amplitud) / frecuencia (octavas). Una octava es el intervalo entre las frecuencias (f1, f2) tal que f2=2*f1.

En la gráfica puedes ver que el filtro tiene una pendiente de 6dB / octava, por lo que necesita un "espacio" de 14 Khz para atenuar totalmente una señal de 18dB, aunque esto no deja de ser otra aproximación.

A mayor pendiente, antes (entendido como "en una banda de frecuencias más estrecha") hará el filtro su trabajo. Como contrapartida, filtros más "abruptos" suelen introducir una mayor distosión de fase, así que, como en casi todo en la vida, hay que valorar qué interesa en casa caso.

A ver si he entendido en el caso de aplicar un filtro paso bajo 24Khz y pendiente de 48dB sería aplicado a señales cuya frecuencia sea > de 24Khz y con una amplitud hasta 48 decibelios ¿cierto?
¿Y cual sería el rango de frecuencias necesario para atenuar totalmente esa amplitud de 48dB? Aquí faltaría definir la pendiente de la recta o bien prefijar dicho rango de frecuencias.
Yo al final lo que veo es un triangulo rectángulo en el que se puede definir la inclinación de su hipotenusa o pendiente como:
m = y / x
donde
m = pendiente
y = amplitud
x = rango de frecuencias necesario para la atenuación

Vamos el clásico concepto de pendiente que nos explicaron en la EGB con 12 años

Eomer escribió:

A ver si he entendido en el caso de aplicar un filtro paso bajo 24Khz y pendiente de 48dB sería aplicado a señales cuya frecuencia sea > de 24Khz y con una amplitud hasta 48 decibelios ¿cierto?

Sí. No obstante ten en cuenta que el efecto de atenuación es progresivo a medida que nos movemos hacia la derecha en frecuencia. Esto quiere decir que un filtro de estas características (paso - bajo con corte en 24 Khz y -48 dB / octava) atenuaría un tono de 48 Khz en 48 dB, uno de 96 Khz en 96 dB y así sucesivamente. Si nuestra señal presentara una componente en frecuencia de 48Khz y 100dB de amplitud, esta se vería atenuada hasta los 100 - 48 = 52dB, pero no quedaría totalmente silenciada. Si una componente con la misma amplitud se diera en 96 Khz, quedaría atenuada hasta los 4 dB (prácticamente inaudible).

Por eso en los ajustes de JRMC, al filtro de 24Khz y 48dB se le denomina "seguro" (es más efectivo a la hora de eliminar el ruido ultrasónico) que el de 30 Khz y -24 dB, que empieza más tarde (en frecuencia) a hacer su faena y, además, tiene una menor pendiente de atenuación, podríamos decir que "decelera" más lentamente.

OK ahora lo veo más claro.

Muy útil, muchas gracias, pero tengo una pregunta sobre la reproducción desde memoria

¿ Es mejor para alargar la vida del disco duro que este no trabaje constantemente y reproducir desde la memoria RAM ?

Un saludo y gracias

Barbablue escribió:Muy útil, muchas gracias, pero tengo una pregunta sobre la reproducción desde memoria
¿ Es mejor para alargar la vida del disco duro que este no trabaje constantemente y reproducir desde la memoria RAM ?

En mi opinión, no.

Ten en cuenta que para reproducir desde RAM primero todo el archivo debe ser leído igualmente del disco de una tacada. Aunque la lectura en bloques puede suponer un mayor movimiento mecánico (en discos magnéticos), no creo que repercuta claramente sobre la vida útil del disco. Si no es el reproductor el que lleva loco al disco duro seguro que será algún otro proceso del sistema.

Bueno, tal cosa no ocurre. solo lo planteaba teóricamente

Gracias

Como siempre, Pablo... de traca....

Claro, conciso y legible. Un auténtico maestro. Sin duda la parte más enriquecedora de todo el foro eres tú y tus aportaciones.

Una duda, tengo algunos discos descargados en DSD256. Si quisiera escucharlos en el Oppo93 ¿qué tendría que hacer? ¿quemarlos tipo SACD en un DVD-r?? Y otros FLACs que el Oppo tampoco "ve", supuestamente con origen en discos SACD y en 4.0???

Gracias y perdona la pregunta...

Pablo, Gracias por tu esfuerzo y la molestia. Es un buen curre y queda muy bien expuesto y explicado.

Como te comenté, el Jriver es mi reproductor y ciertamente vas poco a poco descubriendo cosillas en él conforme te metes. Entre ellas, no sabía lo que comentas sobre el buffer de la memoria Ram. No sabia que tiene un tope. Tengo la version 21 y me gustaria saber cómo es posible averiguar en esta versión el tope y si éste es posible aumentarlo.
Por otra parte, interesantísima la exposición sobre los formatos de salida. Yo dispongo de archivos en todos los formatos. La duda la tengo en los formatos dsd; ¿Cuál seria el formato de salida adecuado si disponemos de archivos de hasta dsd256? ..."4xdsd native formato..."

Un saludo y muchas gracias por tu esfuerzo.

Alex escribió:...
Una duda, tengo algunos discos descargados en DSD256. Si quisiera escucharlos en el Oppo93 ¿qué tendría que hacer? ¿quemarlos tipo SACD en un DVD-r?? Y otros FLACs que el Oppo tampoco "ve", supuestamente con origen en discos SACD y en 4.0???

Gracias y perdona la pregunta...

Resuelto, yo suelo usar un Dune HD como esclavo de un Oppo 93, y el cuello de botella del streaming como siempre está en el Oppo. Si simplemente enciendo el Dune HD como principal, sin usar el Oppo, este reproduce todos los ficheros sin problemas. Y el receptor AV indica DSD en el display por lo que entiendo que lo recibe en formato nativo.

Me queda pendiente instalar una nueva versión del Media Center a ver si me guarda las configuraciones y probar definitivamente la propuesta de Pablopi de usar el Linn Akurate "a lo grande"

Alex escribió:Como siempre, Pablo... de traca....

¡Qué bueno, Alex! En mi tierra "de traca" es una expresión que se emplea para designar algo fuera de lugar, ridículo, etc. etc.  

Bueno, muchas gracias por tus palabras   Yo solo intento aportar lo que puedo y en un ámbito muy reducido de esta afición / pasión. Si algunas personas lo encontráis interesante o útil... pues no sabes cómo me alegro  .

FRAVAD escribió:Entre ellas, no sabía lo que comentas sobre el buffer de la memoria Ram. No sabia que tiene un tope. Tengo la version 21 y me gustaria saber cómo es posible averiguar en esta versión el tope y si éste es posible aumentarlo.

Pues no lo sé. Una posibilidad sería abrir el monitor de recursos y manter vigilado el consumo de RAM mientras se inicia la reproducción de una iso de SACD gorda, por ejemplo. Ni idea de si es posible modificar este parámetro. Parece que esta función de reproducción desde RAM ha ido cambiando ligeramente su modo de funcionamiento desde JRMC 18. Échale un vistazo al foro de soporte de JRiver y a su wiki, se habla de esto, por ejemplo aquí:

https://yabb.jriver.com/interact/index.php?topic=81982.0

Esta gente de JRiver son de los escépticos. El propio equipo de desarrollo niega que la reproducción desde RAM suponga ninguna mejora desde el punto de vista de la calidad percibida. Si ellos lo dicen, yo ni me preocupo:

Sound Quality
JRiver is unaware of any test that shows a sound quality advantage to memory playback.  

FRAVAD escribió:
Por otra parte, interesantísima la exposición sobre los formatos de salida. Yo dispongo de archivos en todos los formatos. La duda la tengo en los formatos dsd; ¿Cuál seria el formato de salida adecuado si disponemos de archivos de hasta dsd256?  ..."4xdsd native formato..."

Gracias de nuevo  .

El formato de salida sería "nada". De ese modo el PCM saldría en PCM, el DSD en DSD, el DSDx2 en DSDx2 etc. etc. (siempre y cuando hayas activado el bitstreaming para DSD)



Si lo ajustas a DSDx2 tooodo el audio emitido se recodificará a este formato.

Alex escribió:
Resuelto, yo suelo usar un Dune HD como esclavo de un Oppo 93, y el cuello de botella del streaming como siempre está en el Oppo. Si simplemente enciendo el Dune HD como principal, sin usar el Oppo, este reproduce todos los ficheros sin problemas. Y el receptor AV indica DSD en el display por lo que entiendo que lo recibe en formato nativo.

No estoy seguro de haberte entendido Alex... que yo sepa el Oppo 93 no reproduce archivos DFF o DSF ni desde una unidad USB ni a través de la red ¿Quieres decir que el Dune HD si es capaz de hacerlo?

pablopi escribió:

Alex escribió:Como siempre, Pablo... de traca....

¡Qué bueno, Alex! En mi tierra "de traca" es una expresión que se emplea para designar algo fuera de lugar, ridículo, etc. etc.  

Bueno, muchas gracias por tus palabras   Yo solo intento aportar lo que puedo y en un ámbito muy reducido de esta afición / pasión. Si algunas personas lo encontráis interesante o útil... pues no sabes cómo me alegro  .

En portugués, la palabra "exquisito" también significa algo extraño, desagradable... y claro cuando nos preguntaban en brasil si nos había gustado la comida y decíamos "exquisita"... ponían cara de      

Sabes que los tiros van por absolutamente todo lo contrario, mi querido amigo. Eres muy digno de admiración.

pablopi escribió:

Alex escribió:
Resuelto, yo suelo usar un Dune HD como esclavo de un Oppo 93, y el cuello de botella del streaming como siempre está en el Oppo. Si simplemente enciendo el Dune HD como principal, sin usar el Oppo, este reproduce todos los ficheros sin problemas. Y el receptor AV indica DSD en el display por lo que entiendo que lo recibe en formato nativo.

No estoy seguro de haberte entendido Alex... que yo sepa el Oppo 93 no reproduce archivos DFF o DSF ni desde una unidad USB ni a través de la red ¿Quieres decir que el Dune HD si es capaz de hacerlo?

Olvídalo, lo que estaba oyendo eran unos archivos FLAC en alta resolución que se habían colado en la carpeta donde tengo los dff y dsf, en el Dune HD, a través del equipo estéreo, sin darme cuenta y que el Oppo 93 no reproducía,.

Y lo que aparecía en el display del receptor AV era un SACD-r que estaba en la bandeja del Oppo, que lógicamente indicaba DSD...

En definitiva, que si quiero reproducir los ficheros dsf y dff que tengo almacenados, o lo hago desde el ordenador por el JRiver o similar o me dedico a quemar SACD-r como loco.

En definitiva, que si quiero reproducir los ficheros dsf y dff que tengo almacenados, o lo hago desde el ordenador por el JRiver o similar o me dedico a quemar SACD-r como loco.

Ah... ¿Pero eso se puede hacer? ¿Usas un programa como nero o similar?
Que yo sepa SACD es un formato protegido.

Eomer escribió:

En definitiva, que si quiero reproducir los ficheros dsf y dff que tengo almacenados, o lo hago desde el ordenador por el JRiver o similar o me dedico a quemar SACD-r como loco.

Ah... ¿Pero eso se puede hacer? ¿Usas un programa como nero o similar?
Que yo sepa SACD es un formato protegido.

Hola Eomer,

hablo de quemar ficheros .ISO obtenidos de SACDs originales. Los hay a puñados por internet. Te los descargas y con programas como el Nero, Burrn, ImgBurn, Utilidad de discos en Mac, etc... dependiendo del ISO que se trate... los quemas en un DVD-r y tienes una réplica exacta del original.

Hay hilos largos y extensos en este foro y en muchos otros... no sé si me lo preguntas en serio o con ironía...

No Alex. Te lo pregunto totalmente en serio.
Se que hay multitud de imágenes ISO de discos SACD por ahí. Lo que desconocía es que fuera posible quemarlas en un disco DVD-R y que luego fuese posible su reproducción.
Así que de ironía nada de nada compañero.
Supongo que el hecho de usar un soporte DVD-R atiende al hecho de mantener la máxima compatibilidad con el reproductor, igual que con imágenes de DVD convencionales ¿no?

Eomer escribió:No Alex. Te lo pregunto totalmente en serio.
Se que hay multitud de imágenes ISO de discos SACD por ahí. Lo que desconocía es que fuera posible quemarlas en un disco DVD-R y que luego fuese posible su reproducción.

Pues sí, Miguel, solo hay que dar con el reproductor adecuado:

https://www.audioplanet.biz/t17008-ya-es-posible-ripear-copiar-sacd-sin-perdida-de-calidad
https://github.com/sacd-ripper/sacd-ripper/wiki/A-list-of-SACD-R-compatible-players.

Alex escribió:
En definitiva, que si quiero reproducir los ficheros dsf y dff que tengo almacenados, o lo hago desde el ordenador por el JRiver o similar o me dedico a quemar SACD-r como loco.

Bueno, otra posibilidad tiene que ver con la autoría de un disco DSD (que no es lo mismo que un SACD). Varios reproductores de SACD de Sony e incluso la PS3 los leen:

http://ps3sacd.com/dsddiscguide.html

No estoy seguro, sin embargo, si los Oppo los reproducen.

Por otro lado, un compañero preparó un estupendo tutorial para "fabricar" un disco SACD-R:

https://www.audioplanet.biz/t17008p340-ya-es-posible-ripear-copiar-sacd-sin-perdida-de-calidad#393015

Pelín laborioso .

Eomer escribió:No Alex. Te lo pregunto totalmente en serio.
Se que hay multitud de imágenes ISO de discos SACD por ahí. Lo que desconocía es que fuera posible quemarlas en un disco DVD-R y que luego fuese posible su reproducción.
Así que de ironía nada de nada compañero.
Supongo que el hecho de usar un soporte DVD-R atiende al hecho de mantener la máxima compatibilidad con el reproductor, igual que con imágenes de DVD convencionales ¿no?

No te preocupes, disculpa la duda, pero como se ha comentado el tema largo y tendido tanto en Audioplanet como en Internet, me parecía un tema obvio. Y sin embargo, no lo es. Como cualquier cosa nueva para cualquier persona.

Yendo al tema. Lo primero es hacerte con un reproductor de los que tengas LA ABSOLUTA SEGURIDAD que reproduce los SACD-r. Los hay caros, baratos e intermedios...  Hay varias listas de dispositivos compatibles. Como muestra

http://www.ps3sacd.com/sacd_bd_players.html

Una vez con el reproductor en casa y conectado, te descargas un SACD.iso y con el programa adecuado lo quemas en un DVD-r. Lo metes en la bandeja de tu reproductor compatible y a escuchar SACDs sin tino...

Pablo,

desde hace días, llevo intentando que el JMRiver me lea una carpeta donde he situado varios SACD ISOs, para intentar reproducirlos desde el Linn.

Y no hay forma... He borrado la biblioteca "Main Library" sopotocientas veces, la he vuelto a importar la misma cantidad de veces, y siempre, cuando voy al Jremote o desde el propio JRiver, están todas las carpetas, menos esa.

¿se te ocurre qué puedo estar haciendo mal o dejando de hacer?

Gracias y un abrazo

Alex