Se connecter
Se connecter

ou
Créer un compte

ou

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

  • 112 réponses
  • 24 participants
  • 15 738 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 "Commentaires sur le dossier : In studio with Blanc-Francard & Schmitt" qui a été fusionnée dans ce sujet le 07/12/11 ]

Afficher le sujet de la discussion
41

 

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.

 

42

 

 

43
De toute façon, pour avoir une réponse définitive, il faudrait faire un test de comparaison en double aveugle, moteur audio en 32 bits vs exactement le même mais en 64 bits (je ne sais pas si c'est possible facilement ; même en prenant des versions succesives d'un même DAW, pas dit que ça soit le seul truc qui ait été modifié en interne).

N'empêche que je suis d'accord avec la plupart de ceux qui ont répondu : même dans le cas du calcul, qui représente un nombre de pistes déjà élevé, on a une différence qui se situe aux alentours de, quoi, -100 dB ? Ça me paraît irréaliste de penser que la différence puisse être audible (et quand bien même quelqu'un arriverait à entendre la différence, c'est très en dessous de tous les aléas incontrôlables introduits par le reste de la chaîne audio).

Bref pour moi, les moteurs audio sont passés en 64 bits parce que les processeurs actuels sont capables de traiter du 64 bits flottants rapidement (SSE2, etc.), et parce que ça fait bien sur la plaquette commerciale, c'est tout.

[ Dernière édition du message le 10/12/2011 à 17:47:16 ]

44
Citation de Aurélien :
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.

Pour le coup, j'abonde dans ton sens. Déjà ça me donne l'occasion de préciser que je n'ai rien contre toi ni Avid ni Digidesign. C'est juste qu'il y a des arguments avec lesquels je ne suis pas d'accord, ce que je ne me priverai pas de dire !

Par rapport à la "pique" suivante, je vais dire pourquoi je la trouve injuste :
Citation de undo :
je n'utilise pas pro-tools, mais j'ai toujours l'impression que ce qui est présenté comme innovation sur cette daw est déjà de l'ordre de l'aquis pour les concurents (!?)
est-ce moi ou la réalité ? pas là pour la polémique mais pour que mes doute soient confirmés

D'abord historiquement Protools n'est pas un suiveur mais au contraire l'initiateur. Du temps où les ordinateurs personnels n'étaient pas assez puissants pour gérer autre chose que du midi, Digidesign est arrivé avec un système capable de le faire. Pour y parvenir, il a fallu ajouter des DSP externes. Ces DSP étaient en virgule fixe car la virgule flottante n'était pas si répandue que ça à l’époque, ces circuits étaient couteux...
Rappelez-vous : sur un PC 386 le coprocesseur arithmétique était un composant séparé, sur le 486 c'était une option (486SX = sans copro ; 486DX = avec copro). C'est ce copro qui permettait de faire les calculs en flottants avec des circuits électronique plutôt que dans le logiciel, d'où un gain énorme de perfos en flottant. Et ces copros de PC étaient très très peu puissants par rapport à des DSP.

Donc Protools a été le premier à populariser les DAW. Ensuite, une fois que clients et constructeurs ont investi dans une technologie (hybride natif + DSP, le tout en virgule fixe), il est compliqué de changer, surtout en conservant la compatibilité (on veut conserver ses sessions, ses plugins...), et il faut que le coût du changement apporte une amélioration en rapport. Face à une solution en 32 bits flottants, la solution 24/48bits fixe de Protools donnait déjà des résultats extrêmement satisfaisants (verra-t-on des tests où des gens font facilement la différence ? j'en doute), donc il n'y avait pas urgence à changer, loin de là.

Voilà pourquoi je pense que c'est un peu erroné et très exagéré de présenter les choses comme ça.


Un autre point me vient à l'esprit en faveur de Digidesign, c'est le fait d'avoir pris le temps d'expliquer précisément et clairement des points techniques, comme le fonctionnement des bus internes et de la sommation.
On trouvera ici le document Digidesign qui explique cela.

C'est moins fun et moins universel qu'une pub Nokia sur Youtube, mais c'est aussi plus convaincant !

Et être vulgarisateur tout en étant rigoureux, non seulement ça prend du temps (même si le doc ne fait que 12 pages) mais c'est aussi une preuve de sérieux et de savoir-faire.

[ Dernière édition du message le 10/12/2011 à 17:53:35 ]

45

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

 

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.

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

Je ne sais pas ce que le mot "scientifiquement" vient faire dans cette phrase.
Je suis d'accord qu'il y a bien 32 bits de plus en 64 bits qu'en 32, et donc la précision est nettement plus grande. Elle le serait encore en 128bits...

Non la seule question qui se pose est : est-ce que cela s'entend ?

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.

Je suis d'accord pour dire que ce n'est pas impossible.
Mais là encore, la question est : "est-ce le cas" ? Est-ce que dans des tests à l'aveugle, des ingés son distinguent sans coup férir Pro Tools HD de HDX ? Ça reste à prouver. Et aucun des deux reportages n'apporte de preuve là-dessus. Il y a juste DBF qui dit que c'est génial, mais on ne sait pas exactement s'il parle uniquement de la sommation, ou de retrouver dans ProTools des effets identiques à ceux de l'Euphonix (qui est numérique)...

Bref, faudrait un vrai test à l'aveugle, où il n'y aurait qu'un seul paramètre qui change.

Et enfin, dernier argument à ne pas oublier : Pro Tools HD est en 24/48bits fixes. Pas en 32 bits float.

À mon avis l'argument massue est celui sur lequel personne n'est revenu, parce-qu'il n'y avait probablement rien à dire :
Citation :
En fait on a toutes les raisons de penser que non. Tout simplement parce-que Sonar le fait depuis pas mal d'années, et qu'il n'y a pas eu des centaines d'ingés son ou des milliers de musiciens pour passer à ce moment là de Cubase/Logic/Protools... à Sonar à cause de la qualité sonore liée à ces 64 bits.



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

Là encore ce n'est pas la question. Les bonnes question sont :
- existe-t-il des différences audibles de manière déterministe par quelques personnes ?
- existe-t-il des différences audibles de manière déterministe par des millions d'auditeurs grand public ?


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.

Peux-tu donner des exemples de "traitements dans le moteur audio" ?
Il est évident que les traitements comme les EQ, les compresseurs, les réverbes sont des effets, et ne sont pas liés au motreur audio.

Ce que je vois moi, comme traitements autres que l'automation et la sommation, c'est : gain, pan. Je ne vois pas grand chose d'autre. Il peut y avoir des défauts comme la non-compensation de la latence, mais ce n'est plus le cas d'aucun DAW.
Alors quoi ?
47

Citation :

De toute façon, pour avoir une réponse définitive, il faudrait faire un test de comparaison en double aveugle, moteur audio en 32 bits vs exactement le même mais en 64 bits (je ne sais pas si c'est possible facilement ; même en prenant des versions succesives d'un même DAW, pas dit que ça soit le seul truc qui ait été modifié en interne).

 

Essaye Logic Pro, en cochant une case tu peux ouvrir ton projet en 64 bits ou pas.

 

Citation :

Bref pour moi, les moteurs audio sont passés en 64 bits parce que les processeurs actuels sont capables de traiter du 64 bits flottants rapidement (SSE2, etc.), et parce que ça fait bien sur la plaquette commerciale, c'est tout.

 

Avec logic pro en 32 bits tu es limité à 4 GB de Ram, ce qui n'est plus le cas en 64 bits. Crois moi c'est fort utile sur une grosse session. J'ai plusieurs fois bénis le seigneur de pouvoir passer en 64 !
48

Citation :

Essaye Logic Pro, en cochant une case tu peux ouvrir ton projet en 64 bits ou pas.

je rappel quand même un des test que j'ai fait:

- sommation de 60 pistes audio dans cubase sx3 (moteur 32 bit float) avec gain et pan sur chaque piste (les pan toujours à l'extrême)-> export

- sommation des mêmes 60 pistes audio avec propellerhead record (moteur 64 bit float) avec mêmes gain et pan-> export

comparaison des deux exports avec l'un d'eux en inversion de polarité, export du résultat et normalisation à 0dBfs

 

résultat, pas un pet de mouche, ni BDQ ni quoi que se soit!

Ce qui va dans le sens de la comparaison faite par Pov Gabou.

Et puis si on va par là, soyons fou, on peut aussi prétendre qu'un DAW native sera meilleur que protools HDX dsp, puisque la sommation se fait sur 80 bit flottant, quand vous ferez des mix avec 8715 pistes, le son sera plus large, plus dynamique, et vous aurez une meilleur conservation des harmoniques, surtout vers 3.412kHz.

 

Citation :

Avec logic pro en 32 bits tu es limité à 4 GB de Ram

ouai, c'est le premier argument en faveur du 64 bit pour moi.

49
Citation :
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.


Citation :
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 : :boire:


Citation :
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 ]

50

Hors sujet :

Pour finir ma pub lol, logic est a 149 Euros depuis décembre.  icon_bravo.gif

---EDITÉ---