Séquenceurs / DAW : dans quel cas, à quel niveau peuvent-ils saturer en interne ?
- 266 réponses
- 18 participants
- 19 660 vues
- 25 followers
Phil443
Citation : par exemple afficher sur le peak-mètre le niveau du signal après-reconstruction pour éviter tout clip inter-sample.
Oui, ça c'est un problème, mais ça va nous faire probablement encore une nouvelle norme à assimiler : je propose le dBEFS (entire full scale) ou quelque chose du genre.
Encore un sujet qui va nous occuper sur AF pour de longues années avec des sujets du style : "au secour, aider moi, j'est pas comprit les Dbefs" ou : "cé koi la diférance entre dbfs et dbefs ?"...
Il faudra en effet bien dissocier les deux sortes de peak-mètres, sous peine de voir se réitérer les erreurs que l'on constate déjà, mais en pire puisqu'un habitué des "EFS" risque de se faire salement piéger s'il tombe sur du FS tout court et ne fait pas gaffe...
En attendant, je vous le re-dis : ne sur-modulez pas vos mixes avant pre-master les amis : vous avez tout à y perdre.
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
bouyakaboy
phil, concernant les peak metres ne t'inquiète pas, ils sont précis au sample près (quand ils sont bien implémenté dans les softs pas trop pourris, sinon on est d'accord que la fonction ne sert strictement à rien) et il n'y a pas de valeur qui passe à la trappe comme tu l'as laissé supposé. Ce qui rentre c'est ce qui est affiché !
Concernant les limiteurs brickwall (Valable pour tous traitement d'ailleurs)
Citation : Mais sommes-nous d'accord pour dire que dans les deux cas, il y a un retard ?
Non il n'y a pas de retard ! On fait ce que l'on veut avec les données ! Si le developpeur veut que le brickwall coupe net au sample près il pourra le faire sans problème et il n'y aura pas de valeur qui dépasse, temp reel ou pas ! C'est à ça que sert un ordinateur ! On a des données en entrée, on veut tel résultat en sortie, on applique l'algo qu'il faut et on a ce que l'on veut, ni plus ni moins.
D'ailleur j'ai bien vérifier dans le sdk vst steinberg on peut gerer un traitement(ils appel ça process) sur un block de sample dont on peut définir la taille(de 1 sample à x samples).
J'imagine que c'est pareil pour toutes les autres api de plug dispo sur le marché mais j'ai pas envie de tout vérifier. Si vst le fait ça me suffit. Peut être qu'un developpeur multi format pourra nous eclairer sur les autres api.
Citation : Le seul endroit ou c'est important c'est sur le bus master qui va être converti lui en 16 ou 24 bit au mastering(et comme il y a des outils pour gerer ça il n'y a pas de risque à avoir.) C'est pour ça que je disait "on s'en fou". Il n'y a pas de problème avec les faders pour en revenir au debut...
Citation : Ah, alors que l'on m'explique : j'ai quand même vu un tas de DAW's (dont les miennes) qui permettent d'insérer des effets externes sur les busses de sous-groupes, où l'on peut assigner les Aux Send aux sorties physiques de la carte son, pour les re-rentrer en return via un bus assigné aux entrées, ce qui permet (et heureusement d'ailleurs) de traîter avec du matos extérieur exactement comme on le ferait sur une console analo.
Si les informaticiens se sont foutus de la qualité du signal sur les groupes et départs d'Aux, c'est plutôt grave là, docteur !
Oui j'avais effectivement oublié de parler aussi des buss d'effet externe, mais c'était implicite puisque qu'il y a conversion comme pour le master.
T'inquiete pas, les informaticien on pensé a tout(pas toujours de 1er coup).
Citation : Les ingés-son et utilisateurs ont expliqué cela aux informaticiens et ces derniers ont corrigé le tir : Il n'est pas indispensable de se lancer des cailloux pour se comprendre.
Oui tu as raison pour les cailloux, je ne voulais pas en venir là. Pour moi ct juste une poigné de sable
Citation : Par contre attention avec tes fichiers 32 bits à +100dB , je pense que tu n'auras pas un tel headroom. Je ne sais pas quelle est la limite précisément, mais je pense qu'elle est moindre que sur les bus internes.
Sisi, le headroom est exactement le même, je me suis arreté à 100db car j'ai rempli les 8 slots pour ajouter du gain, mais j'imgine qu'avec 300db c'est pareil...
Une fois le fichier exporté puis réimporté dans cubase (bon c'est sur qu'à l'affichage ça fait bizzare il est pas beau et parrait tout ecreté) il suffit de baisser le fader pour se rendre compte que le fichier est pas du tout saturé, que la reverb en aux qui a été attaqué avec +100fs n'a pas bronché et qu'il n'y a aucune saturation, le tout sonne nickel. La qualité est identique avec l'export original sans tout ce gain de ouf malade ! Cela meriterais un petit test des 2 fichier hors phase mais à l'oreille en tous cas on voit pas la différence.
Citation : Tout ça a aussi un rapport avec la normalisation. Normalement on n'a jamais besoin d'en faire une, ça n'apporte rien. Mais si jamais on en fait, il faut la faire à -1, -3 voire -6dBFS, mais pas à 0, sans quoi on risque ce clipping inter-samples. Surtout si c'est un fichier final, destiné à l'écoute.
Tu peux normaliser à 0db même à +10db(cette fonction stupide n'existe pas heuresement) du moment que le fichier est en 32bit float ça risque rien(mais bon je vois pas bien l'interet de la manip). Après tu pourra traiter avec des plugs qui gère l'intersample avant effectivement de sortir le fichier final, il n'y aura pas de probleme.
Citation : Dès qu'on est plus en virgule flottante, on perd le headroom des bus internes. C'est valable pour :
- toute conversion N/A (donc autant sur la sortie "master" que sur un send vers un effet extérieur)
- toute conversion vers un format à virgule fixe (le bounce notamment...)
- tout passage par un plug-in qui n'exploite pas la virgule flottante.
Donc sur un aux send vers un effet hardware, il faut faire gaffe à ne pas saturer, et même à avoir un peu de marge pour éviter les clips inter-samples.
La bonne nouvelle c'est que si le niveau interne au DAW est trop important, tu peux baisser le niveau sur le bus, avant l'envoi, pas besoin de toucher aux pistes. Tu peux aussi insérer le peak-meter de SSL. Après il faut bien faire gaffe à l'ordre des plug-ins, de peak-mètre, des entrées et sorties dans le DAW
tout est presque vrai mais ça résume bien, +1 Mr pouet.
Il est possible de bouncer en 32 bit float. L'interet a été expliqué dans le doc cubase en début de thread. C'est pour justement pouvoir baisser ensuite ce fameux fader sans se prendre la tête !
Citation : Et au-delà du côté pratique il y a aussi le soucis de fournir la bonne information : par exemple afficher sur le peak-mètre le niveau du signal après-reconstruction pour éviter tout clip inter-sample.
Je ne suis pas sûr que ça arrive souvent, ni que ça s'entende à mort (voir l'exemple audio de cette page qui ne cliquette pas sur l'interface audio de mon powerbook, ou ces tests ). Mais c'est un peu triste que ce ne soit pas mieux traité dans les manuels des DAW, ni dans le peak-mètre du master. A moins que ça bouffe un max de CPU, mais faudrait au moins expliquer le truc. D'ailleurs là le gars relève plusieurs bêtises (ou au moins approximations) écrites dans les manuels de logiciels...
Déja efectivement ça arrive pas souvent, ça s'entend pas forcement. Et c'est vrai que ça demande du calcul qui n'est pas necessaire. Donc si on fait ça sur chaque piste on va bouffer du cpu pour que dalle. Et surtout le truc c'est que je vois mal un editeur de logiciels faire ça car la reconstruction est différente suivant le convertisseur que tu va utiliser ! Chez prism c'est différent de chez ssl et de chez beringher. C'est donc au constructeur de faire ce petit plug et c'est ce qu'à fait ssl.
La saturation en interne des daws 32 bit float n'existe pas ! tous les editeurs le dise il sufit de les croire... Après chacun sa méthode de travail... Tant que l'on sait ce que l'on fait y a pas de problème. Mais j'avoue que c'est quand même bien pratique.
C'est pas tout ça mais j'ai un mix à faire... celui là je compte bien lui mettre les 60 pistes dans le rouge !
Dr Pouet
- pour le 32 bits flottant, on a 24 bits de mantisse et 8 d'exposant ?
- (en supposant qu'on a 24 bits de mantisse et 8 d'exposant) comment est représenté les 0dBFS : avec l'exposant à zéro et la mantisse à 1 ?
- Dans ce cas, le headroom correspond à un passage de l'exposant de 2^0 à 2^7= 127, soit : 20log(127) = 42dB. D'où ma remarque : "en 32 bits flottants, on sature à +42dBFS". Je me trompe ?
Citation : Tu peux normaliser à 0db même à +10db
Je pensais à des wav classiques, donc en virgule fixe, donc sans headroom. C'est vrai que j'ai oublié de le préciser. ;)
Citation : Donc si on fait ça sur chaque piste on va bouffer du cpu pour que dalle.
C'est clair. Il ne faudrait le faire que sur des sorties ! Ou alors proposer en standard un plug-in capable de le faire, et l'expliquer dans la doc.
Citation : Et surtout le truc c'est que je vois mal un editeur de logiciels faire ça car la reconstruction est différente suivant le convertisseur que tu va utiliser !
Peut-être. Mais la différence entre les méthodes de reconstruction seront faibles par rapport à un peak-mètre sans reconstruction. De plus, en théorie (voire dans la norme Red Book ? ), la reconstruction devrait être faite à base de sinusoïdes, donc selon un algo unique. Du reste, vu qu'il y a un filtrage après pour virer les harmoniques supérieures à 22kHz, on doit de toute façon être vraiment proche d'une reconstruction par sinus...
Citation : Non il n'y a pas de retard ! On fait ce que l'on veut avec les données ! Si le developpeur veut que le brickwall coupe net au sample près il pourra le faire sans problème et il n'y aura pas de valeur qui dépasse, temp reel ou pas !
Là tu parles de ce qu'il est possible d'écrire dans un plug-in. Mais l'autre question est : est-ce que c'est fait comme ça ?
Il me semble que tu disais plus haut que non, car ça ne sonnerait pas bien, ça ferait comme une saturation (ou au moins une distorsion, ce qui me semble logique). Dans ce cas, même le brickwall le plus violent mettrait quelques instants à se déclencher. On est bien d'accord ?
Citation : La saturation en interne des daws 32 bit float n'existe pas ! tous les editeurs le dise il sufit de les croire...
Il faut quand même au moins le vérifier dans la doc de chaque soft ou faire un test. Par exemple, sauf erreur de ma part, Reaktor 4 sur Mac sature à partir de 0dBFS, comme s'il travaillait en virgule fixe, sans headroom. Du coup si tu ne fais pas gaffe... Ca couine !
Citation : Il est possible de bouncer en 32 bit float.
Certes. Mais corrige-moi si je me trompe : le wav ou l'aiff ne supportent pas le 32 bits flottants, du coup chaque fichier risque d'être lié à une marque de logiciel, non ?
Merci pour les infos que tu nous apporte.
Phil443
Citation : Oui tu as raison pour les cailloux, je ne voulais pas en venir là. Pour moi ct juste une poigné de sable
OK, Y'a pas de mal !
Citation : Dans ce cas, même le brickwall le plus violent mettrait quelques instants à se déclencher. On est bien d'accord ?
Ca, c'est la question qui me turlupine un peu : même si le courant électrique va vite (273,000km/s dans le cuivre), le signal doit parcourir physiquement un trajet donné et complexe dans la partie hardware de l'ordi. Hors élément résistif, il faut compter déjà 40ns pour qu'un électron se mette en mouvement dans un circuit ouvert et que l'on ferme...
Or un circuit harware est truffé de résistances, de capacités... il serait étonnant que tout cela ne génère pas un retard mesurable dans le sens où le temps mis par l'information pour arriver au soft qui déclenche un limiteur n'est pas nul.
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
Dr Pouet
Anonyme
Anonyme
Phil443
Citation : on n'est plus vraiment en temps réel non plus car dans ce cas la latence est obligatoire.
C'est bien ce qu'il me semblait...
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...
Anonyme
JM
CaptainBoom
- < Liste des sujets
- Charte