Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Le son d'un soft.

  • 206 réponses
  • 28 participants
  • 5 003 vues
  • 2 followers
Sujet de la discussion Le son d'un soft.
Quand est il vraiment?

Est-ce simplement une vue de l'esprit ou certain séquenceurs sonnent t'ils mieux que d'autres?

Si oui, lesquels sonnent le plus mieux?



Je sent que ça va saigner :bravo:


Avant de vous etriper entre cubaseux, Logiqueux, Samplitudeux, Sonareux... je serais curieux d'avoir quelques avis objectifs...
Afficher le sujet de la discussion
126
J'en discute avec un autre post, et putan, c'est chaud de vraiment tout tester

Je sens que je vais meme etre oblige de programmer des plugs VST pour enregistrer les flux audio ( par exemple, je crois pas du tout a des compresseurs, dither caches par pistes, ce serait tout simplemet impossible a faire techniqeuement pour des raisons de puissance de calcul, mais par contre, sur le master, c'est envisageable, finalement... D'ou la necessite de faire des plugs qui capteraient les flux audio ).

Ca me rend trop fou, ce truc !
127
Sur le forum de Nuendo un mec nommé Fredo avait donné une explication fournie, de mémoire...
128
Si tu serais capable de me retrouver le post, ce serait genial :clin:

Je rentre chez moi, et je commence a reflechir a tout cas sur papier
129
Ok moi je vais me coucher et je te laisse réfléchir :bravo:

VIM qui n'a jamais eu son tee-shirt...

130
C'est de ça dont tu parles Number 6?
131
Clair bien ouej Shariff :bravo:

Y'en a un autre aussi, antérieur à celui ci
132
Bonjour!
Et, un petit :clin: a Fmarine.
Travaillant à la fois avec Logic et Samplitude, je reponds à l'hesitation de Gabou quant au travail en 32bit flottant avec Samplitude: il le fait.
Subjectivement et objectivement, Samplitude possède un grand moteur audio. De plus les developpeurs s'impliquent vraiment puisque les beta testeurs et autres coupeurs de cheveux en quatre se retrouvent sur le forum de Samplitude. Le son d'un moteur audio n'est pas un mythe. D'ailleurs, si j'ai craqué pour Samplitude, c'est grace à une one take commise avec Samplitude. Je connais le son de ma Jazz Bass par coeur, donc, je suis amène de savoir si le rendu est correct. J'ai fait ce test avec Samplitude. Son moteur audio est une merveille d'autant que, comme Logic, il intègre en natif le POW-r!
Autre test banal mais efficace, une écoute de MP3. Donc, j'importe un MP3 dans Samplitude et je me rends compte que le MP3 sonne droit et propre, lineaire.
Pareil pour les EQ: lineaire puisque issus du travail des accousticiens de l'université de Dresde.
Donc, faites le test par vous meme et telechargez la demo de Samplitude...ici
http://www.samplitude.com/de/news.htm
Ne possedant pas Nuendo, son seul concurrent valable sur PC, il serait interessant de faire des comparaisons.
Mes enceintes: Yam NS10m et MAckie HR824 mais, j'ai travaille en stud sur Genelec et Altec Lansing chez un ingé pro qui bosse avec Sequoia (le grand frère) pour de la post prod.
Voila.
A+
133
Bah oui, ce thread a justement été motivé par la "grosse" différence qu'il m'a "semblé entendre" entre Cubase, et Samplitude, test à l'aveugle à l'appui.

Et je suis bien loin des grandes oreilles de la maison de la radio coté feuille, et j'écoute tout cela sur de vieilles Tannoy!!!



Une question qui me turlupine, c'est pourquoi les fabriquants de logiciel communiquent tous si mal sur ce sujet?
Ils vantent tous leur "moteur audio" sans expliciter même de façon très sommaire de quoi il s'agit... "Nous avons dévelloppé un nouveau moteur audio, plus performant, et patati et patata..."
134
> Logicjack : le coup du grand moteur audio, de toute facon, ca se joue pas sur le son. UN moteur audio performant, c'est avant tout un pb purement informatique.

Ensuite, j'ai ma petite idee sur l'absence de reponse des developpeurs, et ca les grandit pas, s'il y a pas de difference.

Enfin, pour les EQ, les MP3 : on parle plus du tout de la meme chose. Evidemment que les EQ sonnent differement; le coup des EQ "lineaires", il y a pas besoin d'etre a Dresde pour savoir en faire ;) Les papiers existent depuis des lustres sur ce genre de problemes, depuis au moins 15 ans. Ces gens qui ont bosse pour lexicon, ensoniq, dans une autre vie, et qui sont maintenant consultants, certainement pour mackie ( UAD-1 ), etc... Faire un EQ, lire un MP3, au niveau audio, c'est beaucoup plus complexe que de faire du mixage. Dire que les EQ de samplitude sonnent differemment de ceux de cubase, c'est comme dire qu'un reverb lexicon sonne differemment qu'une de Wave...

Test en cours cette apres midi ( je viens de me lever... ).
135
En tout cas, il y va pas avec le dos de la cuillere, le fredo. :mdr:

Tiens, encore un pur mythe, et la, pas besoin de tests :

Citation :
What about the resolution of the project:

16 Bit: Tolerable
24 Bit: Maybe
32 Bit: Quite good
Endless Bits: Perfect. Mh, that´s analog.



J'espere que plus personne croit ce genre de connerie ( genre une frequence d'echantillonnage infinie sonnera aussi bien que de l'analogique, aussi.... ).

Lorsque le fredo parle d'arguments techniques, par contre, ils tombent tous a plat :

Citation :
A 32 bit floating point file is actually a 24bit word (called the 'Mantissa'), and an 8bit gain range (called the 'Exponent'). This way, a signal can actually exceed 0dBfs (full scale) by as much as 1000dB, and go pretty much 500dB below full scale. What this does is to keep the full resolution of the audio signal intact throughout the processing chain in the mixer.

Did you notice that hardly any of your plugins have a gain control for input/output? That's why! Those poor ProTools plebs have to worry about setting the input and output gain on EVERY plugin, in order to make sure the signal doesn't clip, or degrade from too little level, because their entire system is based on an antequated 24bit integer processing chain.



C'est un tissu de conneries :( Dommage, j'aimais bien son point de vue...
136
Y a un truc que mon collègue m'a confirmé en passant (au passage je l'ai tanné pour qu'il passe par ici :clin: ) :


le fredo à dit dans un des ses nombreux posts:

What have we learned? That we can’t compare two things while applying different parameters.
That’s why I was saying that every scientific double blind test resulted in a “not able to tell the difference”.

mon collègue m'a dit exactement la même chose avec la phrase suivante en plus :

le problème c'est que les DAW sont devenus complexes et leurs interfaces on fait de gros progrès en terme d'ergonomie... du coup on est jamais sur d'appliquer exactement les mêmes paramètres d'un soft à l'autre

et une 'tite discut de 2mn (ok 15mn) nous a amenés à la conclusion (partielle) suivante:

deux sons a priori "techniquements identiques" (un ensemble de mesures ou de critères présentent les mêmes valeurs) peuvent être perçus différement (l'un meilleur que l'autre ou plus clair ou plus soyeux...) et de façon identique et répétée. c'est un fait... on est humains et notre oreille n'est pas parfaite techniquement... si on cherche à expliquer cette différence, on va souvent ne pas trouver d'explication satisfaisante, parfois trouver une explication ubuesque (l'age du capitaine... il fait bo aujourd'hui.... elle était comment la pizza... la clim est en panne) et très rarement trouver une explication techniquement satisfaisante...
donc les pistes "l'interface qui nous influence", "on est tous en train de psychoter", "y a une 'tite différence technique bien planquée (du coté du master?) qui change le truc" semblent a priori toutes valables et le seul vrai test c'est celui d'une utilisation approffondie où on va apprendre à faire sonner le truc... à partir d'une certaine qualité, c'est l'utilisation qui fait la différence bien plus que la perfection technique

et puis on ne peut pas être sur que notre analyse prend vraiment en compte Tous les paramètres (suit une anecdote édifiante mais un poil longue)
137

Citation :
e problème c'est que les DAW sont devenus complexes et leurs interfaces on fait de gros progrès en terme d'ergonomie... du coup on est jamais sur d'appliquer exactement les mêmes paramètres d'un soft à l'autre



Oui, c'est tout a fait vrai, je suis en train de me prendre la tete a fond la desssus pour faire un tests valable. La seule vraie solution, ce serait d'avoir acces aux codes sources, et de jouer avec. Par exemple, la relation entre gain et course du fader est dependante du soft.

Mais en programmant un petit plug VST qui capterait le flux audio a differents endroits, je pense que je peux pas mal contourner ce probleme.
138
Bon courage

et fais gaffe au compteur, tu t'approches des 6000 :bravo:
139
Sur ce que dit kravatorf, que l'oreille humaine peut très bien percevoir 2 choses complètement identiques différemment, j'suis assez d'accord. On peut pas crédibiliser un test que sur l'écoute (aussi bonne soit-elle). Combien de fois ya eu des avis du genre "A sonne mieux que B" et 20 min. plus tard quelqu'un qui vient dire exactement l'inverse.
Perso, je préfère croire ce que je vois, donc pour le test ya intéret de faire des analyses type sonogramme ou autre. Merci.
140

Citation :
Sur ce que dit kravatorf, que l'oreille humaine peut très bien percevoir 2 choses complètement identiques différemment, j'suis assez d'accord



Oui, bien sur. Mais bon, je pense que si par exemple, mon experience montre qu'un bounce d'un wave sous samplitude et SX est identique au bit pret, sosu reserve que mon test soit valable, il n'y a aucune raison pour dire que SX sonne moins bien que samplitude pour lire un wave, non ?

Dans des tests d'ecoute, il y a toujours une marge d'erreur, et on considere qu'un test n'est valable que s'il ets verifie "statistiquement", en gros, si la majorite des gens peuvent dire avec un intervalle de confiance assez grand ( genre 95 % ) que deux trucs sont bien differents.

Typiquement, un test qui demande si un test sonne mieux que l'autre est a la base, fondamentalement, un mauvais test.
141
En même temps , si tout le monde psychote pareil, c'est peut être complétement ésotérique mais autant en tenir compte

(je suis bien conscient du coté "sciences molles" de mon argument :clin: mais bon j'ai une excuse, j'ai fais un peu de socio lors de mes études :mdr: )
142
Au passage dans les athlons XP et les pentiumsIV, la FPU bosse avec des registres de 40 bit, et c'est pour ça peut être que les bus master font 40 bits de large en pratique dans les softs.

Et d'ailleurs dans l'athlon 64 la FPU fera aussi 40 bits de large, les 64 bit c'est juste pour l'adressage et la largeur des bus. alors pour les perfs audio faudra repasser.

et pour les problèmes de mantisses et d'exposants, on le sait depuis longtemps qu'en informatique (x+y) - x avec y << x ça fait pas y mais ça fait 0, c'est aussi pour ça qu'en calcul scientifique on utilise des float long double précision codés sur 64 bits pour de vrai (ULTRA SPARC) alors sur les plateformes PC actuelles faut pas espérer mieux.

Ca serait marrant de coder un moteur audio qui tourne en 64 bits réels sur une station SUN et de comparer les résultats à ce qu'on a sur PC!
143
À quand la DAW sur un crey..... (n'empêche, ça serait vraiment marrant de faire ce genre de comparaison :clin: )
144
En mode dénormal la FPU bosse sur des operandes de 80bits avec un perf très ralentie.

c'est pour ça peut être que les softs dénaturent le son quand on abaisse trop le gain d'une piste.

a votre avis il vaut mieu enregistrer proche du 0 et attenuer, ou enregistrer un peu moins fort et moins attenue r en soft?
145
Je suis OK pour les 80 bits, mais je me suis mal exprimé sur le mode denormal :

je voulais dire que vu que les softs évitent de faire passer le CPU dans ce mode (float extended precision pour l'IEEE), et ben du coup on ne profite pas de la précision maximale et seulement de opérandes de 40 bits sont utilisées.


et puis j'ai regardé les standards de l'IEEE :

Single-precision format – 32-bit data width, 6 to 7-digit precision
Double-precision format – 64-bit data width, 15 to16-digit precision
Extended-precision format – 80-bit data width, 18 to 20-digit precision

http://research.microsoft.com/%7Ehollasch/cgindex/coding/ieeefloat.html
146

Citation :
e voulais dire que vu que les softs évitent de faire passer le CPU dans ce mode (float extended precision pour l'IEEE), et ben du coup on ne profite pas de la précision maximale et seulement de opérandes de 40 bits sont utilisées



Oui, on profite pas la precision maximale, mais ces nombres sont tellement petits que c'est pas grave de perdre un ou deux digits ( franchement, je suis sur que c'est pas ca le pb, et que d'ailleurs, ce genre de trucs sont bien en deca du bruit de fonctionnement de n'importe quel truc analogique )

Par contre, ton truc de 40 bits, je comprends pas ce que ca veut dire ?
147

Citation :
Au passage dans les athlons XP et les pentiumsIV, la FPU bosse avec des registres de 40 bit, et c'est pour ça peut être que les bus master font 40 bits de large en pratique dans les softs.



Non, c'est 80 bits. Et la master bus de cubase 5 fait justement 80 bits, d'apres steinberg. Le mode denormal, c'est tout a fait autre chose : on bosse sur la meme precision ( par exemple, si on est en 32 bits, on reste en 32 bits ), mais on change la representation de l'exposant et de la mantisse.

Le format IEEE en 32 bits, par exemple, c'est un bit de signe, 23 pour la mantisse, et 8 pour l'exposant.et on code un nmbre comme ca :

+/-(1 + M/2^p)*2^(E-B) avec B le "bias" de l'exposant, M la mantisse, et p la precision en bits de l'exposant.

En monde denormal, ca devient :

+/-M*2^(1-B-P). Le 1 en exposant est la pour assurer la continuite entre le mode denormal et le mode non denormal

( sources : http://ldesoras.free.fr/doc/articles/denormal.pdf )

Pour ton pb de (x+y)-x different de y, c'est vrai, mais comme le format flottant et les arrondis sont normalises ( format IEEE , respecte sur la FPU, le SSE des pentium, et les G4, et tres certainement les G5 ), le probleme est le meme sur tous les proc. Puis de toute facon, les gens parlent de differences entre deux softs sur une meme machine.

Je bosse depuis 3 ans sur des pc avec matlab, qui fonctionne en 64 bits nativement ;) Et nuendo a ete developpe a la base sur des station SGI, qui doivent etre 64 bits ( pas sur du tout, ca , par contre. ).

Pour des infos sur les format sur la FPU des intel

https://www.randelshofer.ch/fhw/gri/float.html#chapterfinitenumbers
148
Bon je reformule le tout avec quelques corrections, après m'être renseigné pour de bon:

les registres de la FPU font 80 bits.

Y'a trois modes de calcul pour la FPU:
-avec des opérandes de 32 bits
-avec des opérandes de 64 bits
-avec des opérandes de 80 bits

le dernier mode n'est jamais utilisé en pratique car trop lent.
les instructions SSE1 et 2 d'après ce que j'ai capté, sont l'équivalent des MMX pour les float, dont le but
est de profiter du parallelisme sur des opérations de largeur réduite.
avec un registre de 80 bits = 4*16= 2*32=1*64
donc je pense que les applis audio utilisent les SSE1 pour streamer des operations sur 32 bits float, et c'est pour ça que je me demande si c'est exact que le bus master fait plus de 32 bits float, et c'est encore pour ça que je pense que 32 bits c'est la précision limite pour les machines actuelles.
Je crois aussi que les registres des SSE2 font 128bits, c'est surement pour faire du 4*32

après 32 bit c'est déjà largement au dessus des besoins pour l'audio?
149
Haaa et puis j'en ai marre je vais ecrire chez steinberg directement pour qu'ils nous disent tout. y'en a marre de spéculer sans voir vraiment comment ils font. tant pis pour le secret industriel.
150

Citation :
e dernier mode n'est jamais utilisé en pratique car trop lent.



Sauf pour le master, justement.

De toute facon, tous les calculs sont faits en 80 bits, en fait, et apres remis en 32 ( ou 64, ou 80 ). La lenteur est essentiellement due a la lenteur de la ram, pas celle du calcul en lui meme, d'apres ce que j'ai pu lire ( mais bon, je suis loin d'etre un specialiste en la matiere, de toute facon ), et ce qu'on m'a dit quand j'ai fait un peu de developpement en stages. Donc tu as de la marge de ce cote la.

La FPU des x86 est assez particuliere, dans le sens ou ca marche tres differement de l'alu et cie. Par exemple, au lieu d'avoir des registres a la eax et cie, tu as une pile de 8 emplacements, qui font bien 80 bits. TOUT flottant traite par le CPU fait 80 bits tant qu'il reste dans cette pile ( tu peux aller voir la doc sur le site intel ).

Citation :
The numeric coprocessor has eight floating point registers. Each register holds 80-bits of data. Floating point numbers are always stored as 80-bit extended precision numbers in these registers. The registers are named ST0, ST1, ST2, . . . ST7. The floating point registers are used di erently than the integer registers of the main CPU. The floating point registers are organized as a stack. Recall that a stack is a Last-In First-Out (LIFO) list. ST0 always refers to the value at the top of the stack. All new numbers are added to the top of the stack. Existing numbers are pushed down on the stack to make room for the new number.



( source : http://www.drpaulcarter.com/pcasm/redir.php?file=pcasm-book.pdf )

Ensuite, la ou ca se corse, c'est avec le SSE : la aussi, tu rajoute 8 registres, qui font ce coup ci 128 bits. En SS1, tu peux y mettre 4 floats, et en SSE2, tu peux aussi y mettre 2 double a la place. Mais la aussi, les performances sont grandement limitees par la vitesse de la ram, qui est beaucoup trop lente, meme avec le cache.