Tordre le cou au moteur audio:
- 212 réponses
- 40 participants
- 29 005 vues
- 56 followers
Anonyme
pour ça, un autre thread:
Tordre le coup au moteur audio: polemiques et crtiques
Pov Gabou
Citation :
Un détail auquel tu pourrais m'éclairer c'est la précision 80bit processeur qu'apparemment Sawstudio sollicite...
Sur les Intel, la FPU (qui fait les calculs en flottant) a deux precisions: 32 et 64 bits. Mais en interne, les calculs sont faits en 80 bits je crois (faudrait verifier, je suis plus sur de la valeur), c'est a dire que si tu multiplies deux nombres entre eux, c'est fait en 80 bits, et le resultat est ensuite converti en 32 ou 64 bits. Pour compliquer les choses, ca n'est plus vrai lorsque tu utilises le SSE, qui est une unite differente de la FPU dans les CPU.
Il y a aussi les long double qui font aussi 80 bits je crois sur Intel, et en entier, je sais pas si c'est dispo. Mais bon, deja 64 bits, je suis un peu mefiant sur l'utilite (a part quelques endroits bien cibles). Fondamentalement, je suis tres curieux de voir que les machines audio ont des besoins plus importants en precision que ce que fournissent des machines de calcul numerique pour les simulations numeriques. Je me demande si ca a ete teste une seule fois en aveugle, cette histoire de sommation en 32 bits vs 64 bits.
Citation :
'ailleurs certains ingés sons qui bossent sur des grosses consoles analo type SSL n'hésite pas a dire que ce soft possède un rendus (sommation, Eq etc...) qui se rapproche de celui de ces grosses consoles qui valent la peau du c..... je doute qu'ils soient payé par le programmeur pour dire ça, ou que leur expérience relève du pûr fantasme...
Je suis tres suspicieux. Faudrait avoir le contexte, mais cette histoire de meilleur rendu "analo", je me mefie beaucoup.
Une sommation, c'est une simple operation, il n'y a vraiment rien de magique, honnetement. Tous les softs le font exactement de la meme maniere. La seule difference, c'est la precision utilisee (32 bits ou 64 bits). Donc ils sont neutres dans le sens ou tous les softs font exactement la meme chose; comme le disait R Heneke d'Ableton, il y a quelque chose de fondamentalement risible a voir tout le monde se prendre la tete sur la sommation des moteurs audio, alors que c'est pas du tout le probleme qu'ils resolvent. Sommer des signaux, c'est une ligne de code en C (le langage de programmation utilise dans 99 % des softs de MAO); quand live 6 a un nouveau moteur audio, c'est surtout pour exploiter les nouveaux CPU avec multi core, qui la demandent beaucoup plus de travail (programmation multi thread, avec tous les problemes que ca pose au niveau performances, synchronisation, etc...).
Il y a une grande part de mystification parce que les gens ne se rendent pas du tout compte de ce qui fait la difficulte des softs audio. Typiquement, avoir un nouveau moteur de routing, ca veut pas dire que tu as de nouveaux algo pour faire le routing, mais parce que tu as une nouvelle architecture de ton logiciel plus flexible pour pouvoir connecter une partie dans une autre (ce qu'on appelle la gestion de graph: une sorte de patch, mais en soft. Faire ca bien, et de maniere performante, c'est pas du tout trivial). C'est difficile de rentrer plus dans les details, faudrait que tu t'y connaisses en programmation pour ca. Dans ardour, qui est un DAW open source (qui est supporte par SSL), la fonction mix, je te la donne la (version non SSE):
void
mix_buffers_no_gain (ARDOUR::Sample *dst, ARDOUR::Sample *src, nframes_t nframes)
{
for (nframes_t i=0; i < nframes; i++) {
dst[i] += src[i];
}
}
C'est donc 6 lignes de code. Par rapport aux 25000 lignes de code que constitue en gros le moteur audio. Bref, c'est quelque chose comme 0.02 % du code ecrit. Peut etre que comme ca, ca parle plus ? Pour continuer dans la meme veine, les fichiers sources les plus gros, c'est les session* (13000 lignes de code) pour gerer une session (gestion de la latence, compensation de latence), route.cc pour gerer une partie du graph (quoi sommer ou: connecter les sorties de tel truc en inser ou il faut dans la chaine audio), tempo.cc pour gerer le tempo, audio_distkstreamer pour gerer l'enregistrement sur DD (2500 lignes de code). Et compare ca aux 6 miserables lignes de code de la sommation sans gain... Sans compter que la majorite du code d'ardour n'est pas le moteur audio, mais l'interface graphique (environ 90000 lignes de code).
Ton probleme d'enregistrement, c'est dur a dire la sans controler tres exactement ce que tu fais, mais tu peux faire l'experience sans enregistrer: tu prends un wave existant, tu ouvres je sais pas, 30 pists avec le meme wave, tu somme comme tu veux, puis tu fais pareil sur un autre daw, et tu compares les waves. Tu verras qu'il n'y a aucune difference si tu fais ca correctement.
karlos73
Pour l'histoire du rendu "analo" de Sawstudio effectivement on entre dans le subjectif des ingés sons, mais je me dit que le 64bit n'y est peut-être pas si étranger que cela, je me souviens de la "perfection" du 44/16 lors de l'apparition des CD dans les 80's... Tout comme pour les photos numériques, avant le tres haut de gamme plafonnait a 5 millions de pixel, desormais c'est plus de 10 et enfin une photo numérique commence a ressembler à de l'argentique en enlevant ce désagreable effet "sharpen"...Entre les chiffres et notre perçeption il y a parfois des surprises ... D'aillleurs les samplers des 80's en 12 bit nous semblait restituer les sons de manière incroyable en 86...de nos jours on adore leur grain vintage au point qu'Elektron implemente un sampleur 12bit dans sa Machinedrum...
Desormais avec la précision en 64bit on repousse les limites de notre perception, dans 20 ans peut-être que nous trouverons qu'un DAW en 32bit c'est terriblement "vintage" pour le son...En tout cas je reste toujours sceptique devant la "perfection", m^me les convertos les plus chers et les plus perfectionnés me semblent encore améliorable (et sont encore améliorés par les ingés) car au delà de la limite physique des 20khz il ne faut pas oublier que notre capacité a percevoir est commandé avant tout par nos cerveaux, et ses capacités d'extrapolation sont largement superieure aux limite du tympan, d'ailleurs Nyquist ne le dément pas...
Sinon pour effectuer une sommation je me doute bien qu'en pratique ce n'est qu'une simple opération, mais ce que l'on entend par sommation ce n'est pas que la procedure de calcul, mais surtout les élément qu'elle implique, comme par exemple ceux que tu appelle les "sessions". Dans le monde du son analo la sommation n'est aussi qu'une bête addition de piste et de composants, ce qui fait qu'un sommateur de chez Dangerous, Neve ou SSL est superieur a Behringer ou Samson, ce sont les composants discrets qui sont sollicités pour l'effectuer. Tous ça pour dire que la manière dont sont codés les sessions doivent bien influer sur le rendus final. Un type comme Bob Lentini de Sawstudio qui ameliore son soft depuis 15 ans sans pour autant complexifier son architecture, ni même changer depuis tous ce temps l'approche de son soft (qui lui est d'ailleurs tres personnelle), ne doit pas avoir encadré et mise sous verre ses lignes de code de sessions en assembleur depuis 15 ans... D'ailleurs si rien n'avait évolué dans la manière de coder on utiliserait encore Rebirth pour emuler des sons de TB eu lieux des plug de D16 et Audiorealism ....
Enfin j'ai déjà fait le test en import/export de wav sur 12 pistes d'un DAW a l'autre, et effectivement après le test de la phase aucun artefact, tout est identique.... donc ok les fichiers ne sont pas altéré, mais comme je le disais cela me semble logique car on ne fait que déplacer des fichiers/données numeriques d'un soft a l'autre avec des import/export(bounce) offline. Ce qui m'interresse desormais c'est de voir comment les DAW se comporte avec des flux audionumériques en temps réel, et pour l'instant là j'ai des artefacts... Mais comme l'erreur de mes test est possible, quand j'aurais le temps, et pour pallier les éventuel défauts de synchro des sources analo externes, je testerais les sorties master des DAW via une connection numerique ethernet avec Wormhole, ce qui ne nécessite rien d'autre qu'un ajustement de buffer pour synchroniser les flux audionumeriques externes.
Pourquoi tous ça? Parceque lorsque je joue avec ma basse sur une piste de Sawstudio, le son de celle-ci possède une certaine présence tout en s'intègrant naturellment dans le mix (comme si je la branchais dans une grosse console analo), et cela sans EQ ni comp, uniquement le volume, ce qui n'est pas le cas dans d'autres DAW qui nécessitent quelques traitement préalable avant que mon instrument sonne. Je veux comprendre et savoir si je fantasme ou pas.
Pov Gabou
Citation :
Tous ça pour dire que la manière dont sont codés les sessions doivent bien influer sur le rendus final
A priori, vraiment pas.
Citation :
Dans le monde du son analo la sommation n'est aussi qu'une bête addition de piste et de composants, ce qui fait qu'un sommateur de chez Dangerous, Neve ou SSL est superieur a Behringer ou Samson, ce sont les composants discrets qui sont sollicités pour l'effectuer.
Non, justement, en analogique, c'est completement different, parce que bien qu'en theorie, tu aies raison, a savoir qu'un sommateur, c'est tout simple, en pratique, appliquer un gain en analogique est etonnament complexe, car les componsants utilises ont un comportement non lineaire, c'est a dire que leur comportement depend du niveau d'entree. Autrement dit, un gain, en electronique analogique, il va toujours y avoir un comportement qui va modifier la dynamique, une sorte de compresseur. Ca depend des composants utilises (transistor ? Lampes ? Quels transistors ? Quelles lampes ?), de comment ils sont utilises, etc... Entre autre, pour amplifier, avec des transistors ou des ampli op, il faut leur appliquer une tension d'alimentation la plus stable possible, ce qui est loin d'etre trivial. C'est pour ca que tu as une difference entre le pre-ampli de ta sound blaster et ceux d'une SSL.
Bref, en analogique, un ampli, c'est tout un metier. En numerique, c'est une ligne de code a la portee du premier rigolo venu. Cette difference fondamentale, les gens ne la comprennent pas, parce que c'est pas intuitif. Ils veulent etre persuades qu'ils paient leur pro tools une fortune parce qu'il fait mieux les gains. Mais c'est pas pour ca que pro tools coute cher.
angoleiro
lohworm
Pov Gabou
Citation :
Il est pas possible de coder les gain pour se rapprocher du fonctionnement non lineaire de l analogique comme c est fait pour les modelisation de synthe analo ?
Possible oui, souhaitable, je sais pas. On se fait chier sur le meterial analo a rester dans les zones de fonctionnement lineaire, et maintenant, en numerique qui n'a pas ce probleme, on veut emuler les non linearites...
Si tu veux mettre ca comme un effet, pourquoi pas, mais en general, ce qui va faire la qualite d'une console haut de gamme, ce sont les EQ, etc... qui la bien surs sont differents entre les logiciels.
Anonyme
Citation : This is not really true, there are surprisingly many ways to do the same thing. The differences are just not where you would expect them if you have no expert knowledge, and they are all in a range way below of what I personally believe is audible.
Of course summing two or more tracks in every DAW is output = a+b+c+d, where a = signal of track a * volume of track a . So it is impossible to introduce here compression or any change in frequency response, and the dynmanic range if you do this with normal floating point mathematics is allready super big, not talking about the headroom if you do it with 64bit resolution.
But there are other details: if you draw a volume automation curve and this curve has a sharp edge theory says that this edge introduces nonlinear distortions to the signal. A good example for this is what is called "zipper noise" when moving a MIDI fader on a cheap audio processor.MIDI resolution is 128 steps. If you move a fader assigned to volume and you do no further smoothing you will get a bit of noise every time a new value comes in. In order to avoid this you have to create a smooth ramp instead of a sharp edge. This is known and every DAW manufacturer of course does some kind of ramping. But this is nothing where you can look up the one perfect way to do it in some research paper and every company does it like that. Instead it is always a compromise between reaction speed, cpu usage, and resulting quality. Some of our competitors are quite conservative here, they do very long ramps. This minimizes distortion but also makes all automation a bit floppy. Others prefer punchy automation, and as a result are more likely to introduce more distortion. Unless they use a more intelligent alogortihm. Which east more CPU or introduces latency... and so on.
This is just one example. There are probably a dozend places in a DAW where there is a potential differerence. So, yes, they all do sound different. But it is important to understand that this is a very very accademic way to look at it, because as mentoned before, the effects are in a range of -120db if things are really bad and maybe -160dB typically. Every active speaker introduces a noise floor way above this, every microphone has less dynamic range, not talking about a typical recording environment.
I personally would judge a DAW by all kinds of things but certainly not buy its meassured sound quality. Much more important is: do i like the way the EQs works, am i fine with the compressor, can i use my favourite plug ins with it and so on. This is what will shape the sound of my productions and not the ramping algorithm.
Citation : People here on the forum did a lot of tests and as a result allways came to the conclusion that nothing is wrong with Live. However, as a reaction to those threads we also did internal tests and comparisons between other DAWs and we found out that if you look careful enough you'll find slight differences between the ideal world and reality in pretty much all DAWs, and that Live is not exeptionally bad here. We are talking about distortion or noise as a result of internal rounding errors and things like this in the range of -180dB to maybe -130dB.... I have serious doubt that this is audible unless you do the most most most extreme treatments.
If you really experience audible issues in a specific case, there must be a simple explanation and a solution for it. The notion of "something sounds muddy" unfortunately will not help so much, since if we cannot track it down to a specific problem, we cannot improve things.
Talking about improving: as a result of the tests we did, we could indeed improve some details, and those improvements will be part of the next major update. But
none of those things IMHO has the power to make a track sound more or less muddy, because even the slightest EQing of some fraction of a dB would be a magnitude more significant.
Citation : I stated, that tests showed that envelope smoothing, sample rate conversion, calculating of EQ filter coefficents on every DAW creates artefacts. I also stated that this is in the range of typcially -180dB to -120dB if things are really bad. Of course theses tests were done comparing the five or six big names we all know.
I furthermore stated that I personally believe the influence of this is very low and does not really matter in the end.
I did *not* say, that Live is perfect. I said *no* DAW is perfect and we could clearly show this. A DAW cannot be perfect, because some operations *do* change audio and you can only aim for the most elegant way to do it, but it is impossible by nature to appy any change to a signal and expect it to remain unchanged. I stated, that Live works as any other DAW, and that it is correct that they do sound a bit different if you want to look extremly close. But differnent does not automaticly imply that Live sounds like uttermost crap and the rest is fantastic by the way!
It is really hard to argue with someone who claims we lie, we are arrogant, who assumes we might have a reason to obscure things and who is not able to understand digital audio deep enough to start a serious discussion.
Since the topic has been brought up here: The zipper noise as a result of volume automation will be dramatically reduced in the next release. That bit of ripple on fast automations will be gone
lohworm
Hors sujet : Citation : It is really hard to argue with someone who claims we lie, we are arrogant, who assumes we might have a reason to obscure things and who is not able to understand digital audio deep enough to start a serious discussion.
ou ...
- < Liste des sujets
- Charte