Se connecter
Se connecter

ou
Créer un compte

ou

Sujet Moteurs audio, 32 bits / 64 bits, distinguer le vrai du faux .

  • 185 réponses
  • 23 participants
  • 26 960 vues
  • 31 followers
Sujet de la discussion Moteurs audio, 32 bits / 64 bits, distinguer le vrai du faux .
Bonjour à tous les audacieux qui auront le courage de se lancer dans cette réflexion ...

voilà, je me pose la question suivante :

a-t-il déjà été fait un comparatif sérieux des moteurs audio qui animent les DAWs les plus réputées (ou les plus répendues ...) ?

Depuis quelques temps, on voit apparaître comme principal argument de renouvellement de certains logiciels, le fait que leur moteur audio passe au 64 bits. Y'a-t-il un gain réel à se lancer dans le 64 bits en tant que moteur de mixage (et pas en tant que moteur de système d'exploitation ... :clin: ) ?

Personnellement, je pense bien qu'il doit y avoir un avantage net puisque nous massacrons joyeusement de plus en plus le signal à coup de plug-ins déjantés, et qu'une précision accrue dans les calculs permet de conserver une cohérence dans le signal traité (ne serait-ce qu'au niveau de sa phase ...). Sans compter que des logiciels aux ambitions très modestes comme Tracktion 2 se sont armés de ces moteurs 64 bits, alors que des plates-formes considérées comme "haut de gamme", comme ProTools, pour ne pas le citer, en reste pour l'instant au 32 bits (alors que ses prétentions qualitatives et pécuniaires sont pour le moins beaucoup plus élevées). Et en outre, des logiciels comme Samplitude ou Pyramix ont des moteurs en 32 bits mais extrêmement réputés (car très bien programmés semble-t-il) pour leur respect du signal. Une vache n'y retrouverait pas son veau ...

Un rapide état des lieux :

moteurs 64 bits :
Sonar 6
Cubase 4
Sequoia 9
Tracktion 2

moteurs 32 bits : (je vais en oublier c'est sûr)
Samplitude 9
Pyramix 5
Nuendo 3
Pro Tools ??? (je me perds dans les versions)
Kristal Audio Engine (faudrait pas oublier les gratuits ...)

voilà, merci à ceux qui voudront bien partager cette réflexion avec moi ...

:bravo:
Si vis pacem para bellum
Afficher le sujet de la discussion
151

Hors sujet : Les miennes ont été un peu repoussées par vos contributions. Encore merci.

152

Citation :
Absolument, je me place comme toi du point de vue du résultat final, soit en 24bits virgule fixe.



Oui mais les calculs, eux, sont pas fait en 24 bits, et on a justement une precision de 24 bits quelque soit la dynamique ! La representation en 32 bits flottant est similaire avec une representation mulaw, en fait; et en plus, c'est pas toujours 32 bits, et il y a la denormalisation... C'est pour ca qu'en ecrivant ma reponse, j'ai commence a programmer, parce que ca devient trop complique (au moins pour moi :oops: ).

Citation :

Concernant les programmes que tu as écrit, bravo, mais je suis une tanche dans ce domaine, 'n'vais pas pouvoir suivre sur ce terrain. Faut savoir admettre ses limites



Pour ma question, pas besoin de programmer: ce que j'ai fait dans le 2e example, c'est:

- generer deux signaux aleatoires (bruit uniforme), avec une dynamique entre les deux fixes ici a 80 dB. Celui a 0 dB est entre [-1, 1]. A est a 0 dB, B est a -80 (en moyenne).
- je convertis A et B en 32 bits, ce qui donne A32 et B32, et je calcule la somme en 32 bits, ce qui donne S32,le mixage des deux.
- Ensuite, je fais S32 - A32, pour recuperer le signal B32_2 apres mixage, et je compare celui ci a la version originale en 32 bits. La difference de niveau entre les deux est de 220 dB en moyenne, 140 dB au pire (j'ai pris le max de la difference et calcule le niveau relatif).

J'ai tendance a penser que ca rend compte du fait que meme apres mixage, on garde encore une grosse precision meme sur le signal a -80 dB.

Je pense que la preuve ultime, ca serait d'utiliser (ou de programmer....) un soft qui fait le mixage en 32 et en 64, de generer 2 wavefiles en 24 bits, de les mixer ensemble avec un niveau relatif de 80 dB, et d'exporter le tout dans un wav a 24 bits, avec les deux modes, 32 et 64 bits. Si mes suppositions sont exactes, on aura exactement le meme fichier...
153
Bonjour à vous et merci d'enrichir à ce point le débat,

(c'est inespéré, les limites sont franchies au-delà du raisonnable :clin: )

pourquoi est-ce si difficile de traiter du DSD (donc un bit modulant) en le convertissant en 32 ou 64 bits float ? Il y a des touffus qui s'y sont collés (équipe Sony Oxford), et le résultat est très lourd dès que l'on veut faire des traitements sur le signal (EQ, compression ...). L'apport du DSD (ou plutôt dirais-je, ce qu'il a de moins) par rapport au PCM est très évident tant sur le plan technique que sur celui du résultat à l'écoute, mais hélas, on ne prend pas cette direction ...

:|
Si vis pacem para bellum
154

Citation : Oui mais les calculs, eux, sont pas fait en 24 bits

Oui Gabou, mais je me répète, au final dans mon fichier 24bits, un son qui s'il était seul serait modulé -80dBfs, ne bénéficie plus que d'une résolution réelle de 14bits. Ce que je dis n'est pas plus compliqué que ça, faut pas chercher plus loin.

Cela dit, 14bits c'est la résolution des premiers lecteurs Philips, pour 0dBfs !

JM
155
C'est marrant çà me rappel quelque chose!!!
156

Citation :
L'apport du DSD (ou plutôt dirais-je, ce qu'il a de moins) par rapport au PCM est très évident tant sur le plan technique que sur celui du résultat à l'écoute, mais hélas, on ne prend pas cette direction ...



C'est pas aussi evident que ca, l'apport du DSD, car c'est (etait ?) un des "hot topics" dans la communaute des chercheurs en audionumerique.

https://sjeng.org/ftp/SACD.pdf
http://www.extra.research.philips.com/mscs/publications2002/dsd-aesformat.pdf
http://www.acoustics.salford.ac.uk/research/angus_files/angus_files/publications/publications.htm
http://www.aes.org/events/112/papers/x.cfm

T'as des gens qui disent que le principe meme est debile, et que ca sert surtout aux constructeurs pour changer tout le parc de materiel... Ce qui est sur, c'est qu'en soi, c'est pas un avantage d'avoir un format different pour le stockage et le traitement. Faut vraiment que le format apporte quelque chose d'enorme. A ma connaissance, il y a pas eu de double test en aveugle sur le plus du DSD par rapport au PCM, mais j'ai pas trop suivi non plus, c'est pas ce qui m'interesse le plus non plus dans le domaine de la recherche en signal audio.

Citation :
Oui Gabou, mais je me répète, au final dans mon fichier 24bits, un son qui s'il était seul serait modulé -80dBfs, ne bénéficie plus que d'une résolution réelle de 14bits. Ce que je dis n'est pas plus compliqué que ça, faut pas chercher plus loin.



Ah oui, bien sur, mais la, ca n'a plus rien avoir avec la chaine de traitement, puisqu'on parle du support. Que ton "moteur audio" soit 32 bits ou 64 bits, le support a la fin sera vraisemblablement du 24 bits au mieux. C'est d'ailleurs une des raisons pour laquelle je pense que c'est pas super utile, d'avoir un path pour le traitement en 64 bits... La difference sera rendue caduque lors de l'export.
157
Sur le DSD, t'as un mail de Sampo Syreeni qui est bon. Je le copie ici car l'archie de musicdsp a l'air d'etre definitivement morte:

Citation :
> As far as I understood DSD is pretty much what comes out of a sigma
> delta converter (ADC)

Yes, but...

> So unlike a high-speed-sampled 1 bit signal which indicates the
> current level (0 or 1) at the sampling instance the DSD signal are
> more like an "upupupdownupdowndownup..." sort of signal which tells
> whether the level at this sampling instance is higher/lower than was
> already accumulated.

True. But think again about 1 bit sampling. If you do it directly, it'll
be horribly nonlinear. If you add enough dither, it'll become linear in
average and work the way you describe, but then the utility signal will
be completely swamped in noise. The big insight of noise
shaping/sigma-delta is that it is possible to shape the noise floor so
that some minute, low-end fraction of the total bandwidth of the 1-bit
signal forms a linear, low noise channel, and the quantization noise is
moved upwards in frequency, while keeping the signal 1-bit. Nothing else
changes, so the utility signal is *still* some time average of the
bitstream. It's just that you don't need as steep a lowpass filter for a
given level of accuracy in reconstruction because the noise is already
concentrated in the high end.

Intuitively it's a bit difficult to see why the sigma-delta modulator
works this way. It's usually analysed statistically and in the frequency
domain, by inserting a dither source inside the quantization loop, then
treating the step quantizer as an independent source of noise, and
finally showing both that the input-output transfer function tends
towards unity in the utility band and that the closed loop response from
the dither input to the output tends to a highpass characteristic
related to the modulator order determining lowpass filter (in your
words, the "accumulator") embedded in the feedback loop.

I'll try to outline one way of getting it in the time domain. If you
look at the modulator, the loop tries to keep the output of the embedded
lowpass/accumulator as close to the input as possible. It always outputs
a correcting bit and assumes that the output will follow in the same
direction, reducing the error. This is a form of negative feedback
similar to that used in analog amplifiers; wrapped around a
nonlinearity, it counteracts it. From another perspective, the
accumulator is the ideal synthesis filter and the loop around it is a
naive optimization process which attempts to synthesize a binary string
which would drive it along the input waveform. The arrangement is stable
as long as the monotonicity assumption holds, and this happens in the
low frequency utility band, so there the process tends towards
transparency with rising sampling frequencies. Above the utility band no
energy was present before and now is, so the entire process tends
towards simple addition of high frequency noise which is designed to be
filtered out by the reconstruction filter.

Now it is relatively easy to see why the loop behaves as it does,
because the delta-sigma modulator can be broken in independent halves.
The lowpass filter inside the loop is basically the optimal, linear
reconstruction filter we're optimizing the bitstream for, and the loop
is the optimizer. Reconstruction is done by lowpass filtering because
that's what the optimizer fitted the bitstream for; the order of the
lowpass filter/accumulator only changes the *kind* of averaging that is
optimal, and not the overarching principle. In simple delta coding the
accumulator and the reconstruction filter are of first order and the
signal is multibit, in sigma-delta they have order upto six and the
signal is 1-bit, but both operators are still just different kinds of
moving averages, capable of emulating one another to a high degree.

Since LTI processing does not shift energy from one frequency band to
another, LTI filters can always be applied directly to DSD as though it
was 1-bit PCM. Any high frequency, shaped noise will stay up there and
be cut out upon reconstruction. Of course any filters will cause the
delicate cancellation between the utility signal and the added noise to
fail, so that the intermediate signals will no longer be 1-bit but will
require normal PCM bit widths. Any nonlinear processing can also cause
interference between the utility band and the noise component, and
corrupt the utility signal. That's why processing PCM is so much easier.
But it's easy to see that going into PCM requires nothing more than
filtering out the noise and (possibly) decimating into the utility
bandwidth. (Sony's solution is 8-bit intermediates without decimation
and reshaping back to DSD for delivery.)


BTW, the last way of looking at delta-sigma modulation is more general
than it seems and quite powerful. It allows us to formulate exactly the
conditions the system relies on, delineate its boundaries, and consider
alternatives. For example, we see that the optimizer is a greedy,
heuristic one and relies on a highly simplified assumption (a monotonic
input-output relationship). This is where the instability of high order
(i.e. more efficient) delta-sigma modulators comes from, so going with a
high order filter and replacing the optimizer with something a bit more
sophisticated can in theory boost the efficiency of bitstream coding and
probably sidestep the Lipschitz-Vanderkooy critique of DSD because a
dither linearized feedback loop is no longer present. It's also evident
from the structure that in principle delta-sigma isn't limited to
lowpass reconstruction -- just replace the embedded filter with
something else and use an optimizer which can cope. Et cetera.

> So in other words it has a 'memory' in it. From what I understood
> there is a specific bitstream that indicates 0.

Sort of. As long as we reconstruct by LTI lowpass filtering and the
transmitted signal is 1-bit, the bitstream will need to alternate
symmetrically about the mean and be as high in frequency as possible.
Depending on which metric you use, the best approximation to zero output
will come from an alternating series of zeroes or ones (least mean
square error: energy is concentrated as high in frequency as it can go
where the reconstruction filter has cut off maximally) or from a
top-heavy noise (supremum norm in the frequency domain: the energy
distribution will have to inversely follow the reconstruction filter
response).

> Given that (unlike PCM) DSD doesn't have the concept of zero there has
> to be a way of telling "ok we're going to start at 0 again". So I
> guess one would have to detect this bitstream to put your PCM signal
> to 0 and then create the signal based on the up/downs and then
> downsample based on that.

Both PCM and DSD have a concept of zero in the same sense: the mean
between the highest and lowest values directly representable. In PCM
systems that will mostly lie between the two middle sampling steps, so
neither PCM nor DSD can realize a zero exactly but only as a time
average of a quantized signal. In practice both systems have finite
memory, so decoding can start anywhere and the resulting average will
converge to the right value. Nowadays high quality PCM will be in-band
noise shaped before delivery as well, so the reasoning about residual
noise levels and zero patterns is almost identical for the two systems.

PCM and DSD really aren't that different if you push them hard.

158
De toute facon, concernant les plugins qui sont une inteface logicielle de calcul, il faudrait que ceux-ci soit compiles en 64bits pour en tirer parti. Concernant le choix de l'OS, je viens de passer d'un protools LE 8.0.3 sur un XP 32 bits à la même config sur Seven 64bits, cela ne change pas grand chose hormis la possibilité d'utiliser plus de 4Go de ram pour les instruments virtuels. 
159
  j'me le garde sous le coude celui là, bravo les gars.
160

j'ai une question :

es ce que sa derange la qualiter d'enregistrement si mon

mac pro est en 32 bits ( snow leopard )

le logic studio en 64 bits

enregistrement en 24 bits

?????????

merci !