Les moteurs audio, enfin du concret!

1- ok si le moteur était 16 bit, mais attention toutefois de pas confondre la résolution d'enregistrement et la résolultin des calculs, je ne connais pas le soft dont tu parles, mais il doit avoir plus de 10 ans pour ne pas avoir un moteur 32 bit float, comme à peu près tous les softs depuis le début des années 2000.

2- no comment, désolé, je ne porte aucun crédit à ce milieu (même si il y a probablement des exceptions et des gens compétents) car on y lit surtout un gros paquet d'idiotie, si c'est audible, c'est mesurable, l'inverse n'étant pas forcément vrai par contre.

3-je n'ai pas tout relu, mais de quel tu parles avec un résultat non nul? Parce que pour tous mes test de sommations et de comparatifs des softs, le résultat était parfaitement nul, et je ne parle pas de "rien d'audible" je parle d'exporter le résultat en le normalisant 0dB avec toujours rien, hors si il n'y a même pas de bruit de quantification, c'est qu'il n'y a pas de signal.

Citation :

Mais je crois que ces différences existent, car l'algorithme utilisé n'est pas toujours le même et ce n'est pas une simple addition.

 non, là clairement tu te trompes, c'est une simple addition, il suffit d'ne parler avec les gens qui programment ce genre de chose, et les démonstrations que l'on a faite le prouve, ce qui n'empêche pas qu'il y a tout un tas de facteur qui font qu'un mix pourra sonner différemment sur différents softs, mais rien à voir avec le "moteur audio" ou la sommation.

Pour le test dont tu parles (lien mort) effectivement le résultat n'était pas nul, mais j'insiste, c'était un test complémentaire d'écoute AVEC DES PLUGS, et dans cette situation, il devient quasi impossible d'avoir une annulation (variables aléatoires, gestion de la compensation de la latence, dithering etc...).

Dis toi bien une chose, sur un vrai mix (avec plugs, automations etc...), à chaque fois que tu fais lecture/stop, il y a des différences qui sont tout le temps plus ou moins du même ordre que celles qui existaient dans ce test, pourtant je n'ai encore jamais lu personne qui se plaignait d'avoir constater ces différences.

Tu peux en faire la démonstration en faisant deux exports de la même session de mix d'un soft donné, tu n'auras pas d'annulation.

Mais pour les opérations élémentaires d'un soft (ce qu'on peu attribuer au "moteur audio") donc pan, gain, sommation, il n'y a aucune raison que ça diffère.

Et en plus, il me semble que ces opérations sont normalisées et décrites dans la norme IEEE754.

Citation :

Attention, il y a différentes lois pour le pan, selon ce qu'on veut faire

 exacte, mais lors des test nous avons fait des pans soit à 0, soit aux extrêmes, la seule différence que j'avais noté était une échelle différente entre cubase et samplitude, une même valeur de pan intermédiaire ne donnait pas la même chose, mais aux extrêmes on retrouvait nos petits.

PT LE, M-powered et toute autre version native était bien en 32 bit float (par contre je ne saurais dire à partir de quelle version c'était le cas, mais j'avais une version 6 du LE qui de mémoire l'était bien), même si effectivement le format n'était pas intégré pour l'enregistrement/gestin des fichiers.

Pour la version TDM, le moteur était en 48 bit fixe (double 24 bit) avec je crois des repassages en 24 bit pour la com inter bus avec dither et la sommation se faisait sur 56 bit fixe avec une réserve (15 bit de mémoire) au dessus du 0dBfs.

Pour la version actuelle de PT, je crois que natif comme HDX, c'est du 64 bit float en calcul avec gestion des fichiers au format 32 bit float.

pas de soucis.

Il y a un tableau au post 4 ou chaque piste est listée avec en face les plugs et réglages utilisés.

de rien.

Je sait plus si je l'ai posté ici, mais voici la doc sur le mixer TDM de protools (l'ancienne version de leur hardware à DSP remplacée maintenant par le HDX):

https://www.rcc.ryerson.ca/media/TECHNICALWHITEPAPERProTools48-bitMixer.pdf

les tests traitent de ce que peut impacter le "moteur audio", les plugs etc.... c'est une autre histoire.

Pour les pan, il n'y avait aucun problème, l'un (cubase ou samplitude je ne sait plus) montait à 95, l'autre à 90 au niveau de l'échelle, aux extrêmes on avait les mêmes valeurs, pour les intermédiaires, il fallait juste faire un rapport 95/90 pour trouver la valeur correspondante, ce qui à l'arrondi près du ratio donnerait la même chose.

Citation :

et encore on ne parle pas de certaines sommation type HEAT dans PT HD

c'est quoi ça? parce la sommation de PT JD TDM est décrite dans le document que j'ai mis au dessus, et mis à part que c'est en entier et non en flottant, c'est exactement la même chose, une bête somme mathématique, totalement transparente d'un point de vue sonore.

Citation :

Je suis bien d'accord docks, mais les tests se limitent alors à une partie "uniquement" (même si c'est déjà bien) de ce qu'il se passe dans un DAW

le problème, c'est que si on va plus loin (ce qui en théorie n'est pas impossible) ça se complique un peu, il faut déjà être sûr que les plugs employés n'entraîne aucune variable aléatoire, ce qui foutrait en l'air un nul test et saboterait le test, après il y a aussi la gestion de la compensation de la latence.

je suis peut être passé à côté, mais je n'ai rien vu à propos de ce HEAT dans la doc du mixer de PT HD TDM (en fait, c'est même la première fois que j'en entend parler, ce qui ne veut pas dire que ça n'existe pas), à moins que ça ne soit un truc propre au nouveau PT HDX, en tout cas, à priori rien d'autre qu'une bête addition pour le PT HD TDM, c'est même précisé dans le document que la sommation du PT HD TDM est tout à fait transparente.

Edit: après une petite recherche, je viens de tomber sur la page avid qui parle de HEAT, à priori un plug additionnel compatible HDX/HD TDM.

Pour mixbus, je l'ai testé, et silicon machine extended aussi, la sommation est tout aussi transparente que n'importe quelle autre STAN dès lors qu'on désactive les simu de tape saturation.

Mais, dans un avenir pas forcément éloigné, je serais étonné de ne pas voir intégré d'office aux STAN des algo de traitement post-sommation qui émuleraient ce genre de chose (désactivable, pour quand même avoir le choix).

les traitements comme HEAT ne changent rien au fait que la sommation reste une bête addition, c'est un traitement supplémentaire comme n'importe quel traitement qu'on mettrait en insert, il intervient après la sommation sur le flux stéréo résultant.

Citation :

Non, cela n'intervient pas uniquement sur un insert du flux stéréo. Cela intervient également sur chaque piste au moment de la sommation.

 oui, si tu le places sur une piste, mais là encore ça ne change rien au fait que la sommation reste une bête somme, par contre on ne somme plus le même signal, comme quand on met un équa ou n'importe quel traitement sur une piste.

Citation :

Bien évidemment en final il y a une addition et ça on y échappe pas, je n'ai d'ailleurs pas dis le contraire. Juste qu'elle n'est pas aussi "simple" qu'on puisse la présenter

 il y a une contradiction dans ce que tu écrits là, ça ne peut pas rester une bête addition et en même temps être plus compliqué que ça, et je ne vois pas 36 façon de faire une addition, d'autant que comme dit plus haut, c'est normalisé et couvert par l'IEEE754.

Citation :

autrement dit, le problème n'est pas le résultat de l'addition mais le fait que le résultat ait par exemple 1mS de retard entre deux voies. 1 mS c'est minuscule mais ça peut être audible sous forme de filtre en peigne (comme un flanger)

comprend pas cette remarque, les échantillons sont dans l'ordre, sommés dans l'ordre, et en plus on est JAMAIS en temps réel au sens stricte, tout est bufferisé en permanence.

Le seul endroit ou le temporel a un impact sur le son, c'est au moment de la conversion (horloge).

Citation :

J'ai juste besoin d'avoir une définition de ce qu'est un moteur audio à l'heure actuel

pour moi c'est l'architecture du soft, son "block diagram" si tu préfères, tout ce qui définis le trajet que peut virtuellement prendre le signal.

non c'est pas incomplet dans le sens ou ça prend en compte tout ce que fait la console virtuelle du soft, soit pan ,gain et somme, les plugs additionnels n'en font pas partis, qu'ils soient ou non intégrés au soft.

Ce thread répondait à deux questions:

- la sommation est-elle différente d'une STAN à l'autre?

- les STAN ont-elles une couleur sonore propre? parce que certains prétendaient que logic sonnait plus chaud, protools avait plus d'harmoniques, cubase avait une meilleur dynamique etc etc sur une simple lecture de fichiers audios.

Pas besoin d'intégrer des plugs et de faire des mix complexes pour mettre en évidence les réponses à ces 2 questions.

Donc est-ce que ces tests prennent en compte des cas pratiques? non.

Est-ce que ça a un intérêt? pas sûr, parce que je sait pas ce qu'on pourrait vraiment conclure des résultats, vu qu'ils ne seraient pas identiques sur un nul test, mais comme déjà dit, c'est déjà le cas si tu fais deux exports d'une même session d'une même STAN.