< Retour vers Techniques du Son

Agrandir

Articles 632 632

Médias 4 983 5k

Tutoriels Tutos 93 93

Forums 17 055 17,1k

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

112 réponses
24 participants
15 983 vues
84 followers

justaudio

Nouvel·le AFfilié·e

Membre depuis 13 ans

Sujet de la discussion Posté le 06/12/2011 à 11:50:33 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

EraTom

2282

AFicionado·a

Membre depuis 13 ans

21 Posté le 08/12/2011 à 07:35:12

Sur un CD, 14 bits, tu as un SNR de 91dB. Si tu arrives à distinguer un bruit de fond ce n'est pas celui lié à la quantification.
Ensuite, tu ajoutes environ 6.5dB de gain sur le SNR pour chaque bits supplémentaires... Oui ça lave plus blanc que blanc.

Anonyme

10074

22 Posté le 08/12/2011 à 08:45:57

Citation :

Petite question théorique (j'suis total newbie dans le domaine), mais si les bruits de quantification de bas niveau se cumule piste a piste, a partir de combien de piste, on pourrait donc théoriquement l'entendre, dans le seuil moyen de l'audition humaine ?

j'en avait déjà parlé dans l'autre filière, mais ce qu'il faut bien garder en tête, c'est que tu ne cumules jamais uniquement le bruit de quantification, tu cumules aussi le signal utile, et le SNR reste donc toujours à peu près du même ordre.

D'ailleur, je suis sûr que Eratom connais les moyens mathématiques d'estimer tout ça, via des stats je suppose?

Sinon, je me suis retenu d'être aussi "cash" que Dr Pouet, mais je suis bien content qu'il l'ai fait, et j'abonde à 200% avec ces posts!

Anonyme

10074

23 Posté le 08/12/2011 à 09:13:10

d'ailleurs y'avait déjà une filière là dessus qui date de ....2006!

https://fr.audiofanzine.com/mastering/forums/t.199891,moteurs-audio-32-bits-64-bits-distinguer-le-vrai-du-faux.html

dans les dernières pages Pov Gabou a écrit deux programmes de comparaison de sommation 64bit float VS 32 bit float et les différences sont en dessous des -144dBfs (plage dynamique du 24 bit) donc pas vraiment dans l'audible.

Dr Pouet

52037

Membre d’honneur

Membre depuis 20 ans

24 Posté le 09/12/2011 à 03:55:12

Citation :

j'en avait déjà parlé dans l'autre filière, mais ce qu'il faut bien garder en tête, c'est que tu ne cumules jamais uniquement le bruit de quantification, tu cumules aussi le signal utile,

On peut aussi dire que généralement les pistes sont peu corrélées entre elles. Par exemple la piste de chant et la piste de grosse caisse sont très peu corrélées.

Plus il y aura de pistes, plus on aura de chances que les erreurs s'équilibrent. Genre parmi 128 pistes, 64 ont une erreur d'arrondi de +1, et 64 autres ont une erreur d'arrondi de -1. Au final : zéro.

C'est une énorme approximation, mais il y a du vrai là dedans.

Si à l'inverse 2 pistes sont corrélées, comme : caisse claire et overhead, on en revient à ce que dit docks : les signaux vont aussi se cumuler. D'ailleurs il est même probable qu'ils se cumulent plus nettement car eux ne sont pas aléatoires, alors que l'erreur d'arrondi reste assez aléatoire.

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

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

DiZ69

3827

Squatteur·euse d’AF

Membre depuis 21 ans

25 Posté le 09/12/2011 à 03:57:07

merci pour les eclairages

justaudio

Nouvel·le AFfilié·e

Membre depuis 13 ans

26 Posté le 10/12/2011 à 14:12:18

Tout d’abord un mea culpa : hors contexte, il y avait en effet un court passage de 1min sur le mixeur 48/56 bits de Pro Tools HD (TDM et non pas HDX) qui empruntait un raccourci prêtant à confusion, comme l’a d’ailleurs souligné ici Docks. Cette partie a donc été rectifiée et la vidéo repostée d’un commun accord avec Gaël.

Après, il est vrai que le fait d’avoir voulu vulgariser puis rendre cette vidéo plus digeste, avec slides et rythme, lui donne un petit côté marketing bien involontaire.

Pour le reste, voici quelques commentaires :
- La discussion était ouverte au Satis ou encore aux Audio Days la semaine dernière. Gaël a été en effet invité tour à tour par Avid et par Audio Addict, et a répondu aux questions posées. Tous les experts et les arguments scientifiques étaient les bienvenus pour contribuer aux différentes discussions fort enrichissantes autour de l’audionumérique.
- On parle ici de système DSP capable de traiter maintenant 768 pistes avec une armada de plug-ins et SANS LATENCE. Il faut donc bien comparer ce qui est comparable et il est bien entendu que Didigesign avait fait tout son possible pour que le moteur audio du Pro Tools HD soit le meilleur possible à l’époque, il y a 9 ans. Cela n’a pas empêché la technologie d’évoluer et, comme le dit si bien Gaël, il faut l’implémenter, même si, en soit, ce n’est qu’une pierre à l’édifice de la production musicale.
- Ne nous méprenons pas non plus, ce n’est pas en si peu de temps que Gaël, ni personne, aurait pu répondre de façon exhaustive sur de tels sujets. Par contre, nous avons pu bénéficier de sa vision pragmatique sur les technologies audionumériques employées et sur les moteurs audio en général.

Ainsi :
- Scientifiquement, des différences existent-elles d’une technologie à l’autre : fix vs float, 32 bits vs 64 bits float? Oui.
- Est-il donc possible que des ingénieurs du son puissent constater une différence audio qualitative entre Pro Tools HD d’un côté et Pro Tools HDX de l’autre? Oui.
- Et plus largement, des différences peuvent-elles exister d’un moteur audio à l’autre? Oui.

D’autre part :
- Au delà de la sommation, existe-t’il une procédure irréfutable de test pour moteur audio, intégrant traitement, automation et sommation? Non.

Donc, il faut expérimenter, partager, et la connaissance de son métier et de ses outils aideront chacun à franchir les limites, comme le dit si bien Gaël. C’est bien ce que nous faisons ici et ce qu’avaient pris le temps de faire DBF et Bénédicte, et maintenant Gaël que je remercie encore.

A bientôt

Aurélien

PS : Cher Dr Pouet, je pense que tout le monde aura apprécié que le talent et la vision se mesurent seulement aux diplômes!

Rickton

656

Posteur·euse AFfolé·e

Membre depuis 16 ans

27 Posté le 10/12/2011 à 14:25:50

Citation :

Ainsi :
- Scientifiquement, des différences existent-elles d’une technologie à l’autre : fix vs float, 32 bits vs 64 bits float? Oui.
- Est-il donc possible que des ingénieurs du son puissent constater une différence audio qualitative entre Pro Tools HD d’un côté et Pro Tools HDX de l’autre? Oui.
- Et plus largement, des différences peuvent-elles exister d’un moteur audio à l’autre? Oui.

D’autre part :
- Au delà de la sommation, existe-t’il une procédure irréfutable de test pour moteur audio, intégrant traitement, automation et sommation? Non.

Heu attention quand même, c'est une démonstration de scientologue ça.

Orienter les questions et tronquer les réponses pour avoir toujours raison et arriver à la conclusion que l'on souhaite, c'est obscurantiste à souhait.

Y'en a un peu marre de ces débats qui orientent les débutants vers des choix inaudibles alors qu'il y a tant à apprendre sur d'autres points.

GaelYvan

Nouvel·le AFfilié·e

Membre depuis 12 ans

28 Posté le 10/12/2011 à 14:33:02

En effet, j’avais essayé de faire ultra simple, mais à trop vouloir vulgariser j’avais fini par trop simplifier. Mea culpa !

Le mixer de ProTools HD TDM (non HDX) utilise une technologie hybride mélangeant à la fois une sommation sur les bus en 48 bits fix ainsi qu'une communication inter module en 24 bits fix. Il y a donc bien les contraintes d'un mixer en pure 24 bits fix de module à module, mais si l'on considère le mixeur dans son ensemble c’est plus complexe que ça et le raccourci était un peu caricatural..

Donc, pour être plus précis : sur un bus, la sommation est calculée en 48 bits dans un accumulateur 56 bits. Grâce à un jeu de décalage de bits, 9 bits sont réservé pour les niveaux au dessus de 0 dBFS donnant un headroom de 54 dB ce qui permet de mélanger théoriquement jusqu'à 250 pistes de son corrélé à +12 dBFS sans saturer le bus. De plus la résolution initiale de 24 bits est préservée jusqu'à une atténuation de 90 dB. Le signal est converti en 24 bits en sortie du sommateur (avec dither cependant) car les bus de communication sont bien en 24 bits fix. Ce qui veut dire que la communication avec les plug-ins, les bus auxiliaires etc... se fait bien en 24 bits fix. Nous perdons donc la résolution de 48 bits dans pas mal de cas ; par exemple, entre chaque plug-in, en utilisant des sous-groupes (bus interne + auxiliaire), les side-chain (Key Input), les auxiliaires de manière générale ou toute autre configuration ou l'on patche un bus sur un autre ; ce qui est très courant dans une session complexe.

La différence majeure avec un mixer 32 bits float (ou 64 bits float) est que l'on garde la résolution maximum tout au long du trajet du signal limitant ainsi au maximum les troncatures et autre bruit de quantification.

Pour ce qui est des erreurs d'arrondies (bruit de quantification) et autres différences entre 32 bits et 64 bits float, dans le cadre d’une sommation ou d’un traitement... le problème est que ces erreurs, mêmes si elles sont "parfois" très faibles ; elles se cumulent car ne peuvent pas toujours être compensé ! Cela finit par s'entendre ! Cela ne veut pas dire que ça ne va pas bien sonner ! mais que les résultats seront différent de ce que l'on pourrait attendre et donc que l'on sera moins précis... De plus dans un filtre (un effet) on peut partir du postulat que l'on va faire une série de calculs bien plus complexe qu'une simple somme et donc ces erreurs peuvent engendrer, par exemple, un problème de stabilité du filtre si l'on ne prend pas garde...

Prenons un exemple simple :

1.01 - 0.993 = 0.017

si l'on regarde le code suivant : en 32 bits float :

Compilé avec le compilateur Intel (v12), avec:
Floating point Model = Precise (/fp:precise)
Executé sur un processeur Intel...

float x = 1.0100000;
float y = 0.9930000;
float res = x - y;

res => 0.017000020 au lieu de 0.017 ! l'erreur est donc 0.000000020 ce qui nous fait: -153.98 dB environ

Jusque-là tout va à peu près bien !
Maintenant, multiplions nos valeurs x et y par un coefficient simple ( 10 ) et divisons le résultat par le même coefficient pour retrouver le même résultat que précédemment :

x *= 10.0;
y *= 10.0;
res = (x - y) / 10.0 ;

res => 0.017000103 au lieu de 0.017 ! l'erreur est donc 0.000000103 ce qui nous fait: -139.74 dB environ

(pour info : multiplication, division etc... par des coefficients sont évidemment chose plus que courante en traitement du signal).

Le même code en 64 bits float (double précision) engendrera une erreur égale à 0.000000000000000006 soit -344.44 dB environ.

Autre exemple : essayons maintenant une sommation de 3 valeurs :

float x = 1.0100000;
float y = 0.9930000;
float z = 0.8270000;

float fres = x + y + z;

res => 2.8299999 au lieu de 2.83 ! l'erreur est donc 0.0000001 ce qui nous fait: -140.0 dB

Maintenant, ajoutons un gain de 6 dB sur chaque valeur puis une réduction de -6 dB sur le résultat comme si nous avions boosté trois pistes de 6 dB puis baissé le master de 6 dB.

float fGain = 1.9952623; // +6 dB
float fGainInv = 1.f / fGain; // -6 dB

x *= fGain;
y *= fGain;
z *= fGain;

fres = (x + y + z) * fGainInv;

res => 2.8300002 au lieu de 2.83 ! l'erreur est donc 0.0000002 ce qui nous fait: -133.98 dB environ !

Le même code en 64 bits float (double précision) engendrera une erreur égale à 0.0000000000000004 soit -307.96 dB environ.

Pour finir un test de sommation "condition mix" pour voir si l'ordre dans lequel on additionne les samples est important et s'il y a des différences importantes (audible) entre 32 et 64 bits float !

Je génère 128 valeurs aléatoires (pour 128 tracks) comprise entre -1.0 et 1.0 puis je les additionne en les prennant dans l'ordre dans lequel je les ai généré. Ensuite je tri mes 128 valeurs par ordre croissant (de leur valeur absolue) et je les additionne en commançant par les plus petites valeurs. Je compare les deux résultats ! Je refais le tout 48000 fois comme si nous avions traité 1 seconde de signal à 48 KHz et ainsi sortir une moyenne sur la seconde !

Compilé avec le compilateur Intel (v12), avec:
Floating point Model = Fast (/fp:fast)
Executé sur un processeur Intel...

Résultat:

//===================================================================================
Difference between sorted and non-sorted sum in 32 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000038146972656250000000000000000000000 => -108.37 dB
MEAN = 0.0000005619600415229797200000000000000000 => -125.01 dB

//===================================================================================
Difference between sorted and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000000000000000000000000000000000000340 => -749.37 dB
MEAN = 0.0000000000000000000000000000000000000000 => -inf dB

//===================================================================================
Difference between non-sorted sum in 32 bit float and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000032186508178710938000000000000000000 => -109.85 dB
MEAN = 0.0000004638123015562693000000000000000000 => -126.67 dB

//===================================================================================
Difference between sorted sum in 32 bit float and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000028014183044433594000000000000000000 => -111.05 dB
MEAN = 0.0000003761090338230133000000000000000000 => -128.49 dB

Le résultat est que en moyenne, nous avons une différence de résultat selon l'ordre dans lequel on a fait la sommation ! On a même des peak qui montre que l'on peut avoir une différence énorme. Ce qui veut bien dire qu'en fonction de la manière dont on fait les calculs en 32 bits float on obtiendra pas le même résultat et que donc potentiellement tout les moteurs de mixage 32 bits float n'aurons pas forcément le même son... Et vu les différences constatées dans cette exemple on peut voir que, en 32 bit float, on peut facilement être loin d'un système idéal... On voit également que la précision du calcul sera bien dépendante de la matière audio (puisque l'ordre de calcul peut influer)... Mais on constate surtout que nous n'avons plus de problème dés lors que l'on travail en 64 bits float... On constate également que l'on améliore le rapport signal sur bruit en 32 bit float en triant les valeurs avant d'en faire la sommation... Biensur, il y a d'autres techniques qui permettent d'améliorer la précision du calcul en 32 bits float... mais tout ceci est très coûteux en CPU... donc quasiment personne ne le fait...

Et voici le graph montrant le bruit entre les deux comparaison 32 / 64 !

Sur 10 secondes ou 1 minute, nous avons exactement la même chose...

Avec 256 valeurs (tracks) le bruit augmente en 32 bit float de plus de 5 dB:

//===================================================================================
Difference between sorted and non-sorted sum in 32 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000076293945312500000000000000000000000 => -102.35 dB
MEAN = 0.0000010352519651254017000000000000000000 => -119.70 dB

//===================================================================================
Difference between sorted and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000000000000000000000000000000000000340 => -749.37 dB
MEAN = 0.0000000000000000000000000000000000000000 => -inf dB

//===================================================================================
Difference between non-sorted sum in 32 bit float and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000059604644775390625000000000000000000 => -104.49 dB
MEAN = 0.0000008595921099185943800000000000000000 => -121.31 dB

//===================================================================================
Difference between sorted sum in 32 bit float and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000044107437133789063000000000000000000 => -107.11 dB
MEAN = 0.0000006586412588755289200000000000000000 => -123.63 dB

Avec:

Floating point Model: Precise (/fp:precise)

on constate une augmentation du bruit de quantification en 32 bits float de entre 5 et 6 dB environ.

Pour 128 valeurs on a :

//===================================================================================
Difference between sorted and non-sorted sum in 32 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000133514404296875000000000000000000000 => -97.49 dB
MEAN = 0.0000011428477979886034000000000000000000 => -118.84 dB

//===================================================================================
Difference between sorted and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000000000000000000000000000000000000340 => -749.37 dB
MEAN = 0.0000000000000000000000000000000000000000 => -1.#J dB

//===================================================================================
Difference between non-sorted sum in 32 bit float and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000115986913442611690000000000000000000 => -98.71 dB
MEAN = 0.0000009411862508083383400000000000000000 => -120.53 dB

//===================================================================================
Difference between sorted sum in 32 bit float and non-sorted sum in 64 bit float
//===================================================================================
Min = 0.0000000000000000000000000000000000000000 => -inf dB
Max = 0.0000079553574323654175000000000000000000 => -101.99 dB
MEAN = 0.0000006874297784330944000000000000000000 => -123.26 dB

Pour les sceptiques, voilà le code (à adapter à vos framework):

// Les statistiques sont calculées en 64 bit pour éviter tout problème de précision sur les stats...

{
CTextFileStream FullLogStream(L"d:\\Log.csv", CFileStream::modeCreate | CFileStream::modeReadWrite | CFileStream::shareExclusive);
CTextFileStream ResLogStream(L"d:\\LogResult.txt", CFileStream::modeCreate | CFileStream::modeReadWrite | CFileStream::shareExclusive);

Math::RandSeed(::GetTickCount());

const long nNumberOfIteration = 48000;
const long nNumberOfValues = 128;

double FloatDiffMin = MAX_f32;
double FloatDiffMax = MIN_f32;
double FloatDiffMean = 0.f;

double DoubleDiffMin = MAX_f32;
double DoubleDiffMax = MIN_f32;
double DoubleDiffMean = 0.0;

double Diff3264Min_A = MAX_f32;
double Diff3264Max_A = MIN_f32;
double Diff3264Mean_A = 0.0;

double Diff3264Min_B = MAX_f32;
double Diff3264Max_B = MIN_f32;
double Diff3264Mean_B = 0.0;

for (long j = 0; j < nNumberOfIteration; j++)
{
float fData[nnumberofvalues];
for (long i = 0; i < nNumberOfValues; i++)
{
fData = Math::Rand(-1.f, 1.f);
}

float FloatRes1 = 0.f;
double DoubleRes1 = 0.0;
for (long i = 0; i < nNumberOfValues; i++)
{
FloatRes1 += fData;
DoubleRes1 += (double)fData;
}

std::sort(fData, fData + nNumberOfValues, Abs_less_than_functor());

float FloatRes2 = 0.f;
double DoubleRes2 = 0.0;
for (long i = 0; i < nNumberOfValues; i++)
{
FloatRes2 += fData;
DoubleRes2 += (double)fData;
}

double FloatDiff = Math::Abs((double)FloatRes1 - (double)FloatRes2);
double DoubleDiff = Math::Abs(DoubleRes1 - DoubleRes2);
double Diff3264_A = Math::Abs(DoubleRes1 - (double)FloatRes1);
double Diff3264_B = Math::Abs(DoubleRes1 - (double)FloatRes2);

FullLogStream.WriteString(ToChar(String::FromFormat(L"%.40f\t%.40f\t%.40f\r\n", Linear2dBClamped((double)FloatDiff), Linear2dBClamped(Diff3264_A), Linear2dBClamped(Diff3264_B))));

FloatDiffMin = min(FloatDiffMin, FloatDiff);
FloatDiffMax = max(FloatDiffMax, FloatDiff);
FloatDiffMean += FloatDiff;

DoubleDiffMin = min(DoubleDiffMin, DoubleDiff);
DoubleDiffMax = max(DoubleDiffMax, DoubleDiff);
DoubleDiffMean += DoubleDiff;

Diff3264Min_A = min(Diff3264Min_A, Diff3264_A);
Diff3264Max_A = max(Diff3264Max_A, Diff3264_A);
Diff3264Mean_A += Diff3264_A;

Diff3264Min_B = min(Diff3264Min_B, Diff3264_B);
Diff3264Max_B = max(Diff3264Max_B, Diff3264_B);
Diff3264Mean_B += Diff3264_B;
}

FloatDiffMean /= (double)nNumberOfIteration;
DoubleDiffMean /= (double)nNumberOfIteration;
Diff3264Mean_A /= (double)nNumberOfIteration;
Diff3264Mean_B /= (double)nNumberOfIteration;

ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(L"Difference between sorted and non-sorted sum in 32 bit float \r\n " ) ;
ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(String::FromFormat(L"Min = %.40f => %.2f dB\r\n", FloatDiffMin, Linear2dB(FloatDiffMin)));
ResLogStream.WriteString(String::FromFormat(L"Max = %.40f => %.2f dB\r\n", FloatDiffMax, Linear2dB(FloatDiffMax)));
ResLogStream.WriteString(String::FromFormat(L"MEAN = %.40f => %.2f dB\r\n\r\n", FloatDiffMean, Linear2dB(FloatDiffMean)));

ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(L"Difference between sorted and non-sorted sum in 64 bit float \r\n " ) ;
ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(String::FromFormat(L"Min = %.40f => %.2f dB\r\n", DoubleDiffMin, Linear2dB(DoubleDiffMin)));
ResLogStream.WriteString(String::FromFormat(L"Max = %.40f => %.2f dB\r\n", DoubleDiffMax, Linear2dB(DoubleDiffMax)));
ResLogStream.WriteString(String::FromFormat(L"MEAN = %.40f => %.2f dB\r\n\r\n", DoubleDiffMean, Linear2dB(DoubleDiffMean)));

ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(L"Difference between non-sorted sum in 32 bit float and non-sorted sum in 64 bit float \r\n " ) ;
ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(String::FromFormat(L"Min = %.40f => %.2f dB\r\n", Diff3264Min_A, Linear2dB(Diff3264Min_A)));
ResLogStream.WriteString(String::FromFormat(L"Max = %.40f => %.2f dB\r\n", Diff3264Max_A, Linear2dB(Diff3264Max_A)));
ResLogStream.WriteString(String::FromFormat(L"MEAN = %.40f => %.2f dB\r\n\r\n", Diff3264Mean_A, Linear2dB(Diff3264Mean_A)));

ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(L"Difference between sorted sum in 32 bit float and non-sorted sum in 64 bit float \r\n " ) ;
ResLogStream.WriteString(L"//=================================================================================== \r\n " ) ;
ResLogStream.WriteString(String::FromFormat(L"Min = %.40f => %.2f dB\r\n", Diff3264Min_B, Linear2dB(Diff3264Min_B)));
ResLogStream.WriteString(String::FromFormat(L"Max = %.40f => %.2f dB\r\n", Diff3264Max_B, Linear2dB(Diff3264Max_B)));
ResLogStream.WriteString(String::FromFormat(L"MEAN = %.40f => %.2f dB\r\n\r\n", Diff3264Mean_B, Linear2dB(Diff3264Mean_B)));
}

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...

Voilà, ce ne sont que de tout petit exemple, très simple ! Cela illustre bien l'intérêt du 64 bits float par rapport au 32 bits float !

Cela ne veut pas dire que nous ne pouvons pas obtenir de bon résultat en 32 bits float mais bien qu'il est beaucoup plus difficile d'obtenir un résultat précis et constant; ce qui n'est plus vraiment le cas en 64 bits float !

Bref, c'est un sujet brûlant sur lequel nous pourrions disserter des heures...

Sinon, j’ai bien dit qu'il est évident que des tonnes d'album ou de film ont été mixés avec succès dans un ProTools TDM, une console SSL ou tout autre système !

Le Matériel importe moins que la qualité de celui qui l'utilise et c'est bien là l'essentiel.

Bien cordialement,
Gael
Flux::

PS: A destination de "Dr Pouet" et "docks":

Vous avez bien raison ; il nous manque des compétences tout au long de notre vie, ce qui nous ammène à devoir étudier constamment !

Je vous invite à venir me rendre visite dans nos bureaux à Orléans. Nous pourrons faire des écoutes comparatives dans notre studio et surtout parcourir mon code et ainsi analyser mon travail ; plus précisément les algorythmes de nos produits : "Solera, Alchemist, Epure, Serie pure, Syrah, Elixir etc..." vous me direz alors s'il s'agit de traitement du signal ou pas ! Je précise que ces produits sont disponible en version d'évaluation sur notre site; vous pouvez donc en evaluer leur qualité.
Vous pourrez également m'ammener votre travail pour me le faire découvrir.

Anonyme

10074

29 Posté le 10/12/2011 à 14:46:10

bonjour aurélien.

Citation :

Scientifiquement, des différences existent-elles d’une technologie à l’autre : fix vs float, 32 bits vs 64 bits float? Oui.

nous sommes, je pense, tous d'accord sur ce point, affirmer le contraire serait soit de la mauvaise fois, soit une méconnaissance totale des différents systèmes.

Mais ces différences technologiques sont connues depuis longtemps, rien de neuf donc.

Citation :

Est-il donc possible que des ingénieurs du son puissent constater une différence audio qualitative entre Pro Tools HD d’un côté et Pro Tools HDX de l’autre? Oui.

là il par contre, il se pose un problème, si sur le papier il existe bien des différences, il faudrait un minimum étayer cette affirmation, avec des tests sérieux (en y allant étape par étape et en commençant par exemple par une simple sommation, avec de plus en plus de pistes).

Il serait ainsi intéressant de quantifier à partir de quand cette différence se ferait entendre à coup sûr, ou du moins avec un résultat statistiquement viable, sinon, ça reste du "blabla".

Personnellement, lorsque j'ai fait les tests comparatifs, j'ai utilisé pas moins de 60 pistes, et à l'arrivée, un nul test entre les différents exports de DAW 32/64 bit flottant s'annulaient parfaitement.

Tout ça pour dire que si on commence à voir apparaître des résidus à -130dBfs (valeur arbitraire pour l'exemple) quand on empile 500 pistes, je me demande alors qui peut être concerné par ça, et surtout, qui sera vraiment en mesure de l'entendre (faudrait-il déjà avoir un système de diffusion capable de retranscrire une telle plage dynamique, et c'est pas gagné), ça impliquerait également un niveau d'écoute démesuré, même dans une pièce avec un niveau de bruit propre extrêmement bas (30dB(A)?), sans compter que le bruit généré par la chaîne d'écoute (amplis, convertos...) serait de toute façon très supérieur à cette valeur même sur un équipement des plus haut de gamme, et je suis pas certain non plus que l'oreille humaine (et même le cerveau) soit capable d'interpréter des informations de si bas niveau.

Citation :

Et plus largement, des différences peuvent-elles exister d’un moteur audio à l’autre? Oui.

sur ce point aussi nous sommes d'accord, sur la précision de l'automation comme dit dans l'interview, sur les valeurs intermédiaires de gain ou de pan, sur la pan law, sur les éventuels dithering, sur les auto-crosse fade, la gestion de la latence etc....

Mais la vrai question c'est:

est il pour autant impossible d'obtenir des résultats identiques sur toutes les DAW, personnellement je pense que non, pas en terme de "son" en tout cas, si on fait abstraction de l'ergonomie ou du côté "affectif" qui fera qu'untel se sentant plus à l'aise avec tel outil arrivera plus facilement au résultat souhaité.

Citation :

Au delà de la sommation, existe-t’il une procédure irréfutable de test pour moteur audio, intégrant traitement, automation et sommation? Non.

je pense le contraire, mais ce genre de test (complet) demande beaucoup de temps et de rigeur par contre.

Citation :

Cher Dr Pouet, je pense que tout le monde aura apprécié que le talent et la vision se mesurent seulement aux diplômes!

je ne crois pas que c'est ce que Dr Pouet a ni dit, ni sous-entendu, seulement qu'il ne suffit pas de présenter quelq'un comme "expert" pour qu'il en soit un, j'ai cité certains memebres dans l'autre filière qui le sont tout autant, mais ont en plus un vrai cursus d'étude, nous avons par exemple Eratom qui nous a rejoint sur cette filière, il me reprendra si je dit une connerie, mais il me semble qu'il est "réellement" expert en traitement du signal et titulaire d'un doctorat, il fait donc au moins autant "autorité" qu'un autodidacte, sans anquer de respect à Gaël dont je ne dout epas des compétences, qui n'occupe sûrement pas son poste par hasard.

D'une manière générale, de toute façon, même si le sujet présente des intérêts (pour sa culture personnelle) ramené à l'utilisation in situ des DAW, on fait clairement dans l'empapaoutage de Lucilia Caesar dans ce débat, vu les rapports signal/bruit dont il est question, déjà largement suffisant pour répondre à nos besoins quotidiens même pour les plus exigeants.

On est en train de s'inventer des problèmes ou des considérations qui n'ont même pas lieu d'être, parce que si on commence à être parano sur le bruit de quantification généré par un traitement 32 bit flottant (ou même 48 bit) alors il faut d'urgence brûler tous les micros et toutes les machines analogiques qui sont en comparaison une vraie catastrophe en terme de bruit, ce qui pourtant ne gêne absolument personne (à tord ou à raison, c'est pas le propos)

Conclusion personnelle:

dormez sur vos deux oreilles quelque soit la DAW que vous utilisez, elle n'est en aucun cas responsable du bon ou mauvais son que vous produisez!

akom

Nouvel·le AFfilié·e

Membre depuis 19 ans

30 Posté le 10/12/2011 à 14:50:57