Se connecter
Se connecter

ou
Créer un compte

ou

Moteurs audio, 32 bits / 64 bits, distinguer le vrai du faux .

  • 185 réponses
  • 23 participants
  • 27 239 vues
  • 31 followers
Sujet de la discussion Moteurs audio, 32 bits / 64 bits, distinguer le vrai du faux .
Bonjour à tous les audacieux qui auront le courage de se lancer dans cette réflexion ...

voilà, je me pose la question suivante :

a-t-il déjà été fait un comparatif sérieux des moteurs audio qui animent les DAWs les plus réputées (ou les plus répendues ...) ?

Depuis quelques temps, on voit apparaître comme principal argument de renouvellement de certains logiciels, le fait que leur moteur audio passe au 64 bits. Y'a-t-il un gain réel à se lancer dans le 64 bits en tant que moteur de mixage (et pas en tant que moteur de système d'exploitation ... :clin: ) ?

Personnellement, je pense bien qu'il doit y avoir un avantage net puisque nous massacrons joyeusement de plus en plus le signal à coup de plug-ins déjantés, et qu'une précision accrue dans les calculs permet de conserver une cohérence dans le signal traité (ne serait-ce qu'au niveau de sa phase ...). Sans compter que des logiciels aux ambitions très modestes comme Tracktion 2 se sont armés de ces moteurs 64 bits, alors que des plates-formes considérées comme "haut de gamme", comme ProTools, pour ne pas le citer, en reste pour l'instant au 32 bits (alors que ses prétentions qualitatives et pécuniaires sont pour le moins beaucoup plus élevées). Et en outre, des logiciels comme Samplitude ou Pyramix ont des moteurs en 32 bits mais extrêmement réputés (car très bien programmés semble-t-il) pour leur respect du signal. Une vache n'y retrouverait pas son veau ...

Un rapide état des lieux :

moteurs 64 bits :
Sonar 6
Cubase 4
Sequoia 9
Tracktion 2

moteurs 32 bits : (je vais en oublier c'est sûr)
Samplitude 9
Pyramix 5
Nuendo 3
Pro Tools ??? (je me perds dans les versions)
Kristal Audio Engine (faudrait pas oublier les gratuits ...)

voilà, merci à ceux qui voudront bien partager cette réflexion avec moi ...

:bravo:
Si vis pacem para bellum
Afficher le sujet de la discussion
131

Hors sujet :

Citation : Le topic m'a semblé suffisamment intéressant et de bonne tenue pour avoir l'honneur de figurer comme "topic de la semaine" dans la newsletter hebdomadaire.

Ca me fout le trac ce truc. :oops:

JM

132
J'ai TOUT compris :8O:

Merci very much. C'est tout con quand c'est si bien expliqué :bravo:

Hors sujet : Faut pas ! Faut pas !
C'est juste la raçon de la gloire

133

Hors sujet : T'as de la chance, en me relisant j'ai vu que j'avais laissé une belle coquille, c'est corrigé. C'est à propos du moteur ne pouvant gérer les mots de plus de un bit, message 129. J'avais écrit "ne pouvant gérer les mots de plus de deux bits", ce qui rendait le paragraphe abscon.



JM
134

Hors sujet : Pas vu la coquille et je ne la vois toujours pas (enfin, sa correction).
J'ai dû faire un "nos lecteurs auront rectifié d'eux-même" :bravo:

 

[ Dernière édition du message le 05/07/2011 à 10:59:03 ]

135

Citation : Le résultat final devrait toujours avoir les qualité inhérentes à la résolution choisie, mais cela ne garantie pas la conservation de la qualité d'origine de chaque piste. Pour ça il faudrait un système capable d'agglomérer les bits à l'infini.


Selon cette logique (que du simple bon sens sans l'appui de la connaissance technique m'avait laissé deviner), ça veut dire que plus le séquenceur travaille avec une résolution poussée, meilleure est la qualité finale.

Donc, théoriquement 16 bits < 24 < 48 < 64 < 128...

Sauf qu'on tombe à la longue sur deux écueils :
1- la puissance de traitement des systèmes mise à rude épreuve par des calculs plus complexes et de plus grandes quantités de donner à gérer
2- la limite de l'oreille humaine qui fait que ça ne servirait à rien de pousser la qualité jusqu'à des différences de toutes façons inaudibles.

à quoi on peut éventuellement ajouter

3- la limite (notamment numérique, cf CD 16/44.1) des systèmes de reproduction qui fait qu'il ne sert pas à grand chose de mixer avec une "qualité" d'un niveau tel qu'il disparaîtra lors du passage sur support de reproduction. Sauf que ceux-ci évoluent et qu'on ne sait pas que seront les standards dans 20 ou 30 ans. Déjà, on a des standards plus précis que le CD.
Pour péréniser ses zoeuvres zimpérissables, il peut donc être préférable (de lièvre) de travailler d'ores et déjà à de hautes résolutions, même si ça ne suit pas (encore) côté reproduction.

J'ai bon ?
136
Oui, j'ajouterais que même si on peut considérer que la résolution de 16 bits du CD peut paraitre suffisante (polémique inside !), un CD est le résultat final d'un mix maitrisé et prémasterisé. Lors de la phase d'enregistrement, il faut pouvoir capter toutes les nuances dynamiques et les convertir en numérique, ce qui fait que les 24 bits ne sont pas superflus, surtout quand tu prévois d'avoir affaire à des brutes qui cognent 12dB plus fort à la prise qu'à la balance (expérience archi vécue inside).

Ensuite, éventuellement un surplus de résolution pendant le calcul, mais à l'arrivée, je pense que le 24 bits et ses 144dB de dynamique devraient suffire ;).

JM

Hors sujet : PS : Bon, je vous laisse, il faut que j'aille chercher du vermifuge pour mon chat

137

Hors sujet : Y'a pas le feu.
Ceci est un forum, pas un chat :mrg:
(même s'il a aussi parfois besoin d'être vermifugé)



Pour la logique consistant à mixer à une résolution supérieure que celle du support final, je pense que c'est acquit pour tout le monde, non ?

Par contre, reste la question de départ : jusqu'où aller ?

Personnellement, je travaille tout en 24/96 pour la résolution de fichiers. Je n'ai pas coché la case « mixage en 64 bits » dans mon Sonar because ressources et je pense que le problème actuel de qualité de son est plus crutial sur mes compétences que le « moteur audio » de mon soft.

Je fais bien (sur mes enceintes de monitoring) la différence entre 44 et 96 k, mais je doute de pouvoir répondre sur des tests en aveugle entre du 16 et du 24 bits.

Bref, selon les résultats de votre discussion, il semble préférable quand on le peut de mixer en 64 bits, mais il ne semble pas utile que les systèmes montent à 128 bits à l'avenir. Me trompé-je ?
138
Plus on aura de reserve de dynamique, mieux ça sera theoriquement.
personnellement, en general, je travaille en 24/48 le plus souvent, en entrée, les 24 bits, c'est vraiment un grand confort, ça evite de limiter les prises et de devoir se mettre au taquet pour avoir une dynamique exploitable.
139

Citation : Bref, selon les résultats de votre discussion, il semble préférable quand on le peut de mixer en 64 bits, mais il ne semble pas utile que les systèmes montent à 128 bits à l'avenir. Me trompé-je ?

Je ne me suis pas prononcé, car je ne sais pas encore comment sont utilisés les 64bits.

JM
140

Citation :
'est quoi cette blague?? latence midi?? 7 ms??



C'est pas une blague du tout. Le midi, si tu l'utilises a travers les ports standards, c'est du 30000 bauds en gros, si mes souvenir sont bons, cad quelques 4 ko/s en gros. Un message Midi pour une note necessite au moins 3 octets, de memoire la aussi: un pour le channel + type de message, un pour la note jouee, et un pour l'amplitude. Ca fait donc presque une ms pour envoyer une note avec un cable midi standart. Si tu joues plusieurs notes, tu peux vite arriver a plusieurs ms.


Citation :
Donc, théoriquement 16 bits < 24 < 48 < 64 < 128...



Deja, le 16 et 24 bits dont on parle sont en representation *fixe*, cad que la precision depend de la dynamique, contrairement aux representations en flottant (celles qui sont en 32 et 64 bits, en general). Le 128 bits flottant n'existe pas sur les cpu courants (ni mac, ni PC; on peut emuler le 128 bits, mais ce serait extremement lent, je pense au moins 10 voire 100 fois plus lent); le standart de representation flottante pour le 128 bits est en train d'etre discute, donc je pense que sur pc, il faudra attendre au moins 10 ans pour les voir venir.

Bref, on peut pas comparer du tout comparer des resolutions entre elles si elles sont de representation differente (fixe ou flottante).


Citation :
Personnellement, je travaille tout en 24/96 pour la résolution de fichiers. Je n'ai pas coché la case « mixage en 64 bits » dans mon Sonar because ressources et je pense que le problème actuel de qualité de son est plus crutial sur mes compétences que le « moteur audio » de mon soft.

Je fais bien (sur mes enceintes de monitoring) la différence entre 44 et 96 k, mais je doute de pouvoir répondre sur des tests en aveugle entre du 16 et du 24 bits.

Bref, selon les résultats de votre discussion, il semble préférable quand on le peut de mixer



Je pense que mixer en 64 bits est une connerie dans 99 % des cas, si ce n'est pas 100 %. Deja, je sais que moi, je fais pas la difference, et meme entre developpeurs, il y en a beaucoup qui sont pas persuades de l'utilite.

Ensuite, le 16 bits peut souvent suffir si tes sources sont d'excellente qualite. Il faut bien comprendre, j'insiste sur ce point, que tes fichiers en 16 bits font etre tranformes en 32 bits des l'instant ou tu vas les mixer dans ton sequenceur. La ou le 24 bits compte beaucoup aussi, c'est lorsque tu vas utiliser le resultat avec un autre outil plus tard. Pour le support final, par contre, je suis pas super persuade de l'interet en general. Le probleme du 16 bits, c'est que la resolution 16 bits n'est valable que si ton signal est proche du 0 dB; si ton signal est a -40 dB par exemple, tu perds beaucoup en dynamique et en precision (c'est difficile de dire combien, car des que tu t'eloignes du 0 dB avec 16 bits, tres vite l'hypothese du bruit de quantification independant de la source n'est plus verifiee, ce qui la formule 1 bits = 6 dB caduque, et rend les calculs tres difficiles).

Le coup de perdre de la resolution avec le mixage pur, c'est du delire integral a mon avis: oui, en theorie, tu as de la perte, mais c'est totalement ridicule par rapport a tous les autres parametres qui peuvent compter pour le son. Par exemple, le fameux probleme de denormalisation, concerne les valeurs tres proches de 0: dans ce cas, c'est un peu diffent. Ces petits nombres sont ridiculeusement petits, et totalement insignifiant pour de l'audio

Je fais un petit rappel: un nombre flottant en 32 bits est represente comme ca (sur powerpc, intel, etc... C'est un standart, IEEE 754):

nombre = s * 2^e * m

Ou s est 1 ou -1 (pour faire la distinction negatif positif), e est un chiffre code sur 8 bits qui va entre -127 et 126, et m est un chiffre entre 1 et 2 (strictement inferieur a 2), code sur le reste, cad 32 - 8 - 1 = 23 bits.

En general, les signaux sont supposes etre entre +1 et -1 (c'est le 0 dB; on peut depasser le 0 dB, par exemple entre plug in, pour faire par exemple de l'overdrive, mais a la fin, quand le signal est converti pour aller vers la carte sonore, tout ce qui est au dela de [-1, +1] est distordu numeriquement, sauf si l'hote fait de la bidouille a ce niveau la; on peut imaginer que differents hotes aient differents comportements a ce niveau la).

Dans cette representation, dite normale, le plus petit nombre representable est de l'ordre de 10^-38. Pour les nuls en maths, ca veut dire qu'on a une dynamique a ce niveau la de ... 740 dB ! Ce chiffre ne veut pas dire grand chose, cependant, car ce qui importe en general, c'est le plus petit nombre representable comme une difference, cad concretement: quelle est la plus petite difference possible entre deux nombres donnes, et la, c'est de l'ordre de 1e-7 (1.2209290e-7 pour etre precis), ce qui donne alors 140 dB en gros de precision. Si on passe au denormal, la representation est differente (e est fixe a -126, et au lieu d'avoir m etre 1 et 2, m est entre 0 et 1, et permet d'aller jusqu'a 10^-45.

Mais il faut bien se rendre compte d'une chose: si on mixe une piste a 0 dB et une a -80 dB (ce qui est stupide en general, mais passons), on utilise encore tous les bits de precision (les 23), c'est essentiellement sur e que ca se joue, donc on perd vraiment quasiment rien, voire rien du tout. Surtout qu'en interne, au moins sur Intel, les calculs intermediaires sont faits sur 80 bits, mais je sais pas vraiment comment. Entre autre, je connais pas le format de representation. Mais rien qu'en 64bits, faut voir qu'on a a deja plus de 6000 dB de difference entre le plus petit nombre et 1, et au pire 300 dB de dynamique entre n'importe quelles valeurs).

Donc ce que dit Jan est que partiellement exact sur son exemple de sommation, je pense.