Bluetooth para enviar musica al ampli

Hola,
Tengo curiosidad por saber cual es el modo tecnico en que se codifica la información cuando se envia música por bluetooth al ampli, con y sin Aptx.
Por ejemplo si enviamos un mp3 al ampli por bluetooth ( no aptx ), la música se comprime más ? o se envia el mp3 tal cual ?

El perfil A2DP definido por el estándar bluetooh para la transmisión de audio puede emplear diversos codecs con distintas capacidades y fidelidad.

El más habitual pero de menor calidad se denomina SBC. Este soporta hasta 48Khz y una tasa de bits máxima de algo más de 320Kbps. Siempre se produce un proceso de recodificación del flujo original a transmitir (por ejemplo, de mp3 a pcm y de aquí a SBC). La calidad es inferior a la de un mp3 de similar tasa de bits pero con resultados muy consistentes con independencia del tipo de audio transmitido. Aquí tienes una comparativa:

http://soundexpert.org/encoders-320-kbps

A2DP también soporta codecs comerciales, como es el caso de aptX, que realmente es propiedad de Qualcomm (el conocido fabricante de procesadores para móviles). aptX mejora claramente a SBC y presenta a su vez distintas variantes (E-aptX, aptX Lossless/HD...), entre las que como puedes ver se encuentra una que aplica, aparentemente, una compresión "sin pérdidas". Esta última soporta audio hasta 24/96. Para sembrar un poquito más la confusión, aptX Lossless ofrece también un modo de funcionamiento híbrido en el que no es totalmente transparente, recurriendo a un modelo con compresión perceptual, con pérdidas, si en determinados momentos se sobrepasan ciertos límites en la tasa de bits resultante. Destacar también que el hecho de que un dispositivo sea compatible con aptX no implica que también lo sea con esta variante de alta calidad. Tampoco es fácil saber el modo real de funcionamiento, en un momento dado, de un par de cacharros (móvil, auriculares) que sobre el papel se anuncian como compatibles con aptX.

Aquí comparan SBC (y mp3) con aptX:

http://www.sereneaudio.com/blog/how-good-is-bluetooth-audio-at-its-best

En cualquier caso, al igual que con SBC, siempre se produce una recodificación del flujo original.

En mi opinión, aptX mejora claramente a SBC. Con respecto a otros protocolos de emisión inalámbrica, con AirPlay tenemos la certeza de que la transmisión emplea una compresión sin pérdidas pero todo el audio se recodifica a 16/44 (osea, si reproducimos un CD lo haremos de modo totalmente transparente sin tocarle un bit al flujo de audio). Por otro lado, aptX queda cláramente por detrás de otros protocolos de transporte de audio que también funcionan en escenarios inalámbricos tales como DLNA y que ofrecen un modo de funcionamiento transparente a cualquier resolución y frecuencia de muestreo.

Muchas gracias, quiere esto decir que enviando un mp3 por bluetooth sin APTX este se recodifica ?

kerouack escribió:Muchas gracias, quiere esto decir que enviando un mp3 por bluetooth sin APTX este se recodifica ?

Exacto... y con aptX también, solo que en el primer caso probablemente el mp3 original aún se degrade más y en el segundo no.

Ya que ha salido el tema,,, alguno utiliza el bluetooth aptX? que tal el sonido? y con qué aparato ,,, hay muchos emisor-receptor , algunos muy baratos,,en amazon etc,,,, con cual estais contentos??? muchas gracias

pablopi escribió:El perfil A2DP definido por el estándar bluetooh para la transmisión de audio puede emplear diversos codecs con distintas capacidades y fidelidad.

El más habitual pero de menor calidad se denomina SBC. Este soporta hasta 48Khz y una tasa de bits máxima de algo más de 320Kbps. Siempre se produce un proceso de recodificación del flujo original a transmitir (por ejemplo, de mp3 a pcm y de aquí a SBC). La calidad es inferior a la de un mp3 de similar tasa de bits pero con resultados muy consistentes con independencia del tipo de audio transmitido. Aquí tienes una comparativa:

http://soundexpert.org/encoders-320-kbps

A2DP también soporta codecs comerciales, como es el caso de aptX, que realmente es propiedad de Qualcomm (el conocido fabricante de procesadores para móviles). aptX mejora claramente a SBC y presenta a su vez distintas variantes (E-aptX, aptX Lossless/HD...), entre las que como puedes ver se encuentra una que aplica, aparentemente, una compresión "sin pérdidas". Esta última soporta audio hasta 24/96. Para sembrar un poquito más la confusión, aptX Lossless ofrece también un modo de funcionamiento híbrido en el que no es totalmente transparente, recurriendo a un modelo con compresión perceptual, con pérdidas, si en determinados momentos se sobrepasan ciertos límites en la tasa de bits resultante. Destacar también que el hecho de que un dispositivo sea compatible con aptX no implica que también lo sea con esta variante de alta calidad. Tampoco es fácil saber el modo real de funcionamiento, en un momento dado, de un par de cacharros (móvil, auriculares) que sobre el papel se anuncian como compatibles con aptX.

Aquí comparan SBC (y mp3) con aptX:

http://www.sereneaudio.com/blog/how-good-is-bluetooth-audio-at-its-best

En cualquier caso, al igual que con SBC, siempre se produce una recodificación del flujo original.

En mi opinión, aptX mejora claramente a SBC. Con respecto a otros protocolos de emisión inalámbrica, con AirPlay tenemos la certeza de que la transmisión emplea una compresión sin pérdidas pero todo el audio se recodifica a 16/44 (osea, si reproducimos un CD lo haremos de modo totalmente transparente sin tocarle un bit al flujo de audio). Por otro lado, aptX queda cláramente por detrás de otros protocolos de transporte de audio que también funcionan en escenarios inalámbricos tales como DLNA y que ofrecen un modo de funcionamiento transparente a cualquier resolución y frecuencia de muestreo.

Pablopi (o quién crea que pueda responder), en varias webs he leído que los codecs opcionales de A2DP incluyen MP3 y AAC (también ATRAC), y por lo tanto, si se envía un archivo comprimido en MP3 o AAC a través de bluetooth se evita esa doble compresión, es decir, se envía tal cuál ... ¿crees que eso es correcto, o en cualquier caso se recomprime? Con Android y Oreo, en las opciones de desarrollador se puede modificar el codec usado por bluetooth. Si se marca "usar los codecs opcionales", tanto si reproduczco ogg como MP3, en los ajustes me marca que usa el codec AAC (con receptores bluetooth que no soporten aptX) ... por lo que entiendo que el MP3 no se envía tal cuál ... ¿tampoco lo haría si reproduzco AAC?

Incluso en el supuesto de que enviemos un archivo, pongamos en ogg q5 (aprox. 160kbps VBR), si sabemos que el codec SBC tiene un ancho de banda de 328kbps (teóricos, que en la práctica pueden caer hasta los 200kbps según condiciones, interferencias, etc.), ¿qué información se comprime si el archivo ya es menor que el ancho de banda? Por lo poco que he encontrado, parece que  la música reproducida por la app de turno (PowerAmp es la que uso) se transforma en la salida a PCM, y el emisor bluetooth la comprime de nuevo. Si esto es así, no es posible que la música en MP3 ó AAC se envíe sin sufrir de esa doble compresión, pero por otra parte, entiendo que el PCM resultante tiene un montón de información redundante e inútil (tipo todos ceros a la izquierda, para entendernos), y que el codec usado para enviar la información por bluetooth (SBC, AAC, aptX ...) sólo truncará esa información redundante, siempre que el archivo original esté por debajo del ancho de banda del codec.
Sobre esto último, he probado a "comprimir" (transformar más bien) un ogg q5 a MP3 CBR 320kbps y no he conseguido notar diferencias entre ellos (igualando volúmenes con ReplayGain) usando auriculares.

En fin, me gustaría leer alguna opinión que arroje luz a todo esto.

Resulta muy complicado determinar cómo funcionan internamente los procesos de conversión a un formato utilizable para la emisión bluetooth, así que no me atrevo a afirmar categóricamente nada en ese sentido.

No obstante, por lo que sé de cómo están diseñadas las arquitectura de audio de los diferentes SO, creo que con independencia de que el códec de partida sea idéntico al utilizado por el hw bluetooth para la transmisión, siempre se va a producir una recodificación, es decir, la cadena debería ser algo como esto:

(A) Archivo original >> (B) Decodificación a PCM >> (C) Recodificación con el códec BT empleado >> (D) Transmisión BT >> (E) Decodificación en destino

Que el resultado en (E) sea más o menos indistinguible de (A) pues ya dependerá de si la recodificación constituye un cuello de botella o no. En cualquier caso, si (C) implica el uso de un códec con pérdidas, por más que su eficiencia sea equivalente al empleado en el archivo original (A), lógicamente siempre habrá alguna diferencia, aunque probablemente solo de matiz.

Lo dicho, es solo una opinión.

Entonces una transmisión DLNA siempre será mejor que cualquiera bluetooth?

Bueno, en principio el audio que se transmite vía DLNA lo hace sin pérdidas, aunque hay servidores DLNA (como por ejemplo el que incluye JRiver Media Center) que pueden transcodificar al vuelo (por ejemplo de FLAC a MP3) para adaptar la tasa de bits al ancho de banda disponible o simplemente a los deseos del usuario. En cualquier caso suele ser algo controlable de un modo totalmente manual por el usuario. No obstante, por diseño, DLNA es una arquitectura transparente (bitperfect), en tanto que bluetooth no.

Creo que es relevante mencionar que DLNA y BT son cosas bastante distintas desde el punto de vista de su topología. El audio BT se emite desde A hacia B, y es A quien debe disponer, bien de modo local o a través de red, de los archivos o el flujo de audio a emitir y de la "inteligencia" para decodificar el archivo original y recodificarlo utilizando alguno de los códecs bluetooth disponibles comunes a A y B.

En cambio, en DLNA tenemos que el flujo de audio siempre parte de un dispositivo capaz de funcionar como servidor (A) hacia un punto de reproducción (B) -habitualmente se le denomina renderer-, con la colaboración posible de un tercer elemento, un controlador (C) desde el que le podemos indicar a B que reproduzca un archivo almacenado en A, pero quien lo recupera a través de la red y lo decodifica y reproduce es B. Lo cierto es que la asignación de estos roles es flexible, y un mismo dispositivo puede aunar varias de estas funciones, por ejemplo las de servidor y reproductor.

Aunque no es del todo exacto, DLNA es un estándar / protocolo que actúa a nivel de aplicación en tanto que BT lo hace en un nivel inferior. Un receptor bluetooth no es consciente del formato original del audio (mp3, flac, wav, dsd...), en tanto que un reproductor sí lo es y debe por tanto ser capaz de decodificarlo de modo autónomo.

Gracias Pablopi, da gusto leer tus explicaciones, aunque a algunos nos cuesta entender por falta de conocimientos.
Yo uso a veces, fuera de casa, un receptor bluetooth aptx que conecto por digital o analógico (según el amplificador disponible) y con móvil o tableta le envío la música, generalmente Spotify o Tidal. Entiendo por tanto, que aunque tidal envíe ficheros de alta calidad el receptor los procesará y recodificará con pérdidas.
El dispositivo es éste:


Es realmente un dispositivo barato, unos 40 €, y me va muy bien en determinadas situaciones.
Mi pregunta es ¿hay algún dispositivo semejante que funcione con DLNA y por tanto mejore la calidad del audio? Los dispositivos que veo solamente tienen conexión USB y por tanto con amplificadores convencionales no se pueden usar. Por otra parte, deduzco que hace falta una red wifi para tal menester ¿es así?
Saludos.

En el caso de Tidal, lo que pasa es lo siguiente:

1. Tu móvil o tableta "sintoniza" la emisión de Tidal, supongamos que en modo Hi-Fi (FLAC 44/16).
   
2. En lugar de reproducirlo a través de su DAC lo redirige a su módulo bluetooth interno. Ahí es donde se recodifica a  SBC, aptX, AAC o lo que sea y se envía de modo inalámbrico al receptor BT AudioTech que tienes.
   
3. El receptor AudioTech lo decodifica a PCM 44/16 (supongo) y lo emite bien por medio de su DAC interno hacia las salidas analógicas o por digital hace un DAC externo, receptor multicanal, etc.
   

No te puedo asegurar cuál es el formato de mayor resolución / frecuencia de muestro que admite de entrada y/o salida tu módulo bluetooth, pero viendo en la imagen que has colgado que es aptX apostaría por esos 44/16 que te mencionaba en  (3).

Efectivamente, para utilizar DLNA necesitas una red local, bien inalámbrica, bien cableada.

Si quieres asegurarte de que la transmisión entre tu móvil / tableta y el ampli es sin pérdidas tienes varias posibilidades:

• Utilizar un Chromecast Audio. Es bueno, bonito y barato (aunque no audiófilo). Admite hasta 96/24. Podrías emitir Tidal Hi-Fi sin pérdidas, por ejemplo.
  
• Si tu móvil o tableta utiliza iOS puedes considerar hacerte con un Airport Express de 2ª mano por cuatro perras. Aquí hasta 44/16. También puedes emitir audio hacia él desde un dispositivo Android con apps como Allstream, pero la cosa puede requerir que hagas root en tu dispositivo. No te lo aconsejo.
  
• Conectar a tu ampli un pequeño AndroidTV o streamer compatible con el perfil renderer de DLNA. O una Raspberry + DAC con Volumio, por ejemplo. En tu móvil o tableta instalas un emisor DLNA como el excelente BubbleUPnP (de pago, pero vale cada céntimo) y tienes una tercera vía.
  

Muchos receptores multicanal relativamente modernos son también receptores bluetooth, AirPlay y DLNA. Si no tienes muchas manías puede ser una opción a medio / largo plazo.

Sí que da gusto
En este hilo se comentan las ideas que presenté más arriba, aunque tampoco se llega a una conclusión clara: https://amp.reddit.com/r/apple/comments/7db893/audiophiles_please_come_in_about_aacsbc_codecs/

Después de todo lo leído, yo creo que en BT siempre hay una doble codificación (salvo que reproduzcas un fichero lossless directamente, como un FLAC por ejemplo), pero que eso no tiene necesariamente que suponer una diferencia audible en la calidad percibida. En este sentido, quizás la opción más lógica (en un escenario de doble codificación) es emplear AAC como formato de partida (que se transformaría en un PCM a la salida), y que sea este mismo codec el encargado de recodificar nuevamente el PCM.

Añado un enlace en el que se analizan los efectos de recodificar 100 veces un archivo lossy mediante diferentes codecs, y parece que el mejor parado es AAC: https://hydrogenaud.io/index.php/topic,100067.0.html

Enviar por bluetooth el audio desde el teléfono o tableta al receptor y de este al previo o al amplificador es realmente un proceso sencillo y cómodo. Pero sujeto a las limitaciones del bluetooth como se ha explicado. Siguiendo las indicaciones de Pablopi de alternativas al bluetooth, he encontrado este artilugio que posiblemente conozcáis al tratarse de una marca conocida en el mundo hifi, se trata del Inakustik Wifi Streaming Receiver:


Tiene una resolución máxima de 24bit/96kHz y entiendo que si enviamos por wifi los archivos flac o semejantes reproducidos en teléfono, tableta o portátil, el dispositivo los reproducirá sin pérdidas, igualmente si reproducimos Tidal. Por tanto, para un uso casero donde siempre vamos a poder disponer de wifi y bien sea con la aplicación EzCast que conecta los dispositivos o por DLNA, entiendo podemos enviar el audio sin recodificaciones.

Siguiendo con los aparatos, he visto este que creo se adapta a lo que estoy buscando. Es un streamer que funciona con wifi y dlna y tiene salida óptica con un máximo de 24/192, suficiente para mis pretensiones por esta vía, y un precio entorno a los 100 €.
Se trata del ieast stream pro: https://www.ieast.net/products/stream-pro/
¿Alguna opinión o experiencia?
Saludos.
PS: Según leo en la red, la salida está limitada a 16/44.1

Mira bien que software usa que la mayoría de veces el software y no el hardware es el punto más débil.

Retomo el hilo para comentar una paradoja en relación a la calidad de audio a través de bluetooth: es posible y probable, que un archivo comprimido con un buen codec a un bitrate medio suene mejor a través de bluetooth que el mismo archivo comprimido a un bitrate más elevado. ¿Por qué? Partimos de que el "ancho de banda" de la conexión bluetooth está limitado:



Eso son límites teóricos, parece ser que en las pruebas reales las tasas de transferencia dependen de la implementación de cada fabricante, interferencias, etc. y por ejemplo en SBC baja fácilmente hasta los 200kbps. Añadamos a esto que, presumiblemente, los codecs citados no tienen la calidad de los reconocidos Ogg Vorvis y (especialmente) Opus. Incluso AAC, aparte de tener un bitrate real bajo en bluetooth, está por debajo de los más modernos HE-AAC o el que usa Apple para iTunes, que siempre ha tenido la fama de ser de mejor calidad que los homólogos para Nero, FAAC, etc.

Por las pruebas que he hecho, estoy bastante convencido de que un archivo comprimido a un bitrate medio (digamos que alrededor de 200kbps) que se transforma a PCM a la salida del reproductor añadiendo información redundante tipo ceros a la izquierda, se comprime por el codec bluetooth dejando intacto el archivo original puesto que "cabe" en su ancho de banda de transmisión, y lo envía tal cuál manteniendo la calidad de audio original.
En cambio, un archivo comprimido a un bitrate más elevado que el ancho de banda de transmisión, es comprimido por el codec bluetooth de forma que sí modifica el archivo original, sufriendo en este caso una compresión sobre lo ya comprimido, con pérdida de calidad. Al utilizar estrategias de compresión diferentes, el resultado final no es coherente.
He hecho pruebas en este sentido usando Opus a 510 kbps (el máximo bitrate permitido) y Ogg Vorvis a calidad q10 (500kbps) frente a Opus a 160kbps, y a través de bluetooth con aptX prefiero este último, me suena totalmente transparente frente al archivo en FLAC, y con los de alto bitrate me da la impresión de que se pierden matices y espacialidad.
Si partimos de un archivo en FLAC sin comprimir, los algoritmos de los codecs bluetooth deberían hacerlo lo suficientemente bien, pero incluso en este caso no las tengo todas conmigo de que no suene algo mejor el archivo en Opus 160kbps. Es decir, es posible que se imponga un bitrate más bajo comprimido con un mejor codec, a un bitrate más alto pero comprimido con un codec peor.

Por último comentar que la versión Opus 1.3 (ya la anterior era muy buena y mejor que la 1.0) es una absoluta maravilla, con un umbral de transparencia menor que el de cualquier otro codec existente (hay mucha info al respecto en internet), y que a mi personalmente me ha maravillado. Del mismo creador que Ogg Vorbis, lo iguala como mínimo a altos bitrates y lo mejora claramente en los bajos, destacando más cuanto más bajo sea el bitrate. Después de Ogg Vorvis, Chris Montgomery comenzó un proyecto nuevo en el que incorporó todo el conocimiento adquirido con Vorbis a la fusión con otro nuevo codec que desarrolló para bajos bitrates llamado CELT, orientado a comunicaciones de audio de baja latencia. Unió fuerzas con Skype y su codec SILK y de todo eso salió el super codec Opus, que te deja con la boca abierta ya con bitrates obscenamente bajos (probarlo a 96kbps ).
Una particularidad de este codec es que, a diferencia de todos los demás, emplea más bitrate (es VBR) en pasajes con pocos sonidos que en otros con mucha información. Por ejemplo suele comprimir menos una pieza de barroco que una de rock. Entiendo que al ser un algoritmo más avanzado, ante más información sonora es capaz de eliminar más cosas de forma perceptualmente inaudible que otros, pero sin ser agresivo en piezas con menos información redundante.
Por otra parte si comprimes a, pongamos, 160kbps, de media tiende a andar por encima de ese bitrate, bajando poco menos pero subiendo bastante más si es necesario. Yo estoy en proceso de comprimir a ese bitrate toda mi música, pues tengo MUCHA y el espacio en mi tarjeta microSD sigue siendo un problema, y en todas las pruebas que he hecho me quedo más que tranquilo para mis orejas con esta versión del codec Opus a ese bitrate. Impresionante.