Se connecter
Se connecter

ou
Créer un compte

ou

Retour sur le moteur audio : 32 vs 64 bits, flottant vs fixe...

  • 112 réponses
  • 24 participants
  • 15 987 vues
  • 84 followers
Sujet de la discussion Retour sur le moteur audio : 32 vs 64 bits, flottant vs fixe...   fusion
Loin de moi l'idée de vouloir relancer un thread qui est bien parti dans tous les sens et je laisse le soin aux modérateurs d’en ouvrir un nouveau si nécessaire.

J’avais promis il y a quelques 400 commentaires plus tôt (!!) d’essayer d’avoir le point de vu scientifique d’un développeur audionumérique tierce partie sur les incidences possibles des évolutions technologiques (48 bits fixe, 32 ou 64 bits float) sur la qualité audio.

Ce fût donc pour moi un immense bonheur de converser avec Gaël Martinet de Flux:: lors du Satis 2011 et on en a profité pour parler de bien d’autres choses…

Voilà, chose promise, chose due.


Aurélien

 

[ Dernière édition du message le 06/12/2011 à 13:26:53 ]

[ Ce message faisait initialement partie de la discussion "In studio with Blanc-Francard & Schmitt" qui a été fusionnée dans ce sujet le 07/12/11 ]

Afficher le sujet de la discussion
91
Citation :
32 bit float: 1 bit de signe, 23 bit de mantisse

Citation :
Si je ne m'abuse, le "0."est implicite dans la mantisse, ce qui rajoute 1 à 2 bits selon la valeur (j'avais fait un petit test de comparaison avec le 24 bits qui montrait bien une différence de 2 bits)

Citation :
Cela dit, la IEEE754 indique quand même 23 bit de mantisse pour le 32 bit flottant.

Je pense qu'il n'y a que ce qui peut apporter de l'information qui est compté. Le 0 du "0." étant fixe, il n'apporte pas d'info et n'est donc pas pris en compte. Il n'est pas non plus stocké puisque ce serait inutile.



Citation de Danguit :
Quelqu'un a déjà comparé ces différences (32/64) avec celles dues par exemple aux tolérances des composants dans la chaîne de conversion numérique-analogique (en se limitant pour commencer au CNA et son filtre) ?

Ce que tu dis va dans le sens de ce que soulignait Docks (mais côté micro et préamps c'est encore pire):
Citation :
N'est-ce pas du coupage de cheveux en 4 quand par exemple on regarde le SNR des meilleurs micros qui sera plus faible d'au moins 40dB?

Ce niveau de bruit n'est-il de toute façon pas plus bas que celui de n'importe quelle chaîne d'écoute?


genirich > on est d'accord ; et c'est bien l'objet du débat.

[ Dernière édition du message le 11/12/2011 à 14:40:22 ]

92
Citation :
Je revient sur le post de Gaël, parce qu'un truc m'interpel:

Pour finir ! Si l'on appliquait maintenant un gain de compensation sur notre somme pour la faire tendre vers le 0 dBFS ; comme si l'on diminait le master fader au lieu de baisser le niveau sur chaque piste. Si l'on considère que les signaux sont tous corrélés nous appliquerons un gain inversement proportionnel au nombre de canaux sommé; soit environ -42.14 dB pour 128 canaux; ce qui repoussera le bruit d'autant ! Malheureusement cela n'est jamais le cas ! Nous ne mixons jamais 128 canaux 100 % corrélé et le gain de correction apporté sera en moyenne beaucoup plus faible d'autant que le niveau des signaux de chaque pistes n'est quasiment jamais à 0 dBFS...

doit on comprendre que dans ton exemple de comparatif, toutes les pistes sont considérées à 0dBfs et que le bruit résultant à -108dBfs est en fait sur un signal dont le niveau crête est à +42.14dBfs?

Non non. Là les nombres sont tirés au hasard, ils ne sont donc absolument pas corrélés.

Un +42dBFS correspondrait au cas extrême où on additionne 128 signaux identiques.
À chaque fois que l'on double le nombre de pistes identiques, le signal augmente de 6dB. Avec 128 pistes identiques, on double le nombre de pistes 7 fois consécutivement : 1 piste, 2 pistes, 4 pistes, 8 pistes... et 7 x 6 dB = 42 dB.
Plus précisément : 7*20log(2) = 42,144199...dB

Du coup, je ne sais pas trop pourquoi Gaël n’obtient pas les mêmes résultats que Gabou.


D'un autre côté, Gabou a procédé différemment : il créée d'abord un tableau de nombres de 64 bits et en fait la somme en 64 bits. Il fait ensuite une copie en 32 bits de ce tableau, et en fait la somme en 32 bits.

[ Dernière édition du message le 11/12/2011 à 22:20:27 ]

93
Le premier 1 est implicite (et non pas 0) l'exposant ramène toujours a une forme
1,xxxx... x 2^yyyy... (sauf en représentation non normalisée)
On ne code donc que les xxxx... et pas le premier 1.
94
Citation :
la résolution pour la sommation à prendre en compte ne serait elle pas de 80 bit flottant dans tous les cas (en natif)

Je ne pense pas. Je pense que celui qui a les idées claires là-dessus c'est Zerosquare.

Voici comment je comprends le truc pour l'instant :
  • il faut imaginer qu'il y a 2 puces utilisées par les logiciels. L'une (M, fonctions de base du microprocesseur) fait les manips de base : transfert d'une case mémoire avec une case du microprocesseur (case appelée registre), tests comparatifs, saut à une autre ligne de code...
  • L'autre (A, coprocesseur arithmétique) ne fait que des calculs mathématiques en flottants. Elle a 2 registres en entrée AE1 et AE2, et un en sortie AS.
  • On peut mettre un nombre dans AE1, et demander sa racine carrée ; elle sera alors disponible dans AS. Calculer une racine carrée demande un sacré paquet de calculs, donc des tas d'additions, multiplications... ce paquet de calculs est fait sur 80bits. Autrement dit, une fois que le nombre a été pris dans AE1, tout se fait en 80bits, jusqu'à ce que le résultat soit remis dans AS à la fin.
  • quelles sont les tailles de AE1 AE2 et AS ? je ne sais pas, probablement 64 bits vu que les cases mémoire sont des octets, et que les registres de M sont en multiples de 8 bits.
  • moralité : à chaque opération, ça commence et ça se termine en 64 ou en 32 bits ; même si pendant l'opération les calculs sont faits sur 80 bits.


Dans le code de Gaël, le calcul est fait ici :
for (long i = 0; i < nNumberOfValues; i++)
{
FloatRes1 += fData;
DoubleRes1 += (double)fData;
}


En 32 bits, c'est précisément ici :
FloatRes1 += fData;

Voici ce que va faire l'ordinateur :
- M va utiliser 2 registres M1 et M2, en 32 bits
- M1 est initialisé à 0

boucle for:
- i vaut 0. La première valeur (float) de fData est copiée de la RAM vers M2
- M1 et M2 sont copiés dans AE1 et AE2 ; il y a alors conversion de 32 vers 64 bits (en gros en ajoutant des zéro pour les chiffres inconnus)
- M demande à A de faire une somme ; elle est faite sur 80 bits
- AS est copié dans M1 ; il y a alors conversion, et donc arrondi de 64 vers 32 bits
- i est incrémenté, et vaut donc 1. On recommence au début de la boucle for, jusqu'à ce que i vaille nNumberOfValues-1

En 64 bits ce serait pareil mais avec des registres M3 et M4 de 64 bits.

Bon c'est peut-être pas exactement comme ça, AE1 AE2 et AS sont peut-être sur 80 bits, mais au final seul un calcul élémentaire est fait sur 80 bits, tandis que les résultats intermédiaires sont stockés sur 64 ou 32 bits. Or la sommation, ou les effets, reposent sur des paquets de calculs intermédiaires. D'ailleurs je pense que la sommation nécessite beaucoup moins de calculs qu'une EQ ou qu'une réverb.


Faudrait que ceux qui savent viennent (Zerosquare, Gaël, guitoo...) faire la correction ! :bravo:
95
Citation :
Le premier 1 est implicite (et non pas 0)
C'est vrai sinon cela n'a aucun sens, mais ma mémoire m'a trahie !

Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet. (G. Courteline)

96
Bon j'ai écrit quelques bêtises (il y aurait 8 registres A sur 128 bits) :
https://fr.wikipedia.org/wiki/Unit%C3%A9_de_calcul_en_virgule_flottante
https://fr.wikipedia.org/wiki/MMX_%28processeur%29
https://fr.wikipedia.org/wiki/Streaming_SIMD_Extensions
https://en.wikipedia.org/wiki/SSE2

Mais je pense que ça ne change pas le fond de l'histoire : stockage des résultats intermédiaires en 32 ou 64 bits. Variables de stockage intermédiaires :

float FloatRes1 = 0.f;
double DoubleRes1 = 0.0;


97
L'architecture Intel c'est pas trop mon domaine. Mais il me semble que tant qu'il y de la place dans les registres de plus bas nivaux les calculs restent en 80 bits. Par contre si il ya une interruption et qu'un autre processus prend la main on perd la précision supplémentaire.

Par contre ça me parait bizarre (et c'est pourquoi je suis absolument pas sur de ce que j'écrit). Ca voudrait dire que le calcul (et donc potentiellement le résultat) peut être différent en fonction des changements de contexte.

[ Dernière édition du message le 11/12/2011 à 15:26:52 ]

98
Je ne suis pas du tout un spécialiste, mais j'ai l'impression qu'il y a des éléments de réponse là : https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

x
Hors sujet :
Edit : je viens d'avoir une promotion ?

Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet. (G. Courteline)

[ Dernière édition du message le 11/12/2011 à 15:36:00 ]

99

Citation :

Du coup, je ne sais pas trop pourquoi Gaël n’obtient pas les mêmes résultats que Gabou.

 

pareil, et aussi les tests pratiques qui vont dans le sens de la conclusion de Gabou.

Alors on pourra me répondre que j'ai testé qu'avec 60 pistes et pas 128, mais si on suit un peu ce qui se passe quand Gaël double le nombre de valeur (de pistes donc) avec une augmentation du bruit de 5/6 dB, on est en droit de penser que dans le cas de mon test de 60 pistes, j'aurait du avoir du BDQ jusqu'à -115/-120 dBfs, hors je n'avait rien du tout à -144.

 

d'ailleur, lors de notre dernière discussion sur la représentation en flottant, j'avais fait un autre test, si je me souviens bien:

- 10 pistes audio x2, les mêmes 10 pistes mises 2 fois (20 pistes au total) avec des gains et pan identiques (mais pas à 0)

- j'ai appliqué des équa et des traitements dynamique sur chacune des premières 10 pistes et j'ai fait un export , appelons le export mix

- j'ai fait un export du second groupe de 10 pistes (celles sans les traitements), appelons le "brut"

j'ai inversé la polarité des pistes brutes et fait un export du tout (10 pistes traitées + les mêmes 10 pistes brutes) ce qui me donne un signal résultant ne correspondant en théorie qu'aux traitements

j'ai ouvert une nouvelle session, j'y ai placé les 3 export, "brut" "FX" et "mix",  j'ai mis l'export "mix" en inversion de polarité et exporté le résultat de la somme des 3 pistes.

tous les exports sont en 32 bit flottant, les pistes source en 44.1/24 bit

 

Premier constat:

cet export est absolument vide, pas un pet de signal

 

second test, j'ai placé uniquement la piste "mix" et la piste "FX" dans une session, j'ai mis "FX" en inversion de polarité et exporté la somme des deux.

En théorie, ça devrait correspondre à l'export "brut"

J'ai placé cet export dans une autre session, avec les 10 pistes source brutes, j'ai mis l'export "brut théorique" en inversion de polarité et exporté la somme des 11 pistes

deuxième constat:

toujours un silence absolu

 

noidea.gif

100
Mouais bon... ces discussion sont sympas parce-qu'on apprend plein de trucs ; d'un autre côté on s'éloigne des questions initiales.


Initialement Aurélien semble faire affirmer à DBF que le mixage en 64 bits float permet pour la première fois d'avoir un résultat parfait.

Déjà ça n'est pas la première fois :
- Sonar le fait depuis longtemps
- tous les autres DAW le font désormais et l'ont fait avant protools HDX

Ensuite il y a la question "est-ce que la différence s'entend ?", avec 3 contextes : protools hd (24/48 bits fixes), 32 float, 64 float.

Pour cela Aurélien nous dit "je vais demander un avis scientifique tiers".

Pour avoir un avis scientifique sur "ça s'entend", il aurait fallu avoir des écoutes comparatives à l'aveugle, tout à fait reproductibles, et avec un protocole comparatif rigoureux. Or cette vidéo (comme l'autre d'ailleurs) ne montre pas de comparatifs d'écoutes ; donc ça ne prouve rien.

Ensuite Gaël nous dit : il y a des différences de calculs entre 32 bits float et 64 bits float. Ça, on veut bien le croire, puisque on le dit depuis 5 ans !
D'après sa simulation à base de nombres aléatoires, similaire à celle de Gabou en 2006, il obtient un résultat différent, avec des erreurs à -108dBFS. Même avec ce résultat, beaucoup plus pessimiste que ceux de Gabou, ou les tests d'annulation de docks, soyons clairs : ça ne va pas s'entendre ! (parce-que -100dB ça fait pas beaucoup, faites l'esai) Déjà ça ne sera pas sur le CD en 16 bits qui sera peu ou pas influencé par ce qui est en-dessous de -96dBFS...

Alors de là à ce que ça s'entende facilement à l'écoute...

Si ça s'entendait facilement, tout le monde serait passé à Sonar quand ils ont sorti leur version 64 bits. Si ça s'entendait facilement, tout le monde s'en serait félicité lors des passages récents des DAW (Logic....) au 64 bits. Or je ne crois pas que ce soit le cas.

Donc jusqu'à preuve du contraire, on peut conclure que toutes les infos que l'on a entre les mains disent que ça ne s'entend pas spécialement.

Après, il y a plein d'autres raisons, probablement bien meilleures, de passer de protools HD à protools HDX.