Audiofanzine a 25 ans !
Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
FR
EN
Notifications
  • Refonte graphique octobre 2025
    Refonte graphique octobre 2025
    Une refonte graphique vient d'être mise en ligne. Nous espérons qu'elle vous plaira. Merci de nous signaler tout bug ou perte de fonctionnalité ici →
  • Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Pour célébrer notre quart de siècle, UVI se joint à nous et vous offre le Digital Synsations Vol.1. Pour en profiter c'est par ici 👉
  • Nouveauté : Bookmark article, news ou tuto
    Nouveauté : Bookmark article, news ou tuto
    Bookmarkez un article, une news ou un tuto et retrouvez-le dans votre section "Mes signets" du menu membre.
  • 6 nouveaux annuaires
    6 nouveaux annuaires
    Luthiers, Réparateurs, Cours de musique, Studios d’enregistrement, de mastering et de répétition... Suggérez l’ajout d’une entreprise, inscrivez la vôtre ou déposez un avis.
  • Alertes disponibilité et baisse de prix
    Alertes disponibilité et baisse de prix
    Ces nouvelles fonctionnalités vous permettent d'être informé·e dès qu'un produit est disponible ou que son prix a baissé.
  • Tentatives d'arnaque dans les petites annonces
    Nous faisons face depuis quelques mois à une recrudescence de tentatives d'arnaques dans les petites annonces. Suivez nos recommandations >
Mastering
News
Articles
Médias
Forums
Tutoriels Tutos

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

  • 185 réponses
  • 23 participants
  • 28 377 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
101
Salut,

Citation : ben pour info, je joue sur scene (enfin pas tant que ça en ce moment) avec ableton live, ou je declenche des samples et joue de synthé, pendant qu'en meme temps le son d'un bassiste et d'une chanteuse le traverse pour les effets, qui sont mofifiés en temps reel. 11 ms de latence, on y voit que du feu.



puisque ça cause de ça, juste mon experience : je suis en train de tester le nouveau Samplitude, pour le live, ça m'a toujours titillé cette histoire de mixer en live avec un ordi...
J'ai mixé quelques voies importantes (kick, snare, 3 voies), pour pas prendre de risques pendant le concert j'ai utilisé les direct out de la console dans une Fireface, 2 rev, des inserts partout, 96 samples de latence... (2,5 ms). Retour vers des tranches de libres de la console ... impec !
La prochaine fois, je pousse + loin, avec des snapshots pour pouvoir encore plus charger, maintenant que j'ai vu à peu près les limites de l'ordi... et je pourrai aussi sans que ça s'entende, monter un poil la latence... faut pas pousser ...
ça marche mieux que Virtual Console Mixer, qui est fait pour normalement !
Ca s'annonce plutôt bien, pour le studio mobile, j'aurai plus de latitude de travail pour les mixs casques avec fx pour les musiciens.

voilà c'était tout...



a+
Phil

Symmetry (electrified folk songs)

Quantum Crash (rock prog solo project)

Lussy Bless (rock-metal)

Po&sic (slam)

102
T'inquiètes live, je connais et j'apprécie beaucoup aussi. Les effets consomment très peu en ressources donc ça permet effectivement de ne ne pas trop monter la latence.
Mais 11 ms ça reste trop pour un enregistrement. Imagines que t'es un batteur et un bassiste à enregistrer. T'équalises certaines pistes de la batterie et tu la renvoies dans le casque du bassiste. Bah si t'as pas une latence très courte, ça va pas être simple pour eux de jouer ensemble.

Citation : Et si PT sais comme tous les systèmes à base de DSP avoir une latence suffisament faible pour être négligeable pour l'utilisateur, la puissance des machines natives permettent des latences de moins de deux millisecondes actuellement pour les meilleures, ce qui est parfaitement acceptable.



Bah oui c'est tout a fait jouable, sauf que pour avoir ces 2ms de latence bah t'as pas grand chose en plugins d'activé donc les buffers au minimum ???
D'ou ma remarque sur le prix du système HD ou de Pyramix qu'est pas si prohibitif que ça compte tenue du confort de travail que cela apporte ;)
M'enfin bon, je suis pas près d'en avoir les moyens, non plus :((
103

Citation :
Quand à ma question initiale sur le délicat sujet des "moteurs" (pour ma part, ça incluait l'espèce d'OS qui fait le lien entre les étapes de mixage de lecture et de gestion des traitements, plugins ou pas), elle peut paraître anodine, mais d'après ce que disent certains ici, les différents moteurs audio ne peuvent pas se distinguer les uns des autres de manière audible ... ce qui revient à dire que Tracktion (150 brouzoufs) sonne exactement ou pas différemment à proprement parler de Protools HD (10000 brouzoufs) ou de Pyramix (3000 brouzoufs). Alors, la vraie question derrière tout ça est : où commence la raison marketing et où finit la fièvre commerciale ?



Pour vraiment comprendre et etre d'accord sur ce que signifie le moteur audio, il faudrait que tout le monde sache comment marche un sequenceur, et qules sont les problemes qu'il resout. En fait, le moteur audio, tu peux voir ca comme un OS: son boulot, c'est de faire une interface entre la carte son, les plugins, et l'interface utilisateur (en general graphique).

Par exemple, si tu veux programmer un effet VST (ou audio unit, etc.., ca change rien au probleme la), tu n'as pas a te soucier de la carte son, du nombre d'entrees de la carte son, et de sa relation avec l'exterieur, y compris du type de sequenceur. Tous les VST ont une meme maniere de "parler" a l'hote: c'est exactement le but du VST.

Donc le moteur audio, lui, il doit:
* gerer la(les) carte son (en general a travers un autre protocole, par exemple asio, core audio, etc..),
* etre capable de se voir plugge pleins de plugs: insert, etc... Tout ce qui est le routing, quoi.
* gerer la latence: faire en sorte que tous les plugs in soient synchronises
* etre efficace: pour avoir une faible latence, tu as pleins de parametres a prendre en compte dans l'interacation vis a vis de l'OS, c'est un peu complique de rentrer dans les details pour les non informaticiens, mais disons que c'est pas trivial.

Tous ces problemes sont complexes, mais *pas du tout tout au niveau traitement audio*. Pour changer le volume d'une piste, c'eest toujours la meme operation, qui est triviale, a savoir la multiplication du signal par un gain. L'aliasing ne joue absolument pas la dedans. La ou l'aliasing intervient, c'est lorsque le signal d'entree a une frequence differente que la frequence de fonctionnement (par exemple utliser un wav @ 44.1 Khz, et une frequence de fonctionnement de l'hote a 48 khz).

Apres, la plupart des sequenceurs incluent des effets (Eq, reverb, etc...), et la, ils sont tous differents, y compris sur le plan sonore.

Citation :
Alors, il y a deux approches, soit la station DtD haut de gamme, avec un "moteur audio" bétonné (optimisation du calcul, dégradation du signal nul même avec de nombreux traitements simultanés (la phase, bordel, la phase !),



Non mais le sequenceur, il a aucune influence sur la phase, tant que tu utilises que les faders.

Citation :
Non, cela fait parti des bases de l'audio-numérique, la latence théorique mini est obligatoirement d'un échantillon. En pratique, l'utilisation de DSP permet d'avoir un environnement optimisé permettant de diminuer la latence, pas de l'annuler.



C'est pas tant la base de l'audio numerique que des contraintes d'implementation. La latence a plein d'origines:

- deja, au niveau de la conversion. Pour ca, faut savoir un peu comment marche la communivation carte son - OS. Tout carte audio ne convertit pas sample par sample, mais remplit un buffer de n samples, et une fois que le buffer est rempli, il dit au CPU: hello, le buffer est rempli, tu peux lire son contenu maintenant (c'est une interruption, passee par les fameux IRQ). A ce moment la, l'OS lit le contenu du buffer, le copie (concretement, il le copie pas forcement, mais ca change pas grand chose a l'idee generale), et le file a travers un protocole style ASIO, etc... aux logiciels qui en ont besoin, comme par exemple ton hote. Le n, c'est ce que tu regles dans ton panneau de carte son, et c'est au moins egal a 64 autant que je sache (pour les RME). 64 samples a 44.1 Khz, ca veut dire 1.5 ms de latence, deja.
- ensuite, le temps d'ecoulement entre l'operation "la carte son signal son buffer plein" et "l'OS traite l'information et file le contenu du buffer aux applications" n'est pas nul. La, ca depend beaucoup de l'OS, en particulier de son algorithme de scheduling. Windows est particulierement mauvais, Mac os X et linux nettement meilleurs pour prendre ca en compte. La, l'hote peut deja faire une difference, car c'est difficile de pouvoir faire ca bien.
- enfin, les traitements audio en eux meme: la aussi, il y a de la latence, qui depend totalement du plug, etc... Recemment, les sequenceurs sont devenus capables de realigner les plugs au niveau de la latence (latency compensation): la latence des plugs etant calculable, le sequenceur lui file les donnes en avance (lorsque les parties audio sont deja enregistrees, evidemment) d'un nombre exactement egal a la latence.

Et la dedans, tu dois prendre en compte le fait que les sequenceurs ajoutent leur propre latence lorsque tu changes les parametres (les traitement audio sont presque toujours faits par bloc; plus le bloc est grand, plus tu as de la latence), etc...

Un systeme DSP fonctionnant sur un OS tres limite, il a beaucoup moins de problemes de latence en general (sous DOS, t'as tres peu de latence aussi :) ), mais le probleme de la carte son demeure par exemple, autant que je sache.

D'ailleurs, faut voir que de plus en plus de constructeurs hardware sont interesses par linux, pour differentes raisons. C'est extremement couteux de faire son propre OS (dit embarque, car a l'interieur d'un hardware specifique, par exemple table de mixage, etc...), et linux offre pas mal d'avantages. Parmi les noms connus du public, il y a quand meme SSL, Harrison/GLW ou Korg (l'OASYS fonctionne sous linux).
104
Quand je disais que la latence théorique est de un échantillon, je voulais juste dire que le simple fait de le prélever dans le flux, et de le réintroduire dans le circuit après une quelconque opération ne peut se faire sans au moins un cycle d'horloge du CPU, et que ce temps très faible mais non négligeable empèche cet échantillon de rester à la même position temporelle, que ce soit du natif, ou du DSP provenant d'une DAW ou d'une console.

Ce que j'appelle les bases, quoi.

JM
105
...sans compter les temps de conversion A/D - D/A ...
106

Citation :
Quand je disais que la latence théorique est de un échantillon, je voulais juste dire que le simple fait de le prélever dans le flux, et de le réintroduire dans le circuit après une quelconque opération ne peut se faire sans au moins un cycle d'horloge du CPU, et que ce temps très faible mais non négligeable empèche cet échantillon de rester à la même position temporelle, que ce soit du natif, ou du DSP provenant d'une DAW ou d'une console.



Oui mais cette latence est justement pas d'un echantillon (un echantillon du signal sonore, d'ailleurs, dont la frequence est bien plus faible que celle du CPU: on parle de plusieurs dizaines de micro seconds pour un echantillon sonore, alors que pour un CPU, c'est de l'ordre de la nano seconds; le CPU n'ar rien a voir dans l'operation dont tu parles).

Le probleme que tu souleves est en fait fondamental, mais pas pour le probleme de la latence dont on parle le plus souvent dans un contexte utilisation de l'ordinateur. C'est un probleme lorsque l'on utilise plusieurs unites hardware numeriques reliees entre eux numeriquement.
107
Euh, je voudrais pas insister, mais je dois mal me faire comprendre.

Je ne confonds pas la fréquence CPU avec la Fe, je dis simplement que même si l'ordi ou le DSP est très très très rapide, il ne calcule pas à vitesse infinie, que par conséquent il ne peut qu'introduire une latence minimum théorique d'un échantillon, parce qu'il n'est pas possible que ce soit zéro, et qu'entre zéro et un, il n'y a pas d'alternative.

Ce qui n'empêche pas d'autre phénomènes d'en rajouter, notamment la conversion AD/DA.

JM
108

Hors sujet :

Citation : T'équalises certaines pistes de la batterie et tu la renvoies dans le casque du bassiste. Bah si t'as pas une latence très courte, ça va pas être simple pour eux de jouer ensemble.


11 ms, pour un batteur c'est largement sufisant, meme pour de la guitare jouée res rapidement, en general, le guitariste n'y voit rien (sur scene, si t'es a 5 metres de ton retour, t'as plus de "latence" que ça!!), il est possible de descendre autout de 5, je ne le fais pas en live pour ne pas prendre de risque,parce que justement j'ai une charge consequente (au passage, les effets de live ne consomme pas tant que ça, certes, mais a coté y'a une dizaine de pistes en timestretching temp reel, des instruments, et des plug ins non natifs, mon cpu tape pas loin des 75%), mais en situation d'enregistrement, on eut tout a fait envisager de descendre, en freezant le reste par exemple.
vraiment, hein, je le fais regulierement, et meme a 11 ms, personne s'est jamais plaint, surtout pas les batteurs.

109

Citation :
Je ne confonds pas la fréquence CPU avec la Fe, je dis simplement que même si l'ordi ou le DSP est très très très rapide, il ne calcule pas à vitesse infinie, que par conséquent il ne peut qu'introduire une latence minimum théorique d'un échantillon, parce qu'il n'est pas possible que ce soit zéro, et qu'entre zéro et un, il n'y a pas d'alternative.



Ah, Ok. Tu as raison, mais une fois encore, c'est totalement negligeable par rapport aux autres origines de la latence: buffer hardware de la carte son, latence de l'OS, etc... En general, la latence est de l'ordre de plusieurs centaines de samples, et les convertisseurs ne convertissent jamais sample par sample autant que je sache (je peux me tromper, je connais pas grand chose au hardware mis en jeu pour les convertions; pour les carte sons, j'en suis certain par contre).

Par contre, la ou c'est pas negligeable du tout, c'est dans les problemes de feedback. Par exemple, c'est une des raisons pour lesquelles les filtres numeriques sonnent pas pareil que les filtres analogiques (qui eux peuvent meme pas etre sans feedback), et selon les designs des filtres numeriques, on va pouvoir diminuer cet effet ou pas.
110
C'est pour ça que j'insistais sur l'aspect théorique, parce que les problèmes de bufferisation par exemple relèvent de choix technologiques. Il serait, toujours théoriquement, possible de s'en passer, même si d'un point de vue rendement et sécurité, ce ne serait pas une bonne idée.

Et cela remettrait beaucoup de chose en question, c'est certain. Notamment la gestion de fichiers et les accès au disques durs. C'est le résultat de l'adaptation de technologie issues de l'informatique à l'audio, qui necessite une gestion de flux continu. A un autre niveau, on retombe dans la même problèmatique que la téléphonie sous IP, mais avec des débits beaucoup plus importants.

JM
111

Citation :
Il serait, toujours théoriquement, possible de s'en passer, même si d'un point de vue rendement et sécurité, ce ne serait pas une bonne idée.



Je me demande par exemple quelle est la latence d'un convertisseur en lui meme, sans parler du controlleur PCI et tout ca. Je sais pas vraiment comment ca fonctionne concretement, en fait.
112
Au niveau de la conversion, mes souvenirs sont un peu trop lointains, mais il y a bufferisation aussi a ce niveau.

Quand j'évoquais les choix technologiques, je pensais notamment aux gestion de flux entre les cartes son, le système (MOBO + CPU + bus PCI) et les disques durs. C'est à mon avis ce qui fait la force des systèmes totalement dédiés, mais ils tendent à disparaitre dans la mesure ou le marché pour des machines forcément très couteuses n'existe plus.

Il suffit d'utiliser un PT HD pour se rendre compte qu'on gagne un peu grace aux cartes d'acquisitions dédiées, mais que le plus gros de la latence reste, il est attaché au fait qu'il faut un Mac pour le faire tourner, et que ça suppose que le soft fonctionne sous le dictat de l'OS et des normes régissant les différents périphériques informatiques utilisés.

Cela dit faut pas se plaindre, j'utilise une machine qui enterre en terme de perfs et de possibilités, celle que j'utilisais il y a cinq ans et qui valait dix fois plus. Ca vaut bien de sacrifier une paire de ms de latence ;)

JM
113

Citation :

Quand j'évoquais les choix technologiques, je pensais notamment aux gestion de flux entre les cartes son, le système (MOBO + CPU + bus PCI) et les disques durs. C'est à mon avis ce qui fait la force des systèmes totalement dédiés, mais ils tendent à disparaitre dans la mesure ou le marché pour des machines forcément très couteuses n'existe plus.



Tu peux aussi voir ca comme le fait que le matos hardware est devenu assez puissant, et les OS qui vont avec. Par exemple, avec un linux (version normale, pas celle RT), tu peux assurer sans probleme, avec 90 % de load CPU, une latence de quelques ms seulement avec jack.
114
RT ?

Hors sujet : J'ai bien l'intention de scruter ce qu'Ardour a sous le capot dès que j'ai un peu de temps, j'espère avant la fin de l'année.



JM
115

Hors sujet : RT = Real Time. Tout ca pour dire que le noyau de base, maintenant, est relativement bon pour avoir des latences tres faibles, de l'ordre de la ms, meme sous un load tres important

116

Citation : J'ai bien l'intention de scruter ce qu'Ardour a sous le capot dès que j'ai un peu de temps, j'espère avant la fin de l'année.



Jan tu as 1000 X raison :bravo: et on peut s'attendre a de la compatibilité avec le matos SSL. (pour GLW c'est déjà intégré) :bravo:
117
Bonjour a tous
Il me semble que l'intéret du mixage 64 bit est la reserve de dinamique pour conserver l'intégritée du signal durant la chaine de traitement.
De plus il s'avererait qu'un signal numerique perdrait durant le mixage interne 1 bit toute les 4 pistes (a verifier) donc plus il y a de bits pour le traitement des signaux mieux c'est.Il n'y a qu'a comparer des mixage en 16 bits 24 bits 32bits float(cubase nuendo) 48 bit/56 bits (protools tdm )ou des traitement de reverbe (comme la time works qui permet le 32 et le 64 bits)pour entendre la difference .
je me rappel que sur falcon atari nous avions devellopé un logiciel multipiste qui travaillait en 96 bits pour conserver parfaitement l'integrité du signal(à l'époque la conversion n'etait "que" 16 bits).
118
J'aurais voulu repondre a silicon reborn qui est tres souvent moderé or sujet : une latence de plus de 7 ms est propement intolerable pour un clavier professionnel jouent "staccato" il en vas de meme pour un batteur qui ,souvent ne supporte meme pas la latence midi (entre 4 et et 8 ms ,et oui) c'est d'ailleur pour cela que les batterie numeriques de tipe roland possedent un processeur de son interne en amont du midi out pour délivrer une latence de l'ordre de 1.5 a 2 ms ,qui dans certains cas ,les dérange déjà.
Pour les guitaristes idem ,pour les chanteur (moins mafois..)celà peut les deranger aussi.Remarque type:"y'a un trrc bizare sur ma voie ,t'aurais pas mis un chorus?
119

Hors sujet : c'est quoi cette blague?? latence midi?? 7 ms??
encore un fois, tu te mets a 5 metres de ton retour, t'as 14 millis. t'as deja entendu un mec se plaindre de ça??

Citation :
c'est d'ailleur pour cela que les batterie numeriques de tipe roland possedent un processeur de son interne en amont du midi out pour délivrer une latence de l'ordre de 1.5 a 2 ms


ça c'est la blague de l'année, et il interprete quoi le processeur de son, qu'on rigole.
je releve meme pas la "latence midi" de 7 ms.

120

Citation : De plus il s'avererait qu'un signal numerique perdrait durant le mixage interne 1 bit toute les 4 pistes

A chaque étape du mix en 32 bits float, le son conserve sa dynamique de 24 bits signifiants, ce sont les sons de chaque pistes indépendantes qui perdent un peu de résolution, de la même ùmanière qu'ils perdraient du rapport signal/bruit en analogique. Ce n'est pas une cata.

Citation : il en vas de meme pour un batteur qui ,souvent ne supporte meme pas la latence midi (entre 4 et et 8 ms ,et oui) c'est d'ailleur pour cela que les batterie numeriques de tipe roland possedent un processeur de son interne en amont du midi out pour délivrer une latence de l'ordre de 1.5 a 2 ms ,qui dans certains cas ,les dérange déjà.

Si tel était le cas, il faudrait qu'ils commence à rapprocher leurs oreilles de la caisse claire, vu que le délai entre la frappe et l'oreille est déjà d'environ 2ms. On peut raconter un peu n'importe quoi, mais un effort pour être crédible n'est pas superflu.

La seule explication peut être le mélange des sources directes et des sources avec latence, un casque bien fermé règle le problème, et hop.

JM
121

Message de modération : Bon, la discussion a été assez courtoise jusqu'à présent et il serait bon qu'elle le reste.

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.

De ce fait, des gens pas forcément au top au niveau technique risquent de débarquer ici (je ne vise personne). Forcément, dans le lot, il y aura des gens qui pourront dire des bêtises. Il serait bon de se contenter de leur réponde gentiment qu'ils se trompent plutôt que de partir dans l'invective.

Je trouve plus intéressant, plus productif en terme de savoir de laisser des gens oser poster quitte à faire des erreurs qui seront rectifiés pluôt que réduire tout le monde au silence par crainte de l'invective.

Par ailleurs, les discussions sur la latence sont hors sujet dans ce topic. On va donc si vous le voulez bien oublier cette notion, déjà (très) largement traitée ailleurs, d'autant que le sujet de base du topic a déjà largement de quoi alimenter du volume ;)

Merci à tous. Que l'excellence de la tenue continue à être à la hauteur de l'excellence du niveau technique de cette discussion. :bravo:

122
Excuse nous Bill, on le fera plus ;)

Hors sujet : A propos, le fond rouge des interventions de modo font un peu descente de la BAC en banlieue chaude, tu trouves pas ?



JM
123
D'ailleurs c'est pas 1 bit tous les 4 pistes, dans le cas ou toutes tes pistes sont identiques, tu perds 3db de dynamique par piste chaque fois que tu doubles le nombre de piste. a moins de travailler avec GRAS de piste, et d'avoir besoin de 100db de dynamique a la fin (ce qui ne risque pas d'arriver souvent), on a largement de quoi couvrir nos besoins.
124
Par contre, si vous pouviez développer cette histoire de dB perdus par piste...
J'avoue que c'est la première fois que j'en entends parler. :noidea:

Et il me semble que ça reste dans le sujet, ça :mrg:
125
Tu perds 3dB à chaque fois que tu doubles, soit 1 bit (6dB) pour les quatre premières, puis 1 bit pour 16, un autre pour 64, etc. Donc en théorie, pour 64 pistes mélangées à parts égales, chaque piste conserve une résolution de 21 bits, soit une dynamique de 126dB, pas de quoi se plaindre.

JM