Sound Designers

J'utilise Insight pour les mesures.
Bref tout ça pour dire, que les plugins "standards" ne marchent pas pour ça...

Et que le ISL de chez Nugen ne fonctionne pas aussi bien qu'ils le disent.

Bonjour, pour corroborer ces choix, le dernier Élixir de Flux::, les iZOtope Ozone 5 (et maintenant 6) ne m'ont pas posé de problèmes. Quelque soit la destination, systématiquement je finalise la version publiée avec un de ces deux limiteurs True Peak (meme pour une édition en CD). Après avoir vérifié le résultat de la limitation en AAX en temps réel sur Pro Tools 11, j'applique les réglages en AudioSuite sur le fichier finalisé. Il n'y a pas de différence de traiement entre ces deux procédures, ce qui n'est pas vrai pour toutes les stations de travail (je me rappelle avoir constaté des différences audibles avec Waveslab).

En matière d'affichage, j'utilise Insight ou PPMulator, voire Flux:: Pure Analyser System (ce dernier est plutôt capricueux en terme de stabilité, sa mesure est exacte, très précise, et doit être installé de préférence sur un second ordinateur).

Comme notre production actuelle sera un jour ou l'autre forcement publiée avec de nombreux algorithmes de compression de données (du mp3 à l'AAC, mpeg2...) il est très très important de respecter l'absence de True Peak dans les mixages. La présence d'une seule True Peak peut mettre en échec la qualité sonore d'un segment de 50ms de son lors de la décompression du flux sonore. Ces problèmes ne se posent pas si l'on reste en PCM, évidemment.

Parmi mes grands regrets, Sonnox n'a pas passé en AAX son analyseur Fraunhofer Pro-Codec qui va beaucoup plus loin que la simple analyse basiques des True Peaks. Ce bel outil etait vraiment génial pour vérifier la robustesse à la compression de donnée de tout mixage avant publication. Et nous l'avons encore qu'en RTAS donc complètement incompatbile avec Protools 11.

Bien amicalement

cedric34 a écrit :Je ré-ouvre le sujet comme je viens de mixer un trailer et malgré différents tests que ça soit avec un L1, ML4000, le ISL cité ci-dessus, le Maxim (de Protools) je me retrouve avec entre 0.2 et 0.3dBTP au dessus de la valeur qui est censé être limitée par le plugin (-1).

Normal puisque ce ne sont pas de limiteurs True Peak...
Avec ce type de limiteur (perso, j'utilise pas mal le ML1000 inclu dans le ML4000), il faut descendre au moins à -4,5/-5 pour être sûr que rien ne passe au dessus d'un -3 par exemple.
Ceci dit, Maxim, oublie, c'est une horreur ce truc (saturation and co).

ISL de Nugen EST un limiteur True Peak ! Je suis étonné d'entendre qu'il ne marche pas ???

Bah oui, ça m'a étonné aussi... Lors de mes tests j'ai mis la limite à -1dBTP sur l'ISL (en manuel et avec les différents presets en remettant la limite à -1), et en mesurant derrière avec Insight ça montait à -0.8dBTP...

Donc ok c'est pas grand chose, mais 0.2 quand même...

Comme l'algorithme de détection des True Peak est basé sur de la prédiction, il y a un risque de constater des différences sur le relèvé des mesures des programmes de différents éditeurs.

Bien amicalement

Merci pour les précisions Labroue, à chacun de vos posts, j'apprends pleins de choses !

Je pensais que les limiteurs True Peak utilisaient plus ou moins les mêmes algorithmes, visiblement non...
Donc je vais m'orienter vers l'Elixir pour mon prochain achat, qui lui correspondait bien entre la limite fixée et la mesure

PS : j'ai refais les tests en audiosuite/offline, ça donnait les mêmes résultats.

Avec plaisir,

La recommandation de UIT, la ITU-R-BS.1770-2, dans son annexe 2, offre un guide pour celui qui développera son algorithme de détection des True-peak (Guidelines for accurate measurement of “true-peak” level). Dans l'appendice 1-2 de cette annexe, la recommandation précise des considérations pour améliorer la précisions de la détection (Considerations for accurate peak metering of digital audio signals). En revanche aucun algorithme de calcul mathématique n'est donné précisément. Cette annexe contient suffisamment de descriptions (dont certaines sont mathématiques) pour aboutir à l'objectif fixé. Ce ne sont que des lignes directives, avec de surcroît des éléments optionnels, que le développeur pourra choisir ou pas (optional pre-emphasis shelving filter, optional DC blocking filter). Je ne sais pas si le développeur propose, sous forme de case à cocher, ces options à l'utilisateur ?

Par contre, pour le Loundness Range, l'algorithme est vraiment fourni par l'UER. Il n'y a plus qu'à l'introduire dans son code. Il s'agit d'une implémentation bien plus simple.

Bien amicalement

Quid du limiter TP intégré dans le WLM Plus de chez Waves?

Au passage Cedric34, si ça t'intéresse je vends une licence ElixirV3 AAX/Native.