Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

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

  • 185 réponses
  • 23 participants
  • 28 380 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
26
Le débat est encore très courtois je trouve.

JM
27

Citation : Je reredis et rererépète que les entrées et les sorties sont en 24 bit max pour tout le monde, c'est une limitation des DACs, donc les fichiers crées sont pour tout le monde en 24 bits de résolution, (les softs en 32 peuvent les encoder en 32, mais la résolution réelle n'est que de 24).


euh, aux dernieres nouvelles, entre un plug in et le mixage, y'a pas de dac, entre le signal du soft et le traitement du soft non plus d'ailleurs. pourtant, dans protools, le signal est ramené en 24 bits a ces endroits la.
par ailleurs, pour traiter du 48 bits, protools est obligé de tricher avec ses dsp, et ce qu'il appelle la "double precision": les dsp sont conçus pour travailler en 24 bits, et pour parvenir a un traitement 48bits, ce sont deux fois 24 bits qui sont envoyés. ça leur permet de contourner la limitation a cet endroit.
28

Citation : pourtant, dans protools, le signal est ramené en 24 bits a ces endroits la.

Non, décidément non, trouve-moi un texte ou il est clairement indiqué cette info, sans confondre avec les bus d'E/S comme tu l'a fait dans le pdf. Moi j'ai lu exactement l'inverse.

Quand aux deux fois 24, c'est cequi donne la double résolution. Les calculs sont effectués sur des échantillons de 48 bits avec des DSP en 24, rien d'extraordinaire et ça n'a rien à voir avec la choucroute? Figure-toi que la célèbrissime Lexicon 480 fonctionne avec des DSP en 8bits ! C'est tout ce dont disposaient les ingés de l'époque. Et pourtant, le son qui en sort n'a rien à voir avec la résolution des DSP, non ?

JM
29
Ben un plug in tdm rentre du 24 bit, sort du 24 bit, c'est dans les specification du format. si t'en mets deux cul a cul, entre les deux, t'as un signal 24 bits. apres en interne les plug ins font ce qu'ils veulent (enfin, t'as plutot interet de rester en entier si tu veux pas d'accident, mais tu peux passer en 48 bits si tu veux), mais le signal doit sortir d'un plug in en 24 bits. et quand il sort d'un plug in, en general, il attaque pas un dac. d'ailleurs dans le dernier lien que j'ai filé, les gens en causent:
""A double precision plug-in works on the signal with 48-bit processing and then applies dither before reducing the result to 24 bits to be placed back on the TDM bus."" ça vient de la doc du mixer.

Citation : Non, décidément non, trouve-moi un texte ou il est clairement indiqué cette info, sans confondre avec les bus d'E/S comme tu l'a fait dans le pdf. Moi j'ai lu exactement l'inverse.


regarde le schema: au dessus des effets/eq/comp, c'est ecris:
""plug in 24bits in, 48 bit process, 24 bits out
288db process dithered and truncated to 144 db for tdm.""

puis dans le texte:
""There is a dithering stage in most double precision plug-ins
and one final dithering stage at the post master output of the summing mixer.""

je vois pas comment je peux t'expliquer autrement. d'autant que le sdk du format tdm n'a pas l'air d'etre disponible...
a toi de voir, maintenant, en tout cas moi pour le coup, je suis a peu pres sur de ce que j'avance, je ne l'etais pas ce matin, mais la de ce que j'en ai lu, aucun doute.
30
Allez encore un peu:

Citation : 4) Finally, people that are concerned about TDM being 24 bit should realize that if every plugin uses 48 bit internals and dithers back to 24 bits, then low level signal quality can still be preserved with few tradeoffs.



Citation : 1) Note that it's still up to the plugin designer to handle the processing in a plugin. Some vendors are careful to code 48 bit plugins with the same care regarding overload and the use of dither back to 24 bits as the modern mixer, but some still aren't so good at this. Now that we have a large amount of DSP available on modern systems, I hope that more plugin designers will take advantage of this power and try to preserve resolution by using 48 bit internals and dither back to the 24 bit TDM bus. Still, there is a pretty complete set of plugins that appear to process signals cleanly right now, so it's not so tough to make a good sounding mix ITB.



on parle pas de la sortie vers le dac, la, hein, ou alors j'ai loupé un truc :8)
31
Je viens de me rendre compte grâce à ton dernier post, qu'on ne parle pas de la même chose, et qu'on ne risque pas de tomber d'accord.

La lecture du schéma nous donne raison à tous les deux en fait, c'est une histoire de vocabulaire. Comme je l'affirme, tous les calculs sont effectués en 48 bits, y compris ceux du mixage (console), et dans mon esprit, les bus font partie de la console. Or il semble bien que dans l'esprit de Digi, le mot bus ne recouvre que l'aspect connexion entre les modules, de plug à plug, de plug à console ou de console à DAC.

Dans ce cas, il n'y a pas calcul, donc aucun intérêt de passer en 48bits.

JM
32
Euh les gars,

faut pas s'emballer comme ça, moi qui pensait que le topic allait mourir avant même d'être posté ...

bon, évidemment, comme si on en entendait pas assez causer comme ça, on en revient à Pro Tools (que je n'ai jamais porté dans mon coeur, désolé, politique exclusive et hardware de Digidesign oblige ... :furieux: )

j'aime à penser que certains développeurs pensent avant à l'audio plutôt qu'au commercial ... néanmoins merci pour votre contribution et votre acharnement à éclairicir le moteur audio qui anime ProTools, c'est en effet pour le moins sujet à controverse (toujours deux bras ?).

et qu'en est-il alors des autres softs et des différences entre 32 bits et 64 bits A VIRGULE FLOTTANTE ?

:clin:
Si vis pacem para bellum
33
En terme de preservation de la dynamique, 64 bits flottants, c'est bien sur mieux, mais une bonne partie des vst travaille de toute maniere en 32 bit float, ET de toute maniere la difference ne sera pas audible, hormis dans quelques cas tres particuliers (si tu mixes 256 pistes avec les faders a -80 db et qu tu veux que le resultat soit exploitable sur 24 bits au final).
pour l'impact sur le cpu, j'en ai aucune idée, en revanche au niveau de la preservation de la dynamique, c'est une avancée

>Jan, ce qu'ils appellent bus, c'est pas une sortie physique, c'est un "canal" parcouru par le signal, comme sur une numerique. au final le bus tu peux le balancer dans un dac, l'envoyer vers un autre bus, le mixer avec d'autres bus, lui faire traverser des traitements...
le calcul en 48 bits, il est interessant, ça permet de faire faire des galipettes a la dynamique qu'on pourrait pas se permettre en 24, et le dithering permet a ces subtilités d'etre audible (puis bon, en 24 bits, on revient quand meme sur 144 db de dynamique). idem dans le mixer, ça donne une precision bien plus grande, surtout quand tu bosses avec un grand nombre de pistes (la ou tu vas devoir baisser les faders).
MAIS ça n'empeche pas le clipping, et si tu joues au con a un endroit la chaine, t'en auras les repercussions en fin de chaine. c'est pour ça que tu peux avoir interet a rester avec une resolution élevée si possible, t'as juste plus de confort. ET ça ajoute des ditherings a chaque etape, la ou il suffirait de rester en 48 bits (ou comme sur les systemes natif en 32 floats) jusqu'au bout, le seul dithering se trouvant avant d'attaquer le dac.
34
Silicon,

ta remarque sur le multi-dithering dans protools est plus qu'intéressante, elle soulève un problème pas anodin : sachant qu'un dithering est une opération qui serait préférable de rester unique et en fin de chaîne avant rendu définitif d'un mix, le multi-dithering semble un peu dangereux pour le signal. A force de manip, la dégradation doit devenir plus ou moins audible ... non ?
Si vis pacem para bellum
35

Citation : ce qu'ils appellent bus, c'est pas une sortie physique, c'est un "canal" parcouru par le signal

Oui, je sais, mais la nuance qui m'avait échappé, c'est que pour moi, hératage dema formation en analogique, la fonction de sommation est obligatoirement attachée au bus. Or pour Digi, le bus peut n'être qu'une connexion entre deux points, ce qui correspond à une vision qu'on les électroniciens. Ce n'est qu'une histoire de vocable.

Le multi-dithering sert dans ce cas à ne pas faire de calculs sur des base bruitées par l'erreur de quantification, mais il faut se rappeler que cela se passe en dessous de -140dB.

Cela dit, il y a effectivement matière à débat. Mais entre vrais trappus de l'audionumérique ;) Après, on regarde les conclusions.

JM
36
C'est clair, le dithering, effectivement en theorie, il y a des arrondis, donc des degradations, davantage que si tu l'evites tout le long, mais avant que ce ne soit audible, faut quand meme y aller, parce que les algos de dithering, c'est plus des jouets...
37
Aaaaaah

je tiens un "vrai trappu de l'audionumérique", enfin. Depuis le temps que j'en cherche un ... :clin:

J'en profite alors pour oser une autre question qui me turlupine (et qui a indirectement à voir avec le sujet concerné) :

pourquoi a-t-on dès le début adopté le PCM comme format obsolut (oups le lapsus) en sachant que le procédé de numérisation était faillible (décimation ...) alors qu'à la même époque un procédé comme le PWM, qui a abouti au DSD, et dont la chaîne de numérisation semble parfaitement plus logique dans le cas d'acquisition d'un signal électrique analogique existait déjà ?

Promis, le prochain coup je fais des phrases moins longues ...
Si vis pacem para bellum
38
En effet et heureusement,

les procédés de dithering ont bien évolué, mais bon, je continue à trouver dommage que l'on complique le trajet du signal, même lorsque l'on ne sollicite pas vraiment une opération comme ce dithering. Pardon encore.
Si vis pacem para bellum
39
Ben pour les phrases, ne change rien, car j'ai fais une phrase courte qui sous-entendait qu'il fallait attendre des vrais trappus de l'audionumérique, et tu as cru que je pensais à moi, ce qui me laisse dans un état de perplexité avancée...

En ce qui concerne le PCM/PWM, le souci est que le PWM n'est pas le résultat d'une quantification, et donc pose un problème d'encodage. Je n'émet qu'une supposition, mais je ne serais pas étonné que les technologies de l'époque ne permettaient simplement pas de réaliser le DSD.

D'ailleurs cela ne doit pas être si simple, les DAWs qui gèrent ce format sont encore très rares.

JM
40

Hors sujet :

Citation : je tiens un "vrai trappu de l'audionumérique"

Ma parole tu est un vrai trapeur de l'audionumérique! :bravo:

41
Pardon Jan si je t'ai mal compris, ça m'arrive hélas. J'ai déjà été échaudé par des durs d'oreille dans d'autres forums (pas sur AF, s'entend).

ben, d'après une doc que j'avais trouvé sur le sujet (la naissance de l'audionumérique, grande aventure et sujet horriblement vaste, surtout que la moitié doit être en japonais ...), c'est semble-t-il la société 3M qui avait accouché du procédé à s'y méprendre similaire au DSD. Comme quoi il ne font pas que du scotch ... :D:

Mais c'est vrai que l'informatique ayant fait quelques menus progrès depuis, il est très certainement beaucoup plus "facile" de mettre en oeuvre une station tout DSD. A ma connaissance, il n'y a que le SADIE v5 et Pyramix qui soit capable de travailler en multipistes DSD. Bien que très lourd, le DSD en 1Fs ne l'est pas autant qu'un bon gros PCM 192/24 ...

Soit pas perplexe, tout va bien ... :clin:
Si vis pacem para bellum
42
Trapeur de l'audionumérique !

bouge pas, je dois avoir ma toque de raton laveur pas loin ... :P:
Si vis pacem para bellum
43

Hors sujet : :mdr: :mdr: :mdr:

44
SADiE fut le premier en effet, de mémoire aux alentours de 2001. Je ne suis pas un expert, mais pour moi, le DSD et le PWM ne sont pas tout à fait comparables. Le PWM est un encodage à fréquence variable, un peu une FM de puissance, il n'y a pas de quantification, ce n'est pas du numérique. Le DSD que je ne connais encore que très peu, est tout de même un encodage numérique sur un bit à flux élevé.

JM
45
C'est à dire que le PWM fait partie intégrante du procédé de numérisation du DSD, ah, il faut que je remette la main sur la page de Sony qui expliquait ça clairement ...
Si vis pacem para bellum
46
Donc le peu que je connais sur le sujet n'est pas faux, si en première approximation, le DSD est un PWM numérisé.

Il faudra aussi que je me rencarde sur le sujet. Mais les journées n'ont que 24 heures...

JM
47
Moi j'y connais que dalle...
48
Je ne voudrais pas me mêler de ce qui ne me regardes pas, mais en lisant ces 5 pages que j'ai fini par survoler d'ailleurs, je n'ai pas l'impression que quiconque ait répondu à la question de départ.
Au départ on parle de passage de softs de 32 à 64 bits ce qui correspond il me semble à l'architecture des nouveaux procs. C'est donc un problème de parrallélisation du traitment de l'information. En 32 bits 4 octets sont traités en même temps et en 64 ce sont 8 octets qui sont traités en parrallèle.
Et même si le débat sur le traitement interne des différents moteurs audios est intéressant, je ne pense pas que ça ait quelque chose à voir avec l'architecture technique.
D'autant que come le disais je ne sais plus qui, un fichier audio en 24 bits reste un fichier en 24 bits qu'il soit trituré par le moteur en 24, 32, 48 etc... surtout si on utilise la même cart en entrée et en sortie. Elle enregistre de 24, elle lit du 24.
Evitons de mélanger les problèmes. je suis surpris que Aegan ce soit contenté de ces réponses oui alors il n'a pas compris sa question non plus.
Ou bien c'est une question codé dont je n'ai pas compris le sens.
Allez @+
49
Tu as raison, j'ai dit pour ma part que je n'avais pas la réponse. Il semble que personne n'ait l'info, c'est peut-être la raison pour laquelle la filière a dérapé vers les moteurs audio.

JM
50

Citation : D'autant que come le disais je ne sais plus qui, un fichier audio en 24 bits reste un fichier en 24 bits qu'il soit trituré par le moteur en 24, 32, 48 etc... surtout si on utilise la même cart en entrée et en sortie. Elle enregistre de 24, elle lit du 24.



certes, mais si tu as tout pourrit entre temps dans les triturages internes, tu risques de pas être content des 24 bits qui sortent de ta carte ...

Phil

Symmetry (electrified folk songs)

Quantum Crash (rock prog solo project)

Lussy Bless (rock-metal)

Po&sic (slam)