Apuntes propios sobre cuestiones extrañas

Mini análisis de Strawberry: Tidal en bitperfect en Linux (y más cosas)

noreply@blogger.com (Pablo Felip) — Sun, 27 Jan 2019 22:16:00 +0000

Los aficionados que usamos Linux habitualmente andamos un poco dejados de la mano de Dios por lo que hace al abanico de reproductores de audio a nuestra disposición.

Sí, es posible correr Foobar en bitperfect e incluso reproducir con él DSD (vía DoP), tal y como explicaba en este artículo anterior.

También podemos tirar mano de JRiver Media Center (del que soy usuario de licencia maestra desde hace tiempo), aunque personalmente la interfaz me parece que está hecha con los pies y la usabilidad... pues eso, que es más bien tirando a regularcilla.

Por último, cabe recurrir a algún tinglado con Squeezelite, por ejemplo tal y como cuento aquí.

¿No hay más opciones? Pues claro, docenas de ellas, así sin pensarlo mucho se me ocurren reproductores como Audacious, Rhythmbox, Clementine, Lollypop (por cierto, el único con una interfaz elegante, en mi opinión), Amarok, DeaDBeeF, Elisa... y muchos más.

El problema es que unos y otros suelen tener carencias en aspectos que hoy en día consideramos básicos:

Funciones de gestión de biblioteca.
Compatibilidad con ALSA (para emitir en bitperfect).
Edición de etiquetas.
Compatibilidad con formatos de audio (por ejemplo, DSD).
Descarga de carátulas de Internet.
Conexión con servicios en línea.
Interfaz de usuario no absolutamente paleolítica Rolling Eyes.
...y ponga usted aquí lo que quiera (que cosas faltan a puñados).

El caso es que trasteando un rato me he encontrado con una alternativa gratuita y de código abierto que, sin ser la caña de España, me parece más que interesante en este contexto Linuxero y por tanto me gustaría compartir con vosotros.

Strawberry es un fork de Clementine, es decir un desarrollo realizado por otro programador a partir de la aplicación original, estando disponible para Windows, MacOS y Linux. Lógicamente me voy a centrar en esta última plataforma. Ventajas del modelo de desarrollo de código abierto.

Para los impacientes, la descarga aquí: https://www.strawbs.org.

Si no os apetece compilarlo a partir de los fuentes, encontraréis paquetes instalables aquí: https://builds.strawbs.net.

Esto no es en modo alguno un tutorial, así que simplemente voy a comentar brevemente ciertos aspectos por los que Strawberry me parece una opción a tener en cuenta.

Comencemos por la interfaz de usuario. Nada espectacular, con la tradicional yuxtaposición de elementos tales como barra de componentes (contexto, luego volveremos a él, colección, archivos, listas, cola, dispositivos y ¡sí, Tidal!) y paneles correspondientes (izquierda), lista de reproducción (derecha) y visualización espectral de turno con información de la pista en reproducción y botonera de control (abajo).

Strawberry en acción.

Aires viejunos, pero funcionales.

La colección musical (biblioteca) puede explorarse utilizando las típicas vistas (artista, álbum, género y combinaciones de ellas).

Ajustes de agrupamiento de la biblioteca musical.

Además, es posible ajustar algún que otro aspecto de su funcionamiento y aspecto (lejos, no obstante de las barbaridades de Foobar o JRiver Media Center, por supuesto). Veamos algunos de sus paneles de configuración.

Comportamiento general. Algo tan molesto como que el reproductor haga lo que le de la gana, que no suele coincidir con lo que el usuario quiere, cuando se hace doble clic sobre un elemento de la biblioteca puede evitarse fácilmente.

Ajustes generales.

Ajustes de notificaciones.

Configurando las notificaciones de Strawberry.

Podemos utilizar las del sistema o las del propio Strawberry (que son más vistosas) y determinar cuándo y durante cuánto tiempo se mostrarán.

Notificaciones nativas de Strawberry, con carátula y metadatos.

Configuración (ligerita) del aspecto de la interfaz de usuario. Paleta de colores (dos tonos) y posibilidad de utilizar un fondo dinámico a partir de la carátula del disco que está sonando. No está mal.

Para darle un toque personal a la interfaz de usuario...

Pero hay otras características que, en mi opinión, son más destacables.

Strawberry es capaz de monitorizar una colección esparcida por varias carpetas en el sistema de archivos:

Indicando dónde tenemos las carpetas con musiquita.

En mi Ubuntu no es capaz de acceder a recursos de red montados dinámicamente de modo inmediato (no aparecen en el cuadro de diálogo), pero no hay más que buscar los puntos de montaje automáticos en...

/run/user/xxxx/gvfs

...como se ve en la imagen para solucionarlo.

No lo dice por ninguna parte, pero cuando reproducimos un disco sin carátula, Strawberry la busca en Internet y la incorpora a la biblioteca él solito:

Descarga automática de carátulas de álbums de la biblioteca.

De hecho, hay un práctico menú contextual para gestionar las carátulas (clic con el botón derecho de la rata sobre la portada)...

Acciones contextuales sobre el álbum en reproducción.

...que da acceso a un fantástico gestor / buscador de carátulas en servicios en línea (Search for album covers):

Imágenes descargadas de Internet y propuestas por el gestor de carátulas para el álbum seleccionado.

El gestor de carátulas dispone de su propio comando de menú...

El menú de herramientas esconde cositas interesantes...

...e incluso es capaz de identificar todas las que nos faltan y recuperarlas en bloque, además de exportarlas.

Gestor de carátulas de Strawberry en todo su esplendor.

Se dispone de un control magnífico sobre el sistema de reproducción: motor, tipo de salida y dispositivo. OSS, PulseAudio, A2DP (bluetooth), virtual, Jack. Muy completito. Asimismo, se puede escoger el dispositivo HW por nombre o ID. Control total, muy guay. Por tanto, Strawberry es bitperfect.

Completas opciones sobre el dispositivo de audio.

Podemos ajustar el tamaño del buffer y su pre-llenado. También hay controles relativos a los ajustes de ganancia (vía metadatos), así como una función para evitar clipping digital como consecuencia de su aplicación. Del mismo modo, es posible activar un fundido entre pistas con controles muy granulares. Lógicamente los audiófilos deberían mantenerse lejos de estas cosas (ajuste de ganancia y fundidos).

Si usamos ALSA, Strawberry ajustará dinámicamente las propiedades del dispositivo de audio. Aquí lo vemos reproduciendo 88/24 sin el remuestreo característico de Pulse y en modo exclusivo.

Reproduciendo PCM 88/24 sin remuestreo y en modo exclusivo. La consola nunca miente.

Pero sigamos... Resulta que también hay funciones de conversión de formatos, que se utilizan cuando se conecta un dispositivo de audio portátil (¿os acordáis del menú Dispositivos?) o simplemente bajo demanda. No son lo más exhaustivo del mundo, pero pueden venirnos bien en un momento dado. En principio Strawberry puede exportar pistas a dispositivos iPod, iPhone, MTP o simplemente a aquellos que aparecen como almacenamiento USB (no lo he probado personalmente, Spotify sin conexión en el móvil redujo a la irrelevancia esta funcionalidad para mi hace tiempo).

Ajustes de transcodificación (conversión de formatos) de audio.

De listas de reproducción y scrobbling (emitir en plan exhibicionista los metadatos de lo que estamos escuchando) no comento nada porque son funciones que no utilizo demasiado. Pero Strawberry también cumple aquí:

Ajustes relativos a listas de reproducción y scrobbling.

Y sí, tenemos integración (básica) con Tidal.

¡Tidal en Strawberry!

Lamentablemente no se pueden recorrer las listas de reproducción, generales o personalizadas, o los artistas o discos que hemos añadido a nuestra biblioteca personal. Solo realizar búsquedas. Y no, nada de másters (pero sí HiFi). De hecho, Strawberry es una de las maneras más sencillas de disfrutar de Tidal en Linux en bitperfect.

Buscando cosas en el catálogo de Tidal desde la interfaz de Strawberry.

Deezer también está soportado, pero por razones técnicas la cosa es complicada en Linux. Por esa razón, el autor ha optado por eliminar la funcionalidad en esta plataforma.

Con respecto a la compatibilidad con formatos de audio, se admiten los siguientes:

WAV, FLAC, WavPack, DSF, DSDIFF, Ogg Vorbis, Speex, MPC, TrueAudio, AIFF, MP4, MP3, ASF and Monkey's Audio

Para que la reproducción de DSD (DSF, DSDIFF) funcione correctamente, nuestra distribución de Linux deberá utilizar GStreamer y libav en sus versiones 1.15.1 (o superiores, supongo). Podemos averiguar cuáles son las instaladas mediante este comando:

gst-launch-1.0 --gst-version

En mi caso (Ubuntu 18.04 LTS) ando por la 1.14.1, así que algo habrá que hacer al respecto, aunque para mi la compatibilidad con DSD no es en absoluto una función crucial, francamente.

Ni rastro de compatibilidad con ISO de SACD o DVD-A, sin embargo. A extraer pistas toca. Afortunadamente es un tema muy superado.

Más cositas... y viene una buena. Strawberry también permite editar los metadatos (tags) de las pistas a través de un editor incorporado:

Editando los metadatos fácilmente sin salir de Strawberry.

Edición múltiple de pistas, carátulas, integración con el servicio de identificación de MusicBrainz, contadores de reproducción.... muy, muy chulo.

Volviendo a los paneles principales de la interfaz, me gustaría destacar el denominado Context, que nos indica qué y cómo se está reproduciendo y sugiere otros elementos de la biblioteca, aunque de un modo muy rudimentario. No esperéis aquí nada parecido a Spotify o Roon. ¿Quizás esto "apunte maneras" en futuras versiones? Veremos. Y sí, también muestra las letras del tema que está sonando, si así lo queremos.

Panel de información sobre la reproducción en curso.

Y vamos llegando al final de este breve recorrido por Strawberry. Veamos, ¿qué me dejo? Seguro que muchas cosas. ¡Ah, sí!... ¿He mencionado que disponemos de un ecualizador integrado con perfiles?

El sencillo ecualizador gráfico incorporado. Lástima que no sea de tipo paramétrico.

¿Y de reproducción de vetustos cedés, para los más románticos?

¿Alguien sigue usando regularmente cedés ahí fuera?

¿Y de un panel de gestión de listas multipestaña con un completo menú contextual para actuar sobre las pistas? Todo muy bien pensado, la verdad.

Panel multipestaña para las listas de reproducción que vamos creando.

Incluso nos encontramos con una enigmática consola a la que le podemos ¿lanzar comandos? (¿más "maneras apuntadas", quizás para permitir automatizar cositas con scripts en un futuro?).

¿Y esto para qué sirve? ¿Alguna automatización?

Recapitulemos pues. Tenemos un reproductor que:

Reproduce una gran variedad de formatos, incluso de alta resolución.
Es bitperfect.
Gestiona una biblioteca musical.
Edita metadatos.
Busca carátulas en Internet.
Maneja múltiples listas de reproducción.
Reproduce CD.
Descarga letras.
Cuenta con funciones de ecualización.
Convierte y exporta entre formatos.
Se integra con Tidal.
Es razonablemente configurable.
Es estable.
Se integra bien con el escritorio de Linux.
Denota un evidente cuidado en su diseño, funciones y usabilidad.

Y además es multiplataforma (Windows, MacOS, Linux) y de código abierto, con todo lo que eso supone por lo que hace a su evolución y continuidad.

En fin, que Strawberry se ha convertido, sin comerlo ni beberlo, en mi reproductor de cabecera en Linux. Creo que, teniendo en cuenta todo lo anterior, nos encontramos ante un excelente reproductor, bien diseñado, rico en funciones y muy usable.

Con respecto a la calidad del sonido tengo que decir que a mi me suena estupendamente, especialmente a través de ALSA. Pero ya sabéis que no comulgo en absoluto con misterios audiófilos, y si son digitales, aún menos.

Cualquier cosa, comentamos aquí abajo o en el hilo que he abierto en Audio Planet.

Cables ethernet "audiófilos": un experimento casero

noreply@blogger.com (Pablo Felip) — Sun, 09 Dec 2018 18:16:00 +0000

Sí, esto va de cables ethernet audiófilos, de esos que suelen tener bonitos e imaginativos nombres y pueden costar sin despeinarse cientos o incluso miles de euros. Por ejemplo, el de la parte inferior de la foto anterior, un Audioquest Diamond, que ronda los 800€ / metro.

Así, que mejor empecemos por la...

Exención de responsabilidad

Vistas las susceptibilidades que afloran cuando se toca este delicado asunto, anteponga usted, querido lector, a mis afirmaciones subsiguientes las expresiones "en mi opinión", "resulta razonable suponer", "yo diría", "no encuentro motivos para ignorar", "me da la sensación" y cuantas fórmulas de cortesía y humildad similares considere usted necesarias para limar las posibles asperezas que pudieran derivarse de su lectura. No es mi intención que se produzcan, pero tampoco me voy a poner de perfil en esta ocasión. Bueno, solo un poquito, lo justo y necesario.

Motivación

Mucho estoy leyendo en los últimos meses en Audio Planet (y otros lugares) sobre los milagros que ciertos cables ethernet parecen obrar sobre la transmisión de señales digitales de audio. Cables, que naturalmente, son fabricados y vendidos por las mismas marcas que llevan produciendo otro tipo de cableado, tanto analógico como digital, para el exigente mercado audiófilo durante años... lo que por otra parte se me antoja inevitable ahora que el audio hi-end (y el que no es tan "hi" también) ha dejado de ser estrictamente analógico. No dejes que nuevos vientos en el mar te dejen sin pesca en las redes.

Veamos un ejemplo paradigmático:

Esto lo escribe un tal Jay Luong aquí. Así que sonido coherente, suave, con cuerpo y "eufórico", además de rico, musical, natural y adictivo. Agárrate. Es inevitable que cualquiera que se dedique profesionalmente a desplegar y configurar redes locales o simplemente tenga ciertos conocimientos técnicos al respecto enarque preventivamente una ceja (o las dos simultaneamente) ante afirmaciones tan pizpiretas como estas.

¿De verdad podemos atribuirle a un simple cable de transmisión ethernet estas cualidades de un modo tan inequívoco? ¿Será porque es de categoría 8? Pero, ¡dios mío! ¡Si ni siquiera existía tal certificación en el momento (mayo 2017) de escribir ese colorista análisis! Estos fabricantes no cortan el mar sino vuelan o, como hubiera dicho mi abuela, "van delante del aire". Eso va a tener que ver un poquito con la pesca de la que hablaba un par de párrafos más arriba.

Pero dejando de lado las sinestesias, inevitables por otra parte cuando hay cierto tipo de audiófilo en la sala, testimonios como este no son raros, ni tampoco los hilos en los que aficionados preguntan por las bondades de tal o cual cable ethernet. Sin ir más lejos, aquí al lado, en Audio Planet, hemos visto en este hilo reciente algún que otro encontronazo entre escépticos (con ese, por favor) y ¿creyentes?

La cantinela es la de siempre: aficionados que dicen percibir diferencias allá donde otros afirman que por razones técnicas no puede haber más que la manifestación de la propia subjetividad y variabilidad perceptual. Mosqueo in crescendo de los unos y los otros, comentarios jocosos varios con mayor o menor gracia, susceptibilidades henchidas y honores mancillados hasta que simplemente la cosa alcanza su clímax y nuevamente las aguas vuelven a su cauce tras la salida del hilo de quien corresponda, según toque. Los foros son así, mire usted. Y si no le gustan, tengo otros.

No me avergüenza reconocer que yo mismo caí en la trampa de participar en esta refriega concreta cual forero novato, hasta el punto de que en cierto momento decidí simplemente abandonar. Pero lo cierto es que me quedé con las ganas de hablar del tema con cierto detenimiento. Y como hoy es festivo y tengo mucha musiquita chula que escuchar en mi equipo de 3 chavos, aquí estamos.

Cuando el río suena...

...Agua lleva ¿verdad? Pues no siempre, pero vamos a tratar de valorar todas las posibilidades con la mente abierta, casi tanto como para que se nos caiga el cerebro (Richard Feynman dixit, o al menos algo parecido).

Richard Feynman pensando en sus cosas (seguramente misterios cuánticos).

Antes de entrar en materia, no obstante, recomiendo leer un poquito sobre los distintos cables ethernet, sus características, propiedades, usos y certificaciones. Aquí no hay ningún misterio. Un buen sitio es este. Así me ahorro tener que explicarlo yo aquí, que resulta bastante aburrido.

Pero vamos centrándonos. En lo que sigue voy a tratar de presentar las distintas circunstancias que, tal y como yo lo veo, podrían afectar a la integridad de una señal de audio digital transmitida a través de un cable ethernet. No entraré sin embargo a valorar hasta qué punto esas diferencias medibles pueden o no ser audibles. Eso queda ya en el ámbito de lo subjetivo y simplemente no me apetece traspasar las puertas de Mordor, al menos no sin una legión de Altos Elfos a mi servicio.

Veamos. El aficionado A afirma que su equipo suena mejor con determinado cable ethernet ¿a qué podría deberse? Se me ocurren dos posibles causas.

1. Interferencias radioeléctricas

Los cables no dejan de ser antenas que captan y emiten radiaciones de tipo electromagnético. Un cable ethernet probablemente se encontrará en un ambiente repleto de ellas, tanto más en la medida en que el sistema de reproducción incluya un PC convencional.

Cableado, ventiladores, amplificador, otros componentes... probablemente no sea el entorno más aséptico del mundo.

Estas perturbaciones, a su vez, podrían afectar a los más o menos delicados voltajes digitales de la señal de audio hasta el punto de alterar su integridad, de modo que algunos 1's se transformarían en 0's o viceversa. Y ya la tenemos liada entonces ¿no? Relación causa - efecto justificada y fin del artículo.

¡No tan rápido!

Por otro lado, y aún admitiendo que el fenómeno anterior no afectara en modo alguna a la integridad de la información transmitida, aún podría suceder que dichas perturbaciones se colasen, a través de sus puertos ethernet, en los delicados circuitos electrónicos de los dispositivos de reproducción en los que eventualmente se realiza la conversión de la señal digital al ámbito analógico, perturbaciones que desde ahí podrían asimismo propagarse a los componentes eléctricos de sus etapas de salida y circuitos de reloj. Eso tal vez se manifestara en la forma de variaciones cuantificables en parámetros tales como la distorsión armónica, la relación señal / ruido o incluso el escurridizo jitter, ese elusivo duendecillo al parecer responsable de todas las miserias actuales del audio digital.

Es un hecho conocido que existe una relación entre la actividad de la CPU, GPU y otros componentes de un sistema informático y el patrón de emisiones electromagnéticas que genera cuando está en funcionamiento. Tanto es así que incluso existen sorprendentes técnicas de espionaje capaces de predecir a distancia lo que aparece en la pantalla de un ordenador totalmente desconectado de la red (Kuhn 2003, 2004) o transmitir información desde él, cuando ha sido previamente comprometido, hacia un simple teléfono móvil (Guri et al. 2015). De hecho el trabajo en este campo del tal Mordechai Guri y su alegres hackers es... inquietante. Ya tardáis en buscarlo en Google.

Habiendo reconocido pues el papel que puede jugar toda esta cacofonía de perturbaciones electromagnéticas en un sistema informático, no se requiere de un gran salto de fe para admitir la posibilidad de que un cable ethernet susceptible de captar y propagar ciertas interferencias pudiera comprometer, hasta cierto punto, tampoco nos vengamos arriba, la calidad de sonido en un reproductor digital.

La pregunta, claro, es cuánto.

Pero en el título de este artículo hablabas de un experimento ¿no? En efecto, pero no uno que sirva para dar respuesta a la anterior cuestión. Desgraciadamente no dispongo del equipamiento necesario para medir el posible efecto de distintos cables ethernet sobre la señal emitida a través de la salida de línea analógica de un reproductor conectado a una red ethernet. No obstante, otros como el archiconocido Archimago sí lo tienen... y además lo utilizan asiduamente. Recomiendo encarecidamente la lectura de los extensos y concienzudos artículos que este conocido aficionado publica en su blog. Resultan de gran ayuda para combatir con contundencia la terrible audiofilia nerviosa digital, una variante relativamente reciente de este conocido mal, especialmente cuando aún se encuentra en sus fases tempranas cuando la cosa aún tiene remedio.

Vamos a por la segunda.

2. Perdiendo bits por el camino (y cómo funciona TCP/IP)

Retomemos ahora la especulación anterior acerca de las interferencias de índole electromagnética y la posible corrupción de datos en tránsito. O admitamos que algunos bits simplemente se pierdan de algún modo en su camino de emisor a receptor. Quién sabe, quizás decidan irse de copas y no sepan volver a su casa tras la juerga de rigor. ¿Podría esto justificar la existencia de estos supercables ethernet cuyas propiedades van más allá de donde certificación alguna ha llegado jamás?

Para profundizar un poco en esta posibilidad tenemos que introducir primeramente ciertos conceptos relacionados con el modo en que se transmite la información. Voy a tratar de explicarlo sin profundizar demasiado en los detalles técnicos ni contar demasiadas mentiras, lo que probablemente no conseguiré.

El problema de interconectar sistemas informáticos heterogéneos (es decir, con tecnologías dispares, o lo que es lo mismo, de su padre y de su madre), alejados miles de kilómetros, utilizando una red extensa, insegura, compuesta por una cantidad indeterminada de nodos intermedios que pueden empeñarse testarudamente en extraviar, duplicar o desordenar la información que circula entre ellos no es ninguna bobada.

De hecho, desarrollar el conjunto de tecnologías y protocolos necesarios para lograrlo con éxito ha supuesto muchas décadas de trabajo para algunas mentes más que brillantes. Es la historia de ARPANET (y de lo que había antes de ARPANET). Es la historia de TCP/IP. Y de héroes conocidos como Jon Postel, Douglas Engelbart, Vicent Cerf o, más recientemente, Tim Bernes-Lee. Y también de otros menos conocidos pero cuya contribución resultó también decisiva. Y el caso es que lo que crearon, que seguramente conocerás como Internet, resuelve el problema. Y permite que una empresa de Albacete haga copias de seguridad diarias de sus datos en un servidor de Ohio sin temor a que ni uno solo de sus preciosos bits se pierda por un camino digital de paquetes de datos amarillos que se extiende de extremo a extremo del mundo a través de docenas de redes ajenas.

Vete ahora y explícale a esta gente, o a los pastores que cuidan de la infraestructura que aquellos parieron, que te preocupa que tu cable ethernet de pocos metros pierda datos en una conexión punto a punto doméstica cuando transmite información de audio o vídeo codificada digitalmente de igual modo que los backups de la empresa de Albacete.

Pero sigamos con la mente abierta.

El caso es que el problema descrito, por su complejidad, no resulta fácilmente abordable de modo monolítico. O lo que es lo mismo, es preferible descomponerlo en problemas más sencillos que se irán resolviendo progresivamente. Y así surge la llamada arquitectura por capas de TCP/IP, que a su vez se basa en la propuesta anteriormente por OSI, más estratificada. Si quieres saber más sobre los modelos ISO/OSI y TCP/IP, esta es una buena referencia, bastante completa pero no abrumadora desde un punto de vista técnico.

Prosigamos.

Resumiendo un poco (bueno, bastante), la idea es descomponer el proceso de transmisión en capas (niveles), cada una de las cuales solo se ocupa de determinados problemas puesto que asume que ciertas cosas ya han sido resueltas en las capas inferiores. Y de modo análogo, le facilita por tanto la vida a las superiores tras desarrollar su propia función. Se trata en definitiva de un mecanismo de encapsulación de la complejidad que comprende desde las aplicaciones que desean transmitir información (arriba) hasta las propias señales eléctricas u ópticas que efectivamente se envían (abajo), pasando por toda una caterva de protocolos de distinto pelaje especializados en resolver problemas específicos.

Esquema general del funcionamiento de una arquitectura de red por capas. El número de capas es más que discutible.

Cada capa agrupa los bits de datos en paquetes que en función del nivel al que pertenecen reciben distintos nombres: segmento, datagrama, trama... Además, se añade información de control (cabeceras), necesarias para que surja la "magia" que se practica en cada nivel. Emisor y receptor disponen de todas las capas, de modo que la transmisión de estos paquetes se realiza de arriba a bajo en el emisor, de ahí pasa a la red, y ya en el receptor de abajo arriba. Cada capa, no obstante, tiene la sensación de estar "dialogando" con su equivalente, por lo que desde un punto de vista lógico es como si la comunicación se estableciera horizontalmente entre los niveles (protocolos) homónimos de emisor y receptor. Casi nada.

Dejando de lado el probable galimatías que constituye el último párrafo, que quizás prefieras ignorar sin remordimientos, concretemos el asunto con un gráfico ya adaptado a nuestra peculiar área de interés, los cacharros que reproducen audio.

Una versión maxi single de la arquitectura por capas de TCP/IP en un sistema de reproducción de audio en red.

En la parte superior, tenemos los distintos dispositivos que pueden actuar como reproductores de audio: ordenadores, reproductores comerciales dedicados o basados en hardware abierto (SoCs de tipo Raspberry, ODROID y similares). Y muchos más, claro. Cualquier cosa capaz de reproducir contenidos multimedia a través de la red. De hecho, he excluido del diagrama móviles y tabletas puesto que nos estamos centrando en la conexión ethernet y estos suele carecer de ella, pero conceptualmente tendrían todo el derecho a aparecer ahí arriba.

Los reproductores lógicamente necesitan de un software que los comande. Estos constituyen el denominado nivel de aplicación:

En el caso de ordenadores, se trata de aplicaciones de escritorio como JRiver Media Center, Foobar, Audirvana, las de Spotify o Tidal o simplemente un navegador de Internet mondo y lirondo con el que acceder a servicios genéricos en streaming.
Distros basadas en Linux como piCorePlayer, Volumio o LibreElec para los SoCs abiertos.
Y, por último, lo que quiera que ejecuten los reproductores comerciales, usualmente algo basado también en Linux y otros desarrollos de código abierto con un mayor o menor grado de personalización por parte del fabricante.

Justo debajo nos encontramos con el nivel de sesión, y reconozco que aquí me he tomado una pequeña licencia para colar ciertos elementos que me convenía poner sobre la mesa. A diferencia de ISO/OSI, la arquitectura TCP/IP no maneja de modo explícito un nivel de sesión, de ahí que escriba su nombre en cursiva en el diagrama anterior. El caso es que me interesa introducir ciertos protocolos de red de alto nivel, que estrictamente hablando tampoco deberían aparecer ahí, necesarios para que las aplicaciones que encuentran en la parte superior de nuestra pila (o torre, si lo prefieres) puedan establecer conexiones con otros dispositivos o servidores con los que intercambiar información. Los más utilizadas son SMB, NFS y, en entornos domésticos AV, UPnP. Todos ellos representan el primer paso en el camino para "salir a la red".

Más abajo, y ahora sí reingresamos en la arquitectura TCP/IP de Internet, nos topamos con la capa de transporte, conformada por dos protocolos, TCP y UDP:

TCP proporciona un servicio orientado a conexión que garantiza todo lo que debe ser garantizado en una transmisión segura, creando un "tubo" extremo a extremo de forma que la información pasa a través de él preservando totalmente su orden e integridad. Para ello se incorporan mecanismos de retransmisión de datos cuando se detectan errores. Estos mecanismos tiene un coste, una sobrecarga, que hace que parte de los datos que se transmiten deben ser necesariamente de control para que el tinglado pueda gestionar cualquier eventualidad.
UDP no hace nada de lo anterior, de hecho ni siquiera es un servicio orientado a conexión y, por tanto, se utiliza en escenarios en los que a) se presupone que no se van a producir errores o b) es más importante garantizar que un flujo constante de información llegue al receptor que asegurarse de que esto se consiga sin que se produzcan errores en el proceso (por ejemplo en las retransmisiones de audio y vídeo en tiempo real). A cambio, su eficiencia es mayor que la de TCP.

Los protocolos y aplicaciones situados por encima de la capa de transporte pueden diseñarse para emplear uno u otro. En algunos casos esta elección queda grabada a fuego en la etapa de diseño. En otros puede modificarse a voluntad del usuario o como consecuencia de una decisión inteligente de la aplicación posteriormente, en cada uso.

Por ejemplo, UDP se suele utilizar en aplicaciones de videoconferencia en tiempo real, donde concurren exigencias temporales más restrictivas que las de la simple emisión de flujos de audio o vídeo porque de lo contrario la inteligibilidad de la sesión puede verse seriamente perjudicada al ser la comunicación bidireccional.

Además, tanto TCP como UDP proporcionan un servicio adicional a los niveles superiores, un mecanismo denominado multiplexación de flujos de datos. Gracias a él, diferentes aplicaciones en un mismo dispositivo son capaces de mantener conexiones simultáneas con otros tantos agentes remotos. La capa de transporte etiqueta mediante unos identificadores numéricos asociados aquellos procesos que se encuentran a cada lado de la conexión. Estos identificadores se denominan puertos.

Si un reproductor utiliza un protocolo de sesión que funciona sobre TCP/IP podemos asumir que, salvo circunstancias cataclísmicas, la conexión es segura. Así de sencillo. En el caso de UDP no, pero... sigamos bajando.

Del nivel de red solo voy a decir que proporciona los mecanismos globales de identificación de dispositivos y encaminamiento de datos necesarios para que los paquetes encuentren su destino en una red extensa multipunto. No hay más que pensar en una hipotética red ferroviaria (si es muy densa mejor), con múltiples rutas entre dos estaciones dadas, para entender de qué va esto.

Principales rutas de datos de las conexiones troncales de Internet (2006). Fuente: Opte Project (Wikipedia).

No es que su papel no sea importante (¡es crucial!), sino que no necesitamos profundizar más en este aspecto para abordar el tema que nos ocupa. Simplemente aceptemos que IP es el auténtico corazón de Internet. Funciona, y punto.

Llegamos al meollo del asunto, el nivel donde opera el estándar ethernet, con sus puertos de red, cableado, dispositivos de conmutación (switches, routers, etc.) que en terminología OSI son realmente dos, a saber: la física y la de enlace datos. Estas capas son las responsables de posibilitar en última instancia la comunicación en el ámbito de nuestra red local. Y es aquí donde nos vamos a detener para realizar un pequeño experimento. Pero antes, algunos comentarios. Paciencia, ya casi estamos.

Las comunicaciones entre dispositivos dentro de una red local no requieren estrictamente hablando de ningún mecanismo de encaminamiento como el que proporciona TCP/IP en una red de área extensa como Internet. Los datos simplemente fluyen por el cable hasta un conmutador, típicamente el propio router en entornos domésticos sencillos, y de ahí hasta el dispositivo destinatario de los mismos. Aunque la topología física es una estrella cuyo centro se encuentra un conmutador, a todos los efectos los elementos conectados se hallan dentro de la misma red física.

Un sencillo router doméstico (D-Link DIR-882) como el empleado para las pruebas que siguen.

Ethernet proporciona mecanismos para, por una parte, sincronizar emisor y receptor (control de flujo) y, por otra, detectar los errores producidos en estas transmisiones, digamos, locales, aunque no para recuperarse de ellos. Esto quiere decir que si un paquete de datos es erróneo simplemente se descarta y se informa a las capas superiores para que alguien haga algo, literalmente, si se considera oportuno.

Y aquí es donde todo empieza a encajar (espero). Cuando una aplicación (y ahora volvemos a la parte superior de nuestra bonita torre TCP/IP) emplea TCP como protocolo de transporte, tenemos todas las garantías para considerar que la transmisión es segura y no se pierde información. Si en cambio se utiliza UDP, este garante desaparece.

Pero...

(A) ¿Sabemos qué reproductores utilizan TCP y cuáles UDP?

(B) ¿Cuántos errores de transmisión se producen realmente?

Si quieres averiguarlo por ti mismo, sigue leyendo. ¡Vamos con las pruebas!

Netstat, TCP y UDP

Netstat es una utilidad de línea de comandos disponible en sistemas Windows, Linux y OS X. Su sintaxis difiere ligeramente en cada caso, pero la información que nos proporciona es prácticamente idéntica.

Pero primero voy a presentarte el cable ethernet utilizado en todo lo que sigue:

El John Doe de los cables ethernet.

Sí, estás viendo bien. Se trata de un miserable SFTP de categoría 5E de unos 2 metros de longitud. Ni 8, ni 7 ni 6. Adecuado para conseguir velocidades de 1000 Mbps en full dúplex, de acuerdo a lo que marca la certificación para esta categoría. Ni más ni menos. No sabría decir qué precio tiene puesto que si no me equivoco venía incluido con algún cacharro, pero diría que no debería costar más de unos pocos euros. ¿Esperabas otra cosa?

Comencemos lanzando el cliente de escritorio de Tidal, a ver si somos capaces de determinar qué protocolo de transporte utiliza. Recordemos, TCP ofrece garantía de transmisión de la información sin errores en tanto que UDP opera bajo algo así como "envía & reza", sin proporcionar ningún mecanismos de recuperación el caso de pérdidas o errores en los datos.

Tidal: gran sonido, pésimas recomendaciones.

Para ello primeramente deberemos averiguar su PID (identificador de proceso) utilizando el administrador de tareas. En Windows lo encontraremos aquí:

Localizando el PID de un proceso a través del administrador de tareas de Windows.

Ahora solo necesitamos hacer (seguimos en Windows):

X:\>netstat -ano | find "5556"

TCP 10.255.0.198:52182 2.18.49.14:443 ESTABLISHED 5556

Vaya, el proceso TIDALPlayer.exe abre una conexión de tipo TCP entre el PC local (10.255.0.198) y uno remoto (2.18.49.14) en cuanto comenzamos a reproducir un tema. Si hacemos ahora..

X:\>ping -a 2.18.49.14

Haciendo ping a a2-18-49-14.deploy.static.akamaitechnologies.com [2.18.49.14]:

Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53
Respuesta desde 2.18.49.14: bytes=32 tiempo=15ms TTL=53

...comprobaremos que se trata de un servidor en Akamai, una conocida organización que dispone de una potente red de distribución global de contenidos utilizada por múltiples proveedores de servicios en Internet. Blanco y en botella.

Como ya hemos visto de qué modo proceder en Windows yo seguiré a partir de ahora, por brevedad, desarrollando mi argumentación exclusivamente en un entorno Linux. Como aquí no tenemos un cliente de escritorio de Tidal (¿para cuándo?), probaremos con el de Spotify.

Los duendecillos de Spotify, en cambio, me conocen como si me hubieran parido.

La sintaxis del comando a emplear en una terminal en este sistema operativo será similar:

pablo@menos:~$ netstat -antup | grep spotify

tcp 0 0 0.0.0.0:39157 0.0.0.0:* ESCUCHAR 14991/spotify
tcp 0 0 0.0.0.0:57621 0.0.0.0:* ESCUCHAR 14991/spotify
tcp 0 0 192.168.1.101:56570 72.247.210.56:80 ESTABLECIDO 14991/spotify
tcp 0 0 192.168.1.101:35172 104.199.65.47:4070 ESTABLECIDO 14991/spotify
udp 1536 0 0.0.0.0:57621 0.0.0.0:* 14991/spotify

El número de conexiones varía ostensiblemente durante el periodo de uso de Spotify, así que si estás probado esto en tu equipo es probable que el resultado sea distinto. En esta ocasión nos encontramos con indicios de uso de UDP. Dado que es este un protocolo sin conexión, netstat es incapaz de mostrarnos quién está "al otro lado de la línea", indicando tan solo que el cliente de Spotify del PC está escuchando en UDP/57621. Podríamos escarbar un poco más con alguna herramienta de captura de paquetes para tratar de obtener información más concluyente, pero probablemente no merecería la pena.

¿Quiere esto decir que Spotify usa UDP para su emisión? En mi opinión no. Hay que recordar que nos encontramos tras un router en el que no se han abierto ni redirigido puertos específicos hacia este PC, de modo que no es alcanzable desde Internet. Yo diría que el puerto 57621 más bien se utiliza para algún tipo de funcionalidad relacionada con la interacción con otros clientes de Spotify que pudiera haber en la red local. No obstante, si te sientes más cómodo pensando lo contrario, puedes hacerlo tranquilamente.

Por cierto que Spotify, al menos en sus inicios, tenía una curiosa manera de funcionar, combinando la descarga directa de datos de audio desde los servidores de esta empresa con el uso de una red P2P entre los propios usuarios del servicio para aligerar la carga sobre sus propias infraestructuras. En este artículo (Kreitz, Niemelä 2010) lo explicaban ellos mismos estupendamente.

Spotify, en 2008. Cuando el P2P te ayuda a crecer sin invertir un montón de pasta. El diagrama es prestado (Spotify).

Veamos a continuación qué pasa con un cliente software Squeezelite en un entorno Squeezebox.

pablo@menos:~$ netstat -antup | grep squeezelite

tcp 0 0 192.168.1.101:35276 192.168.1.100:3483 ESTABLECIDO 27308/squeezelite
tcp 1252585 0 192.168.1.101:47026 192.168.1.100:9000 ESTABLECIDO 27308/squeezelite

Ahora TCP sin ambages.

A continuación probemos con un reproductor minimalista como Audacious (Linux) tirando musiquita localizada en una carpeta de mi NAS doméstico compartida en red mediante SMB.

Audacious, un pequeño gran reproductor heredero espiritual de Winamp.

pablo@menos:~$ netstat -antup | grep audacious

pablo@menos:~$

Ya hemos roto algo. ¿Qué ha pasado? Ahora no es Audacious (el reproductor) quien abre la conexión de red, sino que es el propio sistema operativo quien se encarga de gestionar la transmisión de datos a través de sus servicios de red mediante SMB. Pero como sabemos que los servidores SMB deben "escuchar" en el puerto 445, veamos qué conexiones salientes ha establecido nuestro PC hacia ese puerto:

pablo@menos:~$ netstat -antup | grep 445

tcp 0 0 192.168.1.101:51832 192.168.1.100:445 ESTABLECIDO 11563/gvfsd-smb

Ahí la tenemos, de tipo TCP hacia 192.168.1.100, que se corresponde con la IP del NAS donde se encuentran los archivos reproducidos.

Con otros reproductores como JRiver Media Center ocurrirá exactamente lo mismo. De hecho, cualquier aplicación que acceda a la red a través de SMB o NFS lo hará de modo seguro puesto que ambos protocolos utilizan siempre TCP. Esto también incluye a los diversos demonios MPD que se encuentran en el corazón de más de un reproductor comercial de hardware cerrado o de Volumio, por ejemplo. Y SMB se usa mucho ahí fuera. Pero mucho. Incluso los dispositivos de la familia Sonos lo hacen.

Configuración de la biblioteca musical de un Sonos One utilizando una carpeta de red SMB.

¿Y qué ocurre con los reproductores que en cambio optan por UPnP/DLNA? En estos casos se admite el uso tanto de TCP como de UDP, siendo creencia extendida que la emisión del audio se realiza siempre sobre UDP. Vamos a ver si es verdad.

Probemos primeramente con Banshee, un sencillo reproductor para Linux que también es capaz de conectarse con servidores UPnP/DLNA, en este caso uno del tipo miniDLNA.

Banshee en acción.

pablo@menos:~$ netstat -antup | grep banshee

tcp 0 0 127.0.0.1:8089 0.0.0.0:* ESCUCHAR 373/banshee

tcp 0 0 192.168.1.101:40450 192.168.1.100:9000 ESTABLECIDO 373/banshee

tcp 808400 0 192.168.1.101:60384 192.168.1.100:8200 ESTABLECIDO 373/banshee

tcp 0 0 192.168.1.101:60356 192.168.1.174:8008 ESTABLECIDO 373/banshee

tcp 0 0 192.168.1.101:58760 138.201.227.205:80 ESTABLECIDO 373/banshee

tcp 0 0 192.168.1.101:40428 192.168.1.100:9000 ESTABLECIDO 373/banshee

udp 28224 0 0.0.0.0:1900 0.0.0.0:* 373/banshee

udp 35904 0 0.0.0.0:33238 0.0.0.0:* 373/banshee

Conexiones TCP establecidas (3 con el servidor de medios UPnP en 192.168.1.100) y 2 puertos de tipo UDP a la escucha. Ahora servidor y reproductor están dentro de la misma red local. En esta ocasión sí podemos admitir fácilmente la posibilidad de que se esté utilizando un protocolo de transporte no fiable.

En segundo lugar, echémosle un vistazo a JRiver Media Center en su faceta de cliente UPnP/DLNA contra el mismo servidor.

El gran JRMC en Linux.

pablo@menos:~$ netstat -antup | grep mediacenter24

tcp 0 0 0.0.0.0:52100 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 0 0 0.0.0.0:52102 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 0 0 0.0.0.0:52103 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 0 0 0.0.0.0:52199 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 0 0 192.168.1.101:32928 192.168.1.100:8200 ESTABLECIDO 2372/mediacenter24

udp 3456 0 0.0.0.0:52100 0.0.0.0:* 2372/mediacenter24

Similares resultados a los obtenidos con Banshee, ¿no te parece? Ahí tenemos también un puerto UDP abierto (52100).

¿Y qué pasará si cambiamos miniDLNA por otro servidor de medios, por ejemplo el integrado en Logitech Media Server?

pablo@menos:~$ netstat -antup | grep mediacenter24

tcp 0 0 0.0.0.0:52101 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 0 0 0.0.0.0:52102 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 0 0 0.0.0.0:52199 0.0.0.0:* ESCUCHAR 2372/mediacenter24

tcp 7872 0 192.168.1.101:41960 192.168.1.100:9000 ESTABLECIDO 2372/mediacenter24

¡Sorpresa! Ni rastro de conexiones UDP. Squeezebox ama TCP.

Siguiendo los procedimientos descritos con el comando netstat puedes probar tú mismo y sacar tus propias conclusiones.

Llevamos un buen rato con numeritos en pantalla y quizás sea un buen momento para hacer una pausa y recapitular.

Por una parte, sabemos que TCP es un protocolo de trasporte seguro, orientado a conexión, que garantiza la integridad de la información transmitida. Los errores que puedan producirse son detectados y corregidos de modo transparente tanto para el usuario como para las propias aplicaciones que lo emplean. La única consecuencia sería un ligero incremente en la actividad de red en tanto que se retransmiten los paquetes dañados. Tendríamos que llegar a una situación de fallo generalizado realmente extremo, con una auténtica tormenta inacabable de errores, lo que por otra parte delataría algún problema realmente grave, para que la reproducción se interrumpiera. Recordemos además que existen espacios de memoria reservados en el reproductor (buffers) en los que se almacenan por adelantado varios segundos (o más) de la pista de audio en reproducción y que es desde donde esta se realiza realmente. Como muy acertadamente apuntaba un participante en el anteriormente mencionado hilo sobre cables ethernet en Audio Planet, basta con desconectar el cable para comprobar que la reproducción prosigue sin inmutarse durante unos segundos.

Hemos verificado además que servicios populares de audio por suscripción como Tidal o Spotify utilizan TCP. Del mismo modo, cualquier aplicación de reproducción que emplee SMB o NFS también se comunicará realmente mediante TCP. Por si fuera poco, este es asimismo el protocolo de transporte escogido en ecosistemas Squeezebox o MPD, lo que tiene un impacto directo en la popularidad global de este protocolo de transporte (TCP) puesto que un gran número de reproductores comerciales recurren a SMB, NFS o a soluciones basadas en MPD o Squeezebox.

Por otro lado tenemos a UPnP, otro conjunto de protocolos indudablemente muy utilizado en sistemas AV. Hemos verificado que, al contrario de lo que a menudo se afirma, no siempre funciona sobre TCP. Las generalizaciones son arriesgadas.

Ahora bien, olvida todo lo anterior.

Supongamos que todos los dispositivos y reproductores de nuestra red local utilizaran un protocolo de transporte no seguro como es UDP. ¿Tendría esto algún impacto en la fiabilidad de las transmisiones? En definitiva...

¿Tendría sentido la sustitución de los cables ethernet habituales por otros de supuestamente mayor calidad y prestaciones por lo que hace exclusivamente a la consecución de una transmisión libre de errores?

Vamos a tratar de dilucidarlo con otro sencillo experimento. Si aún estás ahí... llegamos al meollo del asunto.

Netstat y los errores de transmisión

Pero descendamos varios peldaños por la escalera de la arquitectura TCP/IP hasta los niveles más bajos para responder a la segunda pregunta que nos hacíamos unos cuantos párrafos más arriba, donde reconocíamos que ethernet no garantiza la transmisión libre de errores.

La cuestión es ¿realmente son estos errores de transmisión tan numerosos como para representar un peligro para la integridad del audio digital (y nuestra tranquilidad audiófila)? ¿Podemos cuantificarlos?

La respuesta es afirmativa. El comando netstat también es capaz de facilitarnos información acerca de los paquetes ethernet en los que se ha detectado algún tipo de error, con independencia de que un mecanismo de nivel superior los corrija posteriomente (TCP) o no (UDP). Es decir, lo que obtendremos será algo así como la tasa de error en bruto, lo que indudablemente representa una métrica relevante de la fiabilidad del conjunto de dispositivos ethernet involucrados.

Por tanto, he registrado las estadísticas del adaptador de red que proporciona el sistema operativo en mi PC de pruebas en un momento determinado y me he sometido a una dura e intensa sesión de escucha continua de más de 5 horas. Durante ese tiempo he seguido trabajando con el ordenador, escribiendo este artículo en Blogger, diseñando los diagramas que lo acompañan, navegando en Internet.... lo normal. Además, dado que este pequeño experimento se ha desarrollado a lo largo de la tarde de un día festivo, la red local doméstica ha estado echado humo durante todo el tiempo: Netflix, videojuegos en red, vídeos de Youtube... red que, para acabar de situarnos, cuenta además con varios dispositivos PLC conectados en diversas habitaciones; sí de esos que al parecer inducen tantas y tan perversas perturbaciones.

Una entretenida tarde festiva de diciembre...

...con el equipo activo mientras suena buena música de fondo.

Por si fuera poco, he tenido que zarandear e incluso retorcer el cable ethernet del PC para poder tomar las fotos del apartado anterior. Sin contemplaciones.

El menú musical ha estado compuesto por:

Air, de esta estupenda banda española, gran descubrimiento reciente para mi, llamada Morgan. 41 minutos de gloria bendita reproducidos desde Tidal con Chrome (cómo me recuerdan en más de un momento a Morcheeba). Cálidos e intensos como ellos solos.

https://tidal.com/album/84653811

El Live in Concert de Natalie Merchant (54:28), una pasada de directo con temas increíbles como una inesperada versión del Space Oddity de David Bowie o auténticos torpedos emocionales como son Beloved Wife o Seven Years. Versiones FLAC que residen en una carpeta compartida vía SMB de un NAS doméstico cuyo cable de red no es en absoluto mejor que el mostrado más arriba, reproducidas por JRiver Media Center.

https://tidal.com/album/1826938

Y finalmente, la BSO completa de NieR Automata, un maravilloso videojuego con una ambientación musical más que notable. Casi 4 horas de nada. También archivos en formato FLAC almacenados en el mismo NAS, retransmitidos en esta ocasión por una instancia de Logitech Media Server corriendo en el mismo dispositivo, hacia un cliente Squeezelite en el PC desde el que escribo ahora mismo.

Este no lo tienen en Tidal ni Spotify.

Veamos las estadísticas del adaptador de red en el estado inicial (sigo en Linux):

pablo@menos:~$ netstat -i

Tabla de la interfaz del núcleo
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
enp30s0 1500 8644154 0 0 0 1464408 0 0 0 BMRU
lo 65536 49406 0 0 0 49406 0 0 0 LRU

En Windows conseguiríamos algo parecido con:

X:\>netstat -e

Y ahora echémosle un vistazo a las correspondientes al estado final, tras más de 5 horas de reproducción.

pablo@menos:~$ netstat -i

Tabla de la interfaz del núcleo
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
enp30s0 1500 11308260 0 0 0 2006796 0 0 0 BMRU
lo 65536 57204 0 0 0 57204 0 0 0 LRU

El número de errores detectados en la transmisión (TX) y recepción (RX) de los más de 3 millones de tramas ethernet que han ido y venido por la red durante casi 6 horas ha sido...

CERO

Complicados cálculos ;-) que arrojan una tasa de error del 0%.

Hasta aquí el experimento y los resultados, absolutamente objetivos. Ahora, mi opinión.

Balance y conclusiones

A lo largo de este artículo he pretendido analizar con la mayor objetividad posible las razones por las que un cable ethernet podría tener algún tipo de impacto sobre la calidad percibida en reproducción en un sistema de audio.

A continuación, me he centrado en tratar de valorar los problemas que pudieran derivarse de la pérdida o corrupción de la información en transito dentro de la red. Eso me ha llevado a describir, brevemente, con muchas simplificaciones y alguna que otra inexactitud, el funcionamiento de la pila de protocolos de Internet y su relación con los dispositivos de reproducción de sonido en red.

Finalmente, he mostrado los resultados de un sencillo experimento fácilmente reproducible por cualquier aficionado en su propia instalación doméstica para tratar de cuantificar la tasa de errores, que en mis pruebas ha sido del 0% durante un periodo de tiempo de casi 6 horas. Esto implica que ninguno de los 3,2 millones de paquetes que en ese tiempo han circulado por mi red local ha tenido que ser retransmitidos.

En este contexto, mi opinión es que ningún cable ethernet, por audiófilo que sea, va a suponer mejora alguna sobre los que utilizo habitualmente por lo que hace estrictamente a la integridad de la información transmitida, ni tampoco va a mejorar el ancho de banda neto de mi red puesto que ahora mismo ya alcanza prácticamente el 90% del teórico (1 Gbps), según mis propias mediciones, y no se están produciendo retransmisiones que un hipotético cableado de mayor ¿calidad? pudiera evitar.

Evidentemente esto es solo una prueba realizada en una única instalación. Bueno, realmente en dos dado que he reproducido el experimento en la red de mi centro de trabajo, con idénticos resultados. Por tanto, aunque es obvio que no se puede concluir, estrictamente hablando, generalización alguna de estas pruebas, no alcanzo a ver absolutamente ninguna evidencia que apunte a otras conclusiones distintas a las indicadas en el párrafo anterior cuando se utilizan cables ethernet convencionales, en buen estado, que cumplan las especificaciones para las que han sido diseñados.

No obstante, dejo la puerta abierta a la influencia de las posibles interferencias electromagnéticas que pudieran introducirse en el sistema a través del propio cableado ethernet y quizás otros elementos asociados a él, factor que no tengo forma de analizar. Pero solo reconozco su posible impacto en la medida en que podrían inducir perturbaciones sobre los circuitos electrónicos de los dispositivos de reproducción, especialmente en relojes y en los más cercanos a las etapas de salida. No creo que en un sistema cuya operación se mantenga dentro de unos parámetros más o menos normales de funcionamiento puedan en ningún caso afectar a la integridad del flujo de datos digital transmitido.

Mi opinión personal es que el efecto de dichas perturbaciones, si es que existe, debería ser insignificante en un sistema bien diseñado, y absolutamente improbable en el caso de cableado asociado a dispositivos tales como sistemas de almacenamiento en red, que no actúan como reproductores directos. Pero esto es eso, opinión.

¿Quiere esto decir por tanto que un cable ethernet de los denominados "audiófilos" es puro placebo? No puedo afirmarlo con total seguridad, pero mi estado mental actual me dice que sí a un 95%. Es decir, que no pondría siempre la mano en el fuego. Pero un dedo sí. Bueno, dos o tres también.

Como ves he cumplido mi palabra y no me he puesto de perfil en este asunto.

A partir de aquí, cada cual puede escuchar lo que le venga en gana y convertir su afición a la música y los cacharros que la reproducen en su cielo o infierno particular. Pero por favor, seamos todos un poco más rigurosos a la hora de utilizar argumentos para justificar opiniones y creencias en foros de aquí y de allá. En ocasiones esto se hace con una ligereza sonrojante. Todos, y me incluyo sin falsa modestia, deberíamos ser más conscientes de nuestras limitaciones. Y también de los contextos, propios y ajenos.

Para terminar, solo decir que si algún lector, tienda, distribuidor o lo que sea quiere enviarme (con billete de vuelta ineludible) uno de esos fantásticos cables ethernet con superpoderes estaré encantado de repetir estas pruebas y contar aquí los resultados, aunque contradigan ferozmente mis conclusiones y convicciones actuales.

¡Salud y buena música para todos!

nVida Shield TV: impresiones de uso

noreply@blogger.com (Pablo Felip) — Tue, 07 Aug 2018 23:40:00 +0000

Ya casi no recordaba la sensación de hacer clic en el botón de Entrada nueva en este espacio. El tiempo que dedico a escribir sobre cosas #EDTECH es cada vez mayor y el que resta se ve proporcional y progresivamente reducido. Pero no sería justo responsabilizar exclusivamente a esta circunstancia de la falta de actividad en este blog. Echando la vista atrás y revisando los contenidos que dieron vida a este espacio allá por el otoño de 2007 y leyendo entradas como esta me doy cuenta de cómo el tiempo y las circunstancias modulan los intereses y, en definitiva, a personas y replicantes por igual.

La historia de este blog es, en gran medida, mi historia en Audio Planet, una comunidad de locos por la música y por los equipos que la reproducen, historia que comenzó en junio de 2010 cuando descubrí maravillado lo que allí se contaba. Y esa historia alcanzó un punto de inflexión (interior) en mayo de 2017, precisamente con aquel artículo en el que trataba de comparar de manera minuciosa Volumio con piCorePlayer, publicado tanto aquí como allí. Por el camino se han quedado miles de mensajes en Audio Planet y docenas de pruebas y publicaciones elaboradas robándole horas al sueño, a la familia y a mi vida, en general. Y siempre con un denominador común: la pasión por experimentar en un campo que me fascinaba. Y que probablemente aún me fascina, querría pensar.

Junio de 2010, ocho años de mi vida...

Desde entonces mi interés por las tecnologías digitales para la reproducción audiovisual ha menguado sensiblemente. Estoy ciertamente apático. Ya no me entusiasman determinadas cosas como solían hacerlo y, tengo que decirlo, esta desafección reciente se origina en el simple y llano aburrimiento, en la falta de emoción, en la ausencia de productos o tecnologías realmente novedosas.

Los resultados que actualmente se pueden conseguir utilizando reproductores basados en sistemas-en-un-chip (Raspberry Pi, Odroid y similares) dotados de placas de conversión D/A montadas sobre sus buses I2S o asociados a sencillos DACs USB y pilotados por desarrollos gratuitos como Volumio o piCorePlayer son simplemente espectaculares. Añade a la ecuación un par de monitores activos y ahí tienes un sistema de reproducción musical de una calidad y funcionalidades que hubieran sido ciencia ficción hace cuántos ¿10 años? Y a un coste ridículo. ¿Realmente tiene sentido complicarse más la vida? Para mi yo actual, definitivamente no.

El audio digital de alta calidad, democratizado, en cuatro instantáneas ligeramente audiopornográficas.

Por ahí dicen que el que afirma estar de vuelta de todo realmente no ha ido a ninguna parte. Posiblemente sea este mi caso, pero desde que el esoterismo audiófilo conquistó lo digital, al menos en ciertos ámbitos, trasladando, actualizando y perpetuando, cuando no inventando, prácticas, creencias y metodologías que no comparto en absoluto, tengo la sensación de que no hay nada nuevo bajo el sol. Y seguramente esté equivocado, pero esta es mi convicción actual, con la que no tengo más remedio que tratar de ser consecuente.

Pero como dice la canción, en ocasiones surgen cosas que te rescatan del naufragio y reavivan la necesidad de escribir sobre tal o cual dispositivo. Hace un par de semanas me he encontrado con una de ellas. Algo que ha (casi) enviado al banquillo de un plumazo a tres de mis artilugios de reproducción de pelis, series y música: Squeezebox Touch, Odroid C2 (con LibreELEC) y Amazon Fire TV Stick Basic. Ahí es nada.

De izquierda a derecha. Odroid C2, Squeezebox Touch y Amazon Fire TV Basic.

Hablemos pues de nVidia Shield TV.

¿Qué es nVidia Shield TV?

Shield TV es un streamer basado en Android TV. No se trata de ninguna novedad, de hecho lleva en el mercado desde el 2015 y el año pasado (2017) su hardware recibió un lavado de cara, aunque manteniendo intactas sus características técnicas definitorias. Y a pesar de sus años sigue siendo una de los cacharros más económicos (en torno a 200€), potentes y polivalentes que podemos adquirir como centro de ocio digital.

En estas cajas tan molonas llega Shield TV.

Pero no es mi intención hacer una descripción detallada del dispositivo. Si quieres conocer en detalle sus características te remito a estos dos excelentes análisis, el de la versión inicial (en Kodimania) y el correspondiente a la posterior revisión del hardware (esta vez en Salón Digital). Ambos son muy exhaustivos y tienen cierto contenido técnico. Si prefieres algo más sencillito puedes leer el que publicaron en Xataka referido a la versión más reciente.

nVidia Shield TV: mi experiencia de uso

Y este es el objetivo del artículo. Resumir y comentar mi experiencia de uso con Shield TV en las apenas 2 semanas que lo tengo en casa. Y comenzaré por el final, diciendo que, en una palabra, es magnífica.

Las primeras impresiones del hardware del aparato son excelentes, al menos en la versión de la que dispongo, la que se lanzó en 2015 en su variante de 16 GB de almacenamiento. Sorprende su tamaño (que alcanza lo ridículo en el caso del hw 2017), aunque el peso delata que dentro hay un buen montón de tecnología en un formato extremadamente compacto. El potente SoC Tegra X1, muy similar al de la Nintendo Switch, junto a los 3 GB de RAM hace que la interfaz de usuario vuele (literalmente) y se despliegue en pantalla con absoluta suavidad (60 Hz), ofreciendo una respuesta inmediata. Acostumbrado a otros dispositivos de similar pelaje como el Amazon Fire TV Stick, también basado en Android pero con el habitual "barniz" casposillo que Amazon aplica a sus productos, la diferencia es evidente de modo inmediato.

Interfaz de control de Shield TV. Sí, admite control y búsquedas por voz mediante Google Assistant.

Además, el dispositivo demuestra una ejemplar trayectoria de actualizaciones continuadas desde su fecha de lanzamiento. De hecho, recientemente ha recibido la versión de Oreo para dispositivos Android TV. Es patente el interés por parte de su fabricante, nVidia, por corregir problemas detectados y añadir nuevas funcionalidades a través de estas actualizaciones, que se han ido produciendo de modo regular a lo largo del ciclo de vida del producto. No resulta infrecuente encontrarse con cacharros que montan unas tripas estelares comandados por un software de mala calidad que conduce a una experiencia de uso deficiente o directamente nefasta. En estos tiempos digitales el software manda tanto o más que el hardware.

Pero vamos por partes. Mi meta con Shield TV era unificar en un único reproductor, sencillo de manejar y apto para un salón familiar, varias prestaciones y funciones. Hablemos de ellas.

Objetivo 1: Servicios de retransmisión de audio y vídeo

Tidal, Spotify, Deezer, Radio Paradise, Amazon Music, Amazon Prime Video, YouTube.... Todos ellos, y muchos otros, están disponibles mediante apps nativas, adaptadas de un modo excelente al contexto de un salón (tele / mando a distancia). Además, pueden descargarse con facilidad de la tienda de aplicaciones de Google directamente en el dispositivo o encargar su instalación cómodamente desde un navegador de escritorio.

Instalando una app en Shield TV desde el navegador de un PC.

Si Amazon nos castiga con una espantosa tienda de apps en sus propios dispositivos, inexplicablemente desprovista de algo tan elemental como un buscador y con una organización de contenidos que en ocasiones es aparentemente incomprensible, aquí disfrutaremos de una experiencia similar a la de cualquier artilugio Android mondo y lirondo. Adicionalmente, Shield TV trae de serie los Google Services instalados, lo que facilita la carga de aplicaciones externas a la tienda por medio de su APK correspondiente y un sencillo explorador de archivos. Shield TV cuenta también con puertos USB a los que conectar dispositivos de almacenamiento (y otros periféricos, por supuesto) y también ranura para tarjetas SD (modelo de 2015 únicamente). Todo facilito.

Tienda de aplicaciones de Google para Android TV.

A diferencia de otros reproductores basados en Android, Shield TV es un dispositivo certificado por Netflix y por tanto admite la reproducción de vídeo a 1080p y 4K en HDR y audio en Dolby Digital Plus (similar a AC3 pero con una tasa de bits superior y soporte para más canales). nVidia ha pasado por caja cuando ha sido necesario para asegurarse de que esto sea así. La calidad en reproducción es excelente, siendo habitual que se alcancen tasas de más de 6 Mbps, cercanas al límite del servicio a 1080p.

Detalle de la tasa de bits de una emisión 1080p de Netflix (capítulo final de Sense8)...

...y audio en Dolby Digital Plus emitido en crudo hacia el receptor a través de HDMI.

Nota para nostálgicos: Resulta sorprendente comprobar cómo han evolucionado los codecs de vídeo en unos pocos años, ahora cobijamos en un flujo digital de 3-6 Mbps una señal 1080p con audio multicanal que se ve infinitamente mejor que el vídeo a 5-10 Mbps codificado mediante MPEG2 en los vetustos DVD. Cualquier tiempo pasado no siempre fue mejor.

El manejo del dispositivo puede lograrse utilizando tanto los mandos suministrados, de control o de juegos, como el de la televisión, puesto que Shield TV soporta el estándar de interoperabilidad HDMI CEC. Con mi equipo el comportamiento es ejemplar, las secuencias de encendido / apagado / cambio de fuente / control de volumen de televisor y receptor multicanal funcionan correctamente, aunque esto es casi casi una lotería que depende mucho de lo bien que se entiendan entre sí los cacharros interconectados. Por ejemplo, mi Amazon Fire TV Stick, conectado a un puerto HDMI del receptor multicanal (Pioneer SC-LX81), se queda "dormido" y no puede ser activado ni "despertar" al resto de dispositivos a través de CEC pasado un tiempo sin ser usado, rompiendo en la práctica la magia de un control unificado con un solo mando.

Mando de control estándar (versión 2015). De aluminio, recargable, con superficie táctil de control y micrófono incorporado.

Por cierto, el mando de control de Shield TV (de aluminio en su versión 2015, muy premium y con poco que envidiar al de un AppleTV) incorpora en su mitad inferior una discreta superficie táctil de control, que fácilmente puede pasar inadvertida, para modificar el volumen e iniciar / pausar la reproducción. El ajuste puede configurarse para que este control actúe sobre el volumen interno (en software) o sobre el del dispositivo externo conectado (receptor en mi caso).

Ah, y aplicaciones más borderline, como Stremio, también funcionan perfectamente. Una gozada.

Ojeando gustosamente series en Stremio.

Por si todo lo dicho no fuera suficiente, resulta que Shield TV es también un dispositivo Chromecast. Pero no una de esas variantes descafeinadas basadas en Miracast y similares. Se trata de un Chromecast Ultra (4K) de tomo y lomo que se anuncia y aparece como tal ante otros dispositivos (ordenadores, móviles, tabletas) en la red local.

nVida Shield TV en su faceta de Chromecast: enviando audio desde Tidal en Chrome.

nVida Shield TV visto desde la app Google Home.

Es posible emitir hacia él audio y vídeo directamente desde determinadas aplicaciones compatibles o el navegador (Chrome) o simplemente clonar totalmente la pantalla del dispositivo emisor.

También podemos no obstante instalar aplicaciones freemium como AirScreen, que en su versión gratuíta constituye un eficaz receptor AirPlay a pantalla completa para i-cosas.

Lástima que, como en todos los dispositivos móviles, la app de Tidal no emita en calidad Master. Aunque bien pensado, a estas alturas casi que me da igual.

Amazon Fire TV Stick sustituido. Vamos a por lo siguiente.

Objetivo 2: Reproductor de medios locales: VÍDEO

Shield TV es un dispositivo diseñado para consumir audio y vídeo en servicios bajo demanda, lo que se lleva ahora. Y hacerlo con mucha clase. Pero eso no es ni la mitad de la ecuación. Sin tener que hacer piruetas podemos instalar VLC y Kodi. Y, por si fuera poco, Shield TV trae preinstalado tanto un cliente como un servidor Plex, con potencia de sobra para transcodificar audio y vídeo al vuelo sin problemas.

Kodi corriendo sobre Shield TV en todo su esplendor (la piel utilizada es Eminence).

Con ellos podemos reproducir prácticamente cualquier archivo de vídeo que habite en nuestra red local, por ejemplo en una carpeta compartida en un NAS. De hecho, en el panel de ajustes de Shield TV existe una sección destinada a explorar y montar sobre el sistema de archivos local, de modo permanente, recursos en nuestra red doméstica. No es necesario ni con Kodi ni con VLC, que son capaces por sí mismos de explorar la red, pero da una idea de la orientación del dispositivo, que abre el acceso a los recursos en red local a cualquier app instalada localmente. Muy bien.

Explorando y montando dispositivos de almacenamiento en la red local.

Sin quitarle el mérito a VLC ni a Plex, para mi el paradigma de reproductor de medios local no es otro que Kodi. De hecho, ha venido siendo mi reproductor de vídeo de cabecera en el equipo del salón desde mayo de 2013 a lo largo de varias generaciones de Raspberries (inicialmente usando Raspbmc y posteriormente su sucesor espiritual, OSMC) y, hará cosa de un año, con LibreELEC corriendo en una fantástica Odroid C2.

Kodi en Shield TV funciona mejor que bien. ¿Decodificación hardware de HEVC de 10 bits (H.265), VP9 y 4K con HDR via HDMI 2.0b? Sí. ¿Cambio automático de frecuencia de refresco con soporte de 23,976 y 24 Hz? Por supuesto. ¿Passthrough de AC3, DTS, TrueHD y DTS-HD hacia el receptor multicanal? También. ¿Complementos instalables? Sin dudarlo. ¿PCM multicanal hasta 192/24? Concedido. ¿Capacidad para ejecutar pieles pesadas? Potencia de sobra. Y toda la compatibilidad de formatos que Kodi proporciona, incluyendo contenedores ISO, DFF/DSF (incluso con remuestreo en alta calidad), etc. etc. nVidia se ha asegurado de que este reproductor corra en su creación a las mil maravillas. Otro minipunto.

Emisión de audio en crudo a tutiplén en Kodi.

De Plex no diré nada dado que no lo he utilizado de un modo extensivo, pero por lo que he leído su funcionamiento es bueno. Con respecto a VLC, más de lo mismo, se trata en este caso de una alternativa ideal si no queremos líos configurando bibliotecas y tal y, en mi experiencia, funciona correctamente.

Y ya tenemos también sustituto para LibreELEC en la Odroid C2.

Objetivo 3: Reproductor de medios locales: AUDIO

¿Y qué tal como reproductor de audio? Bueno, Kodi cataloga y gestiona extensas bibliotecas de archivos de audio sin mayor problema, para muchos eso será más que suficiente.

Personalmente llevo utilizando en casa un ecosistema Squeezebox desde hace un montón de años y me siento muy cómodo con él. Es extremadamente flexible y potente, admite la integración de casi cualquier servicio y dispositivo de reproducción y dispone de una de las mejores apps de control (iPeng). ¿Puede dar cobijo también a Shield TV este entorno? Pues resulta que sí, y casi de modo inmediato, gracias a su papel Chromecast. Solo tenemos que instalar en el servidor de medios de Logitech (LMS), el complemento Chromecast bridge. Shield TV aparecerá como un Squeezebox más, con capacidad de reproducir audio de modo nativo a 96/24. Los archivos codificados a resoluciones superiores serán remuestreados automáticamente por el servidor LMS, como es habitual en este sistema.

Panel de configuración de Chromecast bridge para LMS.

Un reproductor Squeezebox más en la familia, aquí tirando audio a 192/24 (remuestreado a 96 Khz).

iPeng en acción controlando a nuestro Shield TV disfrazado de Squeezebox.

En este caso, no obstante, y como consecuencia de este doble salto mortal hacia atrás para conseguir que Shield TV se lleve bien con LMS, surge alguna que otra limitación. La reproducción continua (sin pausas entre temas) no funciona por el momento. Ni tampoco las pistas en AC3 o DTS. Como hemos visto, Shield TV no tiene mayor problema en hacer passthrough de estas cosas, pero en su faceta Chromecast solo lo admite cuando se usan apps como la de Netflix. Nos topamos por tanto con una de esas malditas limitaciones impuestas por el software.

Bueno, siempre podemos recurrir a Kodi como reproductor universal, que no está nada mal, y en el que los contratiempos descritos más arriba desaparecen, o quizás explorar la posibilidad de instalar en Shield TV alguno de los desarrollos basados en Squeezeplay disponibles.

De un modo u otro, en este caso no me atrevo por tanto a afirmar que Shield TV sea una alternativa perfecta a un reproductor de tipo Squeezebox, pero si no se tienen muchas manías está cerca, muy cerca.

Otras funciones

Y podríamos seguir hablando de características apetitosas que nos ofrece Shield TV, por ejemplo la extensiva compatibilidad con dispositivos bluetooth, pero no solo teclados y ratones, sino también auriculares, altavoces o barras de sonido. De hecho existe un ajuste para compensar el posible desfase entre audio y vídeo, caso de que se produzca, en su panel de control.

Ajuste de sincronización audio / vídeo, importante cuando se emplea un dispositivo de audio externo.

Otra característica destacable es la compatibilidad con DACs USB, para los que Shield TV dispone de un modo de emisión de audio de alta calidad, sin remuestreo forzado.

Modos de audio USB.

Por otro lado, el controlador cuenta con un micrófono desde el que enviar órdenes al Asistente de voz de Google para abrir aplicaciones, realizar búsquedas, etc. En los nuevos mandos de juegos (versión 2017), este micrófono está en modo de escucha permanente, por lo que esencialmente tenemos un Google Home... con aspecto un tanto extraño, eso sí.

Y todo eso sin hablar de GeForce Now, la plataforma de videojuegos en streaming de nVidia, que permite jugar del mismo modo que consumimos audio en Spotify o vídeo en Netflix utilizando la potencia de procesamiento de los servidores en la nube de la compañía, algo que funciona sorprendentemente bien y que en mi opinión es el futuro al que nos dirigimos por lo que hace al consumo de videojuegos.

Como puedes ver, Shield TV es una auténtica navaja suiza del streaming. Y ni siquiera hemos hablado de sus capacidades emulando recreativas y consolas antiguas. La perfección no existe, pero en mi opinión su enorme colección de virtudes, su comedido precio y el que hasta el momento ha sido un excelente soporte convierten a este atractivo cachivache en un dispositivo a tener muy en cuenta como centro neurálgico de entretenimiento digital en el salón.

En cuestiones audiófilas no entramos, claro está.

¿Tienes un Mac defenestrado por Apple? Instala Linux

noreply@blogger.com (Pablo Felip) — Sat, 09 Dec 2017 01:32:00 +0000

Es indudable que en Nueva York hay muchas cosas que hacer. Cruzar andando el puente de Brooklyn al atardecer para terminar admirando el esplendido skyline nocturno desde uno de los miradores al otro lado del East River. Soportar estoicamente las interminables colas a la entrada de una misa Góspel junto al Malcom X Boulevard. Ponerse tibio a hamburguesas en el Jackson's Hole o a pasta en cualquier garito de la calle Mulberry, peregrinar más tarde a la fuente de chocolate en The View y acabar tomando unas cervezas en el Birdland. Y, por supuesto, admirar la Estatua de Libertad desde el ferry a Staten Island o la propia magnificencia de la ciudad desde las alturas del Empire State Building

Y por allí estuve yo en agosto de 2007 acompañado de unos amigos y de la que hoy es mi mujer. Pero además de todas esas cosas (y alguna que otra más), uno de mis objetivos era traerme bajo el brazo (literalmente) un Macbook de aquellos de policarbonato blanco, aprovechándome del favorable cambio dolar - euro del momento y de que los simpáticos dependientes de la Apple Store de la 5ª avenida no debieran ponerme pega alguna cuando les pidiera que me sustituyeran el teclado (americano) de serie por uno español. Y desde luego que no lo hicieron a pesar de que recibieron el encargo a horas intempestivas.

Aunque no se ven, las caras de mis acompañantes eran de notorio alivio tras recoger la bolsita de marras pasada la 1 AM.

Aquel esbelto Macbook (modelo 2,1) montaba un procesador Intel Core2Duo T7400 a 2Ghz y pico, 2 gigas de RAM DDR2 a 667 Mhz y un disco duro SATA de 120GB. En aquel momento, un cañón que literalmente volaba con el Mac OS X v10.4 que traía preinstalado. Casi inmediatamente le amplié la memoria a 4GB (aunque por limitaciones del hardware no era aprovechable en su totalidad) y algún tiempo después sustituí su disco duro por un rápido SSD de la misma capacidad.

A lo largo de más de 10 años el portátil ha mantenido el tipo de un modo ejemplar, sin ningún fallo o avería, en su papel como equipo auxiliar en casa para uso general (ofimática, Internet... lo habitual). Incluso la batería ha degenerado graciosamente y en estos momentos aguanta fácilmente lejos del enchufe un tiempo sorprendentemente prolongado teniendo en cuenta su avanzada edad.

Pero la obsolescencia programada hizo, cómo no, acto de presencia en el momento en que ya no fue posible ir más allá de OS X v10.7 (Lion). La actualización de Mountain Lion, lanzada en verano de 2012 ya pasó de largo, y con ella todas las sucesivas: Mavericks, Yosemite, El Capitan, Sierra, High Sierra... Con este impedimento comenzaron a descolgarse también las versiones más recientes de numerosas aplicaciones, incluyendo las de navegadores como Firefox y, especialmente, Google Chrome. Malo.

El hardware de mi MacBook puede correr perfectamente Chrome 63 o Firefox 57 ¿Dónde está entonces el problema? El problema está en que los fabricantes, seguramente apoyados por el Club Bilderberg, la CIA y hasta Industrias Stark, quieren que compremos regularmente equipos nuevos, y si el hardware no se estropea por si mismo será cosa de ir inutilizándolo poquito a poco. Sí, ya lo sé. Me diréis que diez años son muchos años. Pero si el equipo funciona ¿por qué cambiarlo?

Pero basta de consparanoias alocadas y vamos a por soluciones.

El caso es que hace unas semanas y ante la imposibilidad de que mi mujer pudiera utilizar este portátil para seguir un curso online en la Escuela Oficial de Idiomas de mi ciudad (culpad a Google Meet), tuve que pensar en alternativas para prolongar su vida útil.

Mi primer impulso fue convertirlo en un Chromebook, uno de esos portátiles que corren Chrome OS. Se trata de un sistema operativo con núcleo Linux que utiliza Chrome como interfaz de usuario y ejecuta básicamente aplicaciones web dentro del navegador. Al tratarse de algo muy específico el rendimiento suele ser bueno incluso corriendo sobre hardware poco potente. Recientemente han aparecido modelos capaces de utilizar aplicaciones Android e incluso Windows (bajo emulación), pero más vale que asumamos el condicionante inicial a la hora de decidir si una Chrome-cosa nos hace el apaño o no.

Los dispositivos Chromebook, digamos, originales están supervisados por la propia Google, pero dado que Chrome OS hunde sus raíces en el proyecto Chromium OS, que es libre, existen versiones que se pueden tratar de instalar, si el hardware está soportado, en cualquier ordenador. Hay varias alternativas para ello. En mi opinión la que mejor funciona es CloudReady. Se trata de un producto comercial desarrollado por Neverware que dispone de una versión gratuita para uso personal, versiones específicas para Mac y una excelente documentación para echarnos un cable con la instalación.

En el caso de mi modelo específico de MacBook lamentablemente hay alguna que otra limitación:

Solo se puede instalar la versión de 32 bits. Inicialmente lo intenté con la de 64, pero aunque arrancaba desde el pendrive posteriormente la instalación en el disco duro del portátil fallaba. Tampoco es que sea un problema.
La entrada de micrófono parece que no funciona.
La cámara web tampoco (por una historia con los controladores propietarios de Apple).

Peculiaridades de CloudReady en mi MacBook (fuente: Neverware).

Más sobre estas limitaciones aquí. Ante ellas, y siendo que uno de los usos que se le iba a dar al portátil pretendía ser precisamente el de mantener videoconferencias dentro del navegador, la cosa no parecía pintar bien. Además, las características de gestión remota de los Chromebooks los convierten en maná caído del cielo para los administradores TIC de instituciones educativas que utilicen G Suite y tengan que vérselas con decenas o centenares de dispositivos, pero personalmente sigue sin convencerme eso de verme confinado a un navegador.

Alabemos pues la disonancia cognitiva y pasemos a otra cosa.

La siguiente opción en mi lista era, claro, alguna distribución de Linux. Y aquí nos encontramos con que, al menos en el caso de mi MacBook, la cosa no es tan sencilla. El problema se manifiesta al tratar de arrancar con el CD/DVD o pendrive de una distribución de 64 bits. Aunque en principio el portátil soporta sistemas operativos de 64 bits, la interfaz EFI, a través de la cual el sistema se inicia, es de 32. Matt Gadient explica los motivos en su blog, describe cómo parchear las ISO x64 de varias distros populares para que arranquen y, por si fuera poco, ofrece unas cuantas ya modificadas.

El primer intento fue con Korora (x64), que tenía muchas ganas de probar, a través de su CD live (por cierto, qué chulo Gnome 3). Constatando que aún usando una distro de 64 bits en ningún caso era posible disponer de la totalidad de los 4GB de RAM instalados en el equipo, finalmente opté por algo más conservador en la forma de Xubuntu 16.04 LTS en su versión de 32 bits, que he usado en más de una ocasión para revivir equipos con ya ciertos años.

Xubuntu 16.04 se instaló sin incidentes en unos pocos minutos en mi querido MacBook para mostrar finalmente en pantalla un entorno gráfico sencillo pero razonablemente cuidado y muy ágil. Tras eso solo tuve que hacer un par de ajustes para dejarlo todo funcionando correctamente.

Uno: Por un lado, los problemas con el mapa de teclado (no olvidemos que esto es Apple) se resuelven fácilmente con un pequeño archivo de configuración para xmodmap:

$HOME/.Xmodmap:
keycode 104 = ISO_Level3_Shift
keycode 169 = Delete
keycode 134 = Menu

Con estas líneas se consigue que:

La tecla ALT derecha se comporte como AltGr, dando acceso a ciertos símbolos del teclado (la inevitable @, por ejemplo).
La tecla de expulsión de la unidad óptica haga las veces de DEL.
Mazana derecha funcione como la tecla Menú.

Dos: Por otro lado, para hacer funcionar la cámara iSight del MacBook hay que instalar un driver propietario de Apple y un paquete de soporte. Las instrucciones aquí. Hay que echarle mano a determinado archivo presente en una instalación de OS X 10.4 o 10.5, aunque también se facilita en las propias instrucciones, supongo que de un modo no totalmente legal. Miraremos hacia otro lado.

El escritorio de Xubuntu en mi MacBook 2,1.

Ahora mi defenestrado MacBook ya está al día con las últimas versiones disponibles de Firefox y Chromium y es capaz, vía este último, de mantener estupendas videoconferencias web con Google Meet sin inmutarse.

Llamadme gruñón, pero con el tiempo me toca más y más las narices que fabricantes como Apple o Microsoft conviertan equipos perfectamente utilizables en caros pisapapeles con el mantra de introducir nuevas funciones (a menudo) de dudosa relevancia. Y profundizando en mis sesgos, creo que Apple se lleva la palma en este aspecto. Del mismo modo, cada vez aprecio más la existencia de proyectos en el mundo del software libre que tratan de proporcionar alternativas a esta carrera de ratas digital.

De cabras montesas, routers de apartamentos turísticos y Guifi.net

noreply@blogger.com (Pablo Felip) — Sun, 03 Sep 2017 22:06:00 +0000

Vilafranca del Cid es un pequeño pueblo (2500+ habitantes) situado en la montañosa y muy fría (en inverno) comarca del Alto Maestrazgo, al noroeste de la provincia de Castellón, y colindante ya con la de Teruel. Esta zona goza de atractivos tales como una excelente gastronomía, la sorprendente arquitectura de la Pedra en Sec o los escarpados barrancos y senderos por los que perderse mientras cabras montesas comedoras de moras contemplan al caminante con gesto estoico.

El caso es que, como podéis suponer, he tenido la suerte de pasar unos días de estupendo descanso estival con la familia en un acogedor apartamento turístico en esta localidad... pero no temáis, esta entrada no está dedicada a los encantos de los recónditos rincones del interior de Castellón, sino al choque cultural que puede sufrir un urbanita como yo cuando se encuentra con fuerzas oscuras que tratan de limitar su capacidad de conexión a Internet.

Pero antes de continuar con la historia conviene que hagamos un alto para hablar de Guifi.net. Es esta una red de telecomunicaciones abierta creada y gestionada por sus propios usuarios. Técnicamente se trata de una red descentralizada, en malla, que crece a medida que a ella se conectan nuevos nodos, generalmente de modo inalámbrico mediante enlaces establecidos por medio de antenas de diversos tipos. Podéis encontrar una cantidad ingente de información y orgásmicos detalles técnicos sobre su funcionamiento en la página web de este (admirable) proyecto.

Esta red cuenta con miles de nodos intensamente concentrados en Cataluña y el norte de la Comunidad Valenciana, donde se utiliza en muchos municipios del interior para proporcionar acceso rural a Internet a sus habitantes allí donde las operadoras comerciales no llegan o lo hacen con un acceso caro y/o de mala calidad.

Mapa de nodos de guifi.net (Fuente: Proyecto Guifi.net).

Y claro, Vilafranca tenía que ser uno de esos municipios (cierro paréntesis y prosigo con la narración)...

Cuando llegamos al pueblo ya nos esperaba el propietario del apartamento, que tras entregarnos las llaves de la vivienda y facilitarnos amablemente las oportunas indicaciones se despidió con un poco tranquilizador "la vivienda dispone de conexión a Internet a través de guifinet, la conocéis ¿verdad?". Por supuesto, (léase esto con cierta retranca) ¡quién no ha oído hablar de ella!

Una informativa tarjetita plastificada en el mueble del salón, en la que se podían leer las instrucciones de conexión a Internet a través de Guifi.net por medio de un servidor proxy con usuario / clave confirmó unos instantes después lo que ya apuntaba a auténtica tragedia.

En el reverso de la tarjeta se indican la IP y puerto del servidor proxy, así como el usuario y clave.

Para redondear la situación, la cobertura móvil dentro del apartamento era de las que te obliga a sacar medio cuerpo por la ventana y estirar el brazo peligrosamente mientras sostienes el terminal en la mano en inestable equilibrio para conseguir una barra de señal de pixel y medio.

Pero ¿tan terrible es esto de tener que utilizar un proxy? Veamos...

Los servidores proxy actúan como intermediarios entre los usuarios y los servicios y equipos remotos a los que se conectan en Internet. Esta modalidad de conexión a través de proxy se suele emplear por razones vinculadas a la seguridad y a la eficiencia. Los servidores proxy con frecuencia disponen de una caché en la que se van almacenando copias temporales de las páginas solicitadas por los usuarios, de modo que a menudo estas pueden ser servidas localmente cuando se producen accesos reiterados en un corto espacio de tiempo. Tremendamente populares hace unos años en entornos corporativos, su uso ha menguado en cierta medida como consecuencia de las características cada vez más dinámicas de los servicios web actuales.

Cuando se utiliza un servidor proxy hay que configurar el navegador (y por extensión cualquier otra aplicación que requiera de conexión a Internet) indicando explícitamente la dirección IP (típicamente) o el nombre del servidor que actúa como proxy, además del puerto TCP a través del cual se presta este servicio. Si además se trata de un servidor autenticado, como es nuestro caso, necesitaremos adicionalmente un usuario y clave.

Todo esto no sería más que una leve inconveniencia de no ser por qué resulta difícil en la actualidad encontrar aplicaciones distintas a navegadores o clientes de FTP que permitan la introducción de estos ajustes. Sí, lo habéis adivinado: nada de Netflix, Amazon Prime Video, Telegram, Whatsapp, Google Drive o Dropbox, Spotify y un interminable etcétera. En un terminal Android ni siquiera funciona la tienda de aplicaciones. De torrents (ni de cualquier cosa que requiera abrir puertos en el router) ni hablamos, claro. Por si fuera poco, los servidores proxy suelen aplicar un fuerte filtrado, de forma que es usual que tan solo se permitan las conexiones salientes hacia los puertos 80 y 443 (http y http seguro), así que nada de rarezas.

Francamente, no tenía la menor intención de hurgar en los recovecos técnicos de la conexión a Internet de mi residencia temporal, pero la perspectiva de pasarme varios días secuestrado detrás de un proxy vilanfranquino hizo que saliera de mi indolencia veraniega para curiosear un poquito desde el móvil.

Lo que me encontré fue... digamos que esperable.

De entrada nos topamos en el apartamento con una red wifi con seguridad ¡WEP! Cielo santo.

Que a estas alturas alguien configure la wifi de un dispositivo utilizando WEP, un protocolo totalmente inseguro, en lugar de WPA2, es algo que simplemente me resulta incomprensible y solo puedo atribuir a un descuido. Pero sigamos porque la cosa promete.

Tras conectarnos a la red inalámbrica del apartamento, el icono correspondiente a la conexión wifi en la barra superior muestra un aspa [x], lo que indica que no se ha detectado una conexión a Internet operativa en esta red. Esto es así porque para salir a Internet precisamos del proxy de Guifi.net del que hablábamos más arriba, por tanto la conexión habitual (directa) no funciona. Por no funcionar no lo hace ni siquiera la resolución de nombres a través de DNS. Estupendo.

Bien, veamos ahora qué dirección IP ha obtenido nuestro terminal.

Lo esperable, la típica IP de clase C privada. Vamos a ver qué pasa si nos vamos a un navegador y tratamos de conectarnos a 192.168.2.1.

Estupendo, estamos en la antesala del panel de administración del router de la casa. Probemos el clásico admin / admin...

...y hasta la cocina. Como decía alguien, no hay término en élfico, lengua Ent o de los Hombres, para describir este horror... Pues eso mismo digo yo ahora, aunque no me llame Barbol, al ver este desolador panorama.

Ahora tenemos acceso total al router que, dicho sea de paso, proporciona acceso a Internet a varias viviendas situadas en el mismo establecimiento. Podríamos modificar la configuración del servidor DHCP, establecer otras puertas de enlace o servidores de nombres y, por supuesto, inutilizar el servicio para cualquier usuario... excepto para nosotros mismos, claro. Del mismo modo, conociendo marca, modelo e incluso la revisión del firmware del router se podría pensar en otras fechorías más sofisticadas que simplemente no vienen al caso ahora.

Me temo que lo de utilizar WEP no era un descuido sino simplemente negligencia o ignorancia por lo que hace a las mínimas medidas de seguridad exigibles en un punto de conexión a Internet privado.

Llegados a este punto podríamos (a) conformarnos con lo que hay y configurar dócilmente el proxy de Guifi.net en todos nuestros dispositivos, asumiendo las drásticas limitaciones que ello supone, o (b) buscar alternativas.

Si optamos por lo primero, deberemos modificar los ajustes de la red wifi en nuestro terminal Android. Como véis queda muy clarito que solo tenemos garantías de que lo utilicen los navegadores instalados (ese no pueden usarlo en la captura de pantalla yo diría que es más bien un pueden no usarlo, como consecuencia de una mala traducción del inglés).

Configuración del servidor proxy en el administrador de redes wifi de Android

También podemos proceder de modo análogo en nuestro navegador de escritorio favorito, por ejemplo Firefox.

Configuración del servidor proxy en Firefox.

Al tratar de acceder a cualquier página web tras establecer estos ajustes comprobaremos que aparecerá una ventana de autenticación en la que el servidor proxy de Guifi.net nos solicitará la introducción del usuario y clave autorizados que, recordemos, venían anotados ambos dos en la tarjeta plastificada. Esta solicitud de credenciales aparecerá además probablemente de modo reiterado durante una sesión de navegación, consiguiendo así que nuestro odio hacia ella crezca con cada nueva petición.

¿Y cuál es el plan (b)? ¿Podemos saltarnos este proxy de algún modo? Bien, evitarlo no es una posibilidad, pero sí podemos persuadir al resto de apps de nuestro dispositivo Android para que se conecten a través de él, aunque a priori no estén diseñadas para hacerlo. Para ello necesitaremos una aplicación que reconduzca todas las conexión iniciadas por las distintas apps de nuestro terminal hacia el proxy, rehabilitando de paso la resolución de nombres DNS.

Existen varias aplicaciones, esencialmente servidores proxy locales, que dicen ser capaces de hacer esto. Inicialmente lo intenté con Drony, pero no conseguí que funcionara correctamente. Afortunadamente, investigando un poco más, di con ProxyDroid.

ProxyDroid es gratuita, aunque muestra anuncios poco intrusivos, y requiere root. Sin problemas, mi vetusto Galaxy Note 3 corre Lineage OS 14.1 y está convenientemente rooteado. Dado que la tienda de aplicaciones (Google Play) no funcionaba a través del proxy de Guifi.net, simplemente realicé la descarga desde un repositorio alternativo, generalmente fiable, como es uptodown.

Un par de minutos es todo lo que lleva instalar, ejecutar y configurar ProxyDroid (tras husmear un poco en los menús de configuración, claro) para circunnavegar las restricciones asociadas a esta peculiar modalidad de conexión a través de proxy. Aunque desconozco las interioridades de ProxyDroid, intuyo que su magia tiene que ver con la activación de un servidor NAT local para interceptar las conexiones salientes de todas las aplicaciones, aunque probablemente haya alguna que otra astucia adicional no evidente a primera vista.

En la siguiente captura de pantalla se recogen los ajustes relevantes (!) que hay que manipular en ProxyDroid:

A destacar dos cositas:

ProxyDroid puede activarse automáticamente en cuanto conectemos nuestro terminal a una red wifi determinada (Auto Connect / Bound Network). ¡Bien pensado!
Imprescindible activar el proxy del servicio de DNS para que la cosa funcione como debe (DNS Proxy).

Una vez ProxyDroid se pone en marcha, las restricciones detalladas anteriormente quedan eliminadas. Incluso el indicador de conectividad wifi vuelve a la normalidad.

Más allá de los anecdóticos juegos malabares realizados para lidiar con nuestro querido proxy de Guifi.net, esta experiencia no hace sino reafirmarme en mi convicción de que da miedo (¡pero mucho!) andar utilizando esas redes wifi de restaurantes, hoteles, gimnasios, aeropuertos, etc. cuya existencia damos por necesaria e irrenunciable y a las que nos solemos conectar sin pudor ni contención.

No deberíamos olvidarnos de que no tenemos garantía alguna acerca de la correcta configuración y administración de estas redes más o menos públicas, así que si realmente tenemos que recurrir a ellas que sea tomando en todo momento unas mínimas precauciones profilácticas: cortafuegos arriba, conexiones https, evitar el uso de banca electrónica o de compras online... y siempre, siempre mantener una elevada dosis de sana desconfianza.

Volumio frente a piCorePlayer en la Raspberry Pi: un análisiscomparativo

noreply@blogger.com (Pablo Felip) — Fri, 26 May 2017 21:51:00 +0000

Objetivos

Volumio y piCorePlayer constituyen dos de las mejores y más conocidas (especialmente en el caso del primero) opciones que podemos escoger a la hora de montarnos un reproductor de audio digital basado en ese pequeña cajita maravillosa que es la Raspberry Pi.

Kit básico de cacharreo digital por 53€: Raspberry Pi 3, microSD de 32GB, carcasa, disipadores y fuente de 5V@3A.

Me gustaría comenzar diciendo qué no es este artículo: no se trata en modo alguno de una guía o tutorial paso a paso de instalación y uso de estos reproductores.

Por el contrario, lo que vamos a hacer es enfrentar, siempre amigablemente, las virtudes y defectos de ambos desarrollos con el propósito de clarificar todo lo posible ciertos aspectos relativos a las capacidades de ambos y su adecuación a las distintas modalidades de uso y requerimientos que diferentes aficionados pueden contemplar.

El objetivo es, en definitiva, acercar el uso de estos reproductores al aficionado en general y proporcionarle elementos de juicio suficientes como para que pueda realizar una elección informada, optando directamente por el que mejor se ajuste a sus necesidades.

El artículo está estructurado, una vez superada una sección introductoria en la que comentaremos características generales de ambos, en distintos apartados en los que se analizarán comparativamente sus funcionalidades y destacarán sus particularidades, intentando en cada uno de dichos apartados de establecer un ganador parcial. Concretamente, someteremos a ambos reproductores a un análisis basado en estos aspectos:

1. Coste.
2. Compatibilidad.
3. Formatos de audio soportados.
4. Documentación y soporte.
5. Instalación.
6. Configuración y puesta en marcha.
7. Control.
8. Prestaciones y funciones.
9. Calidad de sonido.

Finalmente, trataremos de llegar a alguna conclusión cualitativa.

Vamos a ver si lo conseguimos.

Introducción y entorno de pruebas

Tanto Volumio, que es un desarrollo basado en Raspify, como piCorePlayer (al que denominaremos pCP en adelante) llevan entre nosotros aproximadamente desde el 2013 y tienen recorrido ya un largo camino de versiones hasta llegar a su estado actual (Volumio 2.163 y pCP 3.20 a 5 de mayo de 2017).

Ambas son aplicaciones estables cuyas funcionalidades se han ido enriqueciendo progresivamente desde las versiones primigenias que funcionaban en la Raspberry de 1ª generación y cuya evolución podéis seguir sin más que hacer una búsqueda en Audio Planet o echar un vistazo, por ejemplo, aquí, aquí o aquí, si os sentís inclinados hacia la arqueología audiófila digital.

Volumio y pCP hacen esencialmente lo mismo: reproducir audio digital codificado en una variedad de formatos almacenado en un dispositivo de almacenamiento local (USB o tarjeta SD) o bien en un servidor en red accesible utilizando protocolos como CIFS o NFS.

Desde un punto de vista más técnico ambos están basados en un núcleo Linux, aunque a partir de este punto las similitudes comienzan a desvanecerse en la medida en que los objetivos de diseño de uno y otro divergen.

Volumio tiene como objetivo de diseño prioritario la sencillez de configuración y uso. pCP, por su parte, surgió condicionado por el propósito original de integrarse en un entorno de reproducción Squeezebox, emulando y sustituyendo a los abandonados reproductores físicos de Logitech tales como los Squeezebox Classic o Touch.

Consecuentemente, Volumio está basado en el excelente Music Player Daemon (MPD), el conocido motor / demonio de reproducción todoterreno habitual en los tinglados Linux, en tanto que pCP se construye en torno a Squeezelite, un extraordinario emulador software de dispositivos Squeezebox reales que se puede encontrar también en el corazón de otros desarrollos como Daphile (exclusivo para arquitecturas x86), Max2Play o incluso premiados streamers de postín como el Innuos Zenith mk2 o el Sonore microRendu ¡Casi nada!

Innuos Zenith mk2: Sí, este bicho de casi 3.000€ lleva un Squeezelite (gratuito y de código abierto) en su interior.

Para comprobar las bondades de nuestros dos contendientes vamos a utilizar la siguiente colección de cacharros cuyas fotos me gustaría colgar por inclinaciones puramente audiófilopornográficas pero que no voy a satisfacer en su totalidad por aquello de que me estoy quitando:

El cepillo para vinilos contempla atónito desde su rinconcito a los extraños vecinos que han concurrido junto al amplificador.

Raspberry Pi 3 (la misma que podéis ver en la foto de la sección anterior).
Un par de tarjetas microSD de 8GB y, tengo que decir, no especialmente rápidas, clases 2 / 4.
Un disco duro externo USB de 2,5" auto alimentado y 640GB de capacidad.
Varios pendrives USB de diversas capacidades.
NAS Netgear ReadyNAS Ultra 4 de 12TB (4 discos x 3 TB).
Red local gigabit, aunque la Raspberry estará conectada a una sección enlazada con el router y el NAS a través de sendos PLC de 500 Mbps. Sí, el cableado ethernet es de ferretería.
Diversos artilugios de control en la forma de un móvil Android y una tableta de Apple.
Un amplificador multicanal Pioneer SC-LX81 en el que se han desactivado absolutamente todas las funciones de ecualización y mejora digital del sonido.
Unos magníficos (o eso me parece a mi) altavoces de columna Amphion Argon 3L.
Por fin, un pequeño pero sorprendente DAC I2S, el Allo Piano, cedido por el compañero Topelin de Audio Planet para las pruebas, conectado al mencionado receptor Pioneer por medio de cableado RCA sin demasiadas pretensiones.

Allo Piano: Un DAC pequeño pero matón (PCM5122, 384 KHz / 32 bit).

Criterio 1. Coste

Si bien es cierto que los creadores de Volumio han abierto una tienda online en la que venden desde sistemas completos hasta DACs pasando por toda clase de accesorios tales como purificadores de USB, carcasas o fuentes de alimentación, el software de reproducción es totalmente gratuito.

Volumio Shop, o de como monetizar Volumio.

pCP por su parte, tiene un carácter más amateur, sin tiendas ni aspiraciones comerciales de ningún tipo, siendo, naturalmente, también gratuito.

Por tanto esto es fácil: tenemos en este apartado un indiscutible EMPATE.

Criterio 2. Compatibilidad

Volumio está disponible para un buen puñado de plataformas hardware, además de la propia Raspberry, claro, como podremos comprobar sin más que dirigirnos a su página de descargas:

Raspberry Pi.
PC (X86/X64).
Odroid C1 / C2.
CUBOX-I.
Sparky.
Beaglebone Black.
PINE64.
UDOO DUAL/QUAD y NEO.
Asus Tinker Board.

pCP, en cambio solo puede funcionar... en una Raspberry. Desde la microscópica Zero hasta la 3, eso sí.

Por lo que hace a los dispositivos de audio que pueden utilizarse, ambos reproductores soportan:

La salida analógica integrada de la Raspberry, que con los últimos firmwares ha mejorado notablemente. Los problemas de interferencias, ruiditos, etc. han sido definitivamente solventados y la relación S/R ha mejorado enormemente. Por cierto que la Rasp no tiene DAC como tal, se utiliza una modulación PWM (Ahora Sigma-Delta de 7 bits) y una especie de filtro en su salida mini-jack (sí, de un modo análogo al audio DSD), así que la cosa tiene su mérito.
La conexión HDMI.
DACs conectados a través del puerto USB. En este hilo del foro de soporte de Volumio se recogen los compatibles, en tanto que lo propio se hace en esta página del sitio web de pCP.
DACs y conversores SPDIF I2S (interesantísimos) acoplados como "sombreros" (hats) sobre el conector de expansión GPIO de la Raspberry. La conexión I2S es probablemente el modo óptimo de obtener sonido de uno de estos micro-computadores puesto que se evita el problemático bus USB, que en este dispositivo está compartido con la conexión ethernet, emplea señales independientes de datos y reloj y, además, supone un camino más corto entre reproductor y DAC.

Raspberry Pi 2 con los conectores de expansión expuestos. GPIO arriba.

Las versiones actuales de los reproductores analizados cuentan con compatibilidad directa con los siguientes dispositivos I2S:

Volumio: 503HTA Hybrid Tube Amp | Allo BOSS / Piano / Piano 2.1 | Aoide DACII / Kazoo DAC / Zero DAC+ / Zero Digi+ | Generic I2S DAC | Hifiberry Amp / DAC / DAC Plus / DIGI | HifiBox DAC | IQaudIO DAC Plus / Pi-DigiAMP+ | JustBoom Amp Boards / DAC Boards / Digi Boards | Mamboberry LS DAC+ | pHAT BEAT / DAC | Picade HAT | pisound | RaspiDACv3 | R-PI DAC | Soekris dam 1021 | Speaker pHAT | ST400 Dac (PCM5122) - Amp.
pCP: Allo Boss / Piano / Piano Plus 2.1 / 2.2 | Dion Audio LOCO | ESS9023 | Generic / simple ESS9023 | Generic / simple TI5102 | HiFiBerry AMP (and +) / DAC+ (and Pro) / DAC+ Light / DAC Zero / MiniAMP / Digi and Digi+ / Digi+ Pro | IQaudIO AMP+ / DAC+ / DAC / DIGI+ | I-Sabre-ES9023 | JustBoom DAC/AMP (and Zero/AMP) / Digi (and Zero) / Mamboberry HiFi-DAC+ | RaspiDAC Rev.3x | RPi DAC.

Aquí los tenéis en una disposición más inteligible:

Dispositivos I2S soportados por Volumio y pCP.

¿A que no sospechabais que hubiera tantos chismes I2S? Varias cosas a tener en cuenta que me parece relevante mencionar:

La lista es (más que) previsible que se amplíe en un futuro inmediato a medida que nuevas versiones de Volumio y pCP soporten otros modelos.
pCP dispone de una versión estándar y otra con ciertas optimizaciones y parches específicos para audio implementados en su kernel Linux. Esta versión optimizada admite frecuencias de muestreo superiores a 192Khz y, además, soporta un número mayor de DACs I2S. La lista recogida en la tabla anterior se corresponde con los compatibles con esta versión. No obstante solo se recomienda su uso cuando se cuenta con un DAC I2S y se utiliza una conexión cableada a la red, puesto que las mencionadas optimizaciones interfieren con el correcto funcionamiento tanto de la conectividad wifi como de los DACs USB.
El nombre de cada dispositivo I2S ha sido reproducido tal y como aparece en los respectivos paneles de control web. Es no solo posible sino también probable que en determinados casos la denominación escogida se aplique de modo genérico a diferentes variantes de un mismo modelo o que otros basados en un hardware similar también funcionen, por lo que resulta arriesgado sin una prueba directa determinar si un dispositivo I2S específico está soportado o no en cada reproductor.

En cualquier caso, yo diría que Volumio parece ofrecer, en términos generales, una compatibilidad más amplia con distintos DACs y conversores, especialmente si tenemos en cuenta que pCP debe renunciar a ciertas funciones casi casi primarias para alcanzar el grado de compatibilidad que se refleja en la tabla anterior.

Minipunto (no sin ciertos reparos) para VOLUMIO.

Criterio 3. Formatos de audio soportados

Ambos reproductores cumplen con creces por lo que hace al soporte de distintos formatos de audio.

Volumio es capaz de reproducir prácticamente cualquier cosa en virtud de su casi universal motor de reproducción, MPD: MP3, OGG, AAC, WAV, ALAC, AIFF, FLAC, DFF, DSF, WMA, MPC, WV... y un larguísimo etcétera compuesto por innumerables y oscuros formatos mucho menos frecuentes.

El reproductor software Squeezelite en el que se fundamenta pCP, por su parte, reproduce directamente secuencias codificadas en MP3, OGG, AAC, WAV, ALAC, AIFF, FLAC, DFF, DSF y WMA, a las que hay que añadir, por obra y gracia de la conversión en tiempo real que realiza el servidor LMS al que todo Squeezebox debe conectarse, una gran cantidad de formatos de audio menos conocidos. Volveremos a los servidores LMS y su papel con respecto a pCP en cuanto alcancemos el apartado 6 de este artículo.

Por supuesto, tanto Volumio como pCP soportan de un modo ejemplar las listas CUE y son capaces de reproducir sin silencios entre pistas (en modo gapless) si la ocasión lo requiere.

Se les atragantan a ambos, sin embargo, los contenedores ISO tales como los empleados por los discos SACD o DVD-Audio. Si la reproducción directa, sin que medie una rápida e indolora extracción manual previa a DSF, de los primeros es requisito ineludible deberemos dirigir nuestra atención más bien hacia cosas como JRiver Media Center. Si además queremos reproducir ISOs o estructuras de carpetas de DVD-Audio no tendremos otra opción que Foobar, siendo este último el rey indiscutible por lo que hace a la compatibilidad con todos los formatos de audio conocidos o por conocer (¡Viva el rey!).

Concretemos pues el resultado de este apartado en un merecido EMPATE.

Criterio 4. Documentación y soporte

¿Qué hacer cuando las cosas no salen como uno quiere y el tinglado que hemos montado no acaba de funcionar correctamente? Pedir ayuda educadamente, claro está. Veamos qué clase de soporte obtendremos con Volumio y pCP.

De entrada, ambos productos son de naturaleza no comercial. No hay ningún compromiso por parte del desarrollador. No obstante, en ninguno de ambos casos estaremos solos, para eso está la Comunidad (sí, con C mayúscula).

En el caso de Volumio disponemos de abundante documentación, tanto de puesta en marcha, destinada al usuario final, como de tipo técnico, para desarrolladores que quieran ampliar las capacidades del reproductor, por ejemplo creando nuevos plugins.

La documentación de Volumio en todo su esplendor.

También existe un activo y bien organizado foro de soporte en el que participan cientos de usuarios.

Foro de soporte de Volumio.

pCP, por su parte, dispone de una guía de puesta en marcha (pelín obsoleta) en la propia web del proyecto. El lugar de referencia al que dirigirse en busca de ayuda, no obstante, es el foro de Slim Devices, que sigue más que vivo y coleando y registra una actividad pasmosa teniendo en cuenta el cadáver que es a estas alturas cualquier reproductor Logitech Squeezebox de plástico y silicio. Hay varios hilos "oficiales" sobre pCP, cada uno anunciando el lanzamiento de una nueva versión. El actual es este (pCP 3.20), pero también podéis dirigiros a alguno de los dedicados a las versiones anteriores: 3.10, 3.00, 2.00 o incluso al hilo original, que data de enero de 2013. Muchos miles de mensajes por leer.

Hilos relativos a piCorePlayer en el subforo sobre sistemas Linux de Slim Devices.

Todo en inglés, por supuesto, en uno y otro caso. Es un buen momento de aprender... o de confiar tal vez en que en algún punto del futuro cercano la IA de turno nos haga quedar con cara de tontos a los que hemos pasado años aprendiéndolo. Por otro lado, en los foros patrios no hay demasiada información ni ayuda sobre Volumio o pCP, excepción hecha de Audio Planet, claro está (salas Planeta Digital y Otras Fuentes).

Aunque inicialmente Volumio parece ofrecer información y recursos mejor estructurados, lo cierto es que personalmente solo he tenido buenas experiencias cuando he tenido que resolver algún tipo de problema con cualquiera de los dos desarrollos.

En su momento intercambié varios mensajes con Steen, el desarrollador inicial de pCP, allá por el verano de 2013, cuando me lié a probarlo y me encontré con ciertos problemas a la hora de utilizarlo conectado a un receptor por HDMI. Hay que decir que tanto Steen como el resto de programadores que se unieron posteriormente al proyecto (Paul, Ralphy y Greg) se desviven por aportar soluciones a las cuestiones y sugerencias que plantean los usuarios.

Del mismo modo, tampoco fue complicado resolver otro problema en cierta versión de Volumio, relativo también al puerto HDMI, husmeando en su foro de soporte.

En fin, que dentro de la ¿inconveniencia? que supone la ausencia de un soporte comercial creo que en este caso tenemos un EMPATE.

Lo de ¿inconveniencia? va con segundas, claro. Otro día si queréis hablamos de las excelencias del soporte comercial de determinados fabricantes, o mejor dicho, de la ausencia notoria de la misma (excelencia) en cuanto lanzan su ultimísimo producto, en ocasiones a medio cocer, y se olvidan de los anteriores. Mucho tienen que aprender. Y nosotros también, que nos tragamos productos inacabados que cuestan un dineral sin rechistar.

Criterio 5. Instalación

La instalación, en ambos casos, no tiene absolutamente ninguna complicación. Basta con descargar la imagen ISO del reproductor y grabarla en una tarjeta SD utilizando alguna de las tantas herramientas disponibles. Yo suelo recomendar Etcher, que es multiplataforma (Windows, OS X, Linux), admite imágenes comprimidas y hace lo que tiene que hacer sin complicaciones.

Etcher en acción.

A destacar que la imagen de pCP no alcanza los 90 MBytes, en tanto que la correspondiente a Volumio son ¡2,9 GBytes! (más de 30 veces mayor).

Nuevo EMPATE, por consiguiente, en este apartado.

Criterio 6. Configuración y puesta en marcha

Y llegamos a lo que probablemente sea el meollo de este artículo. Vamos a ver cuáles son los pasos básicos a seguir para dejar tanto Volumio como pCP operativos. Leed detenidamente esta sección porque será de gran ayuda para a la hora de valorar comparativamente Volumio y pCP de modo global.

Veamos...

Una vez completada la instalación basta con introducir la tarjeta SD con la imagen de Volumio o pCP en la Raspberry, conectarla a la corriente y a la red (conviene que inicialmente cableada) y esperar unos segundos a que el dispositivo arranque. Este primer arranque se toma, al menos en el caso de Volumio, más tiempo del habitual. A partir de ese momento el resto del proceso se desarrollará utilizando un navegador, que deberemos dirigir respectivamente a estas direcciones...

http://volumio.local
http://picoreplayer.local

...o explícitamente a la dirección IP obtenida por el dispositivo en su arranque, que podemos averiguar de distintas maneras:

Observando los mensajes de diagnóstico que aparecen por pantalla, si es que hemos conectado la Raspberry a un monitor o televisor.
Utilizando el panel web de administración de nuestro router, típicamente en las secciones "dispositivos conectados", "concesiones DHCP" o algo así.
Empleando algún escáner de redes como Angry IP Scanner (Windows, OS X, Linux), Fing (Android) o Network Analyzer (iOS).

Volumio

Comencemos por Volumio, que además dispone de una interesante función de punto de acceso inalámbrico (hotspot). Si al arrancar por primera vez detecta un adaptador wifi compatible (el de la Rasp 3 lo es), generará una red wifi con SSID propio (Volumio), a la que podremos conectarnos desde un móvil, tableta o portátil para, a continuación, completar la configuración y conectar la Rasp a nuestra red wifi o cableada de manera ya definitiva. En este modo Volumio siempre tendrá la IP 192.168.211.1 (o volumio.local). Bien pensado.

Panel de configuración del hotspot de Volumio.

Este modo, no obstante, aporta una posibilidad interesante: utilizar Volumio en un escenario en el que no se dispone de infraestructura de red local, es decir, no tenemos un router o, simplemente, no queremos usarlo. En este caso podríamos utilizar medios de almacenamiento locales, conectados a la Rasp por USB, y un móvil o tableta asociado al SSID de la red wifi que levanta Volumio de manera autónoma, para montar un sencillo sistema de reproducción independiente de cualquier red local.

A partir de este punto las cosas son innegablemente más simples e inmediatas en Volumio, que aglutina todos los ajustes en varias secciones, claramente organizadas, a las que da paso un botón en la esquina superior derecha de su interfaz web de control.

A la derecha, el menú de configuración de Volumio.

El sistema de configuración está diseñado para resultar funcional pero no intimidatorio. Acciones necesarias como son...

Elegir el idioma para la interfaz de usuario (menú Apariencia).
Seleccionar los servidores y carpetas en red en las que se encuentra nuestra música (menú Mi música).
Escoger el dispositivo de audio de salida (Menú Opciones de reproducción).
Establecer el modo de funcionamiento de la red, cableado o inalámbrico (menú Red).
Actualizar Volumio o devolverlo a su estado inicial (menú Sistema).

...están magníficamente resueltas, utilizando menús claros, tipografía muy legible y selectores para que todo sea cuestión de hacer clic aquí y allá. Ni siquiera es necesario escribir de modo manual la ruta o nombre de las carpetas de red, Volumio auto detecta todos los recursos compartidos y nos permite seleccionarlos con el ratón. Muy bien (otra vez). Podéis comprobar todo esto echando un vistazo a estas capturas de pantalla de alguno de los paneles de configuración, que deberían ser la envidia de más de una solución comercial.

Volumio: Selección de carpetas de música en red.

Volumio: Selección del dispositivo de audio.

Volumio: Ajustes de reproducción.

Volumio: Ajustes del control de volumen.

Volumio: Ajustes de remuestreo.

Como punto negativo, no es posible desactivar las funcionalidades de AirPlay ni de control UPnP de Volumio desde este panel de control web. Esto probablemente no será del agrado de los que prefieren mantener el software tan ligero como sea posible para conseguir una mayor calidad sonora en reproducción. En mi opinión no tiene demasiada importancia, pero no costaría nada incluir un par de interruptores adicionales en la interfaz web para controlar la ejecución de los módulos que implementan estas dos funciones.

piCorePlayer

Pasemos a pCP. Como algunos habréis intuido ya, las cosas cambian aquí. Y de qué manera. Pero antes de zambullirnos en el extenso y muy exhaustivo panel de control web de pCP, quizás sea el momento de hablar de los dos modos de funcionamiento de este reproductor. Para introducirlos, nada mejor que estos cuatro diagramas:

Diagramas 1, 2, 3a y 3b: Bloques de un sistema de streaming y correspondencia con Volumio y piCorePlayer.

En la parte superior (diagrama 1) se han representado los bloques generales que componen cualquier sistema de reproducción en streaming: Los archivos se encuentran almacenados en algún lugar, el módulo servidor accede a ellos, bien de modo local o a través de la red, bajo las indicaciones de algún tipo de controlador, y envía las secuencias de audio al reproductor. Nada nuevo bajo el sol.

Más abajo (diagrama 2), se representa la correspondencia de esos bloques funcionales con Volumio. Su corazón, MPD, hace las funciones de servidor, catalogando los archivos de audio, pero al mismo tiempo también integra el "motor" de reproducción. Dos por el precio de uno.

pCP, por su parte, puede funcionar de dos modos distintos (diagramas 3a y 3b):

Únicamente como reproductor (3a), para lo que requiere de la presencia de un servidor Logitech Media Server (LMS) en la misma red local a la que se conecta, servidor que por su parte se encargará de las tareas de gestión de la biblioteca musical, esté donde esté. Bueno, realmente los servidores LMS hacen mucho, mucho más que catalogar. De hecho se ocupan de todas las tareas pesadas (conversión de formatos al vuelo, remuestreo, gestión de las distintas fuentes de las secuencias de audio...). Pero esa es otra historia.
Aunando las funciones de reproductor y servidor (3b), cosa que es posible desde la versión 2.03 lanzada en marzo de 2016. De este modo pCP puede funcionar en una Raspberry como un sistema totalmente autónomo, de un modo análogo a lo que es el comportamiento natural de Volumio. Y lo hace bien. Muy bien, diría yo.

Esto, sin embargo, no nos va a salir gratis. Si lo que esperamos encontrar en pCP es un sistema casi, casi "enchufar y listo" como es Volumio estamos abocados a una (pequeña) decepción. Si bien los elementos a ajustar son análogos a los que hemos repasado más arriba con Volumio, nos vamos a encontrar con algunas dificultades adicionales que pueden desanimarnos a las primeras de cambio:

De entrada hay que tomar ciertas decisiones que inicialmente pueden resultar intimidantes ¿Versión de pCP normal u optimizada para audio? ¿Squeezelite con o sin FFMpeg? ¿Solo reproductor o también servidor?
La interfaz web de control de pCP está totalmente en inglés.
La granularidad de los ajustes es notablemente superior a Volumio. Podemos hurgar en un sinfín de lugares y toquetear docenas de opciones que Volumio astutamente esconde bajo su pulida web de control. Esto es especialmente cierto si activamos en la interfaz web de pCP los modos Advanced o Beta, que despliegan numerosos controles y funciones ocultas, algunas no obstante muy, muy convenientes que no encontraremos en Volumio.
El panel de control web no está tan pulido como el de Volumio. Esto se nota en cosas tan triviales como la selección de red wifi o el establecimiento del punto de montaje de un dispositivo de almacenamiento USB; sí hay que escribir ambas cosas a mano.
Por defecto pCP solo activa el módulo de reproducción (Squeezelite). Si deseamos que funcione de un modo similar a Volumio habrá que localizar en su panel de control la pestaña LMS y solicitar que se instale este componente. Tras ello deberemos sufrir una segunda vuelta del proceso de configuración, esta vez localizado en el propio panel web de ajustes del LMS, que por suerte sí se puede mostrar en castellano. Tranquilos, no es mortal, tan solo deberemos configurar el idioma, la carpeta con los archivos de audio y las listas de reproducción y el modo en que se gestionará el control del volumen del reproductor. Como no podría ser de otro modo, este LMS que se ejecuta en el seno de pCP puede, naturalmente, actuar también como servidor de otros reproductores, tanto de tipo software, como pCP o cualquier otro basado en Squeezelite, como hardware, de la familia Squeezebox de Logitech (Classic, Controller / Receiver, Touch, Radio, etc.) que tengamos conectados a la misma red.

Como veis la cosa se complica. Pero no tenéis por qué creerme a pies juntillas, hagamos un pequeño recorrido por la web de ajustes de pCP y valorad por vosotros mismos si es tan fiero el león como lo pintan. De entrada, esto es lo primero que veremos al conectarnos a la web de control de pCP. Se trata de una pantalla de bienvenida presidida por una barra de menú (destacada mediante un recuadro rojo) que da acceso a los distintos paneles de configuración.

pCP: Pantalla de bienvenida del panel de control web.

Veamos qué tenemos en el área principal (Main page):

pCP: Página principal de ajustes.

Aquí se recoge información general del estado de cada una de las funciones de pCP: Squeezelite (reproductor), LMS (servidor) y Shairport (receptor AirPlay). También se puede apagar y reiniciar o actualizar, tanto el propio componente de reproducción como pCP al completo. Pero no os perdáis en la parte inferior de la captura de pantalla una serie de enlaces (de nuevo destacados en rojo) que permiten activar los distintos modos de la interfaz (básico, normal, avanzado y beta).

pCP: Selector de modo de la interfaz web de control.

Por defecto pCP arranca en modo normal, pero si pasamos a los modos Advanced o Beta (en este caso no sin antes leer y aceptar una seria advertencia en pantalla) comprobaremos como el número de ajustes aumenta notablemente.

pCP: Aviso de activación del modo beta. Asusta un pelín, ¿no os parece?

Por ejemplo, en la página principal de ajustes aparecen dos secciones adicionales con un buen montón de botoncitos:

pCP: Festival de ajustes tras activar el modo beta.

Este fenómeno se traslada, como cabía esperar, al resto de páginas de configuración, que incluso en su modo normal contienen ajustes para llenar las interfaces web de varios Volumios. La cosa alcanza niveles estratosféricos en cuanto nos asomamos a las páginas denominadas Tweaks o LMS.

Y es precisamente en las posibilidades que nos brindan unos ajustes tan detallados donde comienza a asomar el morro la superioridad de pCP sobre Volumio.

Examinemos ahora la pestaña Squeezelite. Allí, justo bajo el selector del dispositivo de audio a utilizar, nos encontraremos con un botón de sugerente nombre...

pCP: Selector y opciones del dispositivo de audio.

...que da paso a un no menos interesante panel que nos permite ajustar, en este caso, el tipo de filtro empleado por el DAC:

pCP: Ajustes específicos del dispositivo de audio.

También podemos modificar un gran número de parámetros de bajo nivel del motor de reproducción: tamaño de buffer, ajustes específicos de ALSA (la arquitectura de audio de bajo nivel de Linux), prioridad del hilo del reproducción, parámetros del remuestreo... incluso podemos establecer un script que se ejecutará al iniciar o apagar el sistema. Poco más se puede pedir.

pCP: Ajustes y más ajustes relativos a ALSA y Squeezelite.

Cabe preguntarse si es necesario tan impresionante despliegue. Y la respuesta probablemente sea que no... al menos en el 90% de los casos. No obstante, y pensando en ese 10% restante (y también en el ajuste del filtro del DAC que acabamos de comentar, que sí me parece un elemento relevante al que Volumio no nos facilita acceso), personalmente me resulta tranquilizador saber que de ser necesario es posible manipular todos estos parámetros.

Como contrapunto a tanta exuberancia, más vale que no nos acerquemos a la pestaña de ajustes de la conexión wifi (Wifi Settings), ni tan siquiera encontraremos un triste selector de redes.

pCP: Los ajustes de la conexión wifi son poco amigos del ratón.

En la pestaña Tweaks también tenemos posibilidades inacabables, entre ellas me gustaría destacar:

Incrementar la frecuencia de la CPU, GPU y memoria de la Raspberry (overclocking) para conseguir que funciones más suelta. En mi opinión esto es probablemente innecesario en una Raspberry 2 o 3.
Configurar el envío de un paquete de datos Wake-On-Lan (WOL) a través de la red para despertar o iniciar el servidor LMS, si es que lo ejecutamos en otra dispositivo distinto a la Raspberry Pi.
Configurar el funcionamiento de un panel LCD o un mando por infrarrojos conectado a la Raspberry.
Desactivar la funcionalidad de receptor AirPlay si no la necesitamos.
Ajustar de un modo fino el volumen ALSA (imprescindible, por mi experiencia, cuando se emplea la salida de audio HDMI y aparecen fenómenos de saturación digital).
Configurar un ecualizador gráfico de 10 bandas.
Realizar ajustes fines sobre la temporización y sincronización de las transferencias de audio a través del bus USB, lo que permite solucionar en algunos casos problemas con ciertos DACs.
Programar reinicios periódicos del reproductor (para garantizar un funcionamiento siempre estable). Volumio tan solo admite la planificación del apagado.

pCP: Ajuste de la frecuencia de funcionamiento.

pCP: Wake-on-LAN.

pCP: Ajustes de pantalla LCD y control remoto por infrarrojos.

pCP: Ajustes de audio variaditos.

pCP: Ajuste fino de las transferencias USB.

pCP: Ejecución periódica de tareas programadas.

Por último, en la pestaña LMS podremos activar el servidor de medios local, si es que deseamos configurar pCP de modo que funcione de manera autónoma, al igual que Volumio consigue gracias a su servidor MPD. Lógicamente, en caso de que ya dispongamos de un servidor LMS ejecutándose en nuestra red podemos omitir todo lo que sigue.

pCP: Panel de control del servidor LMS integrado antes de su instalación.

Del párrafo anterior se desprende una implicación que puede que no sea evidente a simple vista: Si pretendemos que nuestra Raspberry con pCP reproduzca audio contenido en unidades USB conectadas directamente a ella necesitamos activar el servidor LMS local. Impepinablemente. pCP es modular también hasta para eso.

Una vez hayamos instalado este servidor LMS utilizando el botón de inconfundible funcionalidad localizado en la parte superior de la pestaña del mismo nombre, podremos iniciarlo, detenerlo, actualizarlo, limpiar su cache, etc. etc. La versión que se instala es la 7.9, que incluye soporte para archivos DSD en formato DFF y DSF (igualito que Volumio).

pCP: Panel de control del servidor LMS integrado después de su instalación.

Los servidores de medios LMS, con carácter general, pueden catalogar y servir el contenido de discos locales y remotos, accesibles a través de la red.

Sin embargo, el servidor LMS de pCP solo es capaz de acceder inicialmente a discos USB, conectados localmente, formateados en FAT/vFAT/FAT32 y ext2/3/4. Estos discos son detectados de modo automático, pero deben montarse manualmente utilizando un panel que encontraremos también en esta pestaña de configuración, bajo los ajustes mostrados anteriormente:

pCP: Montaje de discos USB locales.

El procedimiento no es demasiado intuitivo. Hay que (1) seleccionar el disco, (2) escribir el nombre de la carpeta donde se montará (aparecerá) su contenido y (3) hacer clic en el botón Set USB Mount.

pCP recordará los discos USB que hemos insertado y los mantendrá enumerados en la lista que podéis ver en la imagen anterior. Estos discos pueden pincharse en caliente, pero hay que acceder necesariamente al panel de control web para ordenar su montaje o reiniciar el reproductor.

En Volumio, por el contrario, solo tenemos que conectar un disco USB para que este se monte, su contenido sea escaneado (catalogado) y aparezca automágicamente como un ítem adicional en su menú Biblioteca, sin intervención manual por parte del usuario ni historias. Así de simple.

Y nuevamente nos toparemos ahora con el diseño modular de pCP: Si además deseamos hacer que LMS lea discos NTFS o conseguir que se conecte a carpetas de red expuestas a través de los protocolos CIFS o NFS, del mismo modo que Volumio hace de serie, será necesario realizar la instalación de una serie de sistemas de archivos adicionales:

pCP: Instalación del soporte para discos NTFS y recursos en red CIFS y NFS.

Ahora ya podremos montar unidades compartidas en red, pero nuevamente nada de auto detección de recursos compartidos o de ir pinchando por ahí con el ratón. Tendremos que introducir manualmente los parámetros necesarios: dirección IP de servidor, carpeta compartida, protocolo (CIFS o NFS), usuario y contraseña. Si es que Volumio nos tenía malacostumbrados.

pCP: Carpeta remota compartida a través de NFS montada en el sistema local.

Por otra parte, Volumio, dando nuevamente muestras de un diseño pensado para ponernos las cosas facilitas, comparte automáticamente en la red por medio de CIFS/SMB cualquier espacio de almacenamiento al que tenga acceso. Esto incluye las unidades de almacenamiento USB conectadas, el espacio libre en la tarjeta SD desde la que típica mente arranca e incluso cualquier recurso de red (NFS o CIFS) configurado en su biblioteca (esta última característica permitiría a un cliente no compatible con NFS acceder al contenido de un servidor que solo es NFS, actuando Volumio como intermediario entre ambos, interesante...).

pCP también nos ofrece una función similar, que para variar esta desactivada de serie. Encontraremos sus ajustes en la parte inferior de la pestaña LMS del panel de control de pCP (no nos olvidemos, modo beta activado). En consonancia con la filosofía de este reproductor, nos encontraremos con un panel de control muy completo en el que tendremos que escribir unas cuantas cosas antes de poner Samba (el marchoso nombre propio que recibe el módulo utilizado para compartir recursos por medio del protocolo CIFS) en marchosa marcha:

Panel de control del servidor Samba de pCP.

Aunque pudiera no parecerlo inicialmente a la vista de las opciones presentes en el panel, es posible compartir múltiples carpetas locales a pCP localizadas tanto en unidades USB como en el propio sistema de archivos alojado en la tarjeta SD, aunque siempre de modo manual.

Esta capacidad de funcionar como NAS de la que presumen ambos reproductores (concedido, en pCP con un poquito más de esfuerzo) resulta muy útil en un hipotético escenario en el que tuviéramos toda nuestra música almacenada en un disco USB local al reproductor y quisiéramos añadir o eliminar discos a o de la audioteca o, simplemente, editar tags, reorganizarla o realizar cualquier otra tarea de mantenimiento sin desplazar ni conectar físicamente el disco USB a nuestro ordenador.

Volumio dándolo todo: Almacenamiento interno, disco USB conectado y hasta carpeta de red configurada en un NAS.

Carpeta compartida a través de Samba en pCP.

No obstante la cosa no acaba aquí, nuestra travesía hacia un sistema de streaming autónomo con pCP aún no ha concluido.

Una vez hayamos conseguido montar los discos locales o carpetas remotas en pCP, será necesario indicarle a LMS dónde se encuentran para que pueda catalogar su contenido y servirlo al motor de reproducción. Esto nos lleva a un nuevo panel web de control, esta vez el habitual en cualquier servidor LMS. Para acceder a él podemos escribir en el navegador:

http://volumio.local:9000

La primera vez que accedamos a la web de LMS tendremos que superar un asistente de configuración inicial.

Primeramente se nos pedirán el usuario y clave de mysqueezebox.com, el portal de servicios utilizado originalmente por los reproductores Squeezebox de Logitech, o se nos dará la oportunidad de crear una nueva cuenta en él. Por el momento sigue siendo necesario registrar nuestro servidor LMS en él si deseamos activar algunas aplicaciones y servicios como Tidal o Spotify.

pCP: Inicio de sesión en mysqueezebox.com del LMS integrado.

A continuación deberemos indicarle a LMS dónde se encuentra almacenada la música que debe gestionar. Tendremos que dirigirlo, esta vez sí a golpe de ratón, al punto de montaje correspondiente que hayamos establecido en el panel de control del LMS de pCP:

pCP: Carpeta de música del LMS.

Para finalizar, deberemos indicar la ubicación donde se almacenarán las listas de reproducción. Escogeremos por ejemplo la carpeta /mnt/mmcblk0p2/tce/slimserver, que es donde también se guardan de modo predeterminado las preferencias y la cache del LMS en pCP:

pCP: Carpeta de listas de reproducción del LMS.

Aún tendremos que hacer varios (exactamente tres) esfuerzos adicionales para alcanzar una configuración que permita un funcionamiento equivalente al que Volumio nos regala tan graciosamente tras dedicarle apenas unos minutos de nuestro tiempo a su panel de control. En contra de lo que pudiera parecer, no os pido que paséis por todo esto por pura maldad, sino para que podáis valorar de primera mano el coste temporal que supone dejar uno y otro reproductor en condiciones similares de funcionamiento.

Pero no divaguemos ahora, tiempo tendremos de hacerlo en la última sección de este artículo.

Primero: En la interfaz web de control de LMS tendremos ahora que dirigirnos a un nuevo panel de configuración, ahora sí el propio del LMS:

pCP: Ajustes finales de configuración del LMS integrado.

Y a continuación haremos clic en la pestaña Complementos. Si es la primera vez que configuráis un LMS quizás os sorprenda la enorme variedad disponible, de hecho es esta una de las razones por la que los ecosistemas Squeezebox siguen siendo tan populares tras el abandono de los reproductores físicos por parte Logitech y su encarnación posterior en la forma de emuladores software como el Squeezelite que propulsa pCP.

Concretamente nos aseguraremos de activar DSDPlayer, necesario para que pCP sea capaz de reproducir archivos DFF y DSF.

pCP: Activación de la compatibilidad con archivos DSD en LMS.

Segundo: Echémosle una ojeada al modo en que se gestiona el volumen del reproductor. El consejo habitual es desconectar el control digital interno provisto por LMS. Para ello nos dirigiremos a la pestaña Reproductor, seleccionaremos el que representa a pCP y desplegaremos la subpágina denominada Audio, donde fijaremos el nivel de salida al 100%:

pCP: Ajustes de volumen en LMS.

Tercero y, por fin, último: Nos queda un ajuste final (de verdad que sí) relativo al modo en que LMS nos permite ojear la biblioteca musical. Seguimos en la pestaña Reproductor pero ahora seleccionaremos el submenú Additional Browse Modes, para activar a continuación la casilla de verificación junto a Disks and folders (discos y carpetas).

pCP: Modos de exploración adicionales de LMS.

¿Para qué hacemos esto? Muy sencillo. Por su naturaleza, LMS está diseñado para gestionar una biblioteca de audio única y permanentemente accesible, bien localizada en un disco local conectado a la Raspberry Pi, bien en una carpeta expuesta en red. Esto quiere decir que si tras configurar pCP bajo esta premisa pinchamos en uno de los puertos USB de la Rasp una unidad de almacenamiento adicional, con archivos de audio distintos a los contenidos en la biblioteca principal gestionada por LMS, este se limitará a ignorarla, aunque la hayamos montado previamente utilizando el procedimiento descrito unas líneas más arriba.

Cuando se ha activado la navegación por discos y carpetas, LMS pasa a comportarse de un modo más parecido a Volumio. Si bien existirá una colección principal, interrogable utilizando un cuadro de búsqueda o variados criterios tales como artista, álbum, año de edición, géneros, etc., también se mostrará en una sección determinada el contenido del sistema de archivos local de la Raspberry, navegando en el cual podremos acceder eventualmente al contenido de la unidad USB que se ha montado. En este caso es conveniente que los archivos de audio estén correctamente organizados en carpetas por artista, álbum, etc. para facilitar su localización dado que su contenido no será indexado e incorporado al catálogo de la biblioteca.

Y eso es todo... que no es poco.

Creo que estaremos de acuerdo en que que si prima el criterio de la sencillez de configuración solo puede haber un ganador: VOLUMIO.

Criterio 7. Control

Volumio puede ser controlado de varios modos:

Mediante un navegador conectado a su interfaz web.
Empleando cualquier controlador MPD nativo, de los que podéis encontrar una lista aquí.
Recurriendo a un controlar UPnP. Mi preferido es BubbleUPnP (Android - 3,99€), pero también es posible utilizar otros como el diseñado para los streamers Lumin (iOS, Android - gratuito), que no deja de ser un controlador UPnP genérico compatible con otros cacharros.

Aunque el control a través de un navegador resulta universal y razonablemente cómodo y fluido, la sensación de uso sigue siendo sensiblemente distante de la que sería propia de una aplicación nativa.

Por otro lado, los controladores MPD que he probado me han parecido deslucidos con la excepción de MPaD / MPoD para iOS, que desgraciadamente ya no están disponibles en la tienda de apps de Apple. Ambas aplicaciones no se actualizan desde iOS 7 y están oficiosamente muertas. Lástima. Una alternativa actual es Soundirok (iOS - 5,49€ y Android - 3,04€), aunque no la he probado personalmente.

El uso de BubbleUPnP resulta, tal y como yo lo veo, mucho más aconsejable, pero existe una limitación importante: solo es posible utilizarlo cuando la biblioteca musical se encuentra almacenada en un servidor de medios DLNA. Y Volumio no lo es. O lo que es lo mismo, ya nos podemos olvidar de esta posibilidad si nuestra música está almacenada en un disco duro conectado a la Raspberry por USB, lo que para muchos será imperdonable.

Volumio siendo controlado por BubbleUPnP mientras se explora la biblioteca de un LMS, haciendo las veces de servidor UPnP, en mi NAS (ballena). La biblioteca conectada localmente a Volumio en un disco USB no resulta accesible.

Otro tanto ocurre si decidimos emplear la app de Lumin: una interfaz bastante maja pero, nuevamente, ni rastro de los archivos locales a la Raspberry que corre Volumio.

Repetimos la jugada con la app diseñada para los reproductores Lumin: un bonito controlador UPnP para un streamer casi tan aristrocrático como los de Linn.

Esta limitación no lo es de las apps de control utilizadas (BubbleUPnP, Lumin) sino de la propia arquitectura UPnP/DLNA, que exige que los archivos de audio sean expuestos en la red por un componente de tipo servidor. Y Volumio no lo es. Tropezamos con un muro de piedra (digital).

Por tanto, me temo que en muchos casos el control vía web será la única alternativa aceptable. La buena noticia es que está francamente bien, siendo la experiencia de usuario entre muy chachi, cuando se utiliza un navegador de escritorio o una tableta,y simplemente usable en un móvil. Como muestra un par de botones, Volumio visto desde una tableta (idéntico aspecto al que presenta en un ordenador) y desde un móvil:

Vista web de Volumio desde una tableta: Tema en reproducción en pantalla y controles básicos.

Vista web de Volumio desde una tableta: Explorando la biblioteca por álbum.

Vista web de Volumio desde un móvil: panel de reproducción (izq.) y álbumes de la biblioteca (der.)

En el mundo Squeezebox tenemos, afortunadamente, al menos tantas posibilidades:

Control mediante navegador conectado a la web de control de LMS.
Apps específicas, de las que hay un abundante surtido: iPeng (iOS - 9,99€), Orange Squeeze (Android - 5,49€) o Squeezer (Android - gratuito).
Controladores UPnP genéricos, como (otra vez) BubbleUPnP, puesto que LMS envuelve con una capa de compatibilidad DLNA a todos los reproductores Squeezebox bajo su control, incluyendo, claro está, pCP.

La opción menos recomendable es la primera (control vía la web del LMS). Es completa y funcional, pero, simplemente, no está adaptada a móviles o tabletas, y presenta fallos de usabilidad importantes. A considerar solo como último recurso o como posibilidad ocasional.

Ni me molesto en poner capturas de pantalla específicas para demostrarlo.

El uso de controladores UPnP como BubleUPnP también debería considerarse. Además, en este caso y como consecuencia de la peculiar arquitectura de LMS, si la biblioteca principal reside en un disco USB conectado localmente a la Raspberry sí podremos ojear su contenido sin problemas (minipunto para pCP) Esto es así porque LMS también ejerce como servidor UPnP, de modo que su biblioteca, da igual que sea remota o local, es igualmente visible desde un controlador como BubbleUPnP.

Tampoco incluyo capturas en esta ocasión. Son indistinguibles de las que he colgado más arriba cuando demostraba el uso de BubbleUPnP para controlar Volumio.

En este supuesto (biblioteca local y controlador UpnP) el funcionamiento de nuestro tinglado de reproducción sería el siguiente:

El servidor LMS de pCP cataloga el contenido de una unidad de almacenamiento USB localmente conectada.
El servidor LMS expone esta biblioteca musical de un modo estructurado (artista, género, música nueva, etc.) ante cualquier controlador UPnP presente en la red local (como BubbleUPnP).
Pertrechado con su controlador UPnP preferido en un móvil o tableta, el usuario selecciona un elemento y le ordena a LMS que lo reproduzca.
El LMS lee los archivos de la unidad de almacenamiento, hace su magia al vuelo (conversión de formatos y tal) y le envía a Squeezelite la secuencia de audio que debe reproducir.

Un poco enrevesado... pero hermoso ¿no os parece? Son cosas del audio digital desmaterializado.

No será posible, sin embargo, acceder desde uno de estos controladores UPnP y bajo este supuesto de funcionamiento al contenido de una unidad USB secundaria pinchada ocasionalmente y de modo no permanente puesto que su contenido no se cataloga en la biblioteca de audio principal de LMS.

Vistos todos los hechos y siempre que no nos importe pagar los 9,99€ que vale, tengo que decir que en mi opinión la mejor opción de control para nuestro pCP es iPeng (ahora mismo en la versión 9). Esta app está perfectamente adaptada al ecosistema Squeezebox y permite ojear tanto la biblioteca musical gestionada por LMS (local o en red, tanto da) como cualquier dispositivo adicional conectado directamente a la Raspberry por USB, superando la limitación descrita en el párrafo anterior, dado que admite los modos de navegación extendidos que, recordad, activamos en la parte final de la sección dedicada a la configuración de este articulo (criterio nº 6), para así acceder a los archivos contenidos en discos y carpetas que no forman parte de la biblioteca musical principal.

A mi modo de ver, iPeng sigue siendo la aplicación de control con las que el resto de aplicaciones de control deberían medirse. Sí, incluyendo la de Lumin. Recordad, iPeng solo está disponible para i-cosas, sean de tipo tableta o teléfono... no podía ser todo tan bonito, claro.

Y ahora sí que cuelgo alguna que otra captura.

iPeng: Orgía de reproductores, todos controlables y sincronizables desde un único punto.

Información extendida de la pista, destacando vistosamente sobre el modo nocturno de iPeng (colores oscuros).

Explorando todas las secciones de Spotify desde el maravilloso iPeng, esta vez en modo diurno.

Rompiendo la racha, en esta ocasión creo que es apropiado declarar a PICOREPLAYER justo vencedor, aunque el margen sea probablemente escaso.

Criterio 8. Prestaciones y funciones

Después del exceso en el que se ha terminado convirtiendo el apartado dedicado a la configuración y puesta en marcha (me horroriza dejarme cosas), voy a tratar de telegrafiar esta nueva sección porque el artículo, en términos generales se me está yendo de las manos y ya tengo ganas de liquidarlo.

Para ello, nada mejor que una contundente tabla comparativa, abierta a cualquier comentario, naturalmente, para vuestra consideración. En ella he enumerado todas aquellas funciones y características que he considerado merecedoras de enumeración, otras directamente las he omitido por considerarlas poco relevantes. Al mismo tiempo, he tratado también de agruparlas por categorías. Algunas ya han sido mencionadas en secciones anteriores, si aparecen de nuevo aquí es porque me ha parecido apropiado recogerlas junto al resto para facilitar una evaluación comparativa global.

Tabla comparativa de funciones y capacidades.

Me gustaría mencionar que algunas de las funciones que aparecen como no disponibles en alguno de los reproductores es previsible que sí lo estén en un futuro inmediato, a juzgar por lo que se cuenta en los respectivos foros de soporte de Volumio y pCP. Es el caso, por ejemplo, de la sincronización de reproductores (Volumio) o la compatibilidad con Spotify Connect (Volumio y pCP), de hecho en estos momentos ya hay una versión del plugin de Spotify para LMS en pruebas con esta deseada capacidad.

Del mismo modo, algunas de las limitaciones y carencias que parecen desprenderse de la ausencia de determinadas funciones en la tabla pueden circunnavegarse aplicando modificaciones más profundas y delicadas en los sistemas Linux subyacentes tanto a Volumio como pCP . No obstante estos casos quedan fuera de consideración por razones obvias.

Esperaremos, veremos y actualizaremos la tabla, si procede. Entretanto, punto para PICOREPLAYER.

Criterio 9. Calidad de sonido

Preparado para una prueba ciega.

Soy consciente de que la calidad de sonido obtenida con Volumio y pCP es uno de los aspectos más importantes y, a la vez, probablemente más controvertidos de este análisis. Los que me habéis leído anteriormente ya sabéis que no me gusta dejarme llevar ni por la poesía audiófila ni por las emociones, siendo mi perfil de usuario profundamente racional y objetivista. Es lo que hay.

Por ello, el único modo que entiendo fiable a la hora de valorar esta espinosa cuestión es enfrentar en prueba de conmutación inmediata y, si se tercia, ciega a ambos reproductores.

Como no dispongo de Raspberries ni DACs por duplicado, lo único que se me ha ocurrido es hacer una comparativa en dos fases con un tercer reproductor, en este caso un Squeezebox Touch.

Detallo la prueba para los que gustéis de este tipo de detalles:

Fuente A: Squeezebox Touch con modificación EDO conectado por TOSLINK a receptor. No aplico en el servidor LMS ningún pre-procesamiento. Sin remuestreo y con el ajuste de volumen digital desconectado.
Fuente B: Raspberry Pi 3 con Volumio 2.163 conectada por RCA al mismo receptor. Ningún ajustes distinto a los de serie, sin remuestreo, control de volumen en hardware y mantenido al 100%.
Fuente C: Raspberry Pi 3 con Volumio 3.20 (versión optimizada para audio) conectada por RCA al receptor. Ningún ajustes distinto a los de serie en el Squeezelite o ALSA de pCP, sin remuestreo. Ajuste de volumen digital desconectado.
El resto del equipo empleado es el descrito en la sección Introducción y entorno de pruebas.
Se mide tensión en bornes de altavoces con tono de prueba de 1 Khz sin apreciar diferencias significativas (inferiores en todo caso a 0,25 dB) entre ninguna de las 3 fuentes.
Utilizo iPeng como controlador para sincronizar perfectamente cada par de reproductores, que quedan enlazados y obedecen las órdenes al unísono.

Sí, ya sé lo que vais a objetar: el DAC del receptor (WM8740), que es el determinante en el caso del Squeezebox puesto que está conectado digitalmente, no es igual al PCM5122 del pequeño Allo Piano montado en la Raspberry ¿Cómo van a sonar igual? ¿Estamos locos?

En mi defensa diré que una prueba que suponga escuchar un fragmento, cambiar la tarjeta SD insertada en la Raspberry, iniciar con otro reproductor y volver a reproducir el mismo corte escuchado ya hace quizás minutos no me parece fiable. En cualquier caso, y para vuestra tranquilidad, deciros que esto también lo he hecho, con el resultado que podéis suponer y que me ha llevado a este otro procedimiento para determinar si finalmente era capaz de percibir algún cambio cualitativo en el sonido emitido o no.

Primero he enfrentado a Volumio (fuente B) con el Squeezebox (fuente A) y posteriormente he hecho lo propio con (A) y pCP (fuente C), en ambos casos practicando una escucha relajada y sabiendo de antemano qué fuente sonaba.

No he sido capaz de apreciar diferencias de calidad entre A/B y A/ C.

A continuación he repetido ambas pruebas, ahora ya en modo paranoide, conmutando insistentemente en tiempo real A/B y A/C... adelante, atrás, adelante. Un co*azo, vamos, pero todo sea por la ciencia.

Con el traje de las comuniones tratando de oír cosas. El que conmuta es mi cuñado Pedro, que como habla francés queda bien en las fotos.

Del mismo modo, me ha sido totalmente imposible encontrar diferencia alguna entre cada par de fuentes: Idéntico timbre, tono, escena, separación de instrumentos, etc. Si las hay están por encima (o debajo, según se mire) de mi capacidad auditiva o tal vez enmascaradas por otros factores como la calidad del equipo de prueba o los problemas acústicos (numerosos) ocasionados por mi (no dedicada) sala.

A la vista de esto no me ha parecido necesario poner en marcha un protocolo doble ciego riguroso, con sus intentos, porcentajes y tal.

En conclusión, ambos reproductores ofrecen, en mi opinión, exactamente la misma calidad de sonido, cuando se configuran del mismo modo.

A destacar el hecho de que un aparatito de poco más de 70€ (Rasp + accesorios + DAC Allo) suene igual que un reproductor que en su momento costaba 300€ (Touch) conectado al DAC de un receptor de más de 2.500€. Cosas, supongo, de la democratización digital que muchos siguen negando obstinadamente.

Por tanto, EMPATE.

Conclusiones finales ¿Tenemos un ganador?

Si nos limitamos a mirar el marcador nos encontraremos con esto:

Volumio vence en los apartados de compatibilidad y configuración (2 puntos).
piCorePlayer resulta superior por lo que hace a las prestaciones y a los mecanismos de control (2 puntos).
Ambos reproductores empatan en otros 5 de los 9 criterios analizados: Coste, formatos de audio soportados, documentación y soporte, instalación y calidad de sonido.

Juro y perjuro que este empate final a los puntos no estaba preparado, ha salido lo que tenía que salir. Tengo que reconocer que hasta el momento de preparar este artículo, cosa que me ha llevado unas tres semanas de intensas pruebas casi siempre de madrugada, estaba mucho más familiarizado con pCP que con Volumio y, debo reconocer, tenía clara preferencia por el primero.

En este sentido, cosas como el visible (y por otra parte respetable) interés del creador de Volumio en popularizar y monetizar su proyecto, en ocasiones mediante publicaciones en su blog no demasiado afortunadas en mi opinión, o el lanzamiento de una versión 2.0 con un aparente peor rendimiento, habían conspirado para conformar en mi un sesgo negativo hacia este reproductor.

Ahora que ya nos conocemos más no me importa admitir que ese sesgo ha menguado notablemente y me veo en la obligación de aplaudir el gran trabajo realizado con Volumio por su equipo de desarrollo, a pesar de que mis inclinaciones personales hacen que siga prefiriendo piCorePlayer.

Me gustaría concluir con unas recomendaciones generales que quizás sean de ayuda a la hora de decidirse por el uso de Volumio o piCorePlayer en determinados escenarios:

Recomiendo Volumio si:

Nuestra biblioteca musical está desparramada en varios discos USB, que pretendemos conectar a la Raspberry de modo no permanente.
La facilidad de puesta en marcha y sencillez de uso resultan primordiales.
No disponemos de infraestructura de red a la que conectar el reproductor o preferimos mantenerlo aislado de la misma.
Y última pero no menos importante... si le tenemos manía al módulo servidor de pCP, LMS.

Recomiendo piCorePlayer si:

Disponemos de una biblioteca permanentemente accesible por el reproductor, bien de tipo local (USB), o en red.
Deseamos integrar el reproductor con otros, quizás de diferentes tipos (AirPlay, Chromecast, UPnP), en un entorno multi habitación en el que se permita la emisión de distintas secuencias de audio, en su caso sincronizadas.
Queremos tener un control de bajo nivel de los ajustes del reproductor.
Nos gusta que solo se mantengan en ejecución aquellos módulos y componentes estrictamente necesarios.

Confío en que los lectores que hayáis conseguido resistir los embates de mi no siempre claras y concretas explicaciones y estéis ahora leyendo esto hayáis encontrado esta comparativa jugosa e interesante. Confío del mismo modo en que el presente artículo os haya permitido configurar vuestra propia opinión, que naturalmente no tiene por qué coincidir con la mía. De un modo u otro gracias por leerme hasta aquí.

Creo que me voy a tomar unas vacaciones ;-).

Spotify, Tidal, Google Music (y más) en bitperfect en Linux y OS X

noreply@blogger.com (Pablo Felip) — Tue, 02 May 2017 00:45:00 +0000

Pero... ¿cuál es el problema?

Una de las quejas más frecuentes de los usuarios de los distintos servicios de streaming de audio, después de la que supone el uso de codecs con compresión con pérdidas (Spotify y Google Music) es la que tiene que ver con el software de reproducción.

Aunque en ocasiones dispondremos de programas nativos para acceder al servicio correspondiente, como es el caso de Spotify para Windows, OS X y Linux (excelente soporte multiplataforma) o Tidal para Windows y OS X, en otras deberemos recurrir a una interfaz web, más o menos afortunada, y a un navegador desde la que explorarla, como ocurre con Google Music. Lo que es común a todos los casos es la incapacidad de unas u otras alternativas de saltarse el mezclador de audio del sistema y utilizar el dispositivo de sonido de modo transparente, directo y exclusivo, esto es, funcionar en lo que se conoce como modo bitperfect o modo de reproducción transparente.

Esta características se considera indispensable para alcanzar una reproducción de alta fidelidad puesto que de este modo las aplicaciones de reproducción evitan dos fenómenos que tienen lugar en el ámbito digital, en un escenario en el que varios procesos del sistema operativo compiten naturalmente por la capacidad de emitir sonido, y potencialmente pueden dañar la integridad del flujo de audio:

Remuestreo de los flujos de sonido a una frecuencia y profundidad de bits prefijadas por el sistema operativo en su configuración del mezclador.
Mezcla de estos streams de audio en uno solo, que es el que finalmente se envía al dispositivo de audio para su reproducción.

Además, estos dos procesos pueden llevar parejos otros fenómenos menos evidentes: normalización, compresión del rango dinámico, conversiones entre distintos formatos de representación numérica, incremento de la latencia (aunque esto en principio no tiene por qué empeorar la calidad percibida), etc. etc.

Todos los sistemas operativos utilizados en la actualidad disponen de mecanismos para conseguir la reproducción en modo transparente. En Windows tenemos WASAPI, soportado directamente por la arquitectura de audio de Windows, y ASIO (siempre y cuando el controlador del dispositivo lo admita), en OS X los propios servicios de Core Audio y en entornos Linux, ALSA. El problema nos lo encontramos si el reproductor no está diseñado para gestionar el audio utilizando estas funciones, como es el caso cuando hablamos de servicios de streaming.

En mi experiencia, y lejos de otras prácticas audiófilas más o menos esotéricas, el uso de un reproductor capaz de funcionar en modo bitperfect sí suele comportar mejoras audibles, al menos cuando el audio reproducido tiene cierta calidad. Sea por esto, sea por conseguir nuestra tan deseada tranquilidad audiófila, veamos pues qué podemos hacer para mejorar esta situación.

Algunas soluciones conocidas

Existen soluciones específicas, que no obstante dependen del sistema operativo y servicio de streaming particular empleado. Algunas muy conocidas son estas dos:

Si utilizamos Spotify en Windows podemos recurrir a Fidelify, un cliente de audio gratuito de alta calidad para el servicio que sí admite WASAPI.
En OS X, reproductores como Audirvana (de pago) permiten acceder al catálogo de Tidal (también Qobuz) y reproducir cualquier tema utilizando su motor de audio de alta calidad, que lógicamente es capaz de utilizar el modo exclusivo de Core Audio.

En ambos casos se trata, como podéis ver, de utilizar un proxy de audio, un intermediario que se conecta al servicio, evitando los modos de acceso, digamos, oficiales, y se las apaña por su cuenta para conseguir una reproducción de mayor calidad.

En este artículo voy a presentar una alternativa similar, pero aplicable de modo general a Spotify, Tidal, Google Music (y otros servicios como las radios de Tune-In o Pandora) y en sistemas Linux. Y gratuita, claro.

Bienvenidos a Mopidy

Si dirigimos la mirada hacia los servidores de audio de código abierto más populares disponibles en la actualidad nos encontraremos de un modo ubicuo con dos grandes protagonistas, con el permiso de Kodi y sus numerosas variantes y, por supuesto, los incontables servidores DLNA / UPnP de variado pelaje:

Logitech Media Server (LMS para los amigos) que, una vez trascendidos los Squeezeboxes originales, es el corazón de desarrollos tan interesantes como piCorePlayer, Daphile (gratuitos) o Max2Play (este de pago).
Music Player Daemon (MPD), que podemos hallar en el interior de un sinnúmero de desarrollos gratis total como Volumio, RuneAudio o Pi MusicBox, pero también, con modificaciones de mayor o menor alcance, propulsando streamers dedicados de conocidas marcas y frecuentemente elevado coste.

Es precisamente este último, Pi MusicBox, en el que nos vamos a fijar. Se trata de un reproductor para la Raspberry Pi bastante poco conocido y (quizás) de configuración algo antipática, pero que resulta ser una auténtica navaja suiza por lo que hace a sus capacidades. Además de permitir la reproducción de audio local (por supuesto) y ser capaz de hacerse pasar por renderer de audio DLNA / OpenHome y altavoz AirPlay, también puede conectarse a servicios como Google Music, Spotify o SoundCloud, haciendo la función de proxy descrita anteriomente, reproducir podcasts y radios por Internet de diferentes tipos, e incluso interactuar con servidores Subsonic. Casi nada.

Gran parte de todo ello se lo debe sin embargo a Mopidy, un desarrollo quizás incluso más oscuro que Pi MusicBox y que está profundamente asentado en sus entrañas digitales. Se trata de un servidor de audio extensible que a diferencia de Pi MusicBox puede ser instalado en un PC de uso no dedicado que corra OS X o Linux, de modo que podamos estar escuchando musiquita con él mientras trabajamos, navegamos en Audio Planet o hacemos cualquier otra cosa menos (o más) productiva.

Lo más interesante es que Mopidy ofrece una flexibilidad increíble a la hora de ajustar su configuración, flexibilidad que incluye la posibilidad de seleccionar el modo en que se gestionará (lo habéis adivinado) el dispositivo de audio.

Pero dejémonos de divulgación y establezcamos objetivos. Vamos a montar un tinglado capaz de:

Funcionar en un sistema Linux / OS X (aunque el tutorial lo desarrollaré en el primero) de modo no dedicado.
Conectarse a Spotify, Tidal y Google Music para explorar nuestra biblioteca, listas de reproducción y realizar búsquedas en sus catálogos a través de una interfaz web cómoda y vistosa.
Reproducir emisoras de radio por Internet de TuneIn.
Reproducir los flujos de audio de los servicios anteriores de modo bitperfect, a través de ALSA.

Mopidy es capaz de más, mucho más, pero en esta ocasión nos vamos a centrar exclusivamente en resolver el problema descrito más arriba, problema que, dicho sea de paso, también podríamos afrontar con un tinglado similar, quizás algo más aparatoso y complicado de poner en marcha, basado en Logitech Media Server.

Instalando y configurando Mopidy

Antes de comenzar, una advertencia importante: Mopidy requiere un entorno Python y una serie de librerías adicionales en el sistema de las que depende su buen funcionamiento. Pip, el instalador de paquetes Python, también nos va a venir muy bien. Pero esto es Linux, señores, y las circunstancias particulares del entorno y la distribución del sistema operativo de cada uno pueden variar (seguro que lo hacen), condicionando el proceso de instalación. Lo que sigue, por tanto, solo pretenden ser unas indicaciones generales y un registro de los pasos que he tenido que seguir en mi caso (Linux Mint 17.3 Cinnamon). Si no hay contratiempos (yo sí los tuve), el proceso se debería completar en unos minutos. Entramos pues en zona hostil para manazas... precaución, amigo audiófilo.

De entrada es posible que os encontréis con Mopidy entre el catálogo de programas instalables a golpe de clic en vuestra distribución. En mi caso fue así, pero la versión disponible era muy antigua y, además, faltaban en el repositorio de Mint la mayor parte de los paquetes necesarios para instalar las extensiones, que es donde está el meollo de la nuestra cuestión. Por esa razón, lo sano es instalar la aplicación directamente de los reproductores oficiales, en mi caso utilizando los de Debian.

Lo primero es añadir la clave GPG del repositorio de Mopidy:

wget -q -O - https://apt.mopidy.com/mopidy.gpg | sudo apt-key add -

A continuación añadimos el repositorio a nuestro gestor de paquetes. Yo lo he hecho a través de Synaptic.

Tras abrir la aplicación, pinchamos en Configuración :: Repositorios :: Repositorios adicionales.

Hacemos clic repetidamente sobre el botón +Agregar nuevo repositorio y escribimos secuencialmente (1 cada vez) las siguientes direcciones de los repositorios:

deb http://apt.mopidy.com/ stable main contrib non-free
deb-src http://apt.mopidy.com/ stable main contrib non-free

Ahora abrimos una terminal de comandos e instalamos Mopidy:

sudo apt-get update && sudo apt-get install mopidy

Mopidy tiene un elevado número de extensiones que expanden su funcionalidad. Necesitaremos las siguientes para lograr nuestros objetivos:

Mopidy-ALSAMixer: Mezclador de audio para ALSA.
Mopidy-Spotify: Acceso a Spotify.
Mopidy-GMusic: Acceso a Google Music.
Mopidy-Tidal: Acceso al catálogo de Tidal.
Mopidy-TuneIn: Acceso a emisoras de radio de TuneIn.
Mopidy-Iris: Interfaz web de control de Mopidy, ideal para Spotify.
Mopidy-Material-WebClient: Interfaz web alternativa que permite diferenciar mejor el catálogo de Spotify, Tidal y Google Music.

Ahora es cuando nos vendrá bien Pip. Para ver una lista de todos los módulos disponibles podemos utilizar el comando:

pip search mopidy

Como podréis ver hay un montón, muy variados y algunos con muy buena pinta. Dejaremos para otro día cosas como Pandora.

Para instalar un módulo de la lista usaremos:

sudo pip install nombre_del_módulo

Para desinstalar un módulo instalado:

sudo pip uninstall nombre_del_módulo

En nuestro caso:

sudo pip install Mopidy-alsamixer
sudo pip install Mopidy-spotify

sudo pip install Mopidy-GMusic
sudo pip install Mopidy-Tidal

sudo pip install Mopidy-TuneIn

sudo pip install Mopidy-Iris
sudo pip install Mopidy-Material-WebClient

Es posible que para resolver dependencias Pip instale automáticamente otros módulos. No hay problema con eso. Es importante instalar estos paquetes de uno en uno para comprobar que el proceso se desarrolla sin errores, así que teclearemos los comandos despacito, con buena letra y de uno en uno y prestaremos atención a los mensajes de Pip.

Ahora toca modificar a mano el archivo de configuración de Mopidy para hacer nuestra "magia" con ALSA, introducir nuestras credenciales de Spotify, Tidal y Google Music y optimizar alguna cosilla más.

No obstante, antes necesitamos saber como identifica ALSA el dispositivo de sonido que deseamos utilizar con Mopidy en modo exclusivo. Para ello recurriremos al comando;

aplay -l

En mi caso esto es lo que aparece en pantalla:

pablo@menos-mint ~ $ aplay -l

**** Lista de PLAYBACK dispositivos hardware ****

tarjeta 0: STX [Xonar STX], dispositivo 0: Multichannel [Multichannel]

Subdispositivos: 1/1

Subdispositivo #0: subdevice #0

tarjeta 0: STX [Xonar STX], dispositivo 1: Digital [Digital]

Subdispositivos: 1/1

Subdispositivo #0: subdevice #0

tarjeta 1: Intel [HDA Intel], dispositivo 0: ALC889A Analog [ALC889A Analog]

Subdispositivos: 1/1

Subdispositivo #0: subdevice #0

tarjeta 1: Intel [HDA Intel], dispositivo 1: ALC889A Digital [ALC889A Digital]

Subdispositivos: 1/1

Subdispositivo #0: subdevice #0

En mi PC hay dos interfaces de audio (tarjeta 0 y tarjeta 1): una Asus Xonar STX y el integrado en la placa base, un ALC889A de Intel. Cada una de ellos tiene, a su vez, dos dispositivos (dispositivos 0, 1). El primero se corresponde en cada caso con la salida analógica, en tanto que el segundo representa la salida digital. En rojo el que vamos a utilizar.

ALSA utiliza una nomenclatura determinada para etiquetar los dispositivos de audio del sistema. En nuestro caso será:

hw:0,0 (donde los ceros representan tarjeta y dispositivo, respectivamente)

o también, si somos más expresivos:

hw:CARD=STX,DEV=0 (esta nomenclatura quizás resulte más clara)

Con esta información importante en el bolsillo, nos dirigimos ahora sí a editar el archivo de configuración, que se encuentra en:

~/.config/mopidy/mopidy.conf (donde el símbolo ~ representa la carpeta del perfil del usuario)

Para ello tecleamos:

gedit .config/mopidy/mopidy.conf

El archivo de texto está estructurado en diversas secciones, cada una de ellas precedida por su nombre entre corchetes [..], que contienen un serie de parámetros y sus respectivos valores. Por defecto, las precedidas por un # están comentadas, pero sirven para informarnos de los valores por defecto que tomará Mopidy en ausencia de un par (parámetro, valor) asignado por el usuario (esto es, sin el # como prefijo).

Vamos a revisar las que tenemos que modificar.

[audio]

mixer = alsamixer

mixer_volume = 100

output = alsasink device=hw:CARD=STX,DEV=0

#buffer_time =

[alsamixer]

enabled = true

card = 0

control = Master

#min_volume = 0

#max_volume = 100

#volume_scale = cubic

Aquí le decimos a Mopidy que vamos a utilizar ALSA y cuál es el dispositivo de salida que queremos emplear (recordad, lo hemos obtenido hace un momento). Destaco nuevamente en rojo su identificador. Que no os desconcierte el término "mixer" aquí y allá, no se va a producir mezcla alguna de flujos de audio. Ajustamos el volumen a 100, pero activamos la posibilidad de control del mismo a través del control maestro de la Asus Xonar STX.

Vamos ahora a por Spotify, Tidal y Google Music. Recordad, al resto de parámetros del archivo de configuración, dentro de cada sección, no les tocaremos ni un pelo. Solo modificaremos los enumerados en este tutorial (destaco en rojo los cruciales para el funcionamiento del servicio).

[spotify]

enabled = true

username = usuario_de_spotify

password = clave_de_spotify

bitrate = 320

volume_normalization = false

[tidal]
enabled = true
username = usuario_de_Tidal
password = clave_de_Tidal
quality = LOSSLESS

[gmusic]

enabled = true

username = usuario_de_Google_Music

password = clave_de_Google_Music

bitrate = 320

all_access = true

Es necesario disponer de cuenta de pago en Spotify y Tidal. En Google Music, sin embargo, podremos ojear y reproducir las pistas que hayamos subido al servicio si solo disponemos de cuenta gratuita. Si contamos con una subscripción de pago además tendremos acceso a todo el catálogo.

Ahora desactivaremos unos cuantos complementos que no vamos a necesitar puesto que solo queremos escuchar música en streaming. Viva la personalización.

[m3u]

enabled = false

[file]

enabled = false

[local]

enabled = false

Y, por último, desactivamos el control de volumen software, por si las moscas:

[softwaremixer]

enabled = false

El servicio TuneIn no tiene ajustes aquí, así que hemos terminado. Es momento de comprobar si nuestro servidor Mopidy tuneado arranca. Vamos a la línea de comandos y tecleamos:

mopidy

Si lo que aparece es algo como esto podemos cantar victoria, lo hemos conseguido.

INFO Starting Mopidy 2.1.0
INFO Loading config from builtin defaults
INFO Loading config from /home/pablo/.config/mopidy/mopidy.conf
INFO Loading config from command line options
INFO Enabled extensions: spotify, mpd, alsamixer, http, stream, iris, gmusic, material-webclient, local-images, tidal, tunein
INFO Disabled extensions: m3u, softwaremixer, local, file
INFO Starting Mopidy mixer: AlsaMixer
INFO Mixing using ALSA, card 0, mixer control "Master"
INFO Mixer volume set to 100
INFO Starting Mopidy audio
INFO Starting Mopidy backends: TuneInBackend, SpotifyBackend, GMusicBackend, TidalBackend, StreamBackend
INFO Audio output set to "alsasink device=hw:CARD=STX,DEV=0"
INFO Connecting to TIDAL.. Quality = LOSSLESS
INFO Logged in to Spotify in offline mode
INFO Logged in to Spotify in online mode
INFO TIDAL Login OK
INFO Logged in to Google Music
INFO Start refreshing Google Music library
INFO Start refreshing Google Music playlists
INFO Starting Mopidy core
INFO Finished refreshing Google Music library in 1s
INFO Loaded 1 playlists from Google Music
INFO Finished refreshing Google Music playlists in 1s
INFO Starting Mopidy frontends: IrisFrontend, GMusicScrobblerFrontend, MpdFrontend, HttpFrontend
INFO Starting Iris 2.13.15
INFO MPD server running at [::ffff:127.0.0.1]:6600
INFO HTTP server running at [::ffff:127.0.0.1]:6680
INFO Starting GLib mainloop

Destaco nuevamente en rojo las líneas que nos confirman cosas buenas. Todas son importantes, pero esas más puesto que tienen que ver con las extensiones cargadas y la configuración del dispositivo de audio.

El control del cursor no vuelve al usuario tras invocar Mopidy en la terminal de comandos. Mopidy se está ejecutando y por tanto la ventana se bloquea. Si la cerramos o pulsamos CTRL+C finalizaremos el proceso y Mopidy se detendrá. Es posible configurar Mopidy para que arranque automáticamente de modo silencioso, al iniciar el ordenador, quedando de ese modo disponible en segundo plano para su uso en cualquier momento. No obstante yo he preferido crear un script de inicio (no olvidemos hacerlo ejecutable) y un acceso directo al mismo para abrirlo manualmente cuando sea necesario.

¿Y si las cosas no han ido bien a la primera y en la ventana de inicio nos aparecen mensajes indicando que ciertos servicios no han arrancado?

Lamentablemente no hay una respuesta única válida para todos los casos. Esto es Linux (otra vez), si no te sientes cómodo con ello cómprate un Mac o instala Windows y aprende a vivir con las limitaciones de ambos sistemas. Desgraciadamente, no hay más. La curva de aprendizaje puede ser pronunciada, pero hay muchísima gente dispuesta a echar un cable y la sensación de satisfacción cuando se consigue algo, aprendiendo en el proceso, libera tantas endorfinas como correr 15 kilómetros de una tacada. O más.

Sigamos por tanto adelante. Si las cosas fallan y Mopidy no arranca en absoluto o fallan algunas de las extensiones hay que revisar todos los pasos, comprobar que nuestro sistema cumple los requisitos por lo que hace a los paquetes instalados previamente y tirar mucho de Google buscando el mensaje o mensajes de error concretos que nos aparezcan para tratar de acotar el problema y encontrar una solución.

En mi caso particular (por ejemplo), Mopidy no funcionó inicialmente quejándose de la versión de Tornado (un módulo Python relacionado con servicios de comunicación web) presente en mi sistema. Lo solucioné actualizándolo a la versión 4.5.1:

sudo pip install --upgrade Tornado

Por cierto, a la hora de averiguar por qué las cosas están fallando resulta muy útil determinar la versión de los distintos módulos Python instalados, así:

pip show nombre_del_módulo

Por ejemplo:

pip show tornado
---
Name: tornado
Version: 4.5.1
Location: /usr/local/lib/python2.7/dist-packages
Requires: backports.ssl-match-hostname, singledispatch, certifi, backports-abc

A partir de ahí Mopidy arrancó ya más o menos normalmente. El problema más grave, que me llevó un buen rato solucionar, tuvo que ver con la extensión de Google Music, que inicialmente no cargaba, apareciendo un mensaje en al arranque de Mopidy diciendo que la versión disponible en el sistema del módulo Python requests no era compatible. Tras forzar una actualización a la versión 2.13.0 con...

sudo pip install --upgrade requests

... la cosa empeoró, esta vez con una parrafada en color rojo emitida por Mopidy al iniciarse que no pintaba nada, nada bien y que concluía con un fastidioso:

from google.protobuf import symbol_database as _symbol_database
ImportError: cannot import name symbol_database

Tras darle más de dos y más de tres vueltas al asunto, finalmente conseguí solucionarlo desinstalando un vestigio del módulo Python protobuf que estaba haciendo la pascua en mi sistema:

sudo apt-get remove python-protobuf

Otro consejo: en estos escenarios pantanosos de pruebas repletas de incertidumbre conviene anotar las versiones de los módulos instalados que toqueteamos por si, tras una actualización, hay que practicar una regresión de alguno de ellos para evitar males mayores. Con este fin, el comando Pip permite indicar la versión que deseamos instalar. Por ejemplo...

sudo pip install requests==2.2.1

...instala la versión 2.2.1 del módulo requests (sí, el que me hizo pasar un buen rato la madrugada que estuve echando a andar todo esto).

Ojo los que seáis de tiro fácil: todas estas cosas hay que hacerlas con cautela.

Lamento no poder dar instrucciones más concretas ante la ingente cantidad de problemas que pueden surgir, pero si os encontráis con ellos no tenéis más que pasaros por el hilo en el que colgaré este artículo en Audio Planet para comentar la jugada. Seguro que la cosa tiene solución.

Demos pues por cerrada la (espero poco) accidentada instalación de este tinglado y pasemos a ver si el esfuerzo ha merecido la pena.

¿Y esto qué pinta tiene?

Lancemos Mopidy y salgamos de dudas:

mopidy

Como algún lector avispado es posible que ya haya averiguado al hurgar en el archivo de configuración de Mopidy, la interfaz web de control de Mopidy se encuentra en:

http://127.0.0.1:6680

Recordemos que 127.0.0.1 es una dirección IP especial que representa siempre al propio sistema. Abramos por tanto un navegador para acceder. Esto es lo que veremos:

Vamos a olvidarnos de images, se trata de un módulo interno que no nos interesa en estos momentos. Veremos otros 2 enlaces, iris y material-webclient. Si repasais la sección en la que hablábamos de las extensiones que íbamos a instalar, comprobaréis que se trata de sendas interfaces de control web de Mopidy. La chula es la primera, iris, que además se adapta como un guante al modo en que funciona Spotify. La segunda es un cliente web que podemos utilizar alternativamente para ojear con mayor facilidad el catálogo de Tidal o Google Music o TuneIn. Lo suyo, en estos momentos, sería que abrierais ambas interfaces en sendas pestañas y las agregarais a los favoritos / marcadores de vuestro navegador para un rápido acceso.

Comencemos con Iris (en http://127.0.0.1:6680/iris). Primeramente haremos clic en Settings para comprobar el estado de la extensión. Veremos que aunque nuestro perfil de Spotify ha sido reconocido es necesaria una autenticación adicional para acceder sin restricciones al catálogo del servicio. Haremos clic en el botón LOG IN y seguiremos las instrucciones.

¡Atención! Si tenéis un bloqueador de ventas emergentes desconectadlo temporalmente ahora para acceder sin problemas a la ventana de autorización.

De regreso a la ventana de ajustes comprobaremos que ahora sí todo está en orden. Verificaremos también que los backends adicionales (las extensiones de Mopidy que nos dan acceso a Google Music, Tidal, y TuneIn) están activadas.

Solo queda pues disfrutar del servicio. Algunas capturas, por favor...

Como podéis apreciar, Iris es una replica extremadamente funcional y de magnífico diseño de la interfaz web de Spotify. Tenemos de todo: recomendaciones, novedades, catálogo por géneros musicales, nuevos lanzamientos, artistas similares, biografías, imágenes contextuales, diferentes vistas y criterios de ordenación y acceso inmediato a toda la biblioteca personal que hayamos ido construyendo en Spotify. Y ahora podemos disfrutar de todo esto en modo bitperfect.

Comprobaréis que otros catálogos (Tidal, Google Music, TuneIn) no aparecen por ningún lado. Para llegar a ellos tendremos que utilizar la función de búsqueda. Iris ofrecerá primeramente los resultados de Spotify y, a continuación los obtenidos de otros repositorios de búsqueda (los famosos backends), empleando iconos para diferenciar los procedentes de Spotify y Google Music. Cuando nos encontremos con una pista, disco, etc. sin icono... se tratará casi con total seguridad de un elemento extraído de Tidal. No es lo ideal (quizás en un futuro Iris se actualice para dar mejor soporte a otros catálogos musicales), pero al menos resulta funcional.

Lo bueno es que si hacemos clic sobre un álbum o artista de Google Music o Tidal pasaremos a explorar el catálogo correspondiente, siendo ya muy fácil localizar, por ejemplo, todos sus discos. En esta página, a la que hemos llegado haciendo clic en el nombre del artista en cualquiera de los resultados de búsqueda en los que Iris no ha mostrado icono identificativo, vemos todo lo que Tidal tiene de McEnroe, incluyendo una página con información general (About).

Y, por supuesto, sin perdidas.

Si echáis de menos la posibilidad de acceder a vuestros álbumes favoritos / música subida de / a Google Music o Tidal de un modo más diferenciado o simplemente recorrer las estaciones de radio de TuneIn, aún a costa de perder el extremadamente depurado aspecto y funcionalidad de Iris, posiblemente prefiráis la segunda interfaz web de control, material-webclient, que está accesible en http://127.0.0.1:6680/material-webclient.

Desde la sección Library podremos ahora recorrer los catálogos de los cuatro servicios configurados de modo explícito.

Aquí tenemos la música propia que he subido a Google Music. El cuadro de búsqueda que aparece en cada sección lógicamente solo la realizará dentro del catálogo correspondiente:

Y aquí las listas de reproducción de Spotify:

Por último, en esta imagen podemos ver el funcionamiento del directorio de emisoras de TuneIn:

Bueno, ha sido largo pero creo que ha merecido la pena, ¿no os parece?

SACD... ¿DSD o PCM? Husmeando en HRAudio.net (aka SA-CD.net)

noreply@blogger.com (Pablo Felip) — Sun, 29 Jan 2017 15:09:00 +0000

Una de las discusiones más frecuente en foros audiófilos es la que trata de demostrar la superioridad universal de determinados formatos de grabación y distribución de audio.

Aunque para muchos aficionados esta es una cuestión superada (lo importante no es tanto el formato como el modo en que se ha realizado la toma de sonido, la mezcla y la producción en el estudio), no resulta infrecuente que surjan encendidas y recurrentes discusiones en las que se dan cita partidarios de soportes analógicos, defensores a ultranza de lo digital, adalides de los formatos PCM de alta resolución y, cómo no, abanderados del SACD, ese formato inventado por Sony y Philips a finales del siglo pasado y que, a pesar de su escasa popularidad (poco más de 11.000 discos editados en total a lo largo de 20 años de historia), parece resistirse a morir.

A diferencia del audio codificado en PCM, que emplea un número de bits que típicamente oscila entre 16 y 32 para representar cada muestra de sonido, los discos SACD se sirven de un formato denominado DSD basado en el uso de una modulación digital por densidad de impulsos (PDM). En esencia, se trata de codificar la magnitud de cada una de las muestras de sonido utilizando una señal cuadrada de amplitud máxima constante pero anchura variable, lo que en el ámbito digital, en definitiva, no es otra cosa que un rápido flujo de bits {0,1} colocados en fila india.

Me permitiréis que utilice un fragmento extraído de un artículo ya publicado anteriormente en este blog para profundizar un poquito en esta, en principio, peculiar estrategia de codificación digital.

El formato DSD se caracteriza por emplear una representació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 DSD64 porque la frecuencia de muestreo es 64 veces la empleada en un CD adherido al estándar del Libro Rojo (44,1 Khz) o DSDx1 (simplemente DSD). El resultado es por tanto una señal de muy alta frecuencia pero 1 solo bit de resolución.

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 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 el 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. 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 (la joroba en la línea superior) crece mucho a partir de 20Khz:

Sí, lo habéis leído bien: el ancho de banda del formato DSD 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 del corte, 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 (DSD128 o DSDx2), 11,2896 Mhz (DSD256 o DSDx4) y 22,5792 Mhz (DSD512 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.

A partir de esta breve introducción técnica podríamos enfangarnos en un interminable debate acerca de si realmente, como Philips y especialmente Sony nos contaron hace más de 20 años, la codificación DSD es más cercana al fenómeno sonoro (analógico) y por tanto suena mejor (más natural) que las estrategias basadas en PCM multibit más convencionales. Pero este artículo no va de esto, así que pasemos sobre esta cuestión sin mayor comentario admitiendo tentativamente que la codificación DSD sea efectivamente superior a la PCM multibit convencional (que ya es mucho suponer).

El problema son los detalles (últimamente no me puedo quitar esa idea de la cabeza). Y esos detalles están extraordinariamente bien explicados en este artículo técnico de Grimm Audio, en el que se hace un repaso histórico del formato y de una serie de circunstancias que han rodeado su uso en el mundo real:

DSD Myth white paper

Resumamos el artículo en 3 ideas:

Cuando los SACD comenzaron a gozar de cierta popularidad, los conversores A/D utilizados en los estudios de grabación no operaban en un formato idéntico al DSD (1 bit / 2,8 Mhz). Por esta razón era necesario procesar digitalmente la señal capturada para recodificarla en el formato estandarizado por Sony y Philips, que no tuvieron margen de maniobra para escoger otro de mayor calidad... simplemente porque las grabaciones no hubieran cabido en el disco físico adoptado por el estándar SACD, que no olvidemos, es un simple DVD.
El proceso de mezcla y producción en el estudio no podía realizarse directamente sobre la señal DSD, siendo necesario convertirla a PCM para después transformarla nuevamente a DSD. Aunque con el tiempo han surgido estaciones de procesamiento de audio capaces de operar directamente sobre el flujo DSD, estas capacidades son, incluso en el momento actual, incompletas y distan mucho de lo que se puede hacer en PCM. Por ello, la gran mayoría de SACD, según el artículo, han sido editados realmente en PCM. De hecho, incluso Philips en su momento comenzó a utilizar como formato preferido el PCM a 384 Khz y 24 bits para edición en estudio, formato posteriormente rebautizado como DXD.
Por último, los DACs presentes en la inmensa mayoría de reproductores allá por el 1997, incluso los utilizados en los reproductores de SACD, utilizaban internamente una representación sigma - delta de tipo multibit, por lo que necesariamente se producía una recodificación digital previa a la propia conversión D/A. Aunque en estos momentos existen DACs que, supuestamente, disponen de una ruta "pura" para el tratamiento de la señal DSD, en muchos casos incluso los diagramas técnicos resultan lo suficientemente confusos como para que no resulte fácil asegurarlo, en tanto que en otros simplemente se sigue practicando una recodificación de tipo multibit en las entrañas del DAC.

En definitiva, lo que nos cuentan los chicos de Grimm es que la cadena de audio, que Sony y Philips pretendían preservar tan natural y cercana al sonido analógico original...

...se transforma habitualmente, como resultado de la recodificación practicada en algún punto desde la toma de sonido hasta nuestro amplificador, en las etapas de grabación, masterización o reproducción, en algo ya no tan simple y notablemente alejado de la, reconozcámoslo, encomiable idea original:

Pero dejemos de lado lo que pueda pasar en las tripas del DAC de un reproductor y centrémonos no obstante en otro de los aspectos de todo este asunto que el artículo nos hace cuestionar: ¿Tenemos la seguridad de que en los SACD disponibles en el mercado se ha respetado la cadena de producción, manteniendo la señal DSD íntegra, al menos hasta la estampación del policarbonato plástico del disco SACD físico? ¿Cuántos han sido creados de modo que este principio permanezca escrupulosamente inviolado?

De entrada he examinado los libretos que acompañan a la treintena larga de SACD que tengo en casa, cosa que os invito a hacer con los vuestros. De entre ellos, solo 2 contienen alguna mención del proceso de producción:

Así es, ambos han sufrido una conversión a PCM de 96/24 en el proceso de producción.

Intrigado por esta cuestión, me dirigí hace unos días a SA-CD.net. Como algunos probablemente ya sepáis, se trata de una página web de carácter enciclopédico dedicada a la catalogación de todos y cada uno de los discos SACD editados hasta el momento (y algún que otro Blu-ray Audio). En ella podemos encontrar, en forma de fichas específicas para cada disco publicado, información extremadamente relevante: sellos, obras, músicos participantes, fecha de edición, comentarios sobre su calidad e incluso detalles relativos a su grabación y al modo en que ha sido realizada.

Existe además una nueva versión del portal, con exactamente la misma información, pero un aspecto actualizado, más moderno, en HRaudio.net.

Ninguno de los dos sitios web ofrece información de resumen que permita conocer qué porcentaje de discos son realmente DSD y, lógicamente, ir abriendo una por una las fichas de cada uno de ellos no es una opción aceptable.

Por ello, he confeccionado un pequeño script en Python que, en unas pocas horas, es capaz de analizar (parsear, en jerga de informáticos) las más de 11.000 páginas asociadas a cada uno de los trabajos catalogados en SA-CD.net (realmente interroga al nuevo sitio web en HRAudio.net) y generar información de resumen en formato de texto:

C:\Users\pablo\PycharmProjects\ParseoSACD\ParseoSACDnet.py

# Librerías necesarias

from bs4 import BeautifulSoup

import requests

import random

import time

inicio = 1 # 1

fin = 12054 # 12054 a 17/01/17

# URL base de parseo

url_base = 'www.hraudio.net/showmusic.php?title='

# Contadores de tipo de grabación

tgrabacion = ['PCM','PCM 24/48','PCM 24/96','PCM 24/192','PCM 24/44','PCM 24/88','PCM 24/176',

'DXD','DSD','Analogue','DESCONOCIDO','NOINFO']

ntipos = len(tgrabacion) - 2

ngrabacion = (ntipos+2)*[0]

# SACD parseados

ndiscos = 0

print()

# Introducir rango de parseo

#inicio = int(input('ID PRIMER disco en la base de datos: '))

#fin = int(input('ID ÚLTIMO disco en la base de datos: '))

print()

# Bucle de parseo

for id in range(inicio, fin+1):

# URL base para parseo

url = url_base + str(id)

# Pausa en el parseo para no agobiar al servidor

time.sleep(random.randint(1,2))

# Capturar el hml de la pagina web y crear un objeto Response

r = requests.get("http://" + url)

data = r.text

soup = BeautifulSoup(data, 'lxml')

# Obtener título de la página, tratar de obtener título del álbum (tras "-" )

titulo = soup.title.text[soup.title.text.index('-')+2:]

# Obtener sección con información de la grabación

grabacion = soup.find(id='recording_text')

# Tratar de localizar logo SACD

logoSACD = soup.find(alt='SACD')

# Detectar si el URL redirige a página de inicio

if titulo != 'High Resolution Audio':

# ID contiene disco

if logoSACD != None:

# ID corresponde a disco SACD

ndiscos = ndiscos + 1

if grabacion != None:

# Hay sección "Grabación", tomar primera palabra

info = grabacion.text.split()[0]

# Determinar si hay más información sobre resolución PCM,

# aparece en 3er lugar

if len(grabacion.text.split()) >= 3:

info2 = grabacion.text.split()[2]

if info2[0:3] in ['16/','24/','32/']:

info = info + ' ' + info2

# Clasificar SACD en categoría

if info in tgrabacion[0:ntipos]:

# Es un tipo conocido

i = tgrabacion.index(info)

ngrabacion[i] = ngrabacion[i] + 1

else:

# Es un tipo desconocido

ngrabacion[ntipos] = ngrabacion[ntipos] + 1

else:

# No hay sección "Grabación"

info ="NOINFO"

# Conteo

ngrabacion[ntipos+1] = ngrabacion[ntipos+1] + 1

print(format(id,'5d'), '\t',format(url,'<41'),'\t', format(info,'<12'), '\t', titulo)

else:

# El disco no es SACD

print(format(id,'5d'), '\t',format(url,'<41'),'\t','No es SACD')

else:

# ID vacio

print(format(id,'5d'), '\t',format(url,'<41'),'\t','No existe')

# Imprimir resultados

print ('\nSACD:',ndiscos,'->')

for i in range(0,ntipos+2):

print ('\t\t\t',format(tgrabacion[i]+':','<13'),format(ngrabacion[i],'5d'),'['+format(100*ngrabacion[i]/ndiscos,'0.2f')+'%]')

print()

Aquí el script en acción:

Tanto SA-CD.net como HRAudio.net están construidos utilizando HTML no demasiado bien estructurado, lo que dificulta un poquito la recogida de datos. La información relativa a la grabación aparece amontonada (si es que aparece) junto a otros detalles en una determinada sección de la página (ficha) de cada trabajo existente en el repositorio. Aunque el script intenta localizar la información relevante en las tripas del código HTML de la página, no siempre consigue interpretarla al 100%. Por ello, una vez volcada la información obtenida de modo automático en una hoja de cálculo de Google, ha sido necesario un pequeño trabajo adicional con su herramienta de filtros para refinar al máximo los datos cosechados.

Podéis consultar en línea esta hoja de calculo:

Parseo SA-CD.net (a 29/01/17)

Veréis que hay 3 pestañas en el documento:

Original parseado: son los datos en bruto recogidos por el script ParseoSACDnet.py. Cada fila representa un disco, cuya ficha podéis consultar en HRAudio.net sin más que hacer clic en el enlace de la columna B.
Refinado: Aquí se han eliminado los discos Blu-ray Audio catalogados, se han corregido algunos errores menores de parseo, etc.
Resumen: En esta hoja está lo interesante: una tabla dinámica y un gráfico asociado que resumen estadísticamente las características de los SACD analizados.

¿Y qué es lo que averiguamos? Pues que de la mayor parte de los SACD editados, al igual que ocurría con la pequeña muestra constituida por mis propios SACD, no hay información acerca del tipo de grabación (62,71%), lo que personalmente me resulta sospechoso. Después de todo, si la razón que da sentido a la existencia de los SACD es precisamente el uso de una estrategia de codificación superior, ¿por qué el sello discográfico obvia esta información?

Por otro lado, algo más de un 8% de los SACD han sufrido un proceso declarado de conversión a PCM (recordemos que DXD es PCM) en algún punto de su proceso de creación. Llama la atención que en algunos casos incluso a 44/24.

Algo más de un 13,5% se declaran como "analogicos". Y esto ¿qué significa? ¿Que la digitalización se ha realizado a partir de un master original analógico? Pero ¿con un conversor A/D DSD puro o no? ¿Y cómo se ha realizado la edición en el estudio? No hay forma de saberlo.

Por último, solo en algo más de un 15% de los discos SACD contenidos en HRAudio.net se menciona el escueto término "DSD" en el área destinada a mostrar información acerca del tipo de grabación ¿Quiere decir que todo el proceso se ha mantenido en estos casos en el ámbito de la codificación DSD? Personalmente, no me atrevería a asegurarlo.

Bien, estos son los hechos. A partir de ellos cada cual extraerá sus propias conclusiones.

¿Es el SACD un formato revolucionario? En mi opinión, en absoluto, lo que no me impide reconocer que en una gran cantidad de discos editados en formato SACD (quizás en la mayoría) se ha puesto un enorme cuidado en la grabación y producción, siendo el resultado, desde un punto de vista sonoro, incuestionablemente brillante.

¿Sonarían igual de bien en PCM, incluso de 44/16, o en PCM transcodificado al vuelo a DSD64/128/256 por un reproductor capaz de hacerlo como Foobar, JRiver o HQPlayer? Probablemente... pero esto ya es cosa de cada uno.

Cómo (no) usar Audacity y Spek para llegar a conclusiones erróneas (II)

noreply@blogger.com (Pablo Felip) — Fri, 20 Jan 2017 18:40:00 +0000

Tras el shock inicial que supuso el artículo publicado hace unos días en este mismo espacio, Cómo (no) usar Audacity y Spek para llegar a conclusiones erróneas (I), en el que se discutía el uso incorrecto de aplicaciones de procesado y análisis de audio, vamos ahora con la no menos intrigante (espero) 2ª parte.

El Emepretés, ese formato proscrito en cualquier ambiente audiófilo que se precie y que, al mismo tiempo, tanto ha contribuido a democratizar el acceso a la cultura musical y, quizás, a hacer algún que otro descubrimiento asombroso, va a ser precisamente el protagonista de esta segunda entrega.

Fenómeno 2: Encuentros en la 3ª fase con un archivo mp3
¿Quién es ese mp3 y qué le ha hecho a mi archivo wav?

Nuestro experimento consistirá en esta ocasión en:

1. Tomar un archivo wav (pista A).
2. Convertirlo a mp3 utilizando Audacity (pista B).
3. Cargar en Audacity este archivo mp3 y exportarlo como wav (pista C).
4. Comparar los espectrogramas de B y C.

Como todos sabemos, la conversión de un archivo wav en mp3 supone una pérdida de información más o menos audible (en qué medida es algo que nos nos interesa discurtir en estos momentos). Ahora bien, dado que wav es un formato esencialmente transparente, si convertimos una pista de audio mp3 en wav no se producirá absolutamente ninguna pérdida, nos encontraremos con un archivo de un innecesario mayor tamaño pero que debe sonar, medir y pesar exactamente igual. De hecho, esgrimiendo esta certeza, las pistas ogg en mi I test de audio digital fueron recodificadas y publicadas en formato wav para que no fueran inmediatamente distinguibles unas de otras.

¿Estamos de acuerdo? Vamos a ver si es verdad.

Antes de comenzar recordemos que hay que configurar Audacity de modo correcto, tal y como comprobamos en la primera entrega de este artículo, para evitarnos disgustos:

Las pasos necesarios para realizar las 2 conversiones son análogos a los que seguimos en su momento, así que me limitaré en esta ocasión a presentaros las 3 pistas (archivos) de audio resultantes:

Veamos los espectrogramas de las pistas A, B y C que genera Spek:

Espectrograma pista A (wav original)

Clic sobre la imagen para ampliar

Espectrograma pista B (wav > mp3)

Clic sobre la imagen para ampliar

Espectrograma pista C (wav > mp3 > wav)

Clic sobre la imagen para ampliar

Nada inquietante, ¿verdad? En la pista B se aprecia el habitual recorte espectral por arriba (que en cualquier caso queda muy por encima de esos 16 o 17 Khz que algunos se empeñan en señalar, supongo que como consecuencia de utilizar compresores del siglo pasado). Por su parte los espectrogramas de B y C parecen iguales, pero... ¿Seguro que son idénticos?

Recurramos a ImageDiff para hacer una comparación más fina:

Diferencias espectrogramas B y C

Clic sobre la imagen para ampliar

¡Ya la tenemos liada! Esa marea blanca indica que, en contra de la aparentemente obvia apreciación inicial, ambas pistas son distintas. Masivamente distintas. Lo que implica que el formato de archivo wav no es transparente. Fantástico. De nuevo tenemos una brecha espacio - temporal hacia una realidad alternativa abierta ante nuestros ojos.

Superpongamos ambos espectos de las pistas B (mp3) y C (wav exportado) y pongámoslos en movimiento.

Animación espectrogramas B (mp3) y C (wav final)

Clic sobre la imagen para ampliar

Los espectrogramas no es que sean distintos... es que parecen estar desfasados un número reducido, pero apreciable, de muestras. Para entenderlo debemos recordar en este punto que el eje horizontal del espectrograma representa el tiempo

Carguemos ahora las pistas en Audacity, B (abajo) y C (arriba), para observar sus formas de onda bajo el microscopio:

Como podéis comprobar están perfectamente alineadas. Todo un fenómeno.

Para justificar esto tendremos que sumergirnos en el maravillo mundo de los algoritmos de compresión con pérdidas. Concretamente, nos encontramos con un interesantísimo FAQ técnico en la página de LAME en Sourceforge. LAME es, probablemente, el compresor mp3 más popular en la actualidad, y también el que ofrece resultados de mayor calidad:

http://lame.sourceforge.net/tech-FAQ.txt

El FAQ responde a ciertas preguntas muy apropiadas en estos momentos de confusión:

1. Why is a decoded MP3 longer than the original .wav file?
2. Why does LAME add silence to the beginning each song?
3. Why does LAME add silence to the end of each song?
4. Why cant MP3 files be seamlessly spliced together?
5. What is the size of a MPEG1/2 frame?

Resumiendo un poco: LAME, como todos los compresores que se sirven de estrategias perceptuales para descartar elementos poco audibles y reducir así el tamaño del archivo resultante, se ve obligado a añadir muestras de relleno. Esto es así por la propia naturaleza del proceso de compresión, que debe procesar el flujo de audio en paquetes o tramas parcialmente superpuestas de tamaño fijo para hacer su magia sobre ellas (entre otras muchas cosas, aplicar una MDCT).

Sí, ya sé, es una explicación simplista. Si queréis la dura y aritmética realidad no tenéis más que leeros el FAQ. Y si con eso no os basta aquí tenéis más lectura de evasión: Audio Compression using Modified Discrete Cosine Transform: The mp3 Coding Standard.

Los descompresores (reproductores) mp3 más avanzados son capaces de identificar, en mayor o menor medida, las muestras de relleno inyectadas en el proceso de compresión y eliminarlas en el momento de la carga o reproducción

Lo que está ocurriendo aquí, precisamente, es que Audacity y Spek decodifican de un modo ligeramente distinto los archivos mp3 que cargamos en ellos. El primero recurre a LAME, como ya sabemos. El segundo, por su parte, emplea la conocida librería FFmpeg. El resultado es el que ya conocemos: las pistas aparecen perfectamente alineadas en Audacity pero claramente desplazadas en el tiempo cuando las analizamos con Spek. Nuevamente nos encontramos con el diablo y sus detalles.

Por si fuera poco, esta particularidad de los compresores basados en MDCT nos permite entender por qué razón es tan complicado conseguir la reproducción gapless (sin cortes) con archivos mp3 a menos que comprimamos todas las pistas en un único archivo mp3 y recurramos a una hoja cue, claro. Distintos reproductores lo consiguen con mayor o menor grado de éxito (transición continua o breve micro interrupción entre pistas), pero es que incluso un codificador mp3 de baja calidad puede dificultar la consecución de este objetivo al más pintado de los reproductores.

¿Y qué pasará si comparamos la pista wav original (A) con la wav obtenida finalmente a partir del mp3 (C).

Espectrogramas:

Animación espectrogramas A (wav inicial) y C (wav final)

Clic sobre la imagen para ampliar

Formas de onda, A (arriba) y C (abajo), en su inicio. El relleno con 0's se hace patente:

Más formas de onda, A (arriba) y C (abajo), esta vez en su final. El decalaje no coincide con el detectado al comienzo del fichero y, además, las muestras finales son distintas. Esto tiene toda la pinta de ser consecuencia del solapamiento de las tramas de audio que se aplica en el ámbito matemático del proceso de compresión a mp3.

Y ya que estamos, comparemos también sus tamaños de archivo, que como era de esperar difieren, siendo ligeramente mayor el wav obtenido a partir del mp3 (pista C, a la derecha).

El archivo wav original y el obtenido como resultado de una conversión intermedia a mp3 no son iguales. Esto ya lo sabíamos. La novedad es que no solo no lo son como resultado de la mutilación espectral característica de la codificación mp3, sino que estas diferencias también proceden de sutiles cambios en el tamaño de los archivos generados causados por los algoritmos de compresión aplicados.

Para concluir, me gustaría mencionar que de repetir estas pruebas con un compresor ogg en lugar del mp3 utilizado no nos encontraríamos con ninguna de las discrepancias, inicialmente misteriosas, que hemos verificado en este artículo. Otra razón, quizás, para preferirlo a mp3 a la hora de optar por un compresor con pérdidas.

Cómo (no) usar Audacity y Spek para llegar a conclusiones erróneas (I)

noreply@blogger.com (Pablo Felip) — Thu, 12 Jan 2017 20:00:00 +0000

Audacity y Spek son dos aplicaciones, gratuitas y multiplataforma (Windows, OS X, Linux), frecuentemente utilizadas para analizar todo tipo de archivos de audio, cosa a la que como sabéis soy bastante aficionado.

Audacity es un editor de audio multipista, compatible con una enorme variedad de formatos de audio, que además incorpora interesantes funciones de conversión y análisis.

Por su parte, Spek es un analizador de espectro capaz de trazar un gráfico en el que se representa el contenido en frecuencia de una muestra de audio a lo largo del tiempo. Esta herramienta se utiliza a menudo para comparar cuantitativamente la fidelidad de distintos formatos de audio (por ejemplo wav y mp3), reconociendo visualmente las diferencias en los gráficos generados por el programa: si tomo un archivo wav, lo convierto a mp3 (por ejemplo con Audacity) y comparo los espectrogramas de ambos es fácil detectar diferencias en los gráficos que denoten alteraciones en las muestras.

No obstante, pertrechado con tales armas no resulta difícil llegar a conclusiones erróneas, del tipo que desafían la lógica, cuestionan la naturaleza determinista de los algoritmos que ejecuta un ordenador e incluso ponen en duda la naturaleza esencial del universo audiófilo.

Veamos 2 ejemplos y, aprovechando la ocasión, introduzcamos también otras herramientas para enriquecer nuestro kit de de análisis digital.

Fenómeno 1: ¿Seguro que los bits son bits?

Los algoritmos de compresión sin pérdidas realmente sí pierden cosas (a veces)

Esta es una de las cuestiones más discutidas en foros como AudioPlanet. Es más, posiblemente a estas alturas muchos aficionados sigan creyendo a pies juntillas (o por el rabillo del ojo, que viene a ser lo mismo) que en la conversión de un archivo de tipo wav (recordemos, sin compresión de ningún tipo) a flac o alac (compresión sin pérdidas) se alteran a peor, de algún modo sutil e inaprensible, las muestras de audio presentes en el archivo original.

Los lectores más atentos habrán captado que en ningún momento estoy revoloteando alrededor de la afirmación (también recurrente) de que los archivos wav o aiff suenan mejor que los flac o alac.

Me quedo un par de pasos más atrás en la cadena de reproducción, en las intrincadas profundidades de los bits almacenados en los archivos de audio. Es más, me voy a cuidar muy mucho de dar un paso más allá, lo que por otra parte sería probablemente innecesario puesto que reputados gurús del mundillo, que en los últimos años han abrazado la nueva realidad digital que ha invadido esta afición, tales como John Darko, han encontrado ya una certera explicación a este singular fenómeno.

Less obvious to casual observers or computer audio newcomers is how software coders can elevate their app’s sound quality by reducing its thirst for CPU cycles and RAM, in turn reducing the amount of electrical noise generated.

Nada más que decir por mi parte, por tanto, sobre tan espinosa cuestión.

Volvamos a la afirmación inicial, que cuestiona la transparencia de una codificación con compresión pero sin pérdidas como es flac y vamos a ver qué nos cuentan Audacity y Spek. Para ello cualquier aficionado puede plantearse un sencillo experimento:

1. Descargar e instalar tanto Audacity como Spek en el ordenador.

2. Cargar un archivo de tipo wav en Audacity (pista A).

3. Exportar el archivo en formato flac (pista B).

4. Cargar el archivo flac en Audacity y re-exportarlo en formato wav (pista C).

5. Obtener y comparar la representación espectral de las pistas A y C.

Tomamos un archivo wav y lo recodificamos en flac. En este punto se habrán producido (o no) pérdidas. Dando un salto mortal, lo volvemos a convertir a wav y obtenemos los espectrogramas de ambos archivos, wav de partida (A) y final (C). Si ambos gráficos presentan discrepancias es que efectivamente la codificación en flac no es transparente (no respeta la integridad de la información presente en el wav original), lo que reforzaría incuestionablemente la postura de aquellos que perciben diferencias audibles cuando se codifica un archivo de audio empleando un formato de compresión sin pérdidas como flac.

El caso es que la constatación experimental de este hecho sería, en mi opinión, equivalente a la existencia de un glitch en nuestro espacio - tiempo, claro. Pero no nos dejemos llevar por este despreciable sesgo cognitivo. Procedamos con el experimento.

Para llevar a la práctica la prueba propuesta he tomado uno de los fragmentos codificados en formato wav utilizados en mi I test de audio digital, concretamente la pista 4, y la he sometido al proceso descrito, que vosotros mismos podéis verificar examinado los archivos de audio implicados y que del mismo modo os invito a reproducir si os apetece.

Aquí las pistas de audio en cuestión:

Aquí un vídeo del proceso seguido (no ajustéis el volumen, no tiene sonido). Probablemente querréis verlo en pantalla completa para apreciar mejor los espectrogramas que se muestran al final:

Quizás apreciaremos mejor el resultado superponiendo las gráficas que representan el contenido espectral de ambas pistas A y C que se ven en los últimos instantes del vídeo:

Animación espectrogramas A y C

Clic sobre la imagen para ampliar

Pero... ¿qué es esto? El archivo wav resultante de esta secuencia de conversiones wav > flac > wav es sutil pero claramente distinto al original ¿Podéis ver cómo los píxeles de la imagen parecen moverse en la zona superior del gráfico? Esto indica que se han producido cambios (pérdidas) que afectan a la parte alta del espectro, en la banda de 20 a 22 Khz. Puesto que las diferencias son evidentes no es necesario practicar una análisis más concienzudo.

Podéis repetir la prueba con cualquier archivo wav que tengáis en vuestro disco duro. El resultado será el mismo.

Después de todo resulta que la codificación en flac, que debería preservar totalmente la integridad de la señal, no lo hace. El mundo se abre bajo mis pies.

La explicación es, afortunadamente, otra. Para encontrarla deberemos bucear en las profundidades de las opciones de configuración de Audacity. Concretamente deberemos dirigirnos a:

Editar > Preferencias > Calidad

Este panel parece controlar algunos parámetros relacionados con el modo en que Audacity transforma la frecuencia de muestreo de las pistas de audio cargadas en la aplicación en determinadas circunstancias (conversión en tiempo real o transformaciones que dan lugar a una nueva pista definitiva). Es posible ajustar la calidad de la conversión y, además, decidir si se aplica dither o una críptica corrección con ruido blanco.

La aplicación de dither (o dithering) es una fascinante técnica empleada habitualmente en procesos de masterización para disminuir el efecto que sobre la calidad percibida tiene la distorsión de cuantización generada por una reducción del número de bits destinados a codificar las muestras, por ejemplo, al convertir audio de 24 a 16 bits. El fundamento matemático es durillo, pero en esencia se trata de sumarle a la pista a recodificar una señal aleatoria de muy pequeña amplitud. Esto hace que la correlación entre el error de cuantización y la muestra original disminuya, lo que se ha demostrado que es percibido como un sonido más natural puesto que el oído es menos sensible a un ruido impredecible que afecte a todas las frecuencias por igual que a las distorsión armónicas causadas por una recuantización a la baja sin dither. Casi nada.

Audacity solo menciona el término dither en los ajustes de conversión en tiempo real. No obstante, el sentido común nos dice que eso de la corrección con ruido blanco que se muestra en las opciones específicas de la conversión de alta calidad no debe ser otra cosa que una forma de dither ¿Una traducción incompleta? Quizás.

Vamos a desactivar este ajuste misterioso, a ver qué pasa.

Y ahora repitamos el experimento de conversión wav > flac > wav...

Veamos qué aspecto tienen ahora los espectrogramas de las pistas A y C2:

Animación espectrogramas A y C2

Clic sobre la imagen para ampliar

Mucho más tranquilizador, ¿no os parece?

Ahora bien... activemos el modo paranoico: Quizás nos estemos perdiendo algo. Quizás haya diferencias aún más sutiles en la imagen que escapan a nuestra vista, por más zoom sobre la animación que hagamos ¿Podemos mejorar este test para estar seguros de que, ahora sí, el formato flac es realmente sin pérdidas?

Por supuesto. Si los ojos nos engañan, recurramos a los algoritmos. Os presento una nueva herramienta denominada Image Diff.

Esta aplicación, que también está disponible para Windows, OS X y Linux, compara pixel a pixel dos imágenes dadas para identificar cualquier diferencia existente entre ellas. Vamos a ver qué pasa cuando la utilizamos para analizar comparativamente las gráficas de los espectrogramas correspondientes a los dos pares de pistas: A/C y A/C2:

Diferencias espectrogramas A y C

Clic sobre la imagen para ampliar

Diferencias espectrogramas A y C2

Clic sobre la imagen para ampliar

Los puntos blancos en el panel superior de la primera captura representan todos los píxeles que diferencian ambos espectrogramas. Hay muchos más de los que creímos apreciar hace solo un momento al compararlos de un vistazo en la primera de las animaciones. La segunda captura, en cambio, es totalmente oscura. Ni un solo punto blanco se atreve a iluminarse. Esto parece confirmar que, efectivamente, los espectrogramas de las pistas A y C2 son idénticas y, por tanto, flac sí es un códec transparente.

¿Alguien tiene alguna objeción? ¿No? Pues yo sí.

Un espectrograma no es otra cosa que un diagrama bidimensional que representa en el eje horizontal el tiempo y en el vertical la frecuencia. Cada punto del gráfico por tanto se puede denotar mediante sus coordenadas (t,f), calculándose su color a partir de la cantidad de información codificada en la pista de audio en el instante t y para la frecuencia f. Aunque esto no es exactamente así, lo asumiremos como cierto para no complicar en exceso este razonamiento, aceptando por tanto que la vaca es una esfera (mejor os cuento el chiste otro día). Cuando se representa un espectrograma en la ventana de una aplicación hay que encajar los intervalos de tiempo y frecuencia que caracterizan al primero dentro de los límites del área gráfica donde se dibujan, área que lógicamente tiene unas dimensiones limitadas. Lo que quiero poner con esto de manifiesto es que si los algoritmos de cálculo y representación en pantalla no están correctamente diseñados, podría suceder que ciertos detalles espectrales pasaran desapercibidos. Es raro que algo así ocurra con una aplicación, digamos, respetable. Pero no imposible, claro.

Llegados a este punto de locura existencial audiófila, por tanto, solo nos queda una alternativa posible: destripar los archivos y comprobar sus contenido, byte a byte. Y eso es precisamente lo que vamos a hacer.

Me gustaría añadir por tanto a nuestro kit de análisis una nueva aplicación: VBinDiff (Visual Binary Diff). VBinDiff es grande por varios motivos. Uno de ellos tiene que ver con el hecho de que funciona bien incluso con archivos de hasta 4 GB. Afortunadamente los nuestros no van a ser tan voluminosos. Por lo demás se trata de una herramienta sencilla, no dispone de interfaz gráfica ni tampoco de un bonito icono o logotipo que hubieran aportado algo más de vistosidad a esta sección del artículo.

A VBinDiff debemos indicarle qué 2 archivos queremos comparar invocándola mediante un comando como este desde una terminal de comandos:

VBinDiff.exe "Pista A.wav" "Pista C.wav"

Y esto es lo que veremos en pantalla:

En la parte superior tenemos el contenido de la pista A, en la inferior el de la pista B. Las 2 columnas de números a la izquierda representan la posición dentro de los archivos. Cada byte (0 - 255) está representado en notación hexadecimal (0x00 - 0xFF), que como todo el mundo sabe es el sistema de numeración preferido por replicantes y otros seres sintéticos.

De acuerdo con las especificaciones del formato wav, los primeros 44 bytes (que he coloreado de amarillo) son la cabecera y no contienen datos de audio. Los últimos 4 bytes de la cabecera (D4 C1 56 00) indican el número de bytes de datos que siguen a continuación. Como se emplea una ordenación de tipo Little Endian, los bytes deben ser leídos al reves (0x0056C1D4), es decir, 5.685.716 bytes, que sumados a la cabecera de 44 bytes nos da un tamaño total de 5.685.760 bytes. Justo lo que nos indica el explorador de archivos.

Comprobamos que ambas cabeceras son idénticas.

A partir de la posición 0x2C (44 en decimal) se almacenan las muestras de sonido en una representación en complemento a 2 (otra rareza propia de replicantes). Como se trata de audio redbook se emplean 16 bits (2 bytes) para codificar cada una de ellas, esto es, 2 numeritos hexadecimales que, recordemos, deben leerse de derecha a izquierda.

Y ahora sí, lo habéis adivinado, VBinDiff representa en rojo los bytes que difieren de un archivo al otro. Las discrepancias comienzan a partir de la 5ª muestra (posición 0x34 o 52 en decimal). Casi a continuación nos encontramos con un curioso patrón: los bytes que ocupan una posición par difieren habitualmente en muy pequeña medida y los que se encuentran en posición impar son siempre iguales. Recordemos aquello de la ordenación Little Endian y comparemos las muestras una a una:

Pista A: ... 0x0419 0xF2C7 0x05D7 0xF0D6 0x033B 0xEFE0 0x04C0 0xF171 ...

Pista C: ... 0x041A 0xF2C7 0x05D6 0xF0D7 0x033C 0xEFDD 0x04BF 0xF175 ...

La herramienta, con su esplendorosa interfaz de texto, permite el desplazamiento a lo largo y ancho del archivo utilizando los cursores y las teclas de AvPag, RePag, Inicio y Fin. También podemos presionar la tecla Intro para que VBinDiff salte al siguiente byte que difiere en la secuencia del archivo. Obviamente no vamos a comprobarlo porque hasta para un replicante, especialmente para los que son amantes de la música, es francamente aburrido ver cómo interminables secuencias de números hexadecimales se desplazan por la pantalla. Pero creedme cuando os digo que este patrón byte ligeramente distinto, byte igual se repite hasta el fin de los tiempos o, lo que es lo mismo, el final de ambos archivos.

Las muestras que se diferencian siempre lo hacen en su byte menos significativo, y además esa diferencia suele ser muy pequeña, de una magnitud de apenas 3 o 4 unidades en valor absoluto ¿Recordáis en que consistía el dither? Sí, esa señal aleatoria de pequeña magnitud que se sumaba a la original para reducir los errores de cuantización. Acabamos de encontrar a ese señor bajito en las entrañas binarias de nuestras pistas de audio. Por fin todo cuadra.

Como era de esperar, si comparamos ahora la pista A con la C2, obtenida tras desactivar la corrección con ruido blanco en Audacity, nos vamos a encontrar con el resultado esperado (y tranquilizador, añadiría):

VBinDiff.exe "Pista A.wav" "Pista C2.wav"

Ambos archivos, tanto el wav inicial como el obtenido a partir de la conversión intermedia en formato flac, son exactamente idénticos, sin asomo alguno de duda.

Esto demuestra que, contrariamente a las impresiones iniciales, flac (al igual que cualquier otro formato que recurra a la compresión sin pérdidas) es absolutamente transparente y preserva totalmente la integridad de los archivos de audio codificados.

No acabo de entender por qué Audacity, en su configuración predeterminada, inyecta una señal de ruido blanco a modo de dither cuando realiza una conversión de formato, máxime cuando este proceso no lleva parejo necesariamente un reajuste de la frecuencia de muestreo. Pero el caso es que lo hace... y los resultados pueden confundir al más pintado.

Mucho cuidado con los detalles, el diablo suele estar en ellos.

Y aquí la 2ª parte de este artículo:

Cómo (no) usar Audacity y Spek para llegar a conclusiones erróneas (II)

BubbleUPnP, Audiocast y uso de reproductores DLNA antiguos

noreply@blogger.com (Pablo Felip) — Tue, 10 Jan 2017 21:37:00 +0000

Estos días estoy redescubriendo Google Music, la alternativa de Google a Spotify y compañía, como consecuencia de su reciente oferta de 4 meses gratuitos, que estoy utilizando de modo conjunto con BubbleUPnP (3,99€ extraordinariamente bien empleados).

Esta conocida aplicación, que funciona como servidor, reproductor y punto de control DLNA viene aquí de perlas puesto que es capaz de conectarse a este servicio (además de a otras "nubes" como a las de Tidal, Google Drive, Qobuz, Amazon, Dropbox, etc.)...

...para actuar como interfaz de control alternativa a las propias apps nativas de Google Music, Tidal, etc.

Funcionando de este modo BubbleUPnP puede además enviar el audio recibido de estos servicios hacia dispositivos capaces de actuar como puntos de reproducción DLNA (perfil renderer) o simplemente hacia un Chromecast, de un modo análogo a lo que podríamos conseguir con un i-cacharro recurriendo a la conocida función AirPlay, integrada de un modo transversal en todos los dispositivos de Apple, desde ordenadores a móviles y tabletas.

No obstante el uso de Google Music (por ejemplo) desde BubbleUPnP presenta carencias. Por un lado, la reproducción sin pausas (gapless) falla en muchos dispositivos DLNA y, por otro, no es posible realizar búsquedas en el catálogo del servicio.

Afortunadamente BubbleUPnP es una auténtica navaja suiza. Una de sus funciones menos conocidas es la de emitir el audio de cualquier aplicación del sistema hacia un punto de reproducción DLNA, superando estas y otras limitaciones de algunas aplicaciones de audio nativas de Android, que si bien no es infrecuente que puedan emitir hacia un Chromecast suelen ser incapaces de entenderse con dispositivos DLNA o AirPlay. A esta característica de BubbleUPnP se la denomina Audio Cast, y se encuentra relativamente escondida en las profundidades de los ajustes de la aplicación:

Una vez activemos Audio Cast, dispondremos de un botón situado a la derecha de cada reproductor DLNA. Si lo pulsamos el audio de (casi) cualquier aplicación de Android será enviado hacia él, lo que nos permitirá emplear el servicio que deseemos (en mi caso Google Music) directamente a través de su app nativa disfrutando de todas sus funcionalidades.

Aquí podéis ver el tinglado en acción con OSMC corriendo en una Raspberry Pi 2 como punto de reproducción. Fijaos en que el audio se emite sin pérdidas de ningún tipo, de hecho en este caso se envía como LPCM 44/16 (1411Kbps):

Lamentablemente para disponer de Audio Cast necesitamos un móvil o tableta con root, esto es, que haya sido modificado para poder hacer cosas que, de serie, la seguridad de Android no permite. Este requisito es necesario puesto que es imprescindible instalar (realmente flashear en la ROM del dispositivo) previamente un componente denominado Xposed y un módulo sobre este último que permite finalmente la activación de Audio Cast.

El procedimiento no lleva más de 5 minutos en un dispositivo con root utilizando el instalador de Xposed disponible en los enlaces anteriores, y apenas 5 más si es necesario conseguir root previamente (nuevamente hay varias apps muy efectivas y compatibles con gran número de dispositivos, además de docenas de tutoriales en foros especializados). No obstante hay que advertir que esta modificación suele suponer la pérdida de la garantía y, si no se sabe bien lo que se hace, la aventura puede terminar con un dispositivo que no arranca. Mucho ojo.

Otra de las ventajas de aventurarse a activar Audio Cast tiene que ver con el uso de reproductores DLNA que no admitan el control desde apps como BubbleUPnP, esto es, carezcan de compatibilidad con el perfil renderer.

En este caso es posible "sintonizar" un flujo DLNA que genera BubbleUPnP y queda expuesto en la red local como si de un archivo almacenado en un servidor DLNA se tratase. Una vez nuestro reproductor DLNA abre este flujo (navegamos hasta él con su mando a distancia) ya solo es necesario reproducir lo que queramos en el móvil o teléfono, que sonará a través del primero (el montaje es similar al que se puede orquestar con el componente UPnP de Foobar). Aquí podéis ver esta función en acción utilizando el reproductor DLNA de mi receptor Pioneer SC-LX81, que ya tiene unos años a cuestas y no ofrece compatibilidad con el mencionado perfil:

Nuevamente podéis ver que la emisión se realiza en LPCM 44/16 con una tasa de bits de 1411kbps (sin pérdidas). La cosa suena francamente bien y nos permite seguir empleando reproductores DLNA ya un poco antiguos.

En principio esta misma mecánica debería funcionar con los Oppo 9x, pero por alguna razón no he conseguido que el mío inicie la reproducción del flujo Audio Cast. Quizás tenga que ver con la versión del firmware del aparato o simplemente con alguna pequeña incompatibilidad con BubbleUPnP, que dicho sea de paso dispone de un montón de ajustes y tweaks que aún estoy explorando.

Afortunadamente, BubbleUPnP tiene aún otro as en la manga: Es capaz de exponer través de su servidor DLNA integrado la biblioteca de cualquiera de los servicios de streaming que soporta (por ejemplo Tidal o el propio Google Music), permitiendo conectarse a ellos desde un reproductor DLNA, aunque no sea compatible directamente con el servicio en cuestión. Para ello BubbleUPnP, actuando como intermediario, genera una estructura de carpetas dinámicas que cuelgan de su servidor DLNA. Los reproductores simplemente navegan por ellas como si lo hicieran directamente a través de las opciones y menús del servicio de streaming correspondiente. Y esto sí funciona perfectamente con nuestros Oppo 93/95; aquí tenéis a uno ojeando Google Music, la interfaz de usuario no es muy vistosa y hay problemas con las etiquetas, pero es operativo y suena bien:

I test de audio digital: WAV vs OGG ¿qué nos estamos perdiendo?

noreply@blogger.com (Pablo Felip) — Sun, 18 Dec 2016 16:32:00 +0000

¿De qué va todo esto?

Hace unas semanas decidí organizar un pequeño experimento colectivo cuyo objetivo era el de analizar la calidad de audio que podemos conseguir utilizando el codec OGG/Vorbis de modo comparado con la de muestras de audio almacenadas sin compresión de ningún tipo, en formato WAV, a 16 bits y 44 Khz.

OGG/Vorbis (simplemente OGG en adelante) es un veterano codec de audio digital desarrollado por la Fundación Xiph.Org. Pertenece a la familia de codecs llamados perceptivos. Esto quiere decir que utiliza un modelo psicoacústico para reducir el tamaño del archivo resultante del proceso de codificación por lo que cuando se emplea se produce una pérdida en la fidelidad del audio de las muestras originales que se recodifican. Dicho de otro modo, su funcionamiento no es transparente puesto que opera bajo la premisa de descartar información que teóricamente no es audible, del mismo modo que los archiconocidos MP3 y AAC.

Lo que se pretendía tratar de determinar precisamente era en qué medida esa pérdida es audible o no, y bajo qué condiciones.

Aunque es posible que existan otros codecs más eficientes, escogí OGG por el hecho de ser de código abierto, por su popularidad (es el empleado por Spotify) y su buen rendimiento contrastado. En cualquier caso, OGG ofrece mejores resultados que MP3 a igual tasa de bits.

La sistemática de la prueba fue la siguiente:

Seleccioné 5 pistas de audio a partir de mis propios CDs y las extraje en formato WAV.
A continuación, escogí un fragmento de entre 30 y 50 segundos de cada una de ellas y generé 5 archivos en formato WAV.
Estos 5 archivos se recodificaron en formato OGG. En este punto se produjo una pérdida en la fidelidad del audio de las muestras originales.
Para evitar que el tamaño del archivo delatara el codec empleado en cada caso, las muestras en formato OGG se re-empaquetaron nuevamente como archivos WAV.
Los 5 pares de archivos resultantes (versión en WAV / versión en OGG, pero ambos conjuntos presentados en contenedores WAV) fueron renombrados de modo uniforme: Pista 1-A, Pista 1-B, Pista 2-A, Pista 2-B… asignando aleatoriamente los sufijos A y B a cada par de pistas.
Se construyó una página web (www.testaudiocomprimido.tk) en la que se publicaron todos los archivos, así como un cuestionario que contenía una serie de preguntas a responder por los participantes.

Este cuestionario estaba estructurado en 3 secciones. En la primera simplemente había que marcar qué versión de cada uno de los pares de pistas era percibida como de mayor calidad, existiendo también una tercera respuesta posible si no se apreciaban diferencias. Del mismo modo, los participantes tenían que indicar qué grado de confianza habían tenido en las elecciones realizadas. Las siguientes dos secciones contenían preguntas opcionales, pero que se incluyeron con el objetivo de recoger datos que permitieran segmentar los resultados para tratar de interpretarlos mejor.

El test se mantuvo abierto desde el sábado 22 de octubre hasta la medianoche del miércoles 30 de noviembre, invitando a que participasen usuarios de los foros de audio/vídeo más representativos del país. Para ello se abrieron hilos en Audio Planet, ForoDVD, Auriculares.org y Auriculares-hifi.com. Se animó a que los participantes realizaran el test en varias ocasiones, utilizando diferentes equipos, escuchando con altavoces o auriculares, descargando los archivos o escuchándolos en el propio navegador, etc. En total se recibieron 85 respuestas, 2 de ellas repetidas. Otro participante solicitó ser excluido del análisis tras enviar sus respuestas, por lo que finalmente quedaron 83 envíos únicos.

Durante el desarrollo de la prueba, y por supuesto tras la publicación de los resultados, que a continuación presento también aquí, se ha venido produciendo un animado e interesante debate en los foros anteriormente mencionados que os animo a que visitéis, pero no sin antes leer esta entrada, naturalmente.

Vamos pues con...

Los resultados de la prueba

A continuación os muestro una serie de gráficos que detallan los resultados obtenidos. Si alguien desea analizar los datos en bruto, respuesta por respuesta, así como revisar detenidamente todas las tablas dinámicas y gráficos generados a partir de ellos, puede hacerlo en esta hoja de cálculo de Google:

Test audio comprimido (publicado)

Este documento es de solo lectura. No obstante podéis hacer una copia (es necesario para ello disponer de una cuenta de Google) haciendo Archivo > Crear una copia para obtener una versión propia, ya editable, en la que se pueden ver las fórmulas empleadas, editar los gráficos o realizar nuevos análisis. Por ejemplo, quizás sería interesante estudiar en qué modo las variables (tipo de escucha, perfil, nivel del equipo, etc.) determinan el número de aciertos en cada una de las pistas de modo específico e independiente. Yo he hecho el análisis que os presento de modo global, puesto que de lo contrario el trabajo se hubiera alargado mucho, y solo he descendido a este nivel de detalle para relacionar aciertos con confianza en la elección, que sí podréis encontrar más abajo representados pista a pista.

Esta es por tanto una prueba de código abierto :-), así que os animo a utilizar la hoja de cálculo con las respuestas para obtener más información y a compartir los resultados.

Vamos con los gráficos. Hay muchos y su carga puede demorarse, paciencia.

1. Información estadística de los participantes

1.1. Participantes

1.2. Edad Media

1.3. Sexo

1.4. Escucha con auriculares / altavoces

1.5. Nivel del equipo

1.6. Perfil de usuario

1.7. Modo de realización de la prueba

1.8. Uso de mejoras eléctricas

1.9. Sala acondicionada

1.10. Uso de corrección digital / EQ

2. Resultados generales

La secuencia de pistas que se corresponde con los archivos WAV era:

B A A A B

No había ninguna pista “trampa” (ambos archivos idénticos).

2.1. Porcentaje de aciertos generales

2.2. Respuestas por pista

2.3. Confianza por pista

Solo 4 personas de los 83 participantes han identificado correctamente las 5 pistas WAV (4,8%). Comparemos este porcentaje con la probabilidad de acierto fortuito echando mano del cálculo de probabilidades:

La probabilidad unitaria de identificar cada uno de los archivos WAV es de 1/3. Consecuentemente, la correspondiente a que un participante identifique las 5 muestras es de 1 / (3x3x3x3x3) = 0,004115.
Puesto que cada suceso (intento de un participante) es independiente y tiene probabilidad constante, parece razonable suponer que la probabilidad de que 4 personas de entre los 83 participantes identifiquen las 5 pistas WAV puede aproximarse utilizando una distribución binomial B(83,4) en la que la probabilidad de acierto de cada ensayo es p = 0,004115. Eso nos permite calcular la probabilidad de que esto pase de chiripa, que resulta ser de un 0,038%.

En esta tabla se pueden ver los valores que toma la distribución binomial en este experimento:

Por otro lado, aunque solo un pequeño porcentaje de usuarios ha identificado las pistas WAV, lo que podríamos denominar la inteligencia audiófila colectiva ha optado claramente por las versiones WAV de las 5 pistas, lo que no deja de parecerme intrigante.

3. Aciertos en función del tipo de escucha

3.1. Aciertos por tipo de escucha

3.2. Porcentaje aciertos altavoces

3.3. Porcentaje aciertos auriculares

Contrariamente a la creencia popular los resultados apuntan a que resulta más fácil identificar las pistas WAV (4 o 5 pistas correctamente identificadas como WAV) con altavoces que con auriculares (37,5% frente a 12,2%).

4. Aciertos en función del perfil del usuario

4.1. Aciertos por perfil

4.2. Porcentaje aciertos novatos

4.3. Porcentaje aciertos aficionados

4.4. Porcentaje aciertos usuarios con experiencia

4.5. Porcentaje aciertos profesionales

4.6. Porcentaje aciertos músicos

El bajo número de muestras pertenecientes a determinados colectivos no permite extraer, en mi opinión, conclusiones claras (3 músicos, 3 usuarios que se consideran profesionales del sector) en determinados casos.
El porcentaje de usuarios que se consideran aficionados o usuarios con experiencia e identifican 4 o 5 de las pistas WAV es prácticamente idéntico (24,4% frente a 23,1%). Este factor por tanto no parece ser relevante.

5. Aciertos en función del nivel del equipo

5.1. Aciertos por nivel del equipo

5.2. Porcentaje aciertos equipos nivel bajo

5.3. Porcentaje aciertos equipos nivel medio

5.4. Porcentaje aciertos equipos nivel alto

Los participantes con equipos de nivel medio - alto han obtenido un porcentaje mayor de aciertos que los que empleaban equipos de nivel bajo. La calidad del equipo sí contribuye, aparentemente, a facilitar la detección de diferencias.
Ningún usuario con equipo de nivel bajo ha identificado las 5 pistas WAV.

6. Aciertos en función del modo en que se ha realizado la prueba

6.1. Aciertos por modo de realización de la prueba

6.2. Porcentaje aciertos archivos descargados

6.3. Porcentaje aciertos escucha desde el navegador

Las gráficas sugieren que los usuarios que han descargado los archivos para realizar la prueba han tenido más éxito a la hora de identificar las versiones WAV (29,4% frente a 15,6% a la hora de obtener 4 o 5 aciertos).

7. Aciertos en función del uso de mejoras en alimentación

7.1 Aciertos por uso de mejoras en alimentación

7.2. Porcentaje aciertos usuarios sin mejoras

7.3. Porcentaje aciertos usuarios con mejoras

Los resultados obtenidos no permiten vincular un mayor porcentaje de éxito a la hora de identificar los archivos WAV con el uso de mejoras en la alimentación eléctrica del equipo empleado (25,9% frente a 25% a la hora de obtener 4 o 5 aciertos).

8. Aciertos en función del acondicionamiento de la sala

8.1 Aciertos por uso de acondicionamiento pasivo

8.2. Porcentaje aciertos usuarios sin acondicionamiento

8.3. Porcentaje aciertos usuarios con acondicionamiento

2 usuarios han indicado que utilizaron auriculares para realizar la prueba pero también respondieron afirmativamente a la pregunta correspondiente al acondicionamiento acústico. Ambos no han sido tenidos en cuenta en las gráficas de (únicamente) este apartado.
En este caso, y paradójicamente, los usuarios que han realizado la prueba sin contar con una sala acondicionada han obtenido mejores resultados a la hora de identificar correctamente 4 o 5 de los archivos WAV que los que sí disponían de esta mejora (42,3% frente a 30%). Este resultado incongruente me hace pensar que el tamaño escaso de la muestra (solo 10 usuarios participantes que disfrutan de acondicionamiento pasivo) impide obtener conclusiones concluyentes.

9. Aciertos en función del uso de ecualización

9.1 Aciertos por uso de ecualización

9.2. Porcentaje aciertos usuarios sin ecualización

9.3. Porcentaje aciertos usuarios con ecualización

El uso de EQ y/o corrección digital de sala parece tener un impacto positivo en el índice de aciertos (45,5% frente a un 20,9% en el caso de los participantes que no disponían de esta mejora). No obstante, y nuevamente, el relativamente reducido número de usuarios que han indicado que empleaban EQ obliga a ser muy prudente a la hora de correlacionar estos factores.

10. Confianza en la elección: Pistas 1

10.1. Confianza personas que NO identifican el archivo WAV

10.2. Confianza personas que SÍ identifican el archivo WAV

En este caso los participantes que no identifican correctamente el archivo WAV demuestran más confianza en su elección que los que sí lo identifican (39,5% frente a 22,5%).

11. Confianza en la elección: Pista 2

11.1 Confianza personas que NO identifican el archivo WAV

11.2 Confianza personas que SÍ identifican el archivo WAV

En la pista 2, como podemos ver, el grado de confianza es similar en ambos grupos.

12. Confianza en la elección: Pista 3

12.1 Confianza personas que NO identifican el archivo WAV

12.2 Confianza personas que SÍ identifican el archivo WAV

En la pista 3 se obtienen resultados en lineas similares a los de la pista 2. La cosa está igualada, con una pequeña ventaja para los usuarios que no identifican correctamente el archivo WAV.

13. Confianza en la elección: Pista 4

13.1 Confianza personas que NO identifican el archivo WAV

13.2 Confianza personas que SÍ identifican el archivo WAV

En la pista 4 las tornas se invierten: los usuarios que identifican correctamente la versión WAV lo hacen con mayor confianza (37,5% frente a 25,6%).

14. Confianza en la elección: Pista 5

14.1 Confianza personas que NO identifican el archivo WAV

14.2 Confianza personas que SÍ identifican el archivo WAV

Finalmente, en la pista 5 se repite un resultado similar al evidenciado en la pista 3: porcentajes similares en ambos grupos, con una cierta ventaja para los usuarios que no identifican correctamente el archivo WAV.

Hasta aquí los resultados, vamos ahora con las...

Conclusiones personales

Y llegamos por fin al final de este experimento, pero antes de concluir me gustaría agradecer a todos los participantes su colaboración en este estudio informal.

Personalmente extraigo varias conclusiones:

La primera y principal es que el tamaño de la muestra me parece demasiado pequeño como para tomarse esto muy en serio. Mis expectativas iniciales eran, quizás, demasiado altas (cientos de muestras). Esto es especialmente cierto si tenemos en cuenta el reducido número de participantes pertenecientes a determinados colectivos:

Usuarios que identifican las 5 versiones WAV (4).
Participantes que se consideran novatos (6).
Músicos (3).
Usuarios profesionales (3).
Usuarios que disponen de salas acondicionadas (12).
Usuarios que emplean ecualización (11).

Esto invalida en gran medida cualquier análisis que pretenda correlacionar la influencia de estas variables entre ellas o con otras de las manejadas por esta prueba.

Por otro lado, me ha sorprendido enormemente que la respuesta colectiva a la hora de determinar qué pistas sonaban mejor ha convergido de un modo claro hacia los archivos WAV (BAAAB), a pesar de que solo 4 usuarios (4,8%) los han identificado correctamente a título individual.

Además, durante el tiempo en que la prueba ha estado abierta he podido comprobar en tiempo real cómo este comportamiento colectivo se iba perfilando y tendía progresivamente hacia esos 5 aciertos. De hecho, la tendencia ha sido muy clara desde los 20 - 30 primeros participantes en el caso de las pistas 1, 4 y 5, no tanto en las número 2 y 3. Especialmente la 3ª pista no ha tendido a su valor final (A) hasta prácticamente los últimos 10 días. Ha sido francamente curioso ver cómo, poco a poco, también en este caso las respuestas iban decantando la balanza en favor de la versión WAV. Aquí lo podéis comprobar en este time lapse:

Tampoco debemos perder de vista que aunque 10 participantes (12%), casi todos utilizando auriculares, no han identificado correctamente ninguna de las pistas WAV, esto no debe interpretarse como que han preferido de un modo consistente las versiones OGG, puesto que existía una 3ª respuesta posible (suenan igual). De hecho, tan solo se ha registrado 1 respuesta en la que el usuario ha preferido las 5 versiones OGG (secuencia ABBBA). Para que lo veáis claro he añadido varios filtros a la hoja de cálculo de respuestas:

Activad los filtros "5 OGG" y "0 aciertos" y entenderéis lo que digo.

Con respecto a las pistas de prueba, los espectrogramas de las versiones codificadas en OGG muestran una (muy sutil en algunos casos) disminución en su densidad de contenido espectral en la parte alta, quedando ligeramente desmochados, como se puede ver en estas imágenes. Creo que es innegable que el codec OGG hace un gran trabajo, al menos desde el punto de vista del análisis espectral.

Aquí podéis ver los espectros de las pistas de prueba, de la 1 a la 5, versión WAV a la izquierda, OGG a la derecha (los archivos de audio se pueden descargar aquí).

Estas imágenes no dicen gran cosa puesto que su tamaño no permite apreciar los detalles. No obstante podemos hacer un pequeño experimento adicional.

Vamos a invertir la forma de onda de una de las muestras en OGG y reproducirla al mismo tiempo que la original en WAV. Si ambas fueran idénticas se produciría una cancelación perfecta (silencio absoluto) al superponerlas (sumarlas digitalmente). En caso contrario lo que se escucharía es precisamente el audio que se ha perdido en la conversión de WAV a OGG.

Aquí un ejemplo con la pista 1 de la prueba:

Arriba la pista WAV. Abajo la versión OGG tras aplicar el filtro de inversión de Audacity.

Esta es la pinta que tiene la señal resultante de sumar (realmente restar, puesto que una de ellas está invertida) ambas pistas:

Y aquí tenemos un análisis espectral de la pista diferencia (recordemos, contiene la información descartada por el compresor OGG):

Como vemos, la transformación WAV > OGG se ha cepillado cosas en los extremos del espectro, estamos hablando de componentes que, como mucho, andan por los -60dB, aunque realmente el volumen medio es bastante inferior. Por ejemplo, en la parte alta del espectro la señal mutilada está por debajo de los -87dB. En resumen: que lo que se ha eliminado sonaba muy bajito.

¿Cómo de bajito? Pues aquí os muestro la pista cuyas gráficas se han representado más arriba en streaming para que podáis escucharla. Reproducidla en vuestros equipos y fijaos en cuánto hay que girar el pote de volumen para escuchar la "pérdida". Tened en cuenta, además, que la "ausencia" de lo que se escucha quedaría enmascarada, además, por el resto de la señal que sí se ha preservado en la versión comprimida.

Para finalizar, y tras reflexionar sobre los resultados que arroja esta prueba, me inclino a pensar que sí existen diferencias audibles, hablando en términos absolutos y bajo determinadas condiciones, perceptibles por ciertas personas, entre un archivo WAV y su homólogo codificado en OGG utilizando una compresión con pérdidas.

Ahora bien, creo que es procedente cuestionarse si en condiciones normales de escucha esto resulta relevante o no. Al fin y al cabo nadie se sienta en el sofá a disfrutar de su música preferida en estado de alerta mental permanente, repitiendo una y otra vez determinados fragmentos de cada pieza, para detectar deficiencias en lo que está oyendo. O al menos no debería hacerlo si en algo aprecia su cordura. Las diferencias, de ser significativas, deberían ser evidentes y aflorar per se en lugar de requerir una escucha activa y analítica.

Y me temo que la respuesta a esta pregunta es, en última instancia, personal e intransferible.

Integrando LMS con otros bichos (AirPlay, UPnP, Chromecast)

noreply@blogger.com (Pablo Felip) — Sun, 10 Jul 2016 10:11:00 +0000

Me gustaría haceros una pregunta ¿Sabéis qué tienen en común todos estos cacharros?

Que todos ellos forman parte, en estos momentos, de mi tinglado doméstico de reproducción musical (TDRP) y obedecen a un único amo: el servidor de medios de Logitech (LMS) instalado en el NAS que podéis ver en el centro de este collage diogénico digital (o CDD, por seguir con los acrónimos).

Que sendos Squeezeboxes (Touch y Classic) o incluso Squeezelite, el fantástico emulador de Squeezebox, o una Raspberry Pi con piCorePlayer participen de este montaje no tiene ningún misterio. Es su obligación, claro está. Para eso han sido diseñados. Como os podéis imaginar, todos estos dispositivos se encuentran obscenamente repartidos por distintas habitaciones de mi (muy saturado de cacharros) domicilio habitual.

Si os fijáis en la imagen anterior, apreciaréis, sin embargo, otros bichos de diferente pelaje poco frecuentes en un entorno Logitech Media Server, a saber:

Un Airport Express, que actualmente reside en mi cocina, conectado a una preciosa radio Tivoli One. Habitualmente lo empleo para escuchar Spotify, emitido desde un iPad, cuando me veo obligado a fregar las montañas de vajilla que mi familia apila para mi, amorosamente, día tras día, en el fregadero para recordarme que no todo es pasarse el día pensando en pajaritos digitales. De este modo al menos la experiencia se dulcifica. Como quizás sepáis, pocas cosas hay tan gratificantes como disfrutar de Dorian con el estropajo en una mano y el Fairy en la otra.
Un Apple TV de 3ª generación, que actualmente utilizo casi exclusivamente para lanzar contenidos a la tele del salón desde un iPad y para acceder al catálogo americano de Netflix. Qué demonios, la verdad es que lo compré en un impulso y no lo uso para nada. Debería venderlo. Pero bueno, pensaré en eso después de terminar de escribir este artículo.
OSMC (un reproductor multimedia chulo, chulo basado en Kodi) corriendo en una Raspberry 2, también en el salón y como reproductor de pelis, series y música multicanal. La niña de mis ojos de mi tinglado audiovisual, aunque tengo que decir que mi familia no lo aprecia del mismo modo.

A esta lista podríamos añadir la televisión del salón, puesto que en estos momentos también se encuentra esclavizada por el LMS, aunque solo haya sido de rebote.

Y todo esto para qué, seguramente os estaréis preguntando. Muy fácil: para poder reproducir el archivo más recóndito de mi colección musical, la emisora de radio más extraña de Internet o el disco más gafapasta de todo Spotify en cualquier lugar, o en varios de ellos simultaneamente, de forma sincronizada, controlando todo el cotarro desde cualquier navegador, móvil o tableta con una aplicación decente en lugar de las birrias que suelen llevar los reproductores dedicados (tanto más birriosas cuanto más caros y esotéricos, claro).

Muy conveniente, sin duda, para esas fiestas privadas (me refiero a lo de sincronizar reproductores). Lástima que ni me acuerde de la última que montamos en casa. Pero bueno, que no sea por no tener un reproductor (o más de uno) en cada habitación y que todos estén amaestrados para cantar a la vez.

Pero pongámonos serios que vamos a tratar cosas importantes.

Creo haber hablado de Logitech Media Server (la otra niña de mis ojos) en más de una ocasión en este blog (y las que quedan). Adoro ese aroma a beta permanente que desprende, esa incertidumbre que me hace sentir cada vez que le aplico una actualización o trato de instalar, en su infinita tolerancia, un complemento, parido en la guarida de quién sabe qué anónimo programador, que le dote de los superpoderes necesarios para osadamente ir donde ningún otro servidor de medios haya ido antes. Quizás por estas razones, además de por su flexibilidad, rendimiento, compatibilidad y carácter abierto y gratuito, LMS está a punto de hacerse mayor. Son ya más de 15 años los que tiene de vida, dedicado infatigablemente a hacernos felices. Musicalmente hablando, claro.

El caso es que esta mañana, mientras me preparaba el cortado en la Nespresso, he pensado ¡Cómo molaría estar ahora mismo escuchando un disco de los almacenados en mi NAS! ¿Cuál? Pues da igual. Uno cualquiera. Lo importante es la motivación, ¿no? Por eso mismo he recordado la existencia de 3 plugins (complementos) para LMS que en una de tantas idas y venidas al foro de slimdevices.com capté por el rabillo del ojo. Se trata de 3 componentes de tipo bridge (puente) que permiten integrar dispositivos AirPlay, UPnP y Chromecast en nuestro servidor de medios preferido: AirPlay Bridge, UPnPBridge y CastBridge.

Todos tres se encuentran en la sección de plugins de terceros del panel de configuración del LMS:

Si vuestro LMS es un poco viejuno es posible que no aparezcan. Por otra parte, Sourceforge, el lugar donde residen muchos de estos complementos para LMS y desde donde el servidor realiza las descargas pertinentes cuando los activamos, parece estar en modo "voy a elevar tus niveles de estrés", cambiando archivos de URL y esas cosas. Por ello no es mala idea que desconfiemos de los plugins (aparentemente) disponibles en LMS y optemos por agregar el repositorio donde se encuentran, siguiendo para ello las indicaciones del propio padre de las crituras (un tal philippe_44). Los repositorios son estos:

Versión estable:

http://tenet.dl.sourceforge.net/project/lms-plugins-philippe44/repo-sf.xml

Versión de desarrollo:

http://tenet.dl.sourceforge.net/project/lms-to-upnp/dev/repo-sf.xml

Yo he usado la estable (evitemos los chistes fáciles, por favor).

A pesar de ello, me he encontrado con problemas a la hora de instalar el puente para AirPlay. Puede que esto haya sido así porque mi LMS está ya muy acostumbrado a que le hurgue las tripas y cuando intento hacer las cosas siguiendo los procedimientos, digamos, normales demuestra extrañeza e irritación. No obstante, siempre podéis recurrir a realizar la descarga del archivo zip del plugin desde la página del proyecto en sourceforge.net (AirPlay, UPnP y Chromecast), descomprimirlo y colocarlo en su sitio en las entrañas de vuestro LMS con vuestras propias manitas utilizando un cliente SFTP como Filezilla (por ejemplo). En el caso de mi ReadyNas las entrañas en cuestión están aquí:

/c/.squeezeboxserver/Plugins

Si os veis obligados a realizar una instalación manual no os olvidéis (Linux y OS X) de ajustar los permisos de ejecución de los binarios, con el consabido chmod +x o desde el propio Filezilla, situados en:

nombredelplugin/Bin/

Como no tengo un Chromecast (¿cómo es posible?) solo he podido probar los puentes AirPlay y UPnP. Inicialmente he probado con el primero, que despliega este panel de control en la pestaña Avanzada del LMS:

Panel de configuración del puente AirPlay (clic para ampliar).

En el caso del LMS ejecutándose en el ReadyNas Ultra 4, hay que optar por el binario de 32 bits compilado estáticamente, esto es, squeeze2raop-x86-static (1). Para que aparezca el panel de opciones inferior deberemos generar una configuración nueva utilizando el botón Generate (2), proceso que puede demorarse hasta unos 30 segundos (paciencia). También es posible modificar el nombre descriptivo con que cada reproductor aparecerá en el ecosistema LMS (3). Además, podremos decidir si deseamos que LMS empuje la información (4) del tema que se está reproduciendo (metadatos e incluso carátula), de modo que estos se muestren en pantalla del receptor AirPlay de tener este la capacidad de hacerlo (Apple TV o bien OSMC con AirPlay activado, por ejemplo). Por último, en la parte inferior del panel se enumerarán (5) los dispositivos AirPlay detectados, que pueden ser deseleccionados individualmente para dejar algunos de ellos fuera de este montaje. Como veis tengo unos cuantos.

A continuación, instalé y activé (desde el repositorio, recordad), el puente UPnP:

Panel de configuración del puente UPnP (clic para ampliar).

Ahora, lo esperable: Binario estático (1), generación de ajustes de partida (2), envío de metadatos (3) y lista (4) de reproductores detectados (técnicamente, dispositivos UPnP compatibles con el perfil renderer).

No obstante este puente UPnP alberga mayores complejidades. Lo bueno de UPnP es que es un estándar. Y lo que pasa con los estándares es que hay muchos. Y cada fabricante se adhiere a ellos en la medida en que le da la real gana. Dicho de otro modo: es probable que tengáis que trastear con los ajustes desplegados en panel para conseguir que vuestro reproductor UPnP funcione correctamente. O al menos lo más correctamente posible. Fijaos en la captura de pantalla anterior. Los ajustes mostrados (default parameters) se aplicarán, inicialmente, a todos los reproductores UPnP detectados por el complemento (5).

Mirad ahora la captura justo bajo este párrafo. De entrada, disponemos de un menú de ajustes predefinidos, que además pueden descargarse / actualizarse desde la página del proyecto. Como veis, tenemos clásicos irrenunciables como Foobar, JRMC o incluso el correspondiente al conocido Pioneer N30. Simplemente debemos seleccionar (1) el nombre del reproductor detectado cuyos ajustes deseamos modificar y localizar el perfil que le deseamos asignar en la lista (2).

Perfiles predefinidos en el puente UPnP.

Si nuestro dispositivo no aparece en ella no tendremos más remedio que ir probando un perfil tras otro hasta dar con el más adecuado o, alternativamente, modificar directamente los parámetros de funcionamiento que aparecen en el panel de control. Los que dejemos en blanco asumirán los establecidos en el perfil general.

Ajuste fino del perfil UPnP para OSMC.

En el caso de mi OSMC (1), recordad, una variante de Kodi que funciona en Raspberry, he modificado el nombre (2) para diferenciarlo de su identidad AirPlay (sí, amigos, OSMC también puede aparecer como un punto de reproducción AirPlay en la red, a pesar de no tener nada que ver con Apple) y he activado el envío de todos los metadatos posibles (4).

Del mismo modo, he establecido la frecuencia máxima admitida (192 Khz) y me he visto obligado a eliminar pcm de la lista de codecs soportados (3), porque de lo contrario ciertos archivos de alta resolución no se reproducían correctamente por razones inescrutables. También he activado la reproducción sin pausas (gapless), que en OSMC funciona bien (5), y he desactivado el control digital de volumen (6) para respetar todo lo posible la integridad de la señal de audio. En este caso ajusto el nivel desde el mando a distancia del amplificador multicanal al que tengo conectada la Raspberry Pi 2 sobre la que se ejecuta OSMC.

Se me ocurre que un candidato de lo más idóneo para ser sometido a este proceso de transformismo digital es el Oppo 103 / 105. Integrarlo en un entorno LMS podría elevar su usabilidad enormemente. Si tuviera uno (el que se entrevé en alguna de las fotos que acompañan al artículo es un 93, carente del perfil UPnP requerido), no me lo pensaría ni un instante.

¿Y qué conseguiremos tras completar todo este proceso? Algo tan hermosote como que en el selector de reproductores de LMS nos aparezca esta lista de cacharros, cada uno de su padre y de su madre. Los complementos - puente aportarán una capa de compatibilidad para que los dispositivos AirPlay, UPnP y, aunque no lo hemos demostrado, Chromecast se integren con los Squeezeboxes nativos (reales o simulados) encargándose, además, de transcodificar el audio al formato (codec, resolución y frecuencia de muestreo) requerido por cada reproductor.

Lista que, lógicamente, es idéntica cuando nos vamos a cualquiera de las apps de control del tinglado, Por ejemplo Orange Squeeze...

...o el campeón de los controladores Squeezebox, el mismísimo iPeng:

Como cabría esperar, podemos controlar nuestro ejército de reproductores cómodamente, ajustar su volumen, emitir distintos flujos de audio a cada uno de ellos, e incluso establecer varias agrupaciones independientes que funcionarán de un modo sincronizado, como un solo hombre.

Control de volumen y sincronización de reproductores usando Orange Squeeze.

Me gustaría resaltar que la mejor integración se consigue en estos momentos con los dispositivos AirPlay. Tanto la reproducción sin pausas como la sincronización con otros reproductores Squeezebox funcionan estupendamente, lo que no es extensible a los cacharros UPnP y Chromecast, al menos por ahora. En ellos la sincronización entre dispositivos solo es parcial y la reproducción sin pausas depende, en gran medida, de la implementación del perfil renderer soportada por el reproductor UPnP, que suele ser relativamente desigual, y directamente no es posible en los Chromecast.

El caso de OSMC controlado a través de UPnP es un tanto especial, para bien. No solo admite la reproducción sin pausas sino que también soporta las extensiones de descarga de listas de reproducción, del mismo modo que otros streamers pijales como los Linn.

Este excelente comportamiento de OSMC como reproductor UPnP lo hace, a mis ojos, simplemente fantástico. Con este puente UPnP que hemos configurado, ahora puedo unificar en un solo dispositivo tanto las funciones nativas de reproducción de vídeo (y audio multicanal) como las asociadas a la reproducción estéreo de modo integrado con mi ecosistema Squeezebox, que por si no os habéis dado cuenta a estas alturas es mi entorno audiofriki preferido. El Squeezebox Touch del salón cada vez es menos necesario, aunque se ha ganado permanecer en su lugar indefinidamente simplemente por su aspecto indómito, con su pantalla táctil en color y esos atractivos vúmetros animados al ritmo de la música (sí, en castellano se llaman así).

Pero vamos terminando...

En mi opinión es toda una gozada disponer de una red de reproductores tan variopinta (y económica) distribuida por toda la casa, reproductores capaces de hacer sonar lo que sea: desde un mp3 chusquero a 192 Kbps a un archivo DFF o DSF (audio en DSD), que LMS y sus agentes convertirán a PCM de la máxima frecuencia soportada por el reproductor seleccionado y empaquetarán en el formato adecuado.

Y como ejemplo y colofón final, algunas imágenes de OSMC reproduciendo DSD, pcm de alta resolución e incluso ¡DTS! a través del puente UPnP al tiempo que muestra en pantalla información, carátulas y una visualización espacial al ritmo de la música. Una chulada. Aunque tampoco seáis de los que dan fiestas en casa.

OSMC integrado en LMS en acción (clic para ampliar).

Revertir un router D-Link DIR-655 a firmware europeo

noreply@blogger.com (Pablo Felip) — Sat, 11 Jun 2016 23:08:00 +0000

El DIR-655 es un router neutro con 4 puertos gigabit y wifi N que tiene ya 10 años a cuestas. En su momento se trataba de un modelo de altas prestaciones, como atestigua el análisis publicado en aquel lejano año 2007 por SmallNetBuilder.

A pesar de su antigüedad, no obstante, sigue portándose como un campéon en mi tinglado doméstico. O quizás debería decir seguía, puesto que en los útimos tiempos ha comenzado a mostrar síntomas de cansancio. Uno de los puertos ethernet comenzó a fallar hace ya varios meses y desde hace unas pocas semanas está repitiéndose la misma incidencia, aunque con menor intensidad, en otro. El problema ha pasado de ser muy ocasional a casi permanente en el caso del primer puerto y su frecuencia está claramente aumentando en el caso del segundo. Esto no presagia nada bueno.

Pensando en que quizás ha llegado el momento de comprobar si efectivamente la garantía del producto es de ¡11años! (o al menos eso es lo que dice en la caja de mi unidad) he caído en la cuenta de que actualicé el firmware del router a la versión 1.37 hace mucho tiempo. Antes de que me preguntéis, sí, mucho antes de que los puertos comenzaran a fallar. Lamentablemente, como en aquel momento la versión disponible para modelos europeos era únicamente la 1.33 (o similar), ni corto ni perezoso instalé la versión para Norte América (variante NA). No es que esto causara problema alguno, al menos aparentemente, puesto que el aparatejo siguió funcionando correctamente con la única salvedad de que la interfaz web de administración pasó a mostrarse en inglés. El problema, claro, es que la instalación de un firmware de otra zona invalida la garantía.

En estos momentos la versión más reciente del firmware para este DIR-655 que puede descargarse de la página de soporte de D-Link para España es la 1.35. Pero como no podía ser de otro modo, no es posible instalarla sobre mi unidad con el 1.37NA. D-Link activó en su momento una serie de medidas en sus firmwares para el DIR-655 (a partir del 1.3x) que impiden las regresiones. Afortunadamente, tras indagar un poco, he hallado en las profundidades de un servidor ftp de D-Link en Alemania 2 cosas: un firmware 1.34 modificado que permite volver a las versiones europeas y, además, un firmware 1.37EU para las revisiones A, B y C de este router (la mía es la A).

Basta con descargarlas desde ftp://ftp.dlink.de/dir/dir-655/driver_software e instalarlas utilizando la función de actualización nativa del router para acabar con la 1.37EU vivita y coleando.

Brevemente, el procedimiento es el siguiente:

Antes de iniciar el proceso es conveniente hacer una copia de seguridad de los ajustes del router usando su panel web de administración (Herramientas > Sistema) puesto que durante el proceso se inicializarán a los valores de fábrica.
A continuación, hay que instalar (Herramientas > Firmware) el archivo .bin contenido en el archivo DIR-655_fw_reva_134ww_RecoveryFromNA-Firmware.zip. Después procederemos a repetir el proceso con el fichero .bin dentro de DIR-655_fw_reva_137EUb01_ALL_multi_20130606.zip. ¡Ojo, solo revisión A del hardware del router! En caso de disponer de un modelo B o C usaremos los ficheros correspondientes presentes en el sitio FTP anterior, aunque no lo he probado personalmente.
Finalmente, restauraremos la configuración previa del router usando el archivo gateway_settings.gws obtenido en el paso (1).

Bueno, aquí no ha pasado nada. Veremos ahora si efectivamente D-Link se hace cargo de la reparación (o sustitución) de mi router sin cargo.

Para terminar, decir que en el mencionado sitio FTP existen firmwares "puente" similares para realizar este mismo procedimiento con otros modelos de D-Link.

Túnel del tiempo: Experiencias de ajuste de sala con el MCACC pro de Pioneer

noreply@blogger.com (Pablo Felip) — Sat, 04 Jun 2016 19:07:00 +0000

Hace ya unos cuantos años (parece mentira cómo pasa el tiempo, ¿verdad?) publiqué una pequeña guía en Audio Planet y forodvd que pretendía resumir mis experiencias de uso del sistema de ajuste digital de sala de los receptores multicanal de Pioneer.

Las imágenes que acompañaban al artículo se hospedaron en el que por entonces me pareció un estupendo servicio, Minus, que posteriormente decidió modificar los términos de uso de las cuentas gratuitas como la mía. El resultado fue que la guía quedó totalmente mutilada, desprovista de cualquier imagen al bloquear Minus el acceso, imágenes que por otra parte resultaban esenciales para su comprensión.

Cosas de la Nube, claro.

Hace unos días, como consecuencia de un hilo recientemente abierto en Audio Planet, me propuse restaurar el artículo original, aunque solo fuese por motivos arqueológicos, lo que afortunadamente he podido lograr en gran medida gracias a una carpeta, perdida en las profundidades de mi cuenta de Dropbox, que contenía una copia de la mayor parte de los archivos de medios originales.

Sin más preámbulo, aquí la guía, que data del 3 de junio de 2012.

Experiencias de ajustes de sala con el MCACC pro de Pioneer

1. Introducción.

En casa dispongo de 2 receptores multicanal de Pioneer, un VSX-919 en una habitación auxiliar y un SC-LX81 en el salón. Lo primero que hice tras instalarlos fue realizar la calibración completamente automática y no tocar nada más allá de los ajustes de tamaño de los altavoces y frecuencia de corte para el sub, pero recientemente he estado trasteando con los ajustes avanzados (pro) de MCACC y he pensado que sería buena idea comentar los resultados. Vamos a ello, espero que no me salga un ladrillo infumable y que esto le pueda servir de alguna ayuda a alguien.

MCACC son las siglas de Multi-Channel Acoustic Calibration System, es decir, sistema de calibración acústica multicanal. Es un sistema análogo a AUDYSSEY (Denon, Marantz, Onkyo), YPAO (Yamaha), ARC (Anthem), etc. que pretende corregir los problemas acústicos originados por la interacción altavoces - sala para obtener un sonido en principio lo más parecido posible al original.

Para ello dispone de varias armas:

Un sistema de detección automática del tamaño, posición, volumen y fase de los altavoces conectados.
Un ecualizador de 9 bandas por canal (EQ), con la excepción del sub, que no se ecualiza. Para cada banda es posible establecer la ganancia (A), pero frecuencia (F) y amplitud (Q) son fijas.
Un sistema de control de ondas estacionarias (S-WAVE) que emplea hasta 3 filtros paramétricos, en este caso independientes para frontales y traseros (R, L, SR y SL se tratan unitariamente), central y sub.
Un sistema de control de fase para tratar de que todas las frecuencias emitidas por los altavoces lleguen al mismo tiempo al oyente. Este sistema puede ser parcial (919) o de rango completo (LX81).

MCACC ofrece 6 memorias distintas de calibración, que se pueden emplear dependiendo de la posición de escucha o del tipo de material reproducido (por ejemplo música o cine). El único aspecto de la configuración común a todas las memorias es el relacionado con el tamaño de los altavoces, la frecuencia de corte y el modo de funcionamiento del sub. Distancias, niveles y filtros son ajustables independientemente en cada memoria. Contrariamente a la creencia popular, MCACC *sí* puede realizar medidas multipunto (3), aunque solo para el control de las ondas estacionarias. Además, es posible activar y desactivar independientemente (2), (3) y (4) para ver qué combinación nos suena mejor.

MCACC no es tan flexible como DrCop puesto que no podemos fijar una curva de respuesta en frecuencia objetivo, aunque resulta bastante más ajustable (y proporciona más información) que Audyssey, por ejemplo (no tengo el gusto de haber utilizado YPAO o ARC). Como veremos la cosa va bastante más allá del ajuste automático.

El primero equipo con el que me las he visto es el montado en torno al 919. Se trata de un sistema 5.1 instalado en una habitación auxiliar de unos 10 metros cuadros y prácticamente rectangular.

Pioneer VSX-919

Los altavoces son un conjunto Focal Sib&Cub2. Los satélites bajan hasta 78Hz (-3dB) y tienen un pequeño puerto reflex trasero.

En la panorámica se puede ver, más o menos, su ubicación: a ambos lados del sofá sobre pies y en sendos estantes a derecha, izquierda y sobre la tele. Se vé un trocito de sub a la derecha bajo la ventana, en el rincón.

2. Ajuste inicial: Full auto MCACC.

Lo primero que hice fue conectar el micro de calibración al receptor, tras ubicarlo sobre un soporte improvisado en la posición más próxima que pude al punto de escucha.

El micro es omnidireccional, así que es preferible situarlo apuntando hacia arriba o ligeramente inclinado hacia adelante. Lo que *no* debe hacerse es colocarlo sobre una pila de cojines o fijarlo directamente en el respaldo del sofá. Eso puede producir reflexiones de los tonos de prueba emitidos durante el proceso de calibración sobre el material próximo que perturbarían las mediciones.

Es importante tener en cuenta que el ajuste completamente automático realiza una calibración de tipo symmetry, es decir, que aplica exactamente los mismos ajustes a frontales derecho e izquierdo y hace otro tanto con los traseros. Luego hablaremos de esto.

Durante el periodo de autocalibración, en el transcurso del cual se emiten una variedad de tonos (MCACC parece emplear una combinación de ruido rosa e impulsos variados a bastante volumen), es buena idea salir de la habitación y tratar, lógicamente, de que el entorno quede lo más silencioso posible y sin elementos físicos anómalos que puedan repercutir en la calidad de la medición. Si es necesario el receptor avisará de una conexión incorrecta de los altavoces (cables intercambiados) o de algún problema de fase o volumen excesivo en el sub. Ojo porque algunos usuarios hablan de falsos positivos relacionados precisamente con errores de conexión. Si estamos seguros de que no hay ningún problema podemos ignorar el error y seguir adelante.

Como resultado de esta calibración inicial MCACC configuró mis satélites en LARGE, por lo que el sub quedó efectivamente desactivado. Mal empezábamos. Se nota que al calibrador le gusta ponerse la cosas fáciles y olvidarse del subwoofer.

Cada vez que se realiza una calibración automática el receptor obtiene datos del comportamiento de la sala antes y después de la calibración calculada. Para acceder a esta información hay que dirigirse a:

HOME MENU > 1. ADVANCED MCACC > c. MANUAL MCACC > 5. EQ. PROFESSIONAL > b. REVERB VIEW

Lo que podemos ver aquí es lo que Pioneer denomina gráficas de reverberación. Se trata de una representación, por canal, de la respuesta temporal de la habitación para cada una de las 9 bandas de las que consta el ecualizador de 9 bandas del que hablábamos más arriba. Lo que estamos viendo por tanto, nos da información relativa tanto a la respuesta en frecuencia de la sala como a su comportamiento en el tiempo, que es también extremadamente importante. Podemos conmutar entre el "antes" y el "después", con toda la artillería DSP calculada ya funcionando. Pego a continuación mis resultados (disculpad la mala calidad de algunas imágenes):

Sin EQ, altavoces en LARGE:

Calibración totalmente automática, altavoces en LARGE:

Cada línea de color muestra el volumen medido (eje vertical) a lo largo del tiempo (eje horizontal) de una determinada componente en frecuencia. Los primeros instantes (hasta los 50 - 80 ms) se corresponden con el sonido directo procedente de los altavoces. A medida que nos desplazamos a la derecha en el eje temporal podemos ver la influencia del sonido reflejado sobre la respuesta global del sistema. Cuando una línea se mantiene constante en el tiempo quiere decir que esa componente ya se ha estabilizado. Si hiciéramos un ejercicio de imaginación y "cortáramos" el gráfico verticalmente en un instante de tiempo t y representáramos de modo instantáneo dB / frecuencia lo que obtendríamos es un clásico gráfico de respuesta en frecuencia.

Pero al grano ¿Y qué debemos tratar de conseguir? Pues que la gráficas correspondientes al "después" sean lo más parecidas posible entre sí y que las líneas dentro de cada una de ellas discurran paralelas y del modo más uniforme y cohesionado de principio a fin: esto es, buscamos una respuesta en frecuencia plana (inicialmente) y un comportamiento en el tiempo coherente en todos los canales.

Como podréis ver la situación inicial no es demasiado buena, especialmente en el trío frontal. Tras aplicar la corrección de sala la cosa mejora... fijaos incluso en la banda de 63Hz, que no aparece por ninguna parte en las 5 primeras gráficas, pero que se deja ver claramente en el "después". No olvidemos que los satélites solo llegan nominalmente a 78Hz@-3dB. Esto constituye a mi modo de ver un ejemplo más de que la ecualización puede llevar a un sistema de altavoces a sus límites (aparentes, claro, si no no serían límites) y más allá.

¿Y cómo sonaba esto? Pues mucho mejor que "en bolas" (sin ajustes de ningún tipo) y sorprendentemente bien, máxime si tenemos en cuenta que el sub no se estaba utilizando. Supongo que el hecho de que todos los satélites están próximos a la pared y R, L y C andan dentro de huecos en la estantería de unos 35x35x35cm debe contribuir a reforzar la respuesta del sistema por abajo.

Llegado a este punto era obvio que debía realizar más ajustes:

El sub no se estaba utilizando, así que configuré los altavoces en SMALL y ajuste el corte del sub en 80Hz (esto para Pioneer son "altavoces THX" ).
Viendo las gráficas de reverberación iniciales estaba claro que la parte derecha e izquierda de la sala no se estaban comportando del mismo modo. Recordad que la calibración totalmente automática es de tipo simétrico. Era más que recomendable realizar una nueva calibración con el modo all channel adjust, que aplica filtros independientes a cada miembro de las parejas frontal y trasera.

Lo siguiente fue, por tanto, realizar una nueva calibración totalmente automática pero con los altavoces en SMALL y corte en 80Hz, manteniendo como no podía ser de otro modo el ajuste simétrico de los altavoces. Ya a simple oreja el resultado no fue nada satisfactorio. Una zona media francamente alejada y sin cuerpo y un sonido en conjunto bastante chillón. Feo de narices. No pego las gráficas del resultado tras la calibración por no aburrir, pero sí cuelgo las correspondientes al funcionamiento del sistema sin corrección de sala, ahora sí ya con el sub activo y cortado a 80Hz, porque son las que usé como punto de partida para lo que sigue.

Sin EQ, altavoces en SMALL, sub 80Hz:

Ahora el escenario inicial yo diría que es incluso peor que en el primer ajuste (satélites LARGE, sub no activo), al menos por lo que hace a los graves . Fijaos en el trío frontal: algo está pasando con las frecuencias bajas, que entre los 20 y 40 ms sufren un refuerzo bastante importante.

Una cosa curiosa es que la banda de 63Hz ni se ve. No tengo explicación para esto, es como si al quedar ya asignada al sub MCACC no la tuviera en cuenta en las mediciones; recordemos que MCACC no ecualiza el sub, solo realiza un control de estacionarias sobre él, que he podido comprobar sí llega a ubicar algún filtro en las inmediaciones de los 60Hz.

Esta calibración quedó registrada en la memoria M1.

3. Segundo ajuste: MCACC con EQ PRO.

Ante esto y leyendo aquí y allá, me planteé la posibilidad de pasar a utilizar una variante avanzada de MCACC que permite, además de realizar un ajuste independiente por canal si el usuario lo desea, establecer la ventana temporal que se va a emplear para tomar las medidas que posteriormente se usarán para realizar el cálculo de los filtros de EQ y de control de estacionarias. El sistema completamente automático, en cambio, utiliza las muestras obtenidas exclusivamente en el intervalo comprendido entre los 80 y 160ms. A esta capacidad para establecer la ventana temporal de medición Pioneer la denomina EQ PRO y puede adoptar los valores de 0-20ms, 10-30ms, 20-40ms, 30-50ms, 40-60ms, 50-70ms y 60-80ms.

Además, uno de los "papers" de Pioneer sobre el MCACC PRO explica que en caso de que se produzca un refuerzo tardío (>80ms) de las frecuencias más graves del espectro de la señal es posible que el calibrador trate de compensarlo de un modo incorrecto estableciendo EQs de elevada ganancia en la parte alta del espectro, lo que va a resultar en un sonido chillón (justo lo que me pasaba a mi). Al adelantar la medida a intervalos anteriores a 80ms lo que estamos haciendo es ecualizar la sala otorgándole más importancia al sonido directo que al reflejado. Según Pioneer la idea es retrasar todo lo posible la ventana de medición pero no hacerlo tanto como para que el componente reflejado llegue a pesar demasiado, tratando al mismo tiempo de situarla en torno al momento en el que se producen las perturbaciones en las gráficas de reverberación sin EQ (las del "antes") que deseamos corregir. Como véis, clarito a más no poder.

Lo que hice fue probar diversas ventanas con EQ PRO, ajustando además todos los canales de modo independiente (All Ch Adj). En concreto utilicé ventanas de 0-20, 20-40, 30-50, 40-60 y 60-80, almacenando cada una de ellas en las memorias M2 a M6 para comparar con la calibración chillona de la leche obtenida anteriormente y que guardé en M1 puesto que la inicial con los satélites en LARGE no era aceptable para mi al no utilizar el sub. Se trata de acceder al menú de configuración de EQ PRO...

HOME MENU > 1. ADVANCED MCACC > c. MANUAL MCACC > 5. EQ. PROFESSIONAL > c. ADVANCED EQ SETUP

...para ajustar el intervalo de tiempo utilizado en la medida, el tipo de EQ (todos los canales) e indicar si se desea realizar una medición multipunto para controlar las estacionarias (yo no lo hice en ningún caso puesto que en este sistema el punto de escucha es siempre el mismo y está perfectamente localizado justo frente a la tele).

Tras completar el proceso de calibración se mide la respuesta de la sala con la ecualización calculada en:

HOME MENU > 1. ADVANCED MCACC > c. MANUAL MCACC > 5. EQ. PROFESSIONAL > a. REVERB MEASUREMENT

...ajustando EQ a ON para que efectivamente se activen los filtros.

Para finalmente seleccionar:

HOME MENU > 1. ADVANCED MCACC > c. MANUAL MCACC > 5. EQ. PROFESSIONAL > b. REVERB VIEW

Para comprobar el resultado gráficamente. No voy a incluir todas la graficas que obtuve porque la cosa no tenía fin. Solo deciros que el mejor resultado gráfico y sonoro fue el correspondiente a la medición entre 30 y 50ms, que casualmente es también el valor recomendado por Pioneer para la ecualización PRO:

Calibración PRO 30-50ms, altavoces en SMALL, sub 80Hz:

Como veréis las gráficas pintan bastante bien, con la salvedad de alguna anormalidad en la respuesta correspondiente a los canales C y R.

Esta calibración quedó registrada en la memoria M3.

4. Tercer ajuste: Auto MCACC PRO

Por último probé también a utilizar el EQ PRO pero en un modo en el que es el propio receptor quien determina la ventana temporal a utilizar, siempre inferior a los 80ms. Es lo que Pio denomina Auto MCACC (nótese la ausencia del "Full").

HOME MENU > 1. ADVANCED MCACC > b. AUTO MCACC > EQ Pro & S- Wave

De este modo se mantienen todos los ajustes de distancia y niveles de los altavoces y se recalculan los filtros de ecualización y de control de estacionarias.

Aquí tenéis el resultado:

Calibración AUTO PRO, altavoces en SMALL, sub 80Hz:

El resultado es similar al anterior obtenido con una ventana de medición de 30-50ms, aunque los graves en el canal R, que se iban un poco por arriba a partir de los 40ms, parecen, al menos sobre el papel, mejor domados. A oído escasas diferencias.

Esta calibración quedó registrada en la memoria M2.

5. Ajustes finales: Retoques manuales sobre R y C.

Viendo que MCACC parecía andar ya al límite por lo que hace al ajuste automático pensé en la posibilidad de realizar unos ligeros retoques manuales en la ecualización de los canales central y frontal derecho. En el último conjunto de gráficas de reverberación veréis que en el central la banda de 16Khz se situa unos 3 dB por encima del resto a lo largo de toda su respuesta temporal medida. Por su parte, en el canal frontal derecho nos encontramos con una situación similar en esta misma banda y, por otra parte, con que la de 2Khz queda un poquito por debajo del resto. Por esta razón copié los ajustes de calibración de M2 a M4 y modifiqué los valores del ecualizador calculados incrementado o disminuyendo la ganancia de cada banda del siguiente modo:

Central: 16Khz > -3dB.
Frontal derecho: 16Khz > -2dB, 2Khz +2dB.

Vuelta a medir respuesta en frecuencia con estos retoques:

Calibración AUTO PRO, ajustes manuales en R y C, altavoces en SMALL, sub 80Hz:

Mucho mejor ¿verdad? Ambos canales tienen ahora una respuesta mucho más homogénea. A pesar de todo me mosquea bastante ese arranque más lento de las bandas de 125Hz y 250Hz en el frontal derecho, fijaos en el gráfica en torno a los 30ms. Además si revisitáis la gráfica de reverberación de ese mismo canal con una ecualización pro con ventana de 30-50ms (2º ajuste) veréis que también están pasando cosas desagradables, aunque esta vez por exceso, en las inmediaciones de los 40ms ¿Se os ocurre alguna explicación? :hmm:

De todos modos hay que tener en cuenta un detalle importante que no he mencionado hasta el momento: por alguna razón desconocida para mi las gráficas de reverberación que se obtienen con la ecualización activada no tienen las estacionarias controladas. Esto quiere decir que los filtros de control de estacionarias no están activados, por lo que la respuesta real del sistema puede variar (quiero pensar que a mejor) si realmente midiéramos con ellos funcionando, filtros que en esta ecualización final son estos:

Control de estacionarias, calibración AUTO PRO, altavoces en SMALL, sub 80Hz:

Solo queda adjuntar los ajustes de ecualización para tener la imagen completa. Aquí van:

(dB)	63Hz	125Hz	250Hz	500Hz	1Khz	2Khz	4Khz	8Khz	16Khz	Trim
L	nd	-3,5	+4,5	+0,5	-2	+5,0	-6,0	-0,5	-2,5	0
R	nd	-3,5	+4,5	-1,0	-1	+4,5	-5,5	-2	-5,0	+1,0
C	nd	+4,0	+3,5	-0,5	-2	+4,0	-6,5	-2,5	-6,5	+1,0
SL	nd	-4,0	-4,0	+3,5	+1,5	+4,5	-3,5	-0,5	-0,5	-2,5
SR	nd	-7,0	-3,5	+0,5	+1,5	+4,5	-3,5	-0,5	-1,0	-2,0

El ajuste de "trim" representa una compensación global para todos los filtros de un canal.

¿Y qué decir con respecto al sonido final obtenido? Al fin y al cabo esto no son más que numeritos... La diferencia entre el "antes" (sin ningún tipo de corrección de sala) y el "después" (memoria M4) es considerable. Creo que tener un receptor de este tipo y no perder unos buenos ratos con él para tratar de sacarle todo el jugo a sus características de ajuste de sala es imperdonable, porque el esfuerzo merece realmente la pena.

6. Midiendo el resultado con REW (editado 10/07/12).

NOTA: Las imágenes de esta sección que recogían las mediciones se han perdido, al parecer definitivamente.

Por fin tengo equipamiento para poder medir el comportamiento de la sala:

Edirol UA25.
Behringer ECM8000 (calibrado a 0 y 90 grados).
REW 5 y pico.

Aunque he tratado de aproximarme, la posición del micro de medición no es la misma que la que tuvo el micro de calibración. Como la respuesta del equipo / sala es extraordinariamente dependiente de la posición del punto de escucha (tanto más a medida que aumenta la frecuencia, hasta el punto de que unos pocos cm. pueden suponer un gran cambio) los resultados no son todo lo válidos que debieran. En cualquier caso, supongo que mis orejas tampoco suelen estar exactamente donde puse el micro, así que me conformaré con esto.

Sin más preámbulo:

Respuesta en frecuencia de R:

[imagen perdida]

Rojo: original / Azul: MCACC + control de fase.

Respuesta en frecuencia de L:

[imagen perdida]

Verde: original / Rosa: MCACC + control de fase.

Respuesta en fase de R:

[imagen perdida]

Rojo: original / Azul: MCACC + control de fase.

Respuesta en fase de L:

[imagen perdida]

Verde: original / Rosa: MCACC + control de fase.

MCACC parece hacer la mayor parte de su "faena" por debajo de los 200Hz. Además, comparando los canales derecho e izquierdo las gráficas de la respuesta en frecuencia presentan un aspecto ligeramente distinto en la zona comprendida entre los 200Hz - 400Hz, sin que se haya intervenido sobre el pico en los 400Hz que se aprecia en el canal izquierdo.

Donde sí parece que MCACC ha tomado medidas drásticas es entre los 30Hz y 70Hz, empujando hacia arriba el nivel del sub. Si echamos un vistazo a las gráficas que muestran la respuesta en fase se aprecia claramente esta intervención. Esto no es debido a ecualización alguna, sino que aparece simplemente activando la función de control de fase del receptor, aún desactivando totalmente el resto del MCACC. Curioso. A pesar de todo no me parece que suene en absoluto sobreecualizado.

Lo que está claro a la vista de esto es que las gráficas de reverberación que proporciona MCACC, al menos en el Pioneer VSX-919, no dejan de ser una simplificación bastante gorda. Creo que para conseguir resultados finos de verdad no habrá más remedio que utilizar un software de medición como REW y tirar de paciencia, mano con el ecualizador y oído. De todos modos sigo pensando que para el 90% de los usuarios los resultados obtenidos directamente mediante el sistema de calibración del receptor serán más que suficientes y desde luego supondrán una mejora con respecto a la situación inicial.

¿Qué opináis?

Bueno, ha sido un primer intento. Como el resultado sonoro final me gusta no voy a perder (por el momento) más tiempo con este equipo y me voy a dedicar a meterle mano al SC-LX81 del salón, pero esta vez con REW desde un primer momento, dado que me parece una herramienta coj*nuda.

Nada más, si me habéis aguantado hasta aquí os merecéis un premio y de los gordos. Espero que aunque sea parte de todo esto pueda resultar de interés a algún compañero que tenga un receptor Pioneer. Ni que decir tiene que agradeceré enormemente cualquier comentario que me hagáis llegar.

Guía: Montaje de un sistema de streaming económico basado en piCorePlayer y Logitech Media Server

noreply@blogger.com (Pablo Felip) — Mon, 11 Apr 2016 16:00:00 +0000

He preparado un documento a modo de guía de integración de un sistema de streaming basado en piCorePlayer y Logitech Media Server.

Para tratar de resumir el proceso, nada mejor que una presentación:

Y aquí la guía:

Confío en que sea de vuestro interés.

Volumio en Raspberry Pi: solucionando los problemas de reproducción por HDMI

noreply@blogger.com (Pablo Felip) — Sat, 06 Feb 2016 16:57:00 +0000

Tras la reciente llegada a casa de una Raspberry Pi 2, mi equipo principal ha quedado configurado definitivamente (bueno, todo lo definitivas que son estas cosas, que ya nos conocemos) por lo que hace a fuentes digitales del siguiente modo:

Oppo 93 para la reproducción cada vez más ocasional de discos físicos y Netflix, configurado este último para acceder al catálogo americano del servicio dejando el cliente de Netflix de la TV para la programación disponible localmente.
Squeezebox Touch como reproductor de audio de cabecera.
Raspberry Pi 2 con OSMC para ver pelis desmaterializadas, los podcasts de Radio 3 (fundamentalmente) y el audio multicanal.

Más o menos algo así como lo que se puede ver en la imagen justo aquí a la derecha.

Sin embargo algo fallaba. Aunque es posible escuchar Spotify usando el Squeezebox Touch, lo cierto es que resulta mucho más cómodo utilizar la app en la tableta. Hasta iOS 9 esto estaba chupado con Kodi / OpenELEC / OSMC, que aparecían en el conocido panel inferior presente en todo dispositivo iOS como altavoces Airplay. Un par de movimientos del dedito y la cosa estaba resuelta. Sin embargo, desde esta actualización del sistema operativo de las i-cosas portátiles, Airplay está roto.

Tras varios intentos infructuosos de hacerme con un AppleTV 3 a precios razonables, finalmente he optado por buscar una solución temporal poniendo en servicio de nuevo una Raspberry Pi que, con la llegada de su hermana mayor, había quedado sin uso.

En concreto he valorado 3 reproductores para Raspberry: Pi Music Box, Rune Audio y Volumio. Todos ellos son capaces de recibir audio a través de Airplay y ¡sorpresa! todos ellos parecen haberse adaptado a las diabluras de Apple puesto que en todos sigue funcionando esta característica aunque la i-cosa empleada corra ya iOS 9.x. Estupendo.

Puesto que Volumio parece el proyecto más activo me he decantado por él, aunque como digo de entrada solo estaba interesado en montar un receptor Airplay no-Apple.

Las instrucciones de descarga e instalación de Volumio están perfectamente documentadas en su web:

https://volumio.org/get-started

Como mi receptor AV tiene activada toda la artillería de procesado de señales, para mi el modo natural de conectarle cosas es por vía digital. En el caso de las Raspberries lo más inmediato es utilizar la conexión HDMI 1.3, capaz de transportar audio 7.1 en 192/24. No obstante, una vez alojada ya la RPi 1 junto a su hermana en el cajón de los trastos me he encontrado con 2 problemas. Uno de ellos, además, importante. Veamos cuáles son.

El audio por HDMI está amplificado digitalmente unos 4dB. Esto hace que si se reproduce alguna pista pasada de loudness(relativamente frecuente en Spotify), los altavoces saturen. Muy feo.
Animado por lo chulo que es Volumio, he probado también a reproducir audio desde un NAS. Sorpresa. Todo se remuestrea a 44 o 48 Khz (no he tenido la paciencia de determinarlo con exactitud).

Inicialmente he pensado que el problema debía proceder del mezclador de Volumio, pero su desactivación no ha causado el menor efecto en mi caso.

El segundo problema (remuestreo a la baja) tenía peor pinta. Es cierto que si se utiliza Volumio exclusivamente como destino Airplay esto no tiene importancia dado que este último remuestrea incondicionalmente a 48 Khz todo flujo de audio que transporta, pero ya metidos en harina había que investigar un poquito más.

La solución definitiva la he hallado en los foros de Volumio. Un aguerrido usuario ha encontrado el modo de resolver nuestro segundo problema y, de propina, el primero. La estrategia de choque pasa básicamente por instalar un kernel modificado sobre el que viene de serie con Volumio. Aunque las instrucciones están más o menos desparramadas en este hilo, me permito resumirlas aquí en román paladín con alguna que otra aportación de mi cosecha para facilitar el proceso.

1. Descargar los archivos modificados:

https://www.dropbox.com/sh/7kagpd4cxorubgb/AACl7fENqLm5SwvCDZsMPbMZa?dl=0

https://mega.nz/#F!AoRQ3QAQ [copia]

2. Transferir los archivos a la Raspberry

Esto tiene que hacerse empleando el protocolo SSH.

Si usamos un PC con Linux o un Mac bastará con abrir la interfaz de comandos, situarnos en la carpeta donde hemos descargado los archivos anteriores y teclear el comando:

scp boot-3.18.11+.tgz modules-3.18.11+.tgz root@volumio.local:/

El nombre de anfitrión volumio.local puede ser sustituido por la IP de la RPi que corre Volumio en caso de problemas, aunque en condiciones normales el primero debería resolverse correctamente. La contraseña que se nos solicitará para establecer la conexión es volumio.

Si empleamos un PC con Windows, mejor será que nos procuremos cuanto antes dos estupendas aplicaciones que nos vendrán de perlas para completar el proceso, WinSCP y PuTTY. WinSCP ofrece una interfaz gráfica similar a la de cualquier cliente de transferencia de archivos mediante FTP pero realmente funciona sobre SSH. PuTTY lo emplearemos más adelante para instalar los archivos descargados en nuestra Raspberry.

https://winscp.net/eng/download.php

http://www.putty.org/

Tras instalar WinSCP solo hay que ejecutarlo e introducir los datos de conexión hacia Volumio en nuestra RPi. Nuevamente, se puede emplear la IP o el nombre de anfitrión. La contraseña que nos pedirá el sistema será también, lógicamente, la indicada unas líneas más arriba (volumio).

La primera vez que conectemos será necesario autorizar explícitamente la comunicación entre nuestro ordenador y Volumio en la RPi.

...para, tras conectar, copiar los archivos a (por ejemplo) la carpeta raíz de la SD de Volumio.

3. Desempaquetar el nuevo kernel y archivos relacionados

Otra vez echaremos mano de SSH, pero en esta ocasión personificado en una terminal de comandos remota.

Linux & Mac: invocaremos nuevamente la línea de comandos y teclearemos la siguiente instrucción:

ssh -l root volumio.local

Windows: Aquí emplearemos PuTTY, en el que de un modo análogo a como hicimos con WinSCP estableceremos una conexión de tipo SSH con Volumio.

En ambos casos (Linux / Mac o Windows), introduciremos la clave que se nos solicita para completar la conexión (volumio), con lo que tendremos bajo las órdenes de nuestros dedos el entorno Linux de Volumio en la Raspberry...

...para a continuación teclear los comandos:

cd /

tar xvzf boot-3.18.11+.tgz

tar xvzf modules-3.18.11+.tgz

Los 2 últimos probablemente se tomarán su tiempo, especialmente si hacéis esto en una RPi 1. Ambos comandos tar descomprimirán los paquetes descargados y sobreescribirán los archivos de Volumio que deban ser sustituidos para mejorar las prestaciones de la salida de audio a través de HDMI.

Cuando aparezca nuevamente el cursor parpadeante reiniciaremos Volumio tecleando:

reboot

Y con esto queda completado el proceso.

Tengo que decir que Volumio es un reproductor extremadamente parco, ni tan siquiera se muestran las carátulas al navegar utilizando la interfaz de control, que es de tipo web. No obstante funciona extremadamente bien, máxime si se tiene en cuenta el hardware sobre el que corre, y ofrece prestaciones interesantes tales como un modo de reproducción desde RAM, compatibilidad con Spotify, reproducción de DSD vía DoP, exploración en modo biblioteca o por carpetas, un modo muy práctico de acceder a los recursos de audio que gestiona a través de la red, Airplay (como ya sabemos), UPnP, etc. etc. No conviene olvidar que su corazón no es otro que un peso pesado como es el conocido Music Player Daemon (MPD).

Confío en que esto de usar 2 Raspberries sea algo temporal puesto que eventualmente Airplay volverá a ser operativo en Kodi y sus derivados en cuanto los desarrolladores apliquen los parches correspondientes. Por el momento ambas frambuesas comparten cajón bajo televisión y amplificador.

Mi análisis de Roon ¿una revolución en los sistema de catalogación y reproducción de audio?

noreply@blogger.com (Pablo Felip) — Fri, 29 Jan 2016 12:25:00 +0000

Ambiciosa proposición ¿verdad? Pues eso es lo que nos prometen los chicos de Roon Labs, una plataforma de catalogación y reproducción musical que nos "permitirá experimentar la música como nunca antes". Ahí es nada.

Los fundadores de Roon Labs no son nuevos en esto del audio en streaming. Allá por 2007 lanzaron el servidor musical Sooloos, cuya tecnología fue posteriormente adquirida por Meridian Audio. Ahora es la propia Meridian quien propicia el nacimiento de Roon Labs como empresa independiente enfocada en la creación de software específico para la reproducción musical. Y (desgraciadamente) acostumbrados como estamos a dispositivos con unas especificaciones de infarto pero con un pésimo o, cuanto menos, muy mejorable software, esta iniciativa se asemeja lo suficiente a un soplo de aire fresco en la dirección correcta como para no ser tenida en cuenta.

¿Qué es Roon?

Roon es un software compatible con sistemas OS X y Windows (con arquitecturas de 32 o 64 bits) que puede ser descargado desde aquí. Se trata de una versión de evaluación plenamente funcional durante 14 días. Pasado ese periodo de tiempo tendremos que abonar $119 al año o $499 para conseguir una versión permanentemente funcional. Como podéis ver por tanto el producto se ofrece bajo una modalidad de suscripción, con la posibilidad de pagar por adelantado algo más de 4 años de servicio para optar a una licencia perpetua.

No obstante el pago no presupone, como quizás cabría presuponer, el acceso en "barra libre" a una enorme biblioteca musical en Nube, sino que por el contrario será el mismo usuario quien tendrá que aportar su propia colección de audio y sus propios sistemas de almacenamientos. Estamos pagando por tanto, por la posibilidad de acceder a nuestra propia audioteca, almacenada en nuestros ordenadores, discos duros y/o dispositivos NAS, de un modo que, a juzgar por lo que se nos pretende cobrar, debe ser bastante especial.

Roon no es, en definitiva, otra cosa que un catalogador y reproductor de nuestra propia biblioteca musical que puede emplear cualquier dispositivo de audio conectado al ordenador en el que se ejecuta, o enviar el flujo de audio a uno o varios dispositivos de reproducción presentes en nuestra red local. Como podéis intuir, en este sentido no difiere mucho de conocidas aplicaciones como Foobar, JRiver Media Center o Logitech Media Server.

Donde Roon eleva la apuesta, y de qué manera, es en el modo en el que nos permite disfrutar de nuestra biblioteca. Y esto es así por 2 razones.

Primeramente, una vez le indicamos a la aplicación dónde se encuentran nuestros archivos, Roon realiza un extensivo proceso de análisis, extrae las etiquetas presentes en los mismos (cómo no) pero, además, enriquece su contenido con una enorme cantidad de información descargada de Internet: biografías, letras, comentarios, imágenes, clasificación extendida de géneros... Este proceso, que en el mundo anglosajón se denomina scraping, no es único en Roon. Otros gestores audiovisuales lo llevan realizando también desde hace años, gestores como XMBC/Kodi, Plex o el propio Jriver Media Center. Sin embargo, puedo aseguraros que ninguno de ellos implementa este proceso tan bien como Roon. Y eso es mucho decir.

En segundo lugar, con toda esta metainformación adicional obtenida, Roon teje una telaraña de relaciones que cubre géneros, artistas, compositores, colaboradores, épocas, formatos e incluso información sobre próximos conciertos, telaraña que expone ante el usuario a través de una interfaz extremadamente cuidada tanto desde el punto de vista gráfico como de la usabilidad, de un modo muy similar a las propuestas de conocidos servicios de streaming por suscripción como Spotify, Tidal o Google Music.

Si a esto le añadimos un paraguas de compatibilidad bajo el que se cobijan dispositivos de reproducción tan diversos como Airports, streamers de gama alta de Meridian o Auralic o incluso Squeezeboxes (en modo nativo) y una brillante gestión de las etiquetas, coincidiréis conmigo en que tenemos un producto de lo más interesante.

Vamos por tanto a echarle un primer vistazo a, sobre el papel, tan interesante propuesta. Os adelanto que siguen una cantidad indecente de capturas de pantalla.

Usando Roon

He instalado Roon en un HTPC que, en honor a la verdad, tengo bastante olvidado. Se trata de un sencillo PC con las siguientes características:

Caja Antec Fusion Remote.
Placa ASUS P5KPL-AM EPU.
Pentium Dual Core E5500.
4GB RAM DDR2 800.
HD 2,5" SSD Kingston V+ Series 128GB.
Gráfica ATI HD5570 pasiva (la de la foto es una ATI 4670 que sustituí posteriormente).
Fuente modular Thermaltake Toughpower 575W.
LG CH10LS Supermultiblue: lector BR + DVDRW.
Windows 10 (64 bits).

Sí, es el mismo que aparece en el hilo sobre Foobar. De hecho, desde que este equipo ha pasado a algo así como "la reserva activa" lo he venido utilizando para hacer toda clase de pruebas.

El dispositivo de reproducción es la salida HDMI de la propia tarjeta gráfica, que soporta audio multicanal en PCM hasta 192/24, y está conectado a un receptor multicanal Pioneer SC-LX81.

Roon tiene unos requisitos hardware relativamente elevados. De hecho, yo lo he instalado en un equipo que queda por debajo de los recomendados, aunque tengo que decir que no he apreciado, en principio, problema alguno por ello. Lo que sí puede dejar fuera de juego a más de un equipo con ya algunos años a sus espaldas es la exigencia relativa a la compatibilidad con OpenGL 3.0. Es el precio que se paga por una interfaz de usuario tan pulida.

La instalación no tiene secreto alguno. En el transcurso del proceso, que puede requerir la presencia de .NET en el caso de Windows, cuya descarga de ser necesaria realizará por su cuenta el instalador, Roon nos preguntará si deseamos configurar un servidor completo o solo un punto de control. Hablando de controladores, lo habitual será configurar un servidor dedicado sin pantalla, aunque Roon es una aplicación más del sistema que en modo alguno impide la ejecución de otros procesos, que será controlado bien desde las apps nativas disponibles para Android 4.4+ o iOS 8+ (atención, solo tabletas), bien desde otro PC o Mac en el que se ha instalado Roon en modo punto de control.

Cuando ejecutamos Roon por primera vez, tras completar la instalación, tendremos que indicar dónde se encuentra la carpeta que deseamos que gestione.

Yo he dirigido al asistente hacia la carpeta habitual que contiene mi audioteca, localizada en un NAS. Puesto que estamos en terreno Windows, se emplea (implicitamente) CIFS como protocolo de acceso.

A continuación, si lo deseamos, podemos integrar nuestra propia biblioteca con Tidal, sobre la que Roon realizará también su "magia".

Y tras esto ya tendremos ante nuestros ojos la pantalla principal de Roon, que ya habrá iniciado el proceso de análisis de los archivos contenidos en la ruta indicada anteriormente. Inicialmente se mostrarán unas estadísticas básicas acerca de nuestra biblioteca, así como los elementos recientemente añadidos.

Roon admite el uso de perfiles de usuario (profiles). De este modo diferentes personas pueden disfrutar de recomendaciones personalizadas, listas de reproducción y otros elementos vinculados a las preferencias personales de modo independiente. El sistema es similar al mecanismo de perfiles de, por ejemplo, Netflix.

Tras realizar la actualización sugerida (ver captura anterior), lo primero que he hecho es dirigirme a husmear en la configuración de Roon. Esto se consigue desplegando un menú que aparece al hacer clic con el ratón en el típico botón que representa al menú de la aplicación (extremo superior izquierdo).

El menú de ajustes está integrado por 6 pestañas: general, almacenamiento, servicios, ajustes, audio y cuenta. Dado que este artículo no pretende ser un tutorial sino más bien una toma de contacto, solo comentaré aquellas cuestiones que me parezcan más relevantes.

Roon puede vigilar múltiples carpetas, locales o en red, cuyo contenido se mostrará de modo consolidado, como si de una única biblioteca musical se tratase. Es importante mencionar que Roon no va a renombrar o desplazar el contenido de las carpetas vigiladas en ningún momento, del mismo modo que tampoco sobreescribirá las etiquetas de nuestros archivos de modo automático. Si deseamos que la aplicación sí organice nuestra colección de archivos deberemos agregar su(s) carpeta(s) contenedora(s) como Organized folders.

En la pestaña correspondiente a Ajustes nos encontramos con una opción de lo más interesante, precisamente la que nos permite activar la compatibilidad con nuestros queridos Squeezeboxes. A esto dedicaremos unas líneas posteriormente.

En la pestaña Audio podremos activar y configurar los distintos dispositivos de audio soportados, tanto locales como remotos, que aparecen en secciones distintas. Cada dispositivo dispone de un botón de configuración para ajustar cosas como el uso exclusivo, el control de volumen, la frecuencia máxima de reproducción soportada o la compatibilidad con, sí, DSD. Es posible activar o desactivar cada dispositivo detectado, así como configurar zonas de reproducción que, como os podéis imaginar, están perfectamente soportadas en un servidor como este.

Por si fuera poco, Roon soporta dispositivos basados en HQPlayer, el que es para algunos el reproductor que ofrece una mayor calidad de sonido en estos momentos.

Ya de vuelta a la ventana principal, comprobaremos que efectivamente es como si tuviéramos un spotify con nuestra propia música: archivos recientes, artista destacado, función "descubrir", etc.

La mayor parte de elementos que se ven en la pantalla están lógicamente vivos, es decir, se puede hacer clic en ellos para acceder a álbumes, compositores, géneros, etc. Este lujo visual es algo generalizado a lo largo y ancho de la interfaz de usuario, que está plagada de elementos visuales destinados a hacernos descubrir música relacionada con la que estamos ojeando.

Además, podremos crear nuevas etiquetas y modificar la información que Room presenta en pantalla, corrigiendo datos o decidiendo si preferimos la contenida en las propias etiquetas o la descargada de Internet y, además, este aspecto se puede determinar con un alto grado de granularidad para distintos atributos.

Una característica extremadamente interesante es la denominada Focus on. Cuando este botón aparece en pantalla podemos, a través de él, acceder a otros elementos de la audioteca que Roon considera similares al que estamos viendo.

Esta herramienta de enfoque nos permite además refinar los resultados, aplicando filtros por fecha, género, frecuencia de reproducción y una multitud adicional de posibilidades.

Además de una sección en la que el motor de análisis de Roon nos hace sugerencias, se dispone también de las vistas clásicas por género, álbum, artista, etc. y de una función de búsqueda.

Otra función destacable es la que nos mantiene al tanto del procesamiento que está sufriendo la señal de audio a lo largo de toda la cadena de reproducción. A través de un clarificador gráfico podremos comprobar si se está produciendo alguna conversión o remuestreo. Quizás esto a algunos os recuerde a una característica similar presente en JRiver Media Center.

Roon desde la tableta

Probablemente os habréis fijado en que las capturas de pantalla anteriores han sido tomadas utilizando TeamViewer, una conocida aplicación de control remoto, que me permitía interactuar con Roon desde el ordenador en el que me encuentro escribiendo estas líneas. Ha llegado el momento de echarle un vistazo a la app de control que Roon Labs ha preparado. Como no tengo ninguna tableta Android he optado por la versión para iPad (recordad que no existe app para teléfonos, al menos hasta donde yo sé).

Si la interfaz de control de Roon corriendo en un ordenador os parece buena, la que disfrutaréis en una tableta os lo parecerá también: son idénticas. Y esa similitud no se limita a las funciones de exploración y reproducción, sino que (y esto me parece extraordinario), también a las de edición de etiquetas y configuración de la biblioteca, dispositivos, etc. En este sentido creo que la app de control para Roon se sitúa ligeramente por encima de pesos pesados como iPeng o JRemote. Por aquello de que todo no tienen que ser flores, decir que echo de menos la posibilidad de suspender y reactivar el PC desde la propia app de control, cosa que sí nos encontramos sin embargo en otras propuestas competidoras.

Algunas capturas para que comprobéis hasta qué punto esto es cierto:

Una característica de Roon que no he mencionado hasta el momento tienen que ver con los álbumes de los que disponemos en varios formatos o versiones. Roon los identifica automáticamente y nos permite escoger cuál deseamos escuchar por defecto. Y todo ello desde la propia app de control.

Llegados a esto punto, me resulta difícil no estar impresionado. Pero sigamos...

Roon y nuestros adorados Squeezeboxes

Roon incorpora, en fase de pruebas, la posibilidad de utilizar cualquier Squeezebox que tengamos conectado a nuestra red local como dispositivo de reproducción. Y esto no lo consigue a través de la capa de emulación de servicios de reproducción UPnP de la que les dota el servidor de Logitech (Logitech Media Server) al que estos aparatejos se conectan de modo natural. Pues no, Roon ofrece soporte nativo para nuestros veteranos Squeezeboxes. Audiófilos del mundo, podéis apagar vuestro LMS (desde aquí me parece estar oyendo los gritos de júbilo).

Si, como yo, no sois tan drásticos, os alegrará saber que los pasos para vincular un Squeezebox a nuestro servidor Roon son muy simples, perfectamente reversibles y no requieren de acciones tan violentas como la desconexión del servidor LMS que tengamos corriendo en nuestra red. Para conseguirlo bastará con, utilizando los propios controles del Squeezebox, seleccionar una nueva biblioteca musical, que aparecerá en pantalla con el nombre que hayamos determinado al configurar Roon. Esto mismo puede conseguirse desde aplicaciones de control específicas para Squeezebox como iPeng, aunque posteriormente para devolver el Squeezebox a su ecosistema natural será necesario operar manualmente el dispositivo.

Tras este ajuste nuestro (en este caso) Squeezebox Touch ya aparecerá como un dispositivo de reproducción más en Roon.

Y podrá ser utilizado como una zona adicional de reproducción.

Además, como podéis ver en las capturas el plugin EDO, que dota al Touch de capacidad para reproducir audio a más de 96Khz, está soportado.

Mientras se encuentra bajo el control de Roon, no aparecerá en la pantalla del Squeezebox información sobre la reproducción, aunque esto creo que es un bajo precio a pagar teniendo en cuenta lo que ganamos a cambio.

Formatos soportados y calidad de sonido

De acuerdo con la información publicada por Roon Labs, los formatos soportados son estos:

WAV hasta 384/24.
AIFF hasta 384/24.
FLAC hasta 384/24.
ALAC hasta 384/24.
OGG hasta 384/24.
DSD64, DSD128, y DSD256 en formato DSF.
MP3 (depende del SO).
AAC (depende del SO).

Como veis no se ofrece compatibilidad con audio multicanal, aunque he podido comprobar que cualquier formato PCM sin pérdidas con DTS enterrado sí se reproduce correctamente en 5.1 cuando se emite en digital hacia un DAC capaz de descodificarlo. A Roon tampoco le gustan APE, MLP o cualquier contenedor de tipo ISO. En este sentido otros reproductores superan con creces sus prestaciones, pero probablemente estamos hablando de formatos un tanto minoritarios.

Con respecto a la calidad de sonido tengo que decir que no me ha sorprendido ni positiva ni negativamente.

Opinión personal sobre Roon

No quería emitir una opinión personal sobre Roon justo tras escribir el análisis previo por varias razones. La primera tiene que ver con el hecho de que tiendo a entusiasmarme con cada producto o servicio nuevo que por alguna u otra razón me deslumbra a las primeras de cambio, por lo que prefiero dejar que la euforia inicial se diluya para tratar de ser más objetivo. La segunda circunstancia es más prosaica, simplemente me parece de recibo disponer de cierto tiempo para poder probar las cosas con detenimiento. Es por esto que he dejado pasar unos días hasta abordar este apartado de conclusiones. No sé si ese relativamente corto periodo de tiempo es suficiente o no, el caso es que ahora mismo estoy ya razonablemente seguro como para posicionarme al respecto de Roon.

Voy a comenzar por el final: No, no voy a renovar mi suscripción. Paso a explicaros las razones.

De entrada Roon deslumbra. Aunque otros reproductores practican el arte del "scraping" para embellecer nuestra colección audiovisual, ninguno lo hace de un modo tan brillante como Roon, que integra toda la metainformación descargada complementaria para construir una experiencia de uso y exploración de la biblioteca personal que ahora mismo no tiene parangón. Y además lo hace con una aparente sencillez y facilidad que casi asusta, sencillez que no obstante no impide que se ofrezcan extensivas opciones de edición y personalización de su contenido. Simplemente brillante.

Si escarbamos un poquito más nos encontramos con un motor de reproducción capaz de interactuar con una variedad de dispositivos de audio locales y remotos (en red). En este aspecto se echa de menos la posibilidad de integrar reproductores UPnP que dispongan del perfil renderer, aunque me temo que su ausencia delata el estado de cosas por lo que hace a la intercompatibilidad ofrecida por este estándar, estado que en ocasiones hace pensar que hay poco de estándar y mucho de incompleto. Además, las funciones esperables tales como son las relativas a la gestión de múltiples zonas de reproducción o al uso de los dispositivos en modo exclusivo y la gestión de sus capacidades, incluyendo la reproducción DSD, están contempladas.

Roon va a ser inevitablemente comparado con los pesos pesados que llevan dominando el sector de las aplicaciones de catalogación y reproducción. Estamos hablando, lógicamente de aplicaciones estándar que se pueden instalar en un PC o Mac. Y seguramente todos estaréis pensando en contendientes como Amarra, Audirvana, JRiver Media Center o Foobar. Todos ellos se distribuyen como un producto cuyo derecho de uso se adquiere por un periodo indefinido y, con la excepción de ciertas versiones de Amarra, el coste es reducido o nulo. Y eso sin tener en cuenta la variedad de propuestas enraizadas en el mundo del software libre, capaces de ejecutarse algunas de ellas en pequeños dispositivos de bajo coste (universo Squeezebox, Daphile, Kodi, MPD, etc.). Opciones hay para todos los gustos y todos los bolsillos.

Por un lado, muchos de estos productos competidores ofrecen compatibilidad con formatos y contenedores de archivo no soportados por Roon. Os concedo que, seguramente, la mayoría sean minoritarios y hasta innecesarios, pero la diferencia está ahí. Por otro lado, Roon carece de la enorme potencia de la que gozan reproductores como Foobar o, muy especialmente, JRiver Media Center (JRMC) en el ámbito del procesado de señales. En este sentido para mi el campeón indiscutible es JRMC, cuyo módulo de DSP ofrece funciones de gran potencia tales como el cambio automático de zonas, el remuestreo y recodificación condicional, el filtrado paramétrico, la corrección de sala, la gestión de reproductores UPnP como puntos de reproducción y un largo etcétera que podéis repasar vosotros mismos simplemente haciendo una búsqueda en Audio Planet. Y además despliega toda esa potencia a través de una interfaz de control en forma de app (JRemote) sobresaliente. De nuevo tengo que reconocer que muchos usuarios ni conocen ni desean todas estas funciones... pero (nuevamente) la diferencia emerge por sí sola.

Por lo que hace a la calidad percibida de reproducción no voy a hacer ningún comentario. No me ha sorprendido ni positiva ni negativamente, lo que para un objetivista convencido como yo resulta no ya tan solo esperable sino tranquilizador en un reproductor capaz de funcionar bajo la doctrina del bitperfectismo.

¿Merece la pena pagar por Roon, teniendo alternativas más potentes desde el punto de vista de la fuerza bruta de su motor de reproducción, simplemente por su excelsa experiencia de usuario?

En mi caso tengo que decir que no.

Para mi existen alternativas (y varias de ellas) de menor coste que calman mi sed tecnoaudiófila. Al fin y al cabo, si empleamos una aplicación de control desde un dispositivo móvil tenemos a un par de toques de distancia, desde la comodidad del sillón, la Wikipedia, docenas de blogs independientes sobre música, last.fm y, en definitiva, la propia Internet para leer hasta la más recóndita anécdota sobre nuestro disco o artista favorito o quizás descubrir otros relacionados. En mi caso, que Roon relacione entre sí elementos de mi colección es fantástico, pero prescindible fundamentalmente porque no tengo una colección tan extensa como para olvidar totalmente algunos de sus elementos, lo que naturalmente puede no ser el caso de otras personas. Para todo lo demás, Spotify, Deezer o Tidal.

No obstante le auguro a Roon un futuro prometedor. Estoy seguro de que lo veremos formando parte y a la vez siendo núcleo cohesionador de sistemas de audio de altos vuelos configurados por empresas dedicadas a la comercialización de eso que ha venido en denominarse High-End.

Por último, no me gustaría terminar sin apreciar el hecho de que Roon ofrece un foro de soporte que parece tener una intensa actividad. Su lectura indica que detrás de Roon hay un potente equipo de desarrollo, por lo que es de esperar que nuevas funciones y prestaciones sean añadidas a buen ritmo conforme pase el tiempo, del mismo que ha venido ocurriendo en los últimos meses.

Habrá que estar atentos.

Nota: Hay un hilo de conversación que da continuidad a este artículo en Audio Planet.

Feliz 2016

noreply@blogger.com (Pablo Felip) — Thu, 31 Dec 2015 18:18:00 +0000

Mis mejores deseos para todos y que el Viaje siga mereciendo la pena por muchos años.

Configurar Foobar en Linux para reproducción bitperfect

noreply@blogger.com (Pablo Felip) — Sun, 15 Nov 2015 17:13:00 +0000

Desde que he adoptado Linux / Mint como mi SO de uso habitual en casa, no he dejado de explorar distintas alternativas a la hora de reproducir musiquita mientras estoy delante del ordenador, como podréis comprobar si leéis las última entradas de este blog dedicadas a Spotify en Linux o al tinglado que he montado usando Logitech Media Server, Squeezelite, Orange Squeeze y ARC Welder.

No obstante tenía pendiente ver hasta qué punto era posible conseguir que Foobar, el extraordinario reproductor disponible únicamente para Windows, funcionara correctamente en Linux a través de la capa de compatibilidad que proporciona Wine.

En su momento ya hice mis pinitos con la ejecución cruzada de Foobar en OS X, consiguiendo un resultado fantástico que incluso permitía reproducir DSD codificado como DoP, a pesar de las capas de emulación y de los diversos subsistemas de audio implicados:

http://www.pablofelip.tk/2014/06/corriendo-foobar-en-mac-y-con-soporte.html

La única pega que no fui capaz de solventar entonces fue la relativa al hecho de que fuera necesario prefijar una frecuencia de salida en las propiedades de Core Audio para que la emisión en DoP pudiera tener lugar, ajuste que supone, en cualquier caso, un remuestreo incondicional de todo el audio reproducido.

El objetivo de este artículo, por tanto, es ver hasta dónde se puede llegar en un entorno Linux por lo que hace al uso de Foobar como reproductor. Ya os adelanto que bastante lejos, como quizás intuyáis viendo esta captura:

1. Instalar WineHQ y PlayOnLinux

Para comenzar, necesitaremos instalar el paquete WineHQ y un front-end para él denominado PlayOnLinux (POL, en adelante) que facilita enormemente la instalación, configuración y uso de Wine. Estrictamente hablando podemos prescindir de POL, pero en mi opinión aporta lo suficiente como para que contemos con él, así que con vuestro permiso voy a utilizarlo sin contemplaciones. Más adelante hablaremos de estas aportaciones.

Podemos instalar POL desde la página de descarga del proyecto, en la que encontraremos instrucciones detalladas para distintos sabores de Linux.

Alternativamente, podemos utilizar el gestor de paquetes de nuestra distribución (Mint en mi caso) para hacernos tanto con POL como con Wine, que es un paquete requerido por el primero.

2. Instalar Foobar

Ahora procederemos a instalar Foobar empleando POL. Para ello, abriremos la aplicación desde el correspondiente acceso directo que se habrá creado en el menú de aplicaciones.

Y procederemos a instalar un nuevo programa:

POL dispone de una galería de aplicaciones, organizadas en categorías, que podemos explorar casi casi como si de una tienda de aplicaciones se tratara y que se instalarán en un solo click. Foobar es una de ellas, así que bastará con escribir su nombre en el cuadro de búsqueda, hacer clic en la lista de resultados y, a continuación, en el botón correspondiente para iniciar la instalación.

Se iniciará un sencillo asistente paso a paso cuyas instrucciones seguiremos. En un momento del proceso, POL nos pedirá que descarguemos manualmente Foobar2000 desde la página del proyecto, cosa que haremos, para a continuación indicarle al asistente dónde lo hemos descargado para que dé comienzo la instalación propiamente dicha.

Yo he utilizado la última versión disponible de Foobar, la 1.3.9.

A partir de aquí se iniciará el instalador de Foobar, que tendrá exactamente el mismo aspecto que el que mostraría de haberlse ejecutado en su plataforma nativa, Windows. Seleccionaremos la ruta de instalación, el modo (yo he optado por la instalación estándar), los componentes a incluir, etc. etc. Lo seguiremos sin pestañear hasta completar el proceso.

Al finalizar, nos encontraremos con un bonito icono de Foobar en el escritorio de nuestra distribución, icono que también aparecerá en la ventana de POL. Al hacer clic sobre este último se activarán una serie de opciones y comandos en el panel lateral.

3. Un poco más sobre WineHQ y POL

Antes de seguir, hablemos un poquito de Wine y POL.

Wine (Wine is not an emulator) es una capa de software que proporciona compatibilidad con numerosas aplicaciones Windows, incluso con algunos juegos, y que encima lo hace sin necesidad de instalar este sistema operativo sobre una máquina virtual (obviando por tanto la necesidad de disponer de una licencia de Windows).

La estrategia que sigue Wine, como apunta su nombre, no está basada en la virtualización, sino en ofrecer a las aplicaciones Windows un entorno de ejecución anfitrión que trata de parecerse todo lo posible a Windows, esto es, una API (interfaz de programación de aplicaciones) compatible con WinAPI32 y una unidad de disco (C:) que en realidad es una carpeta dentro del sistema de archivos de nuestra distribución Linux. Todo para que nuestros programas Windows favoritos se sientan como en casa.

Esta estrategia tiene, en mi opinión, 2 ventajas:

Facilita la el uso integrado de las aplicaciones Windows con las nativas del sistema operativo.
No es necesario cargar un sistema operativo completo emulado, como sería el caso de emplear Virtualbox o cualquier otra herramienta de virtualización.

Como contrapartida, no todas las aplicaciones funcionan con Wine o, cuando sí lo hacen, pueden aparecer fallos de mayor o menor gravedad.

Por su parte, POL no es otra cosa que una interfaz de usuario que facilita el uso de Wine ¿De qué manera? De varias, aunque si tengo que destacar algunas, más allá de la obvia que supone el uso de su interfaz para la instalación y administración de aplicaciones, serían estas:

Permite crear unidades C: independientes para cada aplicación instalada, lo que facilita el uso de configuraciones específicas para cada aplicación que ejecutemos a través de Wine. De este modo, cada una de estas aplicaciones funcionará dentro de algo así como su propia instalación de Windows, lo que incluye ajustes independientes dentro del registro de Windows.
Dispone de un gestor de versiones de Wine, de modo que podemos elegir con qué versión deseamos ejecutar cada una de las aplicaciones instaladas y probar varias de ellas para determinar con cuál funciona mejor.

Tras este preámbulo, vamos al lío.

4. Configurar POL / Wine para ejecutar Foobar en modo bitperfect

Por defecto, Wine utiliza Pulse como sistema de audio predeterminado. Pulse es, por definición, concurrente, es decir, admite flujos de audio simultáneos procedentes de varias aplicaciones, flujos que mezcla y remuestrea a una frecuencia de salida específica. Esto no es lo que queremos si pretendemos conseguir que Foobar funcione en modo bitperfect (transparente), es decir, respetando las naturaleza y manteniendo la integridad del archivo de audio reproducido. Por tanto, lo primero que tendremos que hacer es pedirle a Wine que ejecute Foobar utilizando ALSA, que sí admite un funcionamiento en modo exclusivo (si queréis saber algo más acerca de la arquitectura de audio de Linux podéis leer esto).

Para configurar Wine / POL / Foobar en modo ALSA tendremos que utilizar el comando Configurar disponible en POL.

Para seleccionar, a continuación, la pestaña Wine y la opción Editor del Registro:

Lo que queremos es, como podéis suponer, acceder al registro del entorno Windows dentro del cual se ejecuta Foobar para introducir una clave que le indique a Wine que debe utilizar el subsistema de audio ALSA en lugar de Pulse.

Una vez se abra el editor del registro, nos dirigiremos a la carpeta:

HKEY_CURRENT_USER :: Software :: Wine :: Drivers

Aquí crearemos una nueva clave dentro de la carpeta Drivers del siguiente modo:

La clave debe llamarse Audio y le asignaremos el valor alsa.

Cerraremos ahora el Editor del registro y haremos clic en la opción Configurar Wine para comprobar que efectivamente el cambio ha surtido efecto.

En el panel de configuración nos dirigiremos a la pestaña Audio para comprobar que, efectivamente, la instancia de Wine que ejecutará Foobar utilizará ALSA (controlador seleccionado: winealsa.drv)

5. Configurar Foobar en modo bitperfect

Ya casi estamos.

Ahora arrancaremos Foobar, bien utilizando el icono que habrá aparecido en el escritorio, bien utilizando el comando Lanzar en POL.

Si todo va como debe, tendremos al viejo Foobar corriendo en nuestro escritorio Linux. Ya podemos reproducir cualquier archivo de audio que tengamos a mano. Al hacerlo apreciaremos que el resto de sonidos del sistema quedan enmudecidos, como era de esperar.

No obstante esto no es suficiente. A pesar de que el audio se reproduce en modo exclusivo, se está produciendo un remuestreo a la frecuencia de salida y resolución (bits / muestra) prefijados por nuestro anfitrión Linux (típicamente 44Khz y 16 bits). Para comprobarlo, bastará con que reproduzcáis archivos con diferentes frecuencias de muestro y, simultáneamente, escribáis en una terminal algo parecido a esto:

more /proc/asound/STX/pcm0p/sub0/hw_params

Tendréis que sustituir STX/pcm0p/sub0 por los correspondientes a vuestro dispositivo de audio. En mi caso, lo que aparece en pantalla es algo como esto otro:

access: MMAP_INTERLEAVED

format: S16_LE

subformat: STD

channels: 2

rate: 44100 (44100/1)

period_size: 440

buffer_size: 1764

Fijaos en las líneas en rojo. Permanecerán invariantes con independencia de las características del archivo reproducido. Malo.

¿Y cómo lo solucionamos? Muy fácil: con el complemento WASAPI para Foobar.

Bastará con descargarlo desde la página de complementos de Foobar e instalarlo del modo habitual:

File :: Preferences :: Components :: Install...

Ya que estamos, podemos instalar también algún que otro complemento adicional. Yo he añadido los siguientes:

APT-x100 Decoder.
DTS-HD decoder.
DVD-Audio Decoder and Watermark Detector
Lyrics Show Panel 3
Super Audio CD Decoder

Algunos de ellos son de tipo -component y se agregan de este modo. Otros deben instalarse manualmente copiando los archivos .dll correspondientes a la carpeta...

\Program Files\foobar2000\components

...dentro de la unidad C emulada para nuestra instancia de Foobar. Para acceder a ella usaremos el comando Abrir un directorio de POL, que abrirá el gestor de archivos de nuestra distribución y lo apuntará a la carpeta en la que se encuentra instalado Foobar.

De modo análogo, nos dirigiremos a...

\users\nombre_de_usuario\Application Data\foobar2000

Para copiar las carpetas dvda_metabase y sacd_metabase necesarias para un funcionamiento óptimo de los complementos de reproducción de DVD-Audio y SACD.

Por último, ya solo queda configurar las propiedades de salida de audio en Foobar para seleccionar el dispositivo que deseemos utilizar en su modo de uso WASAPI (push) y su formato de salida (no, WASAPI event no funciona, o al menos no lo hace en mi sistema):

File :: Preferences :: Playback :: Output

Si ahora repetimos la prueba anterior veremos como la salida del comando...

more /proc/asound/STX/pcm0p/sub0/hw_params

...refleja correctamente la naturaleza del audio reproducido.

5. Comentarios finales

Tras seguir el procedimiento descrito en este artículo, nos encontramos con Foobar ejecutándose en Linux de un modo estable y ofreciendo una reproducción íntegra y de calidad, sin artefactos en el sonido tales como microcortes, ruídos, etc. De hecho, personalmente lo prefiero a cualquiera de los reproductores / gestores de audio nativos que he probado hasta el momento.

Lógicamente podemos seguir configurando Foobar a nuestro gusto: otros complementos como Sox, remezcla a estéreo a través del DSP Manager, aspecto de la interfaz de usuario, etc. etc. En mi caso la cosa ha quedado así:

Lamentablemente no he podido comprobar si Foobar, instalado y configurado de este modo, es capaz de reproducir audio DSD en formato nativo (naturalmente, la transcodificación a PCM de alta resolución funciona perfectamente), bien a través de DoP, bien por medio de ASIO Proxy, aunque probablemente en este caso el tinglado se complique un poquito.

Como en este momento no dispongo de ningún DAC DSD al que meter mano, cualquier comentario al respecto de esta posibilidad por parte de alguien que sí tenga uno y pierda un ratito en seguir estas instrucciones será bienvenido. No obstante, mi apuesta es que funcionará.

No me gustaría concluir sin mencionar un par de cosas más.

Primero: El tándem ALSA / WASAPI es tan, tan exclusivo, que si accedéis a las opciones de salida de audio de Foobar mientras se está reproduciendo algún archivo, probablemente el dispositivo empleado no aparezca en el selector y se muestre un mensaje de error. Simplemente ignoradlo y cerrad la ventana de ajustes.

Segundo: Recordad que POL dispone de un gestor de versiones de Wine. Resulta muy sencillo por tanto probar con otra versión de esta capa de emulación si la empleada inicialmente no acaba de funcionar totalmente bien. Para gestionar las versiones instaladas en POL nos dirigiremos a:

Herramientas :: Gestiona versiones de Wine

Para ejecutar Foobar con otra versión de Wine, utilizaremos el comando Configurar en POL.

Personalmente he obtenido resultados magníficos con la versión 1.6.2.

Nada más, hasta aquí llegamos. Confío en que hayáis encontrado este minitutorial interesante. Podéis hacer comentarios aquí mismo, en el blog, o en el hilo que he abierto en AudioPlanet para intercambiar experiencias con otros intrépidos probadores de cosas ;-):

http://www.audioplanet.biz/t69766-configurar-foobar-en-linux-para-reproduccion-bitperfect

Y el mejor reproductor de audio para Linux es...

noreply@blogger.com (Pablo Felip) — Thu, 15 Oct 2015 18:35:00 +0000

Sigo erre que erre empeñado en hacer de Linux Mint mi hogar digital. Después de Spotify, lo siguiente ha sido añadirle al tinglado un reproductor de audio para mi colección de música desmaterializada.

De hecho, llevo dándole vueltas a esto desde el sábado. Y he probado casi todo lo que ha caído en mis manos: desde organizadores clásicos como RhythmBox, Banshee, Clementine, DeaDBeeF, Guayadeque o gmusicbrowser hasta propuestas más arriesgadas como Musique o Tomahawk pasando por reproductores de la vieja escuela como Audacious o VLC. Y por supuesto, también JRiver Media Center en su incipiente versión para Linux.

Y no me ha gustado ninguno, la verdad. O son un notable desastre (JRMC) o no se ajustan a mi modo de uso (Audacious, VLC) o simplemente no me gustan (todos los demás, con, quizás, la excepción de DeaDBeeF, que me recuerda mucho a Foobar).

La solución, sin embargo, la tenía delante de mis narices (o mejor dicho, orejas) y no era capaz de verla (oirla): Logitech Media Server (LMS) + Squeezelite.

Ya tengo un LMS en su versión 7.9 corriendo 24/365 en un NAS, de modo que solo necesitaba:

Un reproductor software en mi Linux Mint, reproductor que no es otro que el increíble emulador de Squeezebox, Squeezelite.
Un método de control desde el propio PC (la interfaz web de administración del LMS).

La cosa queda tal que así:

¿El resultado? Un software corriendo en el PC que no llega a pesar 500KB, se conecta a mi biblioteca identificando todos sus tags y carátulas, al igual que el resto de Squeezeboxes que andan por casa, y reproduce cualquier cosa que le eche de comer en la carpeta /musica del NAS, incluido DSD encarnado en DFF / DSF, en mi caso con conversión a PCM al vuelo puesto que la tarjeta de sonido utilizada, una Asus Xonar STX, no admite DSD.

A partir de ahí se monta un pequeño script que ejecute Squeezelite con los parámetros adecuados:

...Iconografiado en el menú de lanzamiento rápido de aplicaciones:

...De modo que se abra en el navegador la web del servidor LMS en modo app. Y a disfrutar.

Y aunque con toda seguridad será placebo (y del bueno), el nuevo tinglado me suena en estos momentos mejor que cualquier cosa que haya probado corriendo sobre Windows.

La historia completa, con alguna que otra novedad, aquí:

http://www.audioplanet.biz/t68821-y-el-mejor-reproductor-de-audio-para-linux-es

Spotify para Linux (Debian y derivados)

noreply@blogger.com (Pablo Felip) — Tue, 13 Oct 2015 12:41:00 +0000

Aprovechando el largo puente de la Constitución me he dedicado a probar con cierto detenimiento Linux Mint 17.2 Cinnamon, que me venía haciendo tilín desde hace ya algún tiempo. Me ha gustado mucho, hasta el punto de que ahora mismo arranca de modo predeterminado en mi PC de uso habitual en lugar de Windows 10... aunque esa es otra historia que quizás será contada en otra ocasión.

Puesto que estoy valorando utilizar Mint regularmente, una de las cosas que me tiene que cuadrar es su funcionamiento como reproductor de audio, especialmente con servicios de streaming como Spotify, con el que llevo meses encantado de la vida en su modalidad premium. Pensaba que para utilizar Spotify en Linux había que resignarse a su no-tan-cómodo reproductor web o recurrir a Wine, la conocidad capa de emulación para programas Windows, que al menos en mi caso solo ha funcionado aceptablemente bien.

El caso es que estaba equivocado, estos 4 comandos son lo único que nos separa de disponer de un cliente nativo:

1 sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys D2C19886
2 echo deb http://repository.spotify.com stable non-free | sudo tee /etc/apt/sources.list.d/spotify.list
3 sudo apt-get update
4 sudo apt-get install spotify-client

Y este es el resultado obtenido tras dejar unos segundos que apt-get haga su conocida magia:

Lógicamente esta secuencia de instrucciones se teclea en una terminal ignorando los numeritos que preceden a cada línea. La "receta" debería funcionar correctamente en cualquier sabor de Linux derivado de Debian (Ubuntu, Mint, Elementary, etc.).

Por aquí seguimos hablando de ello:

http://www.audioplanet.biz/t68728-spotify-nativo-para-linux-paquete-deb

Spotiamb, un cliente de Spotify portable a lo Winamp

noreply@blogger.com (Pablo Felip) — Sun, 20 Sep 2015 09:26:00 +0000

Hace tiempo que esto rodaba por ahí, pero no lo había podido probar.

Se trata de Spotiamb, un reproductor de escritorio para Windows que se conecta a Spotify (solo cuentas Premium) y visualmente es idéntico al legendario Winamp, de hecho admite todas sus skins y visualizaciones. El desarrollo procede de la propia Spotify y, como podéis ver, dispone de su lista de reproducción, ventana de carátulas, ecualizador con preajustes, etc. etc.

Aquí lo tenéis en acción con la entrañable visualización MilkDrop (bueno, más bien con una encarnación de la misma basada en OpenGL que funciona bien en Windows 10).

Los paneles de Spotiamb se comportan como los de Winamp; podemos plegarlos, dejarlos siempre por encima del escritorio o no, etc. etc.

Se puede optar por una versión instalable o bien otra simplemente portable, que en cualquier caso tiene un tamaño ridículo. El programa está diseñado para gastar menos gasolina que la moto de un hippie:

Si optamos por la portable, metemos en una carpeta el ejecutable y, si es que vamos a usarlas, las subcarpetas correspondientes a skins y visualizaciones y lo guardamos todo en un pendrive o un servicio de almacenamiento en la nube tipo Dropbox o Google Drive para disponer en cualquier lugar de nuestras listas de reproducción de Spotify a través de un reproductor tremendamente ligero. También podemos hacer búsquedas, aunque el reproductor carece de la biblioteca "Mi música", las funciones de descubrimiento y recomendación de Spotify y de sus elementos sociales.

Pero la cosa no acaba ahí. Podemos levantar un servidor Shoutcast en nuestra red local:

Cualquier reproductor en red que tengamos en casa y sea compatible con Shoutcast (habitual en reproductores que se conectan a emisoras de radio por Internet) podrá conectarse a la IP del PC en el que corremos Spotiamb en el puerto 5010 para "sintonizar" la lista de reproducción que estemos emitiendo.

Además, también podremos controlar otras instancias de Spotify que tengamos en casa:

Pero eso no es todo, Spotiamb también puede ser controlado desde cualquiera de ellas, incluida cualquier versión para dispositivo móvil, como por ejemplo un iPad, lo que nos devuelve el contenido "curado" de Spotify, la carpeta "Mi música", etc. etc. Además, como Spotiamb necesita pocos recursos para funcionar podemos montarnos un reproductor dedicado utilizando un PC antiguo sin problemas.

Juntando todo esto (servidor shoutcast, control desde app) tenemos una forma de reproducir cómodamente Spotify en un dispositivo en red no compatible con Spotify pero sí con Shoutcast.

Una chulada. O al menos, eso me parece.

PS: Parece que el proyecto Winamp no estaba tan muerto como parecía... A ver con qué nos salen.

Tutorial: Configuración del dispositivo de audio en JRiver Media Center

noreply@blogger.com (Pablo Felip) — Sat, 29 Aug 2015 15:28:00 +0000

Siguiendo con el videotutorial anterior sobre la integración de JRiver Media Center en un entorno DLNA, os traigo ahora un pequeño tutorial que pretende clarificar los distintos ajustes que intervienen en la configuración de un dispositivo de audio local en este reproductor.

Aunque 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.

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 [i]bitperfect[/i]. 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 [i]bitperfect[/i], 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 [i]bitperfect[/i]. 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 [i]Core Audio[/i], 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á exactamente 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:

Volumen del Sistema: Es equivalente a actuar sobre el volumen global del sistema.
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:

DSD en formato DoP (DSD y DSDx2).
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 hasta el momento.

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.

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 DSD 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:

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.
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.
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 ASIO, aunque como veremos hay sutiles diferencias.
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 :D. 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

Videotutorial: control de reproductores DLNA desde JRiver Media Center

noreply@blogger.com (Pablo Felip) — Wed, 26 Aug 2015 21:44:00 +0000

Pues eso mismo, os dejo con él sin mayor preámbulo...