De l'impact du logiciel sur la qualité du son

[LittleNooby]

Bonjour,

J'aimerais un peu mieux comprendre l'étape qui est la lecture du fichier audio par le logiciel de décodage et surtout quel est l'impact final sur la qualité du son. Je m'intéresse à des situations usuelles et non des cas idéaux. Particulièrement, si une amélioration se voit réduire à néant par autre maillon de la chaîne, j'aimerais le savoir pour pouvoir investir mon attention à des endroits plus utiles.

D'habitude, je me contente de faire le mouton et de suivre les conseils qu'on me donne mais j'aimerais comprendre un peu mieux.

Voilà quelques questions qui je pense me permettrons de mieux comprendre ce chainon particulier qu'est l'étape de décodage :

• En partant d'un fichier MP3 32kbps à un flac en passant par le 320kbps, un logiciel s'en sort - il mieux qu'un autre ?
• Est - ce que le support physique du décodage (carte son, dédiée ou non) est - il toujours géré correctement par le logiciel ?
• Toute amélioration sur le support physique serait-elle répercutée sur la qualité finale ou au contraire étranglée par le logiciel de décodage ?
• Quelle est la relation entre le logiciel de décodage et le système audio (casque, HP, écouteurs, ...) , à quel point doit-il s'adapter et à quel point en est-il capable ?

Merci merci,

LittleNooby

[GourouLubrik]

Je préfère m'emparer de la question avant que toutes les, mythologies, légendes urbaines et mensonges soit reversés dans ce topic.

En partant d'un fichier MP3 32kbps à un flac en passant par le 320kbps, un logiciel s'en sort - il mieux qu'un autre ?

Tout dépend de comment on interprète "s'en sort le mieux".
Il y a grosso modo 3 écoles dans les logiciels.
Celle de la compatibilité: le but est de lire, pas d'être lossless, particulièrement vrai sous les vieux windows. On va pas vraiment parler de cette catégorie, vu qu'il n'y a probablement pas d'utilisateurs parmis nous =p
Celle du bitperfect (on ne touche à rien à part le controle du volume, et on essaye de sortir sur une sortie audio bitperfect sur le système d'exploitation)
Celle du processing (on rajoute des effets, filtres, du replaygain, de l'oversampling, pour améliorer la qualité perçue - et la je pense naturellement à HQPlayer)

Est - ce que le support physique du décodage (carte son, dédiée ou non) est - il toujours géré correctement par le logiciel ?

La il faut couper court, la carte son ne fait rien au niveau du décodage, tout est fait par le CPU ou le SoC (System on Chip, pour les Dap, téléphones, tablettes...), puis passé au système son de l'o/s qui lui refourguera une son déjà "décodé", sous forme LPCM ou DSD, à la "carte son".
Donc ce que tu veux dire, c'est est-ce que l'interfaçage entre le logiciel et l'o/s et le periphérique de lecture est correctement fait. et la réponse est vaste, rien que sur pc, en fonction de chaque o/s et chaque pile audio existante...
Sur windows le mode Wasapi Exclusif, Kernel Streaming et Asio sont à retenir. MME/DirectSound sont plutôt à éviter, même si DS est moins pire qu'avant. - Il me semble qu'ASIO est obligatoire pour lire du DSD.
Sur linux, Jack et Alsa sont privilégiés, pas trop d'avis sur pulseaudio, j'ai envie de dire que tant qu'on a qu'un stream en cours de lecture et le volume à 0db, il ne nuit pas à la qualité audio, par contre il n'est pas très bon pour la latence (mais en hifi, c'est pas génant, ça l'est pour la MAO).
Sur Mac: j'y connais rien (et ça ne m'intéresse pas )

Toute amélioration sur le support physique serait-elle répercutée sur la qualité finale ou au contraire étranglée par le logiciel de décodage ?

La, j'ai pas compris exactement ce que tu voulais dire...
Le logiciel peut difficilement être coupable tant qu'il est bitperfect...
Après y'a les problèmes qui peuvent être introduit par la latence d'execution (DPC latency), le mieux est de "se faire dépister" avant d'essayer de corriger un problème qui n'existe pas. (pour windows: http://www.resplendence.com/latencymon )
Mais il va de soit que si on a une musique de meilleur qualité que ce que permet le système de reproduction, le gain de qualité sera évidemment tronqué... exemple, du FLAC multicanal 96khz/24 bit sur une carte son stéreo usb ebay à 5€ compatible 16 bits 48khz...

Quelle est la relation entre le logiciel de décodage et le système audio (casque, HP, écouteurs, ...) , à quel point doit-il s'adapter et à quel point en est-il capable ?

Comme je le disais, "le décodage" intervenant dans le pc, il n'y a pas grande relations... donc il ne va pas "s'adapter", par contre, au niveau du transport du signal après décodage, il faut bien sur que "l'interface" (surtout quand on est en usb) et le DAC supporte nativement le matériel joué (en résolution 16/24/32bits, échantillonnage (PCM: 44.1 / 48 / 88.2 / 96 / 176.4 / 192 / 352.8 / 384 et même 768khz ça commence à arriver, et en DSD 2.8 / 5.6 / 11.2 / 22.4 Mhz). Vous notez que j'ai pas cité le "logiquement manquant" 352.4*2 = 705.6khz, je n'en ai jamais vu ...

Après le DAC, au niveau analogique, il faut que les capacités soit également en rapport sur la bande passante, et même résolution/dynamique. Aucun casque ne sait reproduire un signal carré de manière parfaite, suffit de regarder les mesures de Tyll pour s'en convaincre rapidement... les meilleurs sont simplement "un peu moins moche" dans le rendu d'une square wave...

mes 2 centimes, mais j'en rajouterai surement plus tard, je vois déjà poindre de futures questions sur les alimentations, le bruit usb, charger son O/S en ram, le HDD ou le SSD, les ventilateurs, les alimentations à base de batterie, ou l'influence des eruptions solaires sur la qualité audio.

[MrButchi]

Merci Guru

[Franck.T]

En dac connecté à Windows le ''Wasabi event'' est la seul chose a retenir...

[GourouLubrik]

De rien MrButchi

J'aurai dû parler du ré-échantillonnage audio en cas de non bitperfectitude. C'est un sujet aussi controversé que complexe.

En cas de non support par la pile audio de l'o/s ou le DAC, il y aura un rééchantillonage (ou en ASIO, juste ça plantera ).

C'est ce même ré-échantillonage que l'on reproche à MME/DS (et même wasapi en mode partagé). Certains logiciels embarque leur rééchantilloneur (souvent appellés ASRC pour asynchronous sample rate converter). Les implémentations open sources les plus connues sont la libsamplerate et SOX... mais il y en a d'autres moins connues du genre ( https://github.com/avaneev/r8brain-free-src ).


Il va de soi que quand on rééchantillonne "à la baisse" en résolution ou en fréquence, on va perdre de l'information (quant à savoir si c'est audible par un humain, c'est un autre débat).
Pour passer du 24 bits au 16bits, on utilise souvnent la technique de dithering, que wikipedia connait beaucoup mieux que moi...

Contrairement au décodage, qui est déterministe et reformera toujours le même signal audio, l'ASRC et leurs implémentation et leur qualité, sont extrêmement diverses.
Le SRC dont j'ai clairement un très mauvais souvenir est celui de windows XP, quand il rééchantillonait du 44.1 vers le 48khz, c'était assez degueu pour être audible sur un casque "moyen".

Je n'ai abordé au dessus que le coté système d'exploitation, et c'était la partie la plus simple. Car même après, on est concerné par ces mêmes manipulations.
Les SRC peuvent aussi être embarqué dans du hardware comme les puces du même noms (notamment de tête les SRC le DF1704 qui allait avec les dacs R2R PCM1704 ou plus recemment les 4192/4392 chez de Ti, l'AK4137 chez AKM, le CS8422 chez cirrus logic), mais y'en a aussi les puces de DSP (genre les ADAU d'Analog Devices), les FPGA, et si on veut, on peut même le faire dans une puce XMOS...

La majorité du matos ré-échantilonne tout à la hausse (oversampling) avant d'envoyer au DAC. et même s'il le font pas, les dacs (delta sigma), sauf ordre contraire, le font, et applique un filtrage numérique.
C'est la guerre du "Non OverSampling vs OverSampling". Autant le dire, c'est l'oversampling qui a plutôt gagné la bataille commerciale.

Après y'a une petite subtilité, un filtre d'oversampling bien fait, ça coute cher en calcul, et souvent les puce dacs ne savent pas trop utiliser ces oversamplings à filtrage couteux à gros taux d'échantillonage (> par exemple pour les es9018, > 192khz), donc... ils ne l'appliquent pas. d'ou l'idée que finalement... c'est peut être mieux si c'est fait par... le PC, et donc la boucle est bouclé, et rien n'est très simple

PS: dans ce que je dis, il y a des généralités, des inexactitudes, et certains raccourcis, mais je faisais l'état complet (enfin si j'en était capable), j'ecrirais probablement carrément un bouquin au lieu d'un post.

En dac connecté à Windows le ''Wasabi event'' est la seul chose a retenir...  :levit:

Le WASAPI, le wasabi, c'est la sauce pimenté japonaise verte...

Et de ce que je sais, l'event n'est préconisé qu'en cas d'utilisation d'usb, pas en cas d'utilisation d'une carte son, le push est plus approprié (c'est ce que disais le développeur du module foobar). En plus pour être exact, il faut utiliser le mode exclusif du Wasapi pour être pénard, en mode partagé, on peut se faire ressampler.
Après, l'ASIO peut apporter quelques avantages par rapport au WASAPI (support du dsd, latence plus faible), mais aussi pas mal d'inconvénients (plantages).

Il est à noter que Microsoft continue d'améliorer WASAPI ( https://msdn.microsoft.com/windows/hard ... 2147217396 ), et que microsoft travaille même (ENFIN) à l'intégration de l'usb audio class 2.0 dans windows 10 (insider preview) et pour avoir été voir le bug tracker, le driver est loin d'être mature... https://blogs.msdn.microsoft.com/matthe ... o-devices/

[Franck.T]

Ahh bon le mode exclusive est à privilégier, faudra que je compare avec le mode normal ''WASAPI'' ! Il me semblais que j'avais eu plus de plantage sur ce mode ou le Asio avec foobar ou l'app Qobuz en mode usb...

[Eykxas]

Pour ma part le WASAPI exclusive plante tout le temps quelque soit le logiciel (son haché, pas de son etc...)

[LittleNooby]

Cool, merci ! Je vais devoir me renseigner sur pas mal de termes mais j'ai déjà quelques réponses !

Non, je ne vais pas t'embêter avec le SSD, ventilo, etc...

[oswald66]

Le mieux pour pas que ça plante, c'est d'avoir un mac

[Genius753]

Moi perso j ai pas trop de soucis avec asio sur windows 7...genre 6/7 fois en 6 mois...


Envoyé de mon iPhone en utilisant Tapatalk

[Kooka]

Envoyé de mon iPhone en utilisant Tapatalk

.... .... .... Argggg .... ;-)

[kazcou]

Avec le protocole DOP, on peut utiliser l'interface WASAPI pour le DSD.