Gain numérique linéaire vs son logarithmique

Il y a de façon inhérente des approximations de calcul en audionumérique, ne serait-ce que pour un gain.

les tests que j'ai effectués étaient surtout pour contredire Dock's qui disait qu'un gain numérique n'ajoute aucun bruit.

un gain numérique n'ajoute aucun bruit

Je n'ai jamais dit que c'était significatif.

L’automation du niveau de volume entraîne un changement de gain, ce qui est une opération nécessairement non neutre.

Également à mes oreilles, j'ai le sentiment qu'un gain numérique n'augmente pas que le volume, mais change la dynamique du son

En numérique tout ceci n'existe plus du tout. Ton STAN manipule des signaux numériques, il n'y as pas d'erreur possible. Pour t'en convaincre, tu n'as même pas besoin de manipuler des signaux audios, tu peux bêtement faire des opérations en Python par exemple, prendre un nombre extrêmement petit et le multiplier par des nombres très grands puis le rediviser tu retomberas toujours sur ton nombre initial.

Ce qui semble t'échapper c'est que le bruit de quantification est déjà là sur ta piste ou ta sine ou peu importe le signal que tu utilises.

Tu veux que je te rappelle les posts ou tu mets ta main à couper que tu entends tout ça parfaitement même en aveugle?

Le soucis c'est que si au début tu étais dans une saine démarche de compréhension, là tu prends de plus en plus le chemin de celui qui ne sera satisfait que lorsqu'on le confortera dans ses certitudes.

A un aucun moment je n'ai lu des arguments qui valident ce sentiment, y compris au travers de tes tests. et c'est le coeur de ton sujet, non pas des approximations inaudibles pour lesquels le qualificatif de "bruit" de quantification a pu t'induire en erreur.

il n'empêche qu'en cours de chemin nous avons soulevé des questions intéressantes non ?

Alex.d re-confirme qu'il y a bien un arrondi avec un gain numérique. Donc qui refuse de changer d'avis ?..

Si le bruit de quantification est déjà sur la forme d'onde, il est annulé lorsque je fais le test en opposition de phase.

Mais pourquoi tant de hargne contre moi ?

Donc oui j'en conviens après mes tests, la dynamique semble énorme avant d'atteindre une quelconque modification du signal qui soit audible

Un arrondi se manifeste dans le signal par de la distorsion... Donc oui ça contredit ce que tu as pu dire

La distorsion dont tu parles c'est le bruit de quantification*, et sa valeur est au maximum d'un demi pas de quantification.
Et en 64 bit float il est à 290dB sous le niveau du signal, quelque soit ce niveau.
Alors je ne sais pas ce que tu entends, mais il est certain que ce n'est pas l'arrondi dû à un gain ou une atténuation dans une STAN...

...* le BDQ est un bruit car il n'est pas corrélé au signal (au dessus de 4 ou 5 bit) mais c'est aussi une distorsion car sa présence dépend de la présence du signal, pas de signal, pas de BDQ.
Contrairement au bruit analogique qui lui sera présent même en l'absence de signal.

Tu peux expliquer ton dernier calcul Alex.d stp, moi y'en a pas parler python

Alex.d que penses-tu de ce plugin ?

https://www.airwindows.com/bitshiftgain/

Citation de DocK'S :

Tu peux expliquer ton dernier calcul Alex.d stp, moi y'en a pas parler python

>>> f"{0.1:.50f}"
'0.10000000000000000555111512312578270211815834045410'


Je force l'affichage de 50 chiffres après la virgule pour 0.1. Visiblement, ça ne fait pas 0.1. Il y a une erreur d'arrondi. Rien de scandaleux : 0.1 n'est pas représentable de façon exacte en format IEE754, tout est normal.

>>> f"{0.1 * 0.1:.50f}"
'0.01000000000000000194289029309402394574135541915894'

Je prends le même 0.1, et je le multiplie par 0.1, et je demande d'afficher le résultat avec 50 chiffres après la virgule. On s'attendrait à ce que ça fasse 0.01, ou à la rigueur 0.010000000000000000555111512312578270211815834045410 (la représentation de 0.1 avec la virgule décalée d'une position), mais non, c'est encore autre chose. Là aussi, rien de scandaleux : 0.01 n'est pas représentable de façon exacte en IEE754, et l'arrondi n'est pas le même que pour 0.1 (les machines comptent en binaire, pas en décimal, donc pas étonnant).

Les machines calculent donc faux ? Oui, elles calculent toujours un peu faux. Mais on ne s'excite pas, le bruit observé ici est à -1500dB. Rappelez-moi le SNR de vos enceintes ? Là on a un bruit au milliardième de pet de mouche (unité SI officielle). Mais formellement, il existe. C'est tout ce que je voulais montrer.

Quand le CPU enchaîne les calculs et que ça reste en registre, il utilise en interne des flottants sur 80 bits (sur x86-64, du moins), avec une mantisse de 64 bits, et donc un bruit de quantification autour de -384dB.

Pour vous donner les résultats de mon expérience : J'ai d'abord comparé 2 sinusoides généré par Operator dans Ableton (donc en 64 bit). Une sinusoide à 0 dbfs et l'autre à -120 dbfs, compensé ensuite par un gain de +120 db et je n'ai rien en opposition de phase !

Mais mais mais... Si je complexifie un peu la chose, et que je met une onde de bruit loopé (la même je précise bien car j'ai dupliqué operator), j'ai quelque chose qui apparait en opposition de phase si ils ont 90db de différence ! Mon master m'indique qu'un son apparaît à -120 dbfs.

Sachant que toutes les autres formes d'ondes, je n'ai rien qui apparait au master.