Retour sur le moteur audio : 32 vs 64 bits, flottant vs fixe...
- 112 réponses
- 24 participants
- 16 944 vues
- 84 followers
justaudio
Rickton
GaelYvan
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
akom
Merci Gael.
Ah oui d'un coup la scientologie et l'obscurantisme en prenne un coup là.
[ Dernière édition du message le 10/12/2011 à 14:53:23 ]
Anonyme
bonjour Gaël, bienvenu et content que tu te joignes à nous pour discuter.
Je commence par la fin et je répond d'abord à ça:
Citation :
Nous pourrons faire des écoutes comparatives dans notre studio
merci pour l'invitation, cependant, pour ce sujet, je n'ai pas fait et ne ferait pas d'écoute comparative, trop subjective, ou alors avec un protocole solide et en double aveugle, mais je préfère le nul test, objectif, et "scientifique"
Citation :
vous me direz alors s'il s'agit de traitement du signal ou pas !
tout d'abord je précise que je n'ai aucune compétence en traitement du signal, et surtout que je n'ai jamais remis en cause les tiennes.
Simplement, nous avons aussi des gens compétents dans ce domaine parmis les membres d'AF, et il semblait que leur discour à eux ne faisait pas autant "autorité" que le tien, ou que nos tests ne semblaient pas assez pertinents face à tes propos.
Sinon par rapport à l'ensemble de ton post, je n'ai pas les compétences pour analyser les codes etc... mais si j'ai bien compris, on a potenciellement du BDQ qui serait aux allentours de -120/-125dBfs avec du 32 bit flottant pour 128 pistes? c'est bien ça?
Si c'est le cas, comment est-il possible que ça soit audible? quel système de diffusion peut prétendre avoir une telle plage dynamique? l'humain est-il "techniquement" capable d'interpréter des informations de si bas niveau?
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?
Et puis, ramené aux 16 bit finaux, est-ce que la différence est toujours là, vue que si les différences sont à -120dBfs, on peut imaginer que les 16 premiers bits sont totalement identiques.
Eratom, qui lui a toutes les compétences pour comprendre l'ensemble de ton post semble dire que déjà sur un CD (sur 16 bit donc) le BDQ est vraiment le dernier de nos soucis en terme de bruit, alors pourquoi d'un coup ça deviendrait gênant à -120dBfs?
Et excuse d'avance, c'est mon côté taquin, mais le coup de la troncature sur un mot de 24 bit qui s'entend, c'était pour déconner hein? 
Et surtout, comment se fait-il que si je somme plus de 60 pistes sur un soft 32 bit flottant, je peux annuler totalement l'export avec celui réalisé dans les mêmes conditions sur un soft 64 bit flottant? (je précise avec des réglages de gain et de pan, donc avec des calculs en 32/64 bit float sur le trajet du signal?
[ Dernière édition du message le 10/12/2011 à 15:58:55 ]
Anonyme
je revient aussi là dessus, parce que ce n'est pas très clair dans la doc du mixer de PTHD TDM:
Citation :
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.
extrait de la doc:
Citation :
Just as EQs, dynamics, and reverbs are plug-ins, the Pro Tools
Dithered Mixer is a plug-in as well. It differs from most other
plug-ins in that it can grow to span multiple DSPs and as it
grows, it passes signal from DSP chip to DSP chip at a full
48 bits instead of dithering and truncating back to 24 bits.
It does so by using two 24-bit TDM timeslots per connection.
This enables the mixer to maintain an internal dynamic range
of at least 288 dB from beginning to end.
de ce que je comprend, les passerelles entre bus sont bien en 24 bit, mais deux sont utilisées à chaque fois pour conserver une quantification de 48 bit, il n'y aurait donc pas de troncature avant la sortie du bus master, ce qui semble précisé dans un autre passage de la doc:
Citation :
dither is added to the 48-bit signal before it
is reduced to 24 bits to be placed back on the TDM bus and
sent to the DACs. Dither is not added on a track by track
basis, as this would produce unwanted accumulated noise.
Dither is only added once at the Master Fader output of the
mix bus so the total system dither noise is 3 dB at -144 dB
??? 
GaelYvan
Anonyme
ok je comprend, merci.
Mais n'est ce pas là aussi un faux problème quant à la qualité sonore?
Même si on fait ça plusieurs fois sur un mix disons chargé et complexe, cela va-t-il vraiment être audible vu le SNR dont il est question, même en 24 bit?
Si tu as un peu de temps pour répondre à mes autres questions (voir les posts au dessus) ça serait intéressant pour tout le monde je pense.
Une dernière chose, je viens de revoir la vidéo, merci d'abord d'avoir fait le correctif, et aussi je précise que même si il reste quelques points pas éclaircis ou "désaccord" sur ces histoires de résolution, je ne peux qu'être à 200% d'accord avec une grande partie de ton discours, notamment sur le fait que quelque soit la techno ou les performances de l'outil, ce ne sont que des outils et que la grande différence se fait au niveau de l'interface chaise/clavier, c'est probablement un truisme, mais les proffesionnels tenant ce discours sont finalement assez rare (on nous vend bien souvent du rêve et de la magie) pour que ça mérite d'être souligné. 
GaelYvan
C'est toujours un plaisir de discuter; malheureusement je n'en ai pas souvant le temps.
tout d'abord je précise que je n'ai aucune compétence en traitement du signal, et surtout que je n'ai jamais remis en cause les tiennes.
Simplement, nous avons aussi des gens compétents dans ce domaine parmis les membres d'AF, et il semblait que leur discour à eux ne faisait pas autant "autorité" que le tien, ou que nos tests ne semblaient pas assez pertinents face à tes propos.
Je n'ai pour ma part pas perçu les choses comme cela. Personne ne m'a demandé de venir contredire qui que ce soit sur AF mais juste de répondre à une série de questions, lors d'un salon, au sujet du développement de plug-ins et de l'audio-numérique en général et ce à l'occasion de la sortie de nouvelles cartes DSP. Rien de plus. Il se trouve que j'ai un peu d'expérience en la matière et c'est certainement pour cela que l'on m'a demandé de participer. Je ne vois pas en quoi cela pourrait remettre en cause les compétences de quelqu'un d'autre et, dieu sait qu'il y a bien d'autre personne plus compétente que moi. Je crois qu'il faut se simplifier la vie et voir les choses de manière positive. Je suis cependant d'accord qu'il faut toujours garder un oeil critique sur le discour d'un constructeur, y compris le miens, et ce faire son propre avis selon ces oreilles et ces compétences (ou l'inverse).
mais si j'ai bien compris, on a potenciellement du BDQ qui serait aux allentours de -120/-125dBfs avec du 32 bit flottant pour 128 pistes? c'est bien ça?
oui, dans cet exemple de sommation.
Si c'est le cas, comment est-il possible que ça soit audible? quel système de diffusion peut prétendre avoir une telle plage dynamique? l'humain est-il "techniquement" capable d'interpréter des informations de si bas niveau?
l'humain est étonnant
comme je le disais, une partie importante de la perception d'espace, profondeur, transparence etc... se fait grâce au bas niveau. Cela va bien évidement dépendre de chacun ainsi que des conditions d'écoute. Sur un petit ghetto blaster on n'entendra pas la même chose que sur une écoute à 50K€, calibré, dans une pièce acoustiquement adapté ! On ne cherchera pas non plus à écouter la même chose ou de la même manière. Le but diffère...Mais le sujet n'est pas là ; il s'agit dans notre cas de comprendre et ainsi choisir les technologies à utiliser pour créer des machines les plus précise et transparente et ainsi de permettre à l'ingénieur du son de réaliser son travail comme il l'entend. Notre console de mixage doit pouvoir nous permettre de mélanger au mieux tous les signaux; respecter chaque piste même si celle-ci contient une matière capté avec un micro à faible rapport signal sur bruit. Ca matière est aussi importante dans le mix qu'une autre avec un son ultra pure.
Nous pourions également étendre ce débat à un préampli micro par exemple ou un convertisseur... et continuer à débattre pendant des heures pour savoir s'il y a un intérêt à cette quête de qualité.
Ensuite je pense personnellement qu'il y a bien un intéret pour l'ingénieur du son à comprendre les différentes technologies afin de pouvoir utiliser au mieux les machines qu'il aura à sa disposition.
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?
Oui, c'est du coupage de cheveux en 4 ! Mais n'est-ce pas ce que l'on attend d'un constructeur de matériel ? Qu'il essai de fournir le meilleur possible ?
Ce niveau de bruit n'est-il de toute façon pas plus bas que celui de n'importe quelle chaîne d'écoute?
Et puis, ramené aux 16 bit finaux, est-ce que la différence est toujours là, vue que si les différences sont à -120dBfs, on peut imaginer que les 16 premiers bits sont totalement identiques.
Chaque étape est importante afin d'obtenir la meilleur qualité possible avant de dégrader le tout dans un format inférieur en qualité. Le dithering appliqué pour passer en 16 bits par exemple dépendra du signal et donc nous n'aurons pas forcément les mêmes réultats... C'est comme un cuisinier qui souhaiterait préparer des plats sous vide à réchauffer au micro-onde. Doit-il soigner la qualité de son plat ou peut-il considérer que le fait de le réchauffer, en plus au micro-onde, va tellement le dégrader qu'il n'est donc pas nécessaire de bien le préparer ? La qualité du plat dépendra également des produits que l'on choisira, par rapport à la clientèle visé...
Je pense que tout ceci est une question d'exigence et que l'on a tout à gagner à travailler sur la qualité. Nous cherchons, tous ensemble, à créer un système qui nous permet de respecter la moindre nuance d'un artiste et c'est bien là l'essentiel.
Pour finir je concluerais que tout dépend du résultat que l'on veut obtenir et des moyens que l'on se donne pour y arriver. Bien évidemment il est important de souligner qu'aucun constructeur ne fourni de baguette magique et qu'il faut donc, avant tout, faire confiance à ces oreilles et mettre le paquet sur le principale: l'artistique.
Bon Week-End
Gael
Flux::
Anonyme
Citation :
Je n'ai pour ma part pas perçu les choses comme cela. Personne ne m'a demandé de venir contredire qui que ce soit sur AF mais juste de répondre à une série de questions
j'aurais du préciser, mais ce n'était par rapport à toi que je parlais, mais plus par rapport aux premiers post d'Aurélien sur le sujet dans l'autre filière ou on avait un peu l'impression qu'il nous disait gentilment que ce qu'on expliquait (pourtant étayé avec des documents des éditeurs, le discours de gens compétents dans le domaine et des faits= tests) ne valaient pas grand chose.
Citation :
l'humain est étonnant
étonnant, je veux bien le croire, au point de pouvoir clairement interpréter un signal à -120 dBfs, noyé dans disons 20dB de bruit (au mieux) de la chaîne de diffusion et qui obligerait d'avoir un niveau d'écoute bien au delà de ce que put supporter l'oreille humaine sans douleur, là j'ai plus de mal par contre.
Comme ça, si on prend une pièce avec un niveau de bruit propre très bas de 30dBa par exemple, et qu'on ai une chaîne de diffusion ultra haut de gamme qui sort du 120dB de SNR (est-ce que ça existe?) ça ferait déjà un niveau d'écoute de 150dBa pour espérer que ces détails sortent des enceintes, à mon avis, à ce niveau, tu te jettes rapidement sur le potard de volume avant de te poser la question de ce que tu entends ou pas.
Bref, je vois pas comment de si bas niveaux peuvent même simplement être diffusés à niveau d'écoute acceptable. 
Sinon, je ne remet pas en cause la démarche de tirer le meilleur de la techno disponible, juste le fait de conclure que ça apporte une plus value sonore certaine, là j'ai beaucoup plus de mal à le croire, et les quelques tests (pas d'écoute hein 
) que j'ai fait sur différentes DAW me donnent raison.
Citation :
Le dithering appliqué pour passer en 16 bits par exemple dépendra du signal et donc nous n'aurons pas forcément les mêmes réultats...
ça c'est encore un autre sujet, mais l'intérêt du dithering sur les mix tel qu'on les fait aujourd'hui, et les mastering à burne tout le long, ça me paraît aussi utile que d'invoquer les esprits pour faire pleuvoir.
On reste dans cette démarche de qualité optimum, certe, mais raméné à la réalité des pratiques de productions et surtout des pratiques d'écoute de la majorité du publique (c'est quand même pour l'auditeur qu'on fait tout ça au final), tu vois ce que je veux dire....
[ Dernière édition du message le 10/12/2011 à 17:12:53 ]
Dr Pouet
Anonyme
ha deux choses encore pendant que t'es là (tu réponds quand tu as le temps, pas de soucis)
Tu parles à un moment de travailler à la plus haute FE possible, n'est ce pas là aussi un raccourci un peu vite pris?
Déjà, au niveau du convertisseur, c'est loin d'être aussi évident, il y a d'abord le théorème de Shannon et Nyquist qui nous dit qu'on a absolument tout ce qu'il faut et sans distorsion dès lors que la FE est égale au double de la bande passante, donc suivant cette théorie, on est déjà tranquil à 44.1.
Dans la pratique, je crois que Danguit avait fait quelques tests qui montraient qu'autour de la fréquence de ocupure, ça n'était pas aussi idéal que la théorie le dit, soit, mais faut-il pour autant échantillonner à 192kHz?
Dan Lavry a beaucoup écrit sur le sujet, et selon lui passer 60kHz, il n'y a plus aucun apport, pire, on perd en résolution lorsqu'on augmente la FE.
De même en interne pour les traitements, je veux bien croire que pour l'équa, les plugs amenant de la distorsion, le time stretching etc....il y a un intérêt à travailler au dessus de 44.1, mais est-ce que 88.2 ne serait pas largement suffisant?
Désolé de paraître tatillon, mais une grosse partie des lecteurs a quand même un profil "débutant" pour qui toutes ces notions sont un peu flou, et ils auraient vite fait de prendre ce discours pour argent comptant, et de vendre leurs organes pour s'acheter une configue capable de faire du 192kHz du début à la fin.
Et le dernier point, tu parles à un moment de l'importance de l'horloge interne.
A quoi fais tu allusion? peux tu nous en dire plus car je n'ai pas trop compris.
Pour moi (et plein d'autres, dont encore une fois Dan Lavry) la seule et unique horloge qui nous intéresse en audio est celle du converto, c'est la seule qui cadence l'audio vu que le reste du temps (en interne donc) on est pas en temps réel, dans le cas contraire, il me semble que l'export offline serait impossible par exemple.
Rickton
Anonyme
Citation :
En tout cas je suis rassuré, les calculs de Gael m'assurent que tant que je n'ai pas 128 pistes à mixer sur un système d'écoute à 50k€ dans une chambre sourde avec des oreilles de chauve-souris, je n'ai pas besoin d'investir dans le 64 bits.
ben blague à part, c'est un argument qui revient souvent quand il s'agit de comparer différents matériels, je vise pas Gaël en particulier, mais le nombre de fois ou on m'a sorti que j'étais sourd, ou que mon matos était trop pourri pour entendre ce que eux entendent clairement (et des fois y'avait rien à entendre, vu que les signaux comparés s'annulaient
), je les compte même plus, mais au final, si il faut effectivement une pièce avec un traitement à 10 000$ le m², des convertos à 10 000$ les deux canaux, et des écoutes à 50 000$, ça tente quand même sérieusement à prouver que personne ne fait la différence, en tout cas pour 99.999999999 (désolé je suis qu'en 32 bit float, faut que j'arrondisse 
) % de la population mondiale.Anonyme
Citation :
Les explications de Pov Gabou (scientifique et développeur en audio ; docteur es sciences je crois), les explications de Robert Henke (développeur chez Ableton)... et eux disaient le contraire de ce que tu sembles affirmer (sans l'écrire clairement d'ailleurs) :
leur point de vue était qu'il n'y a pas de différences suffisamment audibles pour préférer un moteur audio à un autre.
pour Pov Gabou, c'est même pas que c'est pas suffisamment audible, c'est que c'est pas près de l'être
Citation de Pov Gabou :
Me suis amuse a faire un petit programme en python qui calcule la difference max et en moyenne entre le summing en 32 bits et 64 bits:
Citation :
#! /usr/bin/env python
# Last Change: Mon Oct 30 01:00 PM 2006 J
import numpy as N
n = int(1e5)
dbd = -80
# A is double, between -1 and 1 (0dB)
A = 2*N.random.rand((n))-1
# B is double, between -1e-4 and 1e4
B = (2*N.random.rand((n))-1) * 10 ** (dbd/20)
S = A + B
powerA = N.sqrt(N.sum(A**2)) * 1./n
powerB = N.sqrt(N.sum(B**2)) * 1./n
print "Real db Diff (power) is %f" % (20*N.log10(powerA/powerB))
A32 = N.float32(A)
B32 = N.float32(B)
S32 = A32 + B32
# numpy broadcast to 64 bits automatically, so the difference is done
# in 64 bits
diff = S32 - S
powerdiff = N.sqrt(N.sum(diff ** 2)) * 1./n
maxdiff = N.max(N.abs(diff))
print "average diff of dynamic compared to bigger signal (0 dB) is %f" % (20*N.log10(powerdiff))
print "worse dynamic compared to bigger signal (0 dB) is %f" % (20*N.log10(maxdiff))
Et ca me donne autour de 220 dB de dynamique pour la difference entre 32 bits et 64 bits summing, et la pire valeur sur 100000 echantillons est encore a 144 dB.
Et comme je suis motive, j'ai fait la meme chose en C, pour essayer de plus grosses valeurs et pour que tout le monde puisse essayer (attention, c'est programme a la hache, donc ca prend pas mal de memoire. Sur mon pc du labo, j'ai 2 Go de ram avec 3 de swap, le programme doit consommer autour de 10^7 * 8 * 8 octets, ce qui fai en gros 640 Mo).
Citation :
/*
* Last Change: Mon Oct 30 01:00 PM 2006 J
*
* Small test to see pratical difference beween summing in 32 and summing in 64 bits
* on the platform where this program is run
*/
/*
* For ISO C, all floating functions are for double by default.
* If they have the suffix f, they are float
*/
/* For FLT_ constants */
#include <float.h>
/* for drand48 (SVID standart) and exit */
#include <stdlib.h>
/* for log10 */
#include <math.h>
#include <stdio.h>
int do_compare(size_t nelements, double dbd);
int generate_signals(double *in, double *in2, size_t nel, double dbdiff);
int lev2dB(double ref, double val, double* ret);
double db2coeff(double dblev);
double avdbdiff(const double* ref, const double* val, size_t nel);
double avdbref(const double* in, size_t nel, double ref);
double mindbref(const double* in, size_t nel, double ref);
long double power(const double*in, size_t nel);
int sum32(const float* in1, const float* in2, float* out, const size_t n);
int sum64(const double* in1, const double* in2, double* out, const size_t n);
int diff64(double* inout, const double *in2, size_t nel);
int double2float(const double* in, float *out, size_t nel);
int float2double(const float* in, double* out, size_t nel);
/* alloc or die */
void* xmalloc(size_t n);
/* Not sure about precision, but should not matter, since
* it is used only for db computation*/
double exp10(double in)
{
return exp(in * log(10));
}
/* Entry point */
int main(void)
{
int status;
size_t nel = 10000000;
double dbdiff = -80;
status = do_compare(nel, dbdiff);
if (status < -1) {
fprintf(stderr, "Error while comparing...n");
return -1;
}
return 0;
}
int do_compare(size_t nel, double dbd)
{
double *a, *b, *s, *s64;
float *a32, *b32, *s32;
int status;
double sumdbdiff;
/*
* Allocations
*/
a = xmalloc(sizeof(*a) * nel);
b = xmalloc(sizeof(*b) * nel);
s = xmalloc(sizeof(*s) * nel);
a32 = xmalloc(sizeof(*a32) * nel);
b32 = xmalloc(sizeof(*b32) * nel);
s32 = xmalloc(sizeof(*s32) * nel);
s64 = xmalloc(sizeof(*s64) * nel);
srand48(time(0));
/*
* Generate test signals
*/
status = generate_signals(a, b, nel, dbd);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
/*
* Make a copy of test signals into 32 bits buffers
*/
status = double2float(a, a32, nel);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
status = double2float(b, b32, nel);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
/*
* Do the summation in 32 bits
*/
status = sum32(a32, b32, s32, nel);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
status = float2double(s32, s64, nel);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
/*
* Do the summation in 64 bits
*/
status = sum64(a, b, s, nel);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
/*
* Compute the difference (in 64 bits) (in place into s)
*/
status = diff64(s, s64, nel);
if (status) {
fprintf(stderr, "%s:%s, %d errorn", __FILE__, __func__, __LINE__);
exit(EXIT_FAILURE);
}
/*
* Compare the results
*/
sumdbdiff = avdbref(s, nel, 1.0);
printf("average db diff between 32 bits summing and 64 summing is %fn", sumdbdiff);
sumdbdiff = mindbref(s, nel, 1.0);
printf("worse db diff between 32 bits summing and 64 summing is %fn", sumdbdiff);
#if 0
#endif
/* Those free are just for checking under valgrind */
free(a);
free(b);
free(s);
free(a32);
free(b32);
free(s32);
free(s64);
return 0;
}
/* compute the power of in: 1/nel * sqrt(sum(in ** 2)) */
long double power(const double*in, size_t nel)
{
long double acc = 0;
size_t i;
for(i = 0; i < nel; ++i) {
acc += in[i] * in[i];
}
return sqrtl(acc) / nel;
}
int diff64(double* inout, const double *in2, size_t nel)
{
size_t i;
for(i = 0; i < nel; ++i) {
inout[i] -= in2[i];
}
return 0;
}
/* Generate (uniform) random signals in and in2. in2 has dbdiff dB difference on average
* compare to in1, and in1 is normalized in the range [-1, 1] */
int generate_signals(double *in1, double *in2, size_t nel, double dbdiff)
{
size_t i;
double amp = db2coeff(dbdiff);
for(i = 0; i < nel; ++i) {
in1[i] = 2 * drand48() - 1;
in2[i] = amp * (2 * drand48() - 1);
}
printf("Asked level is %f, real level on average is %fn", dbdiff, avdbdiff(in1, in2, nel));
return 0;
}
/* Convert a and b content to 32 bits and put the results into a32 and b 32.
* I am not sure about the correct way to do the convertion... */
int double2float(const double* in, float *out, size_t nel)
{
size_t i;
for(i = 0; i < nel; ++i) {
out[i] = (float)in[i];
}
return 0;
}
int float2double(const float* in, double* out, size_t nel)
{
size_t i;
for(i = 0; i < nel; ++i) {
out[i] = (double)in[i];
}
return 0;
}
/* give the *average* db level compared to a reference 0 dB */
double avdbref(const double* in, size_t nel, double ref)
{
long double pow;
double dbl;
pow = power(in, nel);
lev2dB(ref, (double)pow, &dbl);
printf("ref is %10e, pow is %10e, level is %fn",
ref, (double)pow, dbl);
return dbl;
}
/* give the min db level compared to a reference 0 dB */
double mindbref(const double* in, size_t nel, double ref)
{
double maxval;
double tmp;
double dbl;
size_t i;
maxval = 0;
for(i = 0; i < nel; ++i) {
tmp = fabs(in[i]);
if ( tmp > maxval) {
maxval = tmp;
}
}
lev2dB(ref, maxval, &dbl);
printf("ref is %10e, max is %10e, level is %fn",
ref, maxval, dbl);
return dbl;
}
/* give the *average* db difference between two signals */
double avdbdiff(const double* ref, const double* val, size_t nel)
{
long double pow1;
long double pow2;
double dbl;
pow1 = power(ref, nel);
pow2 = power(val, nel);
lev2dB((double)pow1, (double)pow2, &dbl);
printf("pow1 is %10e, pow2 is %10e, dbdiff is %fn",
(double)pow1, (double)pow2, dbl);
return (dbl);
}
/* put the db value with reference level ref into ret
* return 0 on success, -1 otherwise */
int lev2dB(double ref, double val, double* ret)
{
if (fabs(val) < DBL_EPSILON || val < DBL_MIN) {
fprintf(stderr, "%s:%s, line %d, val (%f) is below epsilon or negativen",
__FILE__, __func__, __LINE__, val);
return -1;
}
*ret = 20*log10(ref / val);
return 0;
}
/* given a dB level difference, returns the amplitude coeff */
double db2coeff(double dblev)
{
return exp10(dblev / 20.);
}
/* sum in 32 bits */
int sum32(const float* in1, const float* in2, float* out, const size_t n)
{
size_t i;
for(i = 0; i < n; ++i) {
out[i] = in1[i] + in2[i];
}
return 0;
}
/* sum in 64 bits */
int sum64(const double* in1, const double* in2, double* out, const size_t n)
{
size_t i;
for(i = 0; i < n; ++i) {
out[i] = in1[i] + in2[i];
}
return 0;
}
void* xmalloc(size_t n)
{
void* tmp;
tmp = malloc(n);
if (tmp == NULL) {
fprintf(stderr, "Error while allocatingn");
exit(EXIT_FAILURE);
}
return tmp;
}
qui me donne encore une fois autour de 220 dB en moyenne et 141 dB dans le pire des cas sur 10^7 tirages. Je pourrais essayer plus si je me faisais chier a bufferiser au lieu de tout allouer en une fois, mais j'ai pas que ca a foutre non plus
Bref, a moins que je me sois plante quelque part (ce qui n'est pas impossible dans le code C, mais dans le code python, je pense pas trop), le fait que les calculs internes soient faits de toute facon en 80 bits sur un proc intel meme avec des valeurs d'entree/sortie en 32 bits fait qu'on garde bien une precision tres bonne avec du 32 bits, et ce meme dans un cas vraiment extreme (mixage de deux pistes avec 80 dB de difference).
j'ai pas les compétences pour comparer avec le post de Gaël, mais je note quand même que les conclusions sont un peu contradictoires.
DiZ69
Zerosquare
Dr Pouet
Anonyme
vu le nombre de fois ou on a posté cette doc, c'est sûr qu'on peut difficilement nous accuser d'être anti-avid, tout le monde va finir par la connaitre par coeur.
Par contre, par rapport au post de Undo, tu as historiquement raison Dr Pouet, mais pour la suite, Undo est quand même dans le vrai, je pense que digi s'est un peu endormi sur son TDM pendant qu'en face, en natif, on avait de vrais évolutions.
Le protools LE était quand même à la ramasse sur pas mal de points comparé à la concurrence, et ça fait pas bien longtemps qu'ils se remettent à jours sur des trucs pourtant basiques et présents ailleurs depuis belle lurette (compensation de la latence, le midi, l'ouverture aux interfaces tierces, limitation du nombre de pistes, le 32 bit float en format de fichiers etc....) ça ne lui enlève pas ses qualité, mais il était quand même pas mal à la traîne sur pas mal de point.
Dr Pouet
scare
Anonyme
Dr Pouet
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
Tout à fait.
Mais il ne faut pas s'attendre à ce que nous n'ayons pas nous aussi du recul, de l’expérience, ni des connaissances. Il ne faut pas s'attendre non plus à ce que nous prenions pour argent comptant les points de vue d'Avid ou Flux ; ce serait les ériger en arguments d'autorité.
Ce qui compte, et ce qui nous intéresse, ce sont les arguments concrets (et rigoureux ou scientifiques).
Bien évidemment, de notre côté nous pouvons aussi nous tromper.
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.
Oui. Et même si j'ai été un peu "hérissé" par le "petit côté marketing bien involontaire", et que je réagis donc un peu vivement, j'en profite quand même pour souligner qu'il est hyper appréciable, pour moi, et sans doute pour beaucoup d'AFiens, de pouvoir recueillir ainsi vos points de vue, et de pouvoir échanger avec vous.
Donc le plus important :
Par contre, par rapport au post de Undo, tu as historiquement raison Dr Pouet, mais pour la suite, Undo est quand même dans le vrai, je pense que digi s'est un peu endormi sur son TDM pendant qu'en face, en natif, on avait de vrais évolutions.
Le protools LE était quand même à la ramasse sur pas mal de points comparé à la concurrence, et ça fait pas bien longtemps qu'ils se remettent à jours sur des trucs pourtant basiques et présents ailleurs depuis belle lurette (compensation de la latence, le midi, l'ouverture aux interfaces tierces, limitation du nombre de pistes, le 32 bit float en format de fichiers etc....) ça ne lui enlève pas ses qualité, mais il était quand même pas mal à la traîne sur pas mal de point.
Certes. Mais ça demande quand même un travail titanesque de faire des évolutions importantes qui remettent en question de larges pans de la conception initiale d'un logiciel très gros et très complexes.
Mon métier consiste à participer à la maintenance évolutive de logiciels interconnectés dont l'ensemble constitue entre 8 et 16 millions de lignes de code. Ce ne sont pas les bonnes volontés qui manquent, mais des modifications transverses demandent une énergie et donc un temps beaucoup plus grand que ce que l'on pourrait penser quand on ne fait pas ce genre de métier.
Il y a un fameux livre là-dessus : le mythe de l'homme-mois.
[ Dernière édition du message le 10/12/2011 à 18:50:50 ]
scare
Hors sujet :
Pour finir ma pub lol, logic est a 149 Euros depuis décembre.
---EDITÉ---
Construction du nouveau studio
Visitez le site THD STUDIO / page FB THD Studio
Dossier : Conversion analogique-numérique (pour les courageux)
- < Liste des sujets
- Charte