Bluetooth : les codecs sont très importants

J’en parlais il y a peu, il y a différents codecs possibles en Bluetooth A2DP (stéréo). Et si on regardait un peu ça en détail ?

Le codec le plus classique, obligatoire, est le SBC, alias Sub Band Codec. Il faut être clair : c’est un mauvais codec. Le débit moyen peut être élevé (environ 350 kilobits/s dans le meilleur des cas) mais ça reste mauvais. Les tests experts le montrent bien, que ce soit en haute qualité ou en qualité moyenne.

Le souci est simple : une bonne partie des casques, enceintes, adaptateurs (etc.) est uniquement compatible avec ce codec, et pas nécessairement avec les débits les plus élevés. Le bitpool 53 (environ 350 kilobits/s) n’est pas disponible sur tous les appareils.

En dehors de la qualité assez moyenne du SBC, on a le problème du réencodage : en prenant comme postulat que les utilisateurs écoutent de la musique compressée avec pertes, on a donc une double compression à pertes, avec un codec mauvais.

Pour le support chez Apple, c’est assez simple : (Mac) OS X et iOS supportent le SBC, c’est obligatoire. Depuis Leopard (10.5) sur Mac et iOS 3.x dans le monde mobile.

Les codecs optionnels

Le premier, c’est l’ATRAC. Aucun intérêt en 2012, c’est surtout un reliquat de la spécification initiale de 2004. Pour rappel, l’ATRAC est le format de Sony issu du MiniDisc et utilisé dans quelques baladeurs. Je ne suis même pas certains que des appareils compatibles existent.

Le second, c’est le MP3. Si des casques compatibles existent — j’en ai un —, je n’ai pas réellement pu tester. Mac OS X ne supporte pas le MP3 et iOS non plus (a priori). BlueZ sur les appareils Linux (et Android) supporte a priori le codec. L’idée est simple : envoyer directement le flux au casque pour qu’il le décode quand c’est possible (et (ré)encoder en MP3 le reste du temps).

Le troisième, c’est l’AAC. L’idée est la même qu’avec le MP3 : envoyer directement le flux au casque pour éviter le réencodage en SBC quand c’est possible (rarement). Quelques casques et appareils récents (JBL, Nokia, etc.) supportent l’AAC en entrée et — bonne nouvelle — les appareils Apple aussi. OS X Mountain Lion semble le supporter (sans que j’ai pu tester) et iOS 5.x le supporte (en 128 kilobits/s). Pour iOS 6, on passe même à 256 kilobits/s.

Les codecs propriétaires

Le plus connu est l’aptX de chez CSR. De plus en plus d’écouteurs, casques, enceintes, utilisent ce codec. Il offre en théorie une qualité supérieure au SBC — ce n’est pas compliqué — mais reste un codec avec pertes.

Pour la compatibilité, (Mac) OS X le supporte depuis Snow Leopard, iOS ne le supporte pas. Sous (Mac) OS X, il semble qu’il soit désactivé dès qu’on a plusieurs appareils connectés, mais il est possible de le forcer via les outils de développement.

Ensuite, il y a le FastStream de CSR. Ce codec ne semble pas dédié à la musique et à la qualité (CSR ne parle pas de ce point, preuve qu’il ne doit pas exceller) mais est prévu pour limiter la latence. CSR indique que la latence classique en Bluetooth est de 200 ms environ, ce qui est beaucoup. Si c’est peu visible en usage normal, audio, c’est très audible dès qu’on regarde de la vidéo, avec une désynchronisation de la voix. Le FastStream, intégré dans de rares émetteurs, permet de descendre aux environ de 35 à 40 ms. Je n’ai pas trouvé d’indications sur le support du FastStream par des systèmes d’exploitations, les seules références sont des émetteurs matériels.

Comme on le voit, il est impossible d’écouter de la musique sans pertes de qualité, les audiophiles apprécieront. On parle parfois de transfert sans pertes pour la transmission en AAC ou celle en MP3, mais c’est fallacieux comme argument : il n’y a pas de recompressions comme en SBC ou en aptX, mais il y a bien une compression, elle est par contre effectuée avant le transfert. Si on part d’une source lossless (ALAC, FLAC, PCM, etc.), il y a obligatoirement au moins une compression avec pertes.

Maintenant que j’ai présenté les différents codecs, je vais essayer de me procurer des appareils compatibles, pour vérifier si la différence est flagrante…