Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Prise de Son & Mixage
Agrandir
Prise de Son & Mixage
Techniques du Son
Prise de Son & Mixage
Actu 383 383
Articles 358 358
Médias 1 878 1,9k
Tutoriels Tutos 2 2
Forums 4 718 4,7k

Sujet Différence de son entre les DAW : un mythe ?

  • 296 réponses
  • 34 participants
  • 38 027 vues
  • 48 followers
Sujet de la discussion Différence de son entre les DAW : un mythe ?
J'ouvre un nouveau thread pour une discussion qui a commencé dans le sujet Comment sont créés les kicks des productions actuelles ?.
Suite à la remarque d'un membre qui disait qu'on peut avoir le gros son avec seulement des plugs, nous parlions de l'intervention de la qualité des convertos, des plugs et des DAW utilisés.
Nous étions en train de dire qu les DAW et les plugs n'interviennent pas dans ce qui sort du monitoring et que la différence de son entre les bounces et les L-R des softs est un mythe. Voici ma réponse aux derniers posts :


Citation : ben sans être méchant, si ils t'on répondus ca, c'est qu'ils n'y connaissent pas grand chose, d'une parsque les calculs sont faits en 32 bit flottant dans TOUS LES CAS (sauf certains plugs particuliers), et de deux parsqu'il n'y a pas de notion de qualité de calcul à partir du moment ou on applique le même algorythme, on est en numérique, c'est du 1 et du 0, soit ca marche et ca fait tout le temps pareil partout, soit ca marche pas.



Ca me parait logique, mais tous les mecs qui m'ont dit entendre des différences entre les DAW sont des ingés, et pas des mecs qui ont appris sur le tas... comme quoi, ce ne sont pas des clichés de débutants.

Citation : ben oubli ton test alors, il ne vaut rien.



Citation : Tu as répondu toi même au mystère



Je suis d'accord que pour que la mesure soit bonne, on reproduit EXACTEMENT la même situation dans les deux cas; mais ce que je ne comprends pas, c'est qu'on n'obitenne pas le même résultat, quelque soit l'audio sur lequel l'effet est appliqué !
Ca voudrait dire qu'avec un simple coupe haut, on n'a pas le même son sur une guitare que sur une voix par exemple ?

Après ça vient peut être du fait que la source stéréo était un mix entier et que les sources mono étaient des prises de son brutes et individuelles...
Afficher le sujet de la discussion
251
Citation :
je crois qu'on dit la même chose, tu as fait intervenir l'exposant du flottant parce que tu sorts des capacités du 24 bit en faisant la somme

Non non. En flottants, et sauf pour le zéro parfait, le premier chiffre sera toujours un 1 (en binaire).


Quelques exemples pour fixer les idées (avec des formats ayant peu de chiffres, donc faciles à lire !), avec une conversion "virgule fixe à 6 chiffres" (3 avant et 3 après la virgule), vers "flottants 3 bits de mantisse et 3 d'exposant" (je souligne là où la mantisse est prise) :

001,010 -->
101 ; 000

10,100 -->
101 ; 001

101,000 -->
101 ; 010

000,101 -->
101 ; 111 (111 est la manière de représenter -1 en binaire, sur 8 bits on aurait huit 1)

000,010 -->
100 ; 110 (110 vaut -2)

10,010 -->
100 ; 001 => perte due à l'arrondi !

001,001 -->
100 ; 000 => perte due à l'arrondi !



On peut aussi avoir des pertes avec les mêmes formats, en allant de flottants vers entiers:
101 ; 110 -->
000,010 (la valeur exacte serait: 000,0101 mais il faudrait un chiffre de plus)


Cas particulier où le premier chiffre de la mantisse n'est pas un 1:
000,000 -->
000 ; 000

x
Hors sujet :
Et là un pinailleur soulignerait qu'il y a aussi le cas particulier de la dé-normalisation, fameux bug du pentium. Ça concerne les petits nombres, où on utilise la mantisse pour faire encore plus petit que ce que permet l'exposant.

Dans mon format, le plus petit nombre flottant sans dé-normalisation serait :
100 ; 100 (100 vaut -3)
000,001

Avec dé-normalisation (qui est effectivement utilisée par les processeurs):
001 ; 100 -->
000,00001




Citation :
en pratique il se traduira par une surmodulation, donc une atténuation à opérer quelque part

Quand un arrondi a été fait, il y a bien une perte d'information, que l'on ne pourra pas retrouver ensuite. Mais comme tu le soulignes, la perte de ce détail s'est accompagnée d'un gain en niveau.

Autrement dit: le rapport signal bruit est resté constant. C'est un avantage que l'on obtient dès que l'on utilise des nombres flottants. En 32 bits flottants (cas général des séquenceurs), donc avec 24 bits de mantisse, donc 24 bits toujours exploités pour la partie utile du signal, on peut dire que sur ce nombre on a un rapport signal bruit de 144dB.

Donc même après des tas de calculs et avec des tonnes d'arrondis, on doit garder un rapport signal bruit de 120 voire 130 dB, et il n'y a donc aucune chance que l'oreille puisse déceler les pertes (elles seront déjà totalement couvertes par les pertes en analogique, où le rapport S/B doit être de 115 pour les trucs les plus chers, 100 pour du bon matos, facilement 90 ou 80 pour du matos grand public moyen).

Et les tests que tu as fait laissent penser que les pertes dues aux arrondis ne viennent pas vite. Ou alors, autre explication: tes pistes étaient des pistes audio, enregistrées à -12dBFS crête, donc avec au moins 2 bits de poids faible à 0 une fois passé en float.

Dernier point: même si protools travaille en entiers, il y a des astuces sur la conception qui leur permettent de garder une bonne dynamique et un bon rapport signal bruit. Typiquement: "ils déplacent la virgule vers la gauche lorsqu'il y a sommation". Ce déplacement et fixe, et le principal désavantage est la limitation en nombre de pistes (mais elle est élevée).


Enfin en 2 mots: on constate que tout ça fonctionne incroyablement bien, et que les différences que certains entendent sont soit dues à des différences dans leur protocole de test, soit à leur imagination.

Désolé pour le "ghost in the shell" ! :bravo:

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

[ Dernière édition du message le 12/07/2011 à 15:40:46 ]

252
Citation :
Du coup si les daw sont à virgule flottante maintenant, et même s'ils étaient juste en 24bits, je ne voit pas ce qui pourrait faire que le son diffère puisque même sur 24 bits la dynamique est énorme, et si j'ai bien compris, l'ajout de bruit se fait à des fréquences inaudible pour l'oreille humaine ...

Les DAW sont tous en virgule flottante sauf protools (mais ce n'est pas si gênant, voir ci-dessus). Ils sont généralement en 32 bits, avec 24 bits de mantisse et 8 d'exposant. Le signal utile est dans la mantisse, l'exposant donne un overhead confortable (700dB ! c'est plutôt là qu'on va parler de dynamique).

Sur chaque nombre on peut dire que le bruit est à -144dB. Il apparait donc à des niveaux (pas des fréquences) effectivement inaudibles ; et surtout les enceintes (ou le casque), et l'ampli et autres appareils analogiques indispensables pour entendre quelque chose (convertisseur !...) vont avoir un bruit de fond bien supérieur.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

253

   Citation :

autre explication: tes pistes étaient des pistes audio, enregistrées à -12dBFS crête, donc avec au moins 2 bits de poids faible à 0 une fois passé en float

 ben oui, c'est ce que je dit depuis le début, le niveau de chaque piste était tel que leur somme n'entrainait pas de surmodulation au niveau du bus master.icon_bravo2.gif

 

Par contre, un truc me chiffonne dans tes exemples, je ne comprend pas ta virgule dans ta représentation des nombres en entier.headscratch.gif

Citation :

virgule fixe à 6 chiffres......-> 001,010

 pour moi, mais j'ai peut être mal compris, cette représentation n'existe pas, puisque par définition on est en entier.noidea.gif

 

Tu me reprends si je dit une connerie, mais:

on quantifie une tension sur une échelle de 16 777 216 valeurs possibles en 24 bit correspondant à la plage du converto.

avec un exemple concret, ça donnerait, pour un converto qui fait +/-12V :

une tension de 4.956V donnerait la valeur:

(4.956 * 16 777 216)/12 = 6928990,208 sauf que ramenée en binaire, y'a pas de virgule puisqu'on est en entier, et la valeur serait:

11010011011101001011110 (6928990) d'où l'arrondi (erreur de quantification) et le bruit de quantification, et on retrouverait en sortie une tension de 4.955999851..........

non?

edit 1-> je précise que j'ai pas pris en compte le bit de signe, sinon la valeur max ne serait plus 16 777 216 mais 8 388 608, mais ça change rien au principe (l'intervalle de [-12V/+12V] est quantifié sur [-8 388 608/ 8 388 608] ce qui fait bien 16 777 216 valeurs en tout


Edit 2-> pour protools, l'astuce c'est que le bus de sommation est en 56 bit entiers, justement pour avoir la capacité de sommer des nombres en 48 bit entier sans risquer la troncature, je crois que sur le 48 bit entier il y a 15 bit qui servent de "headroom" (et 9 pour des LSB supplémentaires), pour le bus, je ne sait plus, il faudrait relire la doc.

 

 

[ Dernière édition du message le 12/07/2011 à 15:09:47 ]

254
Citation :
ben oui, c'est ce que je dit depuis le début, le niveau de chaque piste était tel que leur somme n'entrainait pas de surmodulation au niveau du bus master.

Ok. Mais du coup ça ne met pas en évidence les problèmes d'arrondi. D'un autre côté, c'est réaliste... (comme j'explique ci-dessous, les zéros ne sont pas à gauche du nombre mais à droite, mais au final ça revient au même, c'est sûr).


Citation :
Par contre, un truc me chiffonne dans tes exemples, je ne comprend pas ta virgule dans ta représentation des nombres en entier.

Au niveau programmation, un entier, ou un nombre à virgule fixe, c'est toujours un "int" (entier 16 bits) ou un "long int" (entier 32 bits).

Mais après le programmeur peut décider que les 4 derniers chiffres sont après la virgule. C'est pas forcément fait comme ça, mais "il suffit d'afficher la virgule juste avant les 4 derniers chiffres". C'est ce que j'ai voulu représenter avec :
Citation :
virgule fixe à 6 chiffres......-> 001,010

Et en gros c'est comme ça que protools travaille. Sauf que c'est 32 bits (pas 6 !), avec la majorité des chiffres après la virgule (en dessous de 0dB), et quelques chiffres avant la virgule (= overhead).


Citation :
on quantifie une tension sur une échelle de 16 777 216 valeurs possibles en 24 bit correspondant à la plage du converto.

avec un exemple concret, ça donnerait, pour un converto qui fait +/-12V :

une tension de 4.956V donnerait la valeur:

(4.956 * 16 777 216)/12 = 6928990,208 sauf que ramenée en binaire, y'a pas de virgule puisqu'on est en entier, et la valeur serait:

11010011011101001011110 (6928990) d'où l'arrondi (erreur de quantification) et le bruit de quantification, et on retrouverait en sortie une tension de 4.955999851...

Au niveau du convertisseur, ça travaille en entiers, donc comme tu l'as décrit. Idem dans le fichier wav 24 bits fixes.

Mais dans le séquenceur, ou dans des fichiers en flottant, ça n'est pas comme ça.

+12V (=0dBFS = le nombre 1) -->
mantisse= 010000000000000000000000 (24 chiffres, le premier pour le signe) ; exposant= 00000000

+6V -->
0100000...00 (24 chiffres, le même nombre qu'au-dessus) ; exposant= 11111111 (c'est -1, normal on a divisé par 2)

+3V -->
0100000...00 (24 chiffres, toujours le même nombre) ; exposant= 11111110 (c'est -2, normal on a encore divisé par 2)

Donc comme je le disais, et sauf cas de dé-normalisation, le premier chiffre (hormis le signe) est toujours un 1. Comme illustré plus haut avec les soulignements, ça revient à "prendre les chiffres significatifs" pour constituer la mantisse. Ça permet clairement d'optimiser le "rapport signal / bruit". Et après on balade la virgule, d'où virgule "flottante".


Citation :
Edit-> pour protools, l'astuce c'est que le bus de sommation est en 56 bit entiers, justement pour avoir la capacité de sommer des nombres en 48 bit entier sans risquer la troncature, je crois que sur le 48 bit entier il y a 15 bit qui servent de "headroom" (et 9 pour des LSB supplémentaires), pour le bus, je ne sait plus, il faudrait relire la doc.

Il y a ce que tu dis au moment de faire le calcul (un peu comme les calculs sur les flottants sont faits en interne par le CPU sur 80 bits), mais une fois le calcul fait, protools revient sur 48 bits, mais en déplaçant la virgule.

De la lecture de leur doc, je me souviens qu'ils déplacent la virgule dans certains cas pour éviter la saturation (après sommation notamment).

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

[ Dernière édition du message le 12/07/2011 à 15:35:19 ]

255

 ok, pigé, mais je vois toujours pas l'arrondi tant qu'on introduit pas des calculs (gain, pan, plugs etc...)

ta valeur 1000000000000000000000 exposant -2, une fois ramenée en 24 bit entier, ça fait 1000000000000000000000-> ce qui fait une valeur de 4 194 304 ce qui sur mon échelle de 12V me fait 6, je retrouve donc bien ma valeur de 6V sans le moindre arrondi.noidea.gif

 

La représentation, entier ou flottant, je l'ai, c'est cette histoire d'arrondi dans le simple cas d'une somme que je ne vois pas.

256
Citation :
Du coup si les daw sont à virgule flottante maintenant, et même s'ils étaient juste en 24bits, je ne voit pas ce qui pourrait faire que le son diffère puisque même sur 24 bits ladynamique est énorme

Oui c'est un peu la conclusion qui s'impose, avec le 32bits flottant ou 24bits fixe, de toute façon les dynamiques disponibles sont telles que les bruits liés à la quantification sont largement inaudibles.
Par contre, l'argument commercial que l'on peut trouver qui stipule que le "tout 24bits fixe" et mieux que le 32bits flottant est un mensonge. A partir de 16bits c'est le flottant qui présente le comportement le plus intéressant lorsque l'on enchaîne des traitements "complexes".

Citation :
et si j'ai bien compris, l'ajout de bruit se fait à des fréquences inaudible pour l'oreille humaine ...? (ou alors je confond tout ?)

Je crois que tu confonds avec un autre problème.
Pour une dynamique de signal assez important (plus de 4LSB), la quantification introduit un bruit qui peut être assimilé à un bruit blanc : un bruit qui couvre toute les fréquences du spectre.

Pour une dynamique très faible (moins de 4LSB), la quantification ne se comporte plus comme un bruit et introduit des artefacts sonores désagréables (des sortes de grincements métalliques). Pour régler ce problème on ajoute au signal à quantifier un bruit qui empêche ces artéfacts de se former : c'est le dithering.
Il existe plusieurs technique, mais l'idée générale est d'ajouter un bruit coloré (il n'est pas blanc) qui privilégie des fréquences inaudibles pour l'homme.

Ce problème se pose à la toute fin, quand tu réduits la quantification à 16bits pour une graveur sur CD. Bon... si tu fais du "D. Guetta" avec des signaux ultra compressés avec une dynamique qui couvre toute la plage de valeur possibles en permanence, le dithering ne sert à rien : ton signal a toujours une amplitude supérieure à 4LSB.
C'est un procédé qui a plus d'intérêt si tu as des fading très long ou que tu laisses mourir des reverbs avec un son de moins en moins fort... jusqu'à atteindre quelques LSB.


Citation :
Mais dans tous les cas, un problème d'alignement en analogique est peu ou prou répété car les défauts des composants évoluent dans le temps, mais pas à la même échelle de temps que l'échantillonnage.

C'est à dire ?

La répétabilité d'un système c'est la dispersion de ses réponses pour des entrées et des paramètre identiques.

Les "potards numériques" sont quantifiés en valeur (cf. les niveaux midi). A priori les dérives en valeur au cours du temps du composant sont de moyenne nulle et d'une variance bien plus faible que le pas de quantification : on lira toujours la même valeur pour une position donnée.


Le problème de la répétabilité analogique pourrave c'est que si tu as un enregistrement A, que tu réalises un copie B, puis une copie C à partir de B, puis un copie D à partir de C... Le niveau de bruit entre D et A deviendra vite franchement audible (en gros, +3dB sur le bruit à chaque copie de copie).

Dans le cas du numérique, ton son A est discrétisé pour obtenir un signal Aq, et si tu fais des copies successives de Aq, Dq présentera le même bruit de quantification que Aq... C'est quand même un sacré avantage.

Mais bon, ce ne sont que 2 exemples parmi tous les problèmes de répétabilité possibles et imaginables lié à l’analogique.
Je ne dis pas non plus que le numérique a permis de résoudre tous les problèmes de l'analogique... en fait il les a plutôt déplacé.


Citation :
je le reprend en binaire:

91=1011011

22=10110

1011011+10110=1110001=113 en base 10



96=1100000

23=10111

1100000+10111=1110111=119 en base 10

et dans les deux cas, j'ai pas eu besoin de plus de bit pour la somme que pour les valeurs d'échantillons, donc pas d'arrondi


C'est normal que tu ne trouves aucune différence en passant en base 2 : Tu codes des entiers qui ne font pas intervenir d'arrondi.
Pour voir l'effet de la quantification il faut utiliser des valeurs qui tombent entre 2 pas de quantif :
1/3 = 0.3333333333333333.... tombera forcément entre deux puissances 2^-n et la quantification introduira une erreur (il y a réellement un arrondi réalisé).


Ensuite, l'arrondi n'est pas réalisé "par valeur supérieure" ou "par valeur inférieure" mais en "se rapprochant de 0" ou en "s'éloignant de 0", de sorte que les erreurs de quantification sont réparties symétriquement par rapport à 0 et s'annulent.


Exemple : avec un arrondi par valeur supérieure avec 1 seul bit après la virgule (par pas de 0.5, qui va introduire une erreur après différence).
1/3 ≈ 0.5 (c'est la valeur supérieure la plus proche d'1/3)
-1/3 ≈ 0 (c'est la valeur supérieure la plus proche de -1/3)

0.5 + 0 = 0.5 : tu fais une erreur de l'ordre de grandeur du pas de quantification.


Exemple : avec arrondi en s'éloignant de 0, toujours sur 1 bit après la virgule
1/3 ≈ 0.5
-1/3 ≈ -0.5

0.5 + (-0.5) = 0 : les erreurs de quantification se sont annulées.


Ce qu'il faut contrôler aussi c'est que si tu calcules A + B = C et que tu quantifies C≈Cq, il faut t'assurer que quantifier d'abord A≈Aq et B≈Bq puis calculer Aq+Bq te donnera bien Cq : la quantification ne propage pas d'erreur.

En faisant la quantification après :
2/3 + (-1/3) = 1/3 = 0.33333... ≈ 0.5 une fois quantifié.

En faisant la quantification avant :
2/3 = 0.66666... ≈ 1
-1/3 ≈ -0.5
1 + (-0.5) = 0.5


Le calcul en virgule flottante te permet de garantir que les erreurs de quantifications ne s'accumulent pas sur les sommes. Par contre sur les produits, c'est là qu'il y a un sushi :

Si je fais 1/3 * 4 et que je quantifie à la fin :
1/3 * 4 = 4/3 = 1.3333... ≈ 1.5

Maintenant si je quantifie au début :
1/3 ≈ 0.5
4 = 4 (il n'y pas besoin de faire un arrondi pour coder cette valeur)
0.5 * 4 = 2

L'erreur de quantification initiale est multipliée et elle n'est plus de l'ordre de grandeur de la quantification initiale. En clair, les bits de poids faibles du résultat du produit ne sont plus représentatifs de la valeur "réelle" attendue : c'est du bruit, ce qui n'est pas vraiment génial quand tu veux relever le niveau d'un signal un peu faiblard.

Si tu veux retrouver la valeur finale "1.5" précise à 1 bit près, il faudrait coder le 1/3 sur des bits supplémentaires pour garantir que la multiplication par 4 donne une erreur qui reste de l'ordre de grandeur de ce que tu attends en sortie.

En clair, dans le cas d'un fois 4, il faut ajouter 2 bits après la virgule (3 au total) pour garantir un erreur d'1 bit après la virgule sur le résultat après application du gain.


Note que je t'ai fait un cas plutôt simple où le gain est une puissance de 2... Mais dans le cas général, le gain lui aussi présente une erreur d'arrondi que le signal va multiplier. En notant X la valeur réelles, Xq la valeur quantifiée et ErrX l'erreur de la quantification :
G = Gq + ErrG
A = Aq + ErrQ

C = G*A (la valeur que tu voudrais avoir)
Cq = Gq*Aq = (G-ErrG)*(A-ErrA) = G*A - (G*ErrA + A*ErrG) + ErrG*ErrA

ErrC = C - Cq = G*ErrA + A*ErrG - ErrG*ErrA

En supposant que A et G sont quantifiés avec une erreur du même ordre de grandeur "Err"
ErrC ≈ Err*(G+A-Err)

En supposant que G+A est plus grand que l'erreur de quantification (ce qui est un cas normal d'utilisation), G+A-Err ≈ G+A
ErrC ≈ Err*(G+A)

Dans le cas de la virgule fixe, l'erreur sur C n'est plus du tout du même ordre de grandeur que l'erreur sur G et A (elle est multipliée par (G+A)).

Je te donne un exemple avec un gain * signal, mais imagine ce que ça peut donner avec un banc de filtres de plusieurs coefficients les uns à la suite des autres, ou avec une modulation en anneau (ouch).


Avec la virgule flottante, les erreurs de quantifications sont "relatives" et non "absolues". Le nombre de bits après la virgule s'adapte tout seul en fonction de la dynamique et le problème qui consiste à "ajouter des bits de précisions" en entrée pour garantir la précision en sortie se fait tout seul et de façon automatique en répartissant les bits pour la partie entière (la dynamique) et les bits de la partie décimale (précision).

En virgule fixe tu es coincé et amplifier un signal de dynamique faible introduira inévitablement du bruit.

[ Dernière édition du message le 12/07/2011 à 19:34:35 ]

257

j'ai compris tout ça EraTom, et je connais le principe de quantification, là où je ne suis plus Dr pouet, c'est sur le fait qu'une somme de pistes audio (déjà quantifiées) introduise des arrondis.

Je cherche donc à comprendre quand et pourquoi car pour moi, tant qu'on introduit pas de traitements (gain, pan, plugs etc...) y'a pas de requantification, donc pas d'arrondis, mais je me plante peut être. noidea.gif

258
Citation :
une somme de pistes audio (déjà quantifiées) introduise des arrondis.

Oh pardon, j'ai lu en diagonale :oops:

Je vais tenter de faire simple et rapide (j'ai un peu tendance à m'étaler... je m'en rends compte quand j'en arrive au point d'avoir la flemme de me relire :lol:)

D'abord, somme ou différence, le problème est le même (je ne vais donc considérer que la somme).

On va considérer un nombre X coder sur "eX" bits pour la partie entière (avant la virgule) et "dX" bits pour la partie décimale (après la virgule) et je vais noter cette quantification [eX,dX].


Si tu fais la somme de deux nombres C = A+B, le plus petit "pas possible" pour C sera donné par le plus petit pas possible de A ou de B.
En clair dC devra être égale au plus grand parmi dA et dB.

Exemple : A avec dA = 1 bit après la virgule, et que des nombres entiers pour B, dB = 0.
A = 4.5
B = 2
C = 6.5

Donc pour ne pas perdre le 0.5 qui vient de A, il faut que dC soit aussi grand que dA.


Si A et B sont quantifiées avec la même précision, dA = dB. Du coup, pour dC tu ne te poses pas de question puisqu'il faudra que tu prennes dC = dA = dB.

En virgule fixe, si tout est codé avec la même quantif (dA = dB = dC), alors il n'y a pas besoin d'une nouvelle quantification après la somme.
Si les quantif sont différentes, il faudra que C suivent la quantification la plus grande.

En virgule flottante, la virgule de A ne sera jamais, a priori, placée au même endroit que la virgule de B.
Du coup, pour C il faudra systématiquement déterminer où placer la virgule pour ne pas perdre d'info... mais il y a un paramètre de plus à prendre en compte.


Pour l'instant j'ai écarté un problème : la partie entière.

Si A est sur eA bits et B est sur eB bits pour les parties entière, il faut que :
eC = 1+max(eA;eB)
Ajouter 1 bit te permet de doubler l'amplitude, ce qui est le "pire cas".


Avec la virgule fixe, tu ne pourras pas ajouter ce bit : en cas de dépassement tu satures (clipping) et puis c'est terminé. Il faut donc que la DAW laisse un marge d'un bit de poid fort non utilisé et que l'utilisateur n'aille pas rogner cette marge en permanence (c'est la marge rouge affichée).

Avec la virgule flottante, la virgule peut-être déplacée vers la droite au détriment de la précision. Bien sûr, au bout d'un moment tu seras coincé (eC+eD ne peut pas dépasser la capacité du bus), mais la marge avant saturation est bien plus importante.
En déplaçant la virgule vers la droite pour garantir eC, tu limites le nombre bits disponibles pour dC : Au lieu de saturer tout de suite comme c'est le cas en virgule fixe, tu refais une quantification de C après la somme pour avoir la dynamique nécessaire.

[ Dernière édition du message le 12/07/2011 à 20:09:50 ]

259
Houla, EraTom est encore plus bavard que moi. :-D

Citation :
j'ai compris tout ça EraTom, et je connais le principe de quantification, là où je ne suis plus Dr pouet, c'est sur le fait qu'une somme de pistes audio (déjà quantifiées) introduise des arrondis.

Ben c'est l'exemple que j'ai mis plus haut.

Je le refais avec des petits nombres, ça me semble difficile à lire sinon, et c'est sans les bits de signe :

[mantisse 4 chiffres, sans signe] ; [exposant 2 chiffres, sans signe]

1101 ; 00
1000 ; 00

somme exacte =
10101

représentation en flottants avec une mantisse toujours à 4 chiffres (bits):
1010 ; 01

On n'a droit qu'à 4 chiffres. On conserve ceux de poids le plus fort (ceux à gauche: 10101), et on joue avec l'exposant pour que le résultat soit juste (= en déplaçant la virgule).

Mais on a perdu le dernier bit de la somme exact, celui souligné:
10101. Il y a bien eu un arrondi.

D'ailleurs je ne sais pas comment on arrondit en binaire, mais avec l'autre possibilité :
1011 ; 01 il y a aussi un arrondi !

Donc dans les deux cas, une petite perte de précision.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

260

ben oui, ça ok, mais c'est aussi ce que je dit depuis le début, et ce que semble confirmer l'explication de EraTom, cet arrondi est du au fait que la somme sort des capacités de quantification du système (tu es en surmodulation), si ton bus de sommation était à 5 chiffres, tu n'aurais eu aucun arrondie, exactement ce qui s'est passé pour mon test, j'avais x pistes de 24 bit, mais les premiers MSB étaient à 0 (puisque j'avais baisser les niveaux), du coup j'avais la réserve suffisante pour sommer le tout sans perte, et c'est ce qui me semble être systématiquement le cas en pratique, quand on mix un morceau en faisant pas clipper le bus master.

En admettant qu'on est que des pistes de 16 bit, si mes calculs sont exactes, on peut en sommer 256 (2^8) sur un bus 24 bit avant d'être embêté avec le moindre arrondi, et encore, en imaginant que les 256 pistes en question aient toutes au même moment un échantillon de la même valeur, donc en pratique ça sera même certainement plus.

Bref, je crois vraiment qu'on dit la même chose depuis le début, c'est sur la forme qu'on doit pas se comprendre.  noidea.gif