Avec son aptX Lossless, Qualcomm promet une qualité CD sans perte en Bluetooth

Avec son aptX Lossless, Qualcomm promet une qualité CD sans perte en Bluetooth

Avec son aptX Lossless, Qualcomm promet une qualité CD sans perte en Bluetooth

Le fabricant propose déjà depuis longtemps des codecs aptX (audio processing technology), notamment une version HD (16 bits, 44,1 kHz) et Adaptive (24 bits, 48 kHz), mais l’aptX Lossless est la première à proposer une compression « sans perte ».

Qualcomm précise que sa technologie peut détecter automatiquement et activer l'audio sans perte lorsque la source l’est aussi. De son côté, l’utilisateur peut choisir entre 16 bits et 44,1 kHz sans perte ou 24 bits et 96 kHz avec perte. De plus amples détails techniques sont disponibles ici.

Pour que l’aptX Lossless fonctionne il faut évidemment un SoC et un casque audio compatibles. Les fabricants intéressés devront payer une licence à Qualcomm pour l’utiliser.

Commentaires (9)


“Les fabricants intéressés devront payer une licence à Qualcomm pour l’utiliser.”



RIP.


Ça, et le fait qu’en pratique, avec les interférences, le débit BT n’est que rarement suffisamment pour ce codec.



Hugues1337 a dit:


“Les fabricants intéressés devront payer une licence à Qualcomm pour l’utiliser.”




C’est déjà le cas avec l’aptX « classique ».
J’ai eu beaucoup de mal à l’installer sur Windows, pour un résultat très décevant (niveau stabilité). Sur mobile, les grands constructeurs casquent (haha) sans broncher, mais pas les plus petits. Du coup pas moyen de l’avoir sur mon Fairphone 😒
Les codecs propriétaires, cette plaie …


Buh ? Ça fait bien 5 ou 6 ans que j’entends parler de l’aptX Lossless ! Je pensais que c’était un truc du passé !



Arkeen a dit:


Sur mobile, les grands constructeurs casquent (haha) sans broncher




Commentaire entré dans le palmarès des meilleurs que j’ai lu depuis que je suis sur NXI, rien que pour la blague ;D



24 bits et 96 kHz




A part pour les concours de celui qui a la plus grosse, c’est tout à fait inutile. Et cerise sur le gâteau, cette fausse promesse de qualité est avec perte contrairement à la “qualité CD”.



AncalagonTotof a dit:


Buh ? Ça fait bien 5 ou 6 ans que j’entends parler de l’aptX Lossless ! Je pensais que c’était un truc du passé !




Je crois que tu confonds avec l’aptX Low-Latency.



Arkeen a dit:


J’ai eu beaucoup de mal à l’installer sur Windows, pour un résultat très décevant (niveau stabilité).




J’ai essayé une fois d’installer le driver bt aptx (dell je crois) sur windows… j’ai du reinstaller windows…



Depuis win10, apparemment ca utilise directement aptx si c’est dispo (lequel?), mais MS n’a pas pensé que ce serait intéressant d’en informer les utilisateurs (aucune doc sur le site MS ni dans l’OS). Pour savoir si ca passe bien en aptx c’est infame, entre logs d’ecoute BT et hexadecimal (et encore… mon casque aptx pas reussi a trouver, enceinte non aptx j’ai reussi a savoir que c’etait du sbc)




Arkeen a dit:


Sur mobile, les grands constructeurs casquent (haha) sans broncher, mais pas les plus petits.
De ce que j’aperçois ca n’a rien a voir avec leur grosseur, des gros mettent l’aptx, d’autres non, mais c’est pareil pour les petits (meme vu des projets KK qui l’avait), et c’est pareil pour les casques/enceintes, c’est quasi aléatoire, et meme je dirais que les gros font de moins en moins d’aptx (sony, marshall… l’ont récemment abandonné) alors qu’on le trouve parfois sur des appareil “noname”a moins de 50€.




Bref, l’adoption de l’aptx lossless ca pue tant qu’il n’y aura pas un vrai intérêt commercial a le faire (genre faire comme Apple s’il se met un jour a faire du BT lossless, que ce soit celui de qualcomm ou maison).



jpaul a dit:


Je crois que tu confonds avec l’aptX Low-Latency.




Je ne pense pas. Le lossless existait déjà vers 2015 il me semble. Mais j’ai la flemme de rechercher dans mes archives.
A l’époque, j’avais tenté de faire du FW sur CSR 8670, la puce qu’on trouvait dans presque toutes les enceintes BT.
Mais quelle de pain in the ass !
L’I2C ultra limité, déjà.
Mais pire : sizeof(uint8)==>2. En plus, ils ont parfaitement le droit ! Mais après, on se demande toujours ce qu’on manipule en mémoire, est-ce qu’il y a des trous dans mes data …


Fermer