Normalisation de crête contre normalisation de sonie, et la cible qu'on ne peut pas atteindre

Crête et sonie répondent à deux questions différentes

La normalisation de crête pose une question : quel est l'échantillon le plus fort de ce fichier, et par quelle constante multiplier le tout pour qu'il atterrisse exactement sur un plafond choisi ? C'est une mesure et une multiplication. C'est rapide, exact et à peu près inutile pour faire sonner deux enregistrements à force égale, parce que l'instant le plus fort d'un audio ne dit rien de la force ressentie. Un enregistrement clairsemé d'une voix avec un claquement de porte, et un mur de musique dense, peuvent culminer exactement à la même valeur d'échantillon alors que l'un paraît plusieurs fois plus fort que l'autre.

La normalisation de sonie pose l'autre question : quelle force ce programme entier donne-t-il à entendre, et de combien faut-il le déplacer pour qu'il en donne autant que tout le reste ? Y répondre demande un modèle de l'audition, et il en existe un : l'ITU-R BS.1770 définit un filtre qui approche la réponse en fréquence de l'oreille, additionne les canaux avec des poids fixes et — surtout — écarte les passages calmes pour qu'un long silence final ne tire pas le chiffre vers le bas. Le résultat est une sonie en LUFS, et deux fichiers qui mesurent la même valeur en LUFS sonnent réellement à peu près aussi fort. L'EBU R 128 est la pratique bâtie sur cette mesure, et c'est de là que viennent les cibles.

Cet outil ne fait que la seconde. Il n'y a pas de bouton de normalisation de crête, et c'est le bon choix : la normalisation de crête, c'est ce que voulait dire la case « normaliser » des gestionnaires de fichiers d'autrefois, et cela ne faisait presque jamais ce qu'on attendait. Ce que l'outil garde du monde des crêtes, c'est un plafond — une limite de crête réelle, à −1 dBTP par défaut — et ce plafond se révèle la commande la plus lourde de conséquences de la page, pour des raisons qu'aborde la troisième section.

Deux passes, et pourquoi une seule ne suffit pas

Un normaliseur de sonie en une passe a une tâche impossible : il doit décider à chaque instant du gain à appliquer, en ne connaissant que ce qu'il a déjà entendu. Devant une ouverture calme, il la remonte, puis un refrain fort arrive qu'il doit rabaisser. Le résultat est un enregistrement dont l'équilibre interne a été réarrangé par un algorithme qui devine l'avenir — c'est un compresseur, pas un normaliseur, et ce n'est pas ce qu'avait en tête celui qui demandait une normalisation.

La forme en deux passes supprime la devinette. La première passe lit tout le programme et imprime ses mesures : sonie intégrée, crête réelle, plage de sonie et seuil de porte utilisé. Ces quatre nombres, plus un décalage de cible, sont rendus à la seconde passe, qui connaît désormais la réponse avant de commencer et peut appliquer un gain constant du début à la fin. Rien n'est réarrangé ; l'enregistrement est simplement déplacé. C'est ce que signifie la normalisation linéaire, et c'est ce que l'outil demande avec linear=true.

Quand il y a de la marge, cela fonctionne exactement comme annoncé. Une tonalité de test régulière mesurée à −29,75 LUFS avec des crêtes très basses à −26,02 dBTP, à qui l'on demande la cible de diffusion de −23 LUFS, est sortie à −23,05 LUFS : cinq centièmes de décibel de l'objectif, ce qui en pratique est l'objectif. La conception est saine. Le problème, c'est ce qui arrive quand il n'y a pas de marge.

La cible demandée n'est pas toujours la cible obtenue

linear=true n'est pas une instruction, c'est une préférence. Le loudnorm de ffmpeg applique un gain constant seulement si cela maintient la crête réelle sous le plafond que tu as fixé. Si le gain constant qu'impliquent les mesures devait franchir ce plafond, le filtre abandonne discrètement le mode linéaire et retombe sur son algorithme dynamique — qui respecte le plafond et, ce faisant, ne peut pas atteindre ta cible de sonie. Rien dans le journal n'annonce le basculement. L'outil affichait le nombre demandé et appelait l'écart « correction appliquée » ; il repasse désormais le fichier produit dans le même mesureur et affiche ce qui en revient, si bien que le chiffre à l'écran est un chiffre mesuré et non un chiffre demandé.

Voici ce que cela coûte sur du matériel parfaitement ordinaire. Prends un programme mesuré à −16,06 LUFS dont les crêtes sont à −0,09 dBTP — un profil tout à fait normal pour n'importe quoi masterisé depuis vingt ans, puisque presque tout est poussé près de la pleine échelle. Demande la cible streaming par défaut de −14 LUFS avec le plafond par défaut de −1 dBTP. Un gain linéaire d'environ deux décibels porterait ces crêtes à quelque +1,9 dBTP : le mode linéaire est donc refusé. Le fichier résultant mesure −15,59 LUFS : le gain réel a été d'un demi-décibel, pas des deux annoncés par le panneau. Le panneau affichait « Mesuré : −16,1 LUFS → −14,0 LUFS · Correction appliquée : +2,1 LU », dont chaque mot était une supposition déguisée en mesure. Il affiche désormais −15,59, parce que la sortie est mesurée avant que quoi que ce soit ne soit montré — et quand le résultat atteint s'écarte d'une demi-unité ou plus de la cible, la cible est affichée à côté pour que tu voies que le filtre a refusé.

L'écart se creuse sur du matériel à large plage de sonie. Un programme à −13,15 LUFS contenant un unique transitoire à pleine échelle, à qui l'on demande −14 LUFS, est sorti à −26,71 LUFS — près de treize décibels sous la cible, et audiblement faible. Le même fichier passé dans un loudnorm simple en une passe, ce contre quoi la note de l'outil met en garde, a atterri à −14,75 LUFS. Ce n'est pas un argument contre les deux passes ; deux passes sont justes pour la grande majorité des fichiers. C'est un argument pour se méfier d'un affichage qui n'a jamais été mesuré. Si le résultat sonne faux, il est peut-être faux, et le moyen de le savoir est de mesurer la sortie toi-même plutôt que de lire le panneau.

Quelle cible, et pourquoi plus fort n'est pas mieux

Trois préréglages couvrent l'essentiel. −23 LUFS est la cible de diffusion européenne, inscrite dans l'EBU R 128 et attendue par la télévision. −16 LUFS est un usage courant pour les podcasts parlés, pas une norme publiée par qui que ce soit. −14 LUFS est à peu près le niveau auquel les grands services de streaming normalisent la lecture, et c'est le réglage par défaut ici. L'indication du préréglage regroupe Spotify, YouTube et Apple Music à −14 ; les chiffres publiés pour ces services ont bougé au fil des ans et ne sont pas tous identiques, alors prends −14 comme un voisinage plutôt qu'une spécification, et sers-toi du curseur sur mesure si on t'a donné une valeur à atteindre.

Ce qu'il faut intégrer, c'est que sur une plateforme qui normalise, livrer plus fort que la cible ne rapporte rien. La plateforme baisse ton morceau à sa propre référence sur le chemin de l'auditeur. Ce qui ne revient pas, c'est tout ce que tu as sacrifié pour être fort — les transitoires aplatis, la dynamique compressée. Tu arrives au même volume de lecture que tout le monde, avec moins de choses dans l'enregistrement. Normaliser en amont, au chiffre qu'utilise la destination, c'est ainsi qu'on garde la dynamique tout en atterrissant au bon volume.

La normalisation ne défait pas un écrêtage déjà inscrit

L'écrêtage survient quand un signal a dépassé la valeur maximale qu'un échantillon peut contenir, et que ce qui dépassait a été purement et simplement coupé. Il reste un sommet plat là où il y avait une courbe, et le son produit est cette arête dure qu'on appelle distorsion. L'information qui se trouvait au-dessus du plafond n'est ni atténuée ni cachée : elle n'existe pas dans le fichier. Aucun traitement ultérieur ne peut la ramener, parce que rien n'a enregistré ce qu'elle était.

Passer une source écrêtée dans cet outil le démontre proprement. Un fichier de test volontairement écrêté mesurait −1,55 LUFS avec une crête réelle de +0,10 dBTP — au-dessus de la pleine échelle, ce à quoi sert précisément un indicateur de crête réelle : il reconstruit ce qui se passe entre les échantillons et trouve les dépassements qu'un indicateur de crête d'échantillon rate. Normalisé à −14 LUFS, il est sorti à −14,35 LUFS avec une crête réelle de −12,67 dBTP. Le niveau est désormais correct et le plafond largement respecté. Les sommets plats sont toujours plats. Baisser une distorsion donne une distorsion plus discrète.

Ce qui sort — et le fichier qu'on ne peut pas faire entrer

Donne-lui une vidéo et l'image est recopiée avec -c:v copy, intacte, tandis que le son est remplacé par une nouvelle piste AAC à 192 kbit/s — de l'Opus au même débit pour un conteneur WebM, puisque le WebM ne peut pas porter d'AAC. Donne-lui de l'audio et tu choisis la sortie : MP3 à 192 kbit/s par défaut, ou WAV en PCM 16 bits, M4A en AAC, OGG en Vorbis à la qualité 5, ou FLAC. Il n'y a pas de copie de flux, ce qui est inévitable — les échantillons ont changé, il faut donc les réécrire. Si ta source est sans perte, choisis FLAC ou WAV ; laisser le MP3 par défaut transforme un master sans perte en fichier avec perte, comme effet secondaire d'un réglage de volume.

Une chose arrêtait certains lecteurs avant même de commencer. Bien que l'outil porte le nom de l'audio, propose cinq formats de sortie audio et affiche « Choisir un fichier audio ou vidéo » au-dessus de sa zone de dépôt, son sélecteur de fichiers était configuré pour la vidéo seule : la liste acceptée contenait MP4, MOV, WebM, MKV, AVI et M4V et aucun type audio, si bien que déposer un MP3 était refusé comme mauvais type et que toute la branche audio — les boutons de format, les sorties MP3 et FLAC — restait inatteignable par le sélecteur. Celui-ci accepte désormais les deux, et l'étiquette décrit enfin ce que fait l'outil. Il vaut la peine de comprendre pourquoi ce genre de défaut survit : tout ce qui est en aval du sélecteur fonctionnait parfaitement, donc rien n'échouait, rien n'était testé, rien n'était journalisé. La fonction était simplement derrière une porte que personne ne pouvait ouvrir.

Questions fréquentes

Cet outil fait-il aussi de la normalisation de crête ?

Non. Il ne fait que de la normalisation de sonie, via le filtre loudnorm de ffmpeg, qui mesure en LUFS selon la méthode ITU-R BS.1770. Ce qu'il garde du monde des crêtes est un plafond de crête réelle, qui est une limite et non une cible : il dit jusqu'où le résultat a le droit d'approcher la pleine échelle, pas à quelle force il doit sonner. Si tu voulais vraiment une normalisation de crête — chaque fichier mis à l'échelle pour que son échantillon le plus fort atterrisse à la même valeur — tu constaterais que deux clips sonnent toujours très différemment, et c'est pourquoi presque personne n'en veut une fois l'alternative entendue.

Le panneau dit que la cible est atteinte. Puis-je me fier à ce chiffre ?

Seulement la première moitié. Le chiffre « Mesuré » est réel — il vient de la première passe, qui a réellement analysé ton fichier. Le second n'est pas du tout une mesure : c'est la cible que tu as choisie, réaffichée, et la correction indiquée n'est que la différence arithmétique entre les deux. Si ffmpeg a refusé le gain linéaire parce qu'il aurait franchi le plafond de crête réelle, la sortie est ailleurs et rien sur la page ne te le dira. Le signe qui alerte : une source qui culmine déjà près de la pleine échelle et qui est plus faible que ta cible. Cette combinaison ne peut pas être satisfaite, et le résultat restera en dessous.

À combien régler le plafond de crête réelle ?

Laisse-le à −1 dBTP pour tout ce qui sera réencodé après toi, c'est-à-dire presque tout. Un encodeur avec perte ne reproduit pas exactement tes échantillons ; il reconstruit une approximation, et cette approximation peut légèrement dépasser là où se trouvaient tes échantillons. Laisser un décibel de marge donne à ce dépassement un endroit où aller au lieu d'écrêter dans le lecteur de l'auditeur. Remonter le plafond vers zéro t'achète un peu de force sonore et dépense ta marge de sécurité, et cela ne rend pas moins probable le refus du mode linéaire décrit plus haut.

La normalisation peut-elle réparer un enregistrement déjà distordu ?

Non, et il vaut mieux le dire franchement. Si l'enregistrement a écrêté au moment de la prise, les crêtes au-dessus du maximum ont été jetées à cet instant ; le fichier contient des sommets plats là où il y avait des formes d'onde, et rien nulle part ne consigne à quoi ressemblaient les parties manquantes. La normalisation change le niveau, donc la distorsion devient plus discrète, mais la forme demeure. Un fichier de test écrêté mesurant une crête réelle de +0,10 dBTP est sorti de l'outil à −14,35 LUFS, ses crêtes bien rangées à −12,67 dBTP et ses sommets plats parfaitement intacts. Si tu peux réenregistrer, réenregistre. Sinon, des logiciels spécialisés de dé-écrêtage devinent la courbe manquante, avec des résultats inégaux.

À quoi sert le curseur de plage de sonie, et faut-il y toucher ?

Il décrit de combien le niveau a le droit de bouger sur la durée du programme, mesuré en unités de sonie, et vaut 11 LU par défaut. Il compte quand loudnorm travaille en dynamique plutôt qu'en linéaire : une valeur basse aplatit davantage l'écart entre passages calmes et forts, une valeur haute les laisse plus éloignés. Quand la voie linéaire est prise — le cas normal, quand il y a de la marge — tout le programme est déplacé d'une constante et la plage n'est pas touchée : le curseur ne change alors rien du tout. Laisse-le où il est sauf si on t'a spécifié une plage, et si tu te surprends à le baisser pour rendre audible une parole ténue, ce que tu veux vraiment est un compresseur, pas un normaliseur.