Comment AudioLab mesure les choses.

La valeur d’échantillon maximale d’un enregistrement numérique n’est pas la même que la valeur maximale de la forme d’onde continue sous-jacente. Entre deux échantillons situés tous deux confortablement sous 0 dBFS, le signal analogique reconstruit peut brièvement dépasser 0 dB, ce qu’on appelle une crête inter-échantillon. Les limiteurs qui ne regardent que les valeurs d’échantillon les manquent. Les décodeurs de référence des plateformes de streaming, non.

BS.1770-4 Annex 2 spécifie un suréchantillonnage 4× via un interpolateur FIR, suivi d’une détection de crête sur le signal suréchantillonné. AudioLab utilise un interpolateur cubique à 4 points qui insère trois échantillons intermédiaires entre chaque paire d’originaux. La valeur absolue maximale sur le buffer suréchantillonné est rapportée comme le true peak.

L’interpolation cubique suffit pour le facteur 4× que prescrit BS.1770 (la référence de la norme utilise un FIR à 12 taps ; nous restons dans les 0,1 dBTP sur les signaux de test standard). Pour une analyse de qualité mastering, un noyau d’ordre supérieur est préférable ; le relevé d’AudioLab est destiné au travail de loudness diagnostique, non à remplacer un instrument de laboratoire calibré.

La corrélation stéréo dans MixLab est le coefficient de corrélation de Pearson entre les canaux gauche et droit, calculé échantillon par échantillon sur l’ensemble du programme (hors ligne) ou sur une fenêtre glissante de 1024 échantillons (pendant la lecture). Les valeurs vont de +1 (parfaitement mono) à 0 (décorrélé) puis –1 (parfaitement inversé, incompatible avec un repli mono).

Le phase scope est une figure de Lissajous : un tracé 2D avec L sur un axe et R sur l’autre, dessiné à partir d’une fenêtre glissante d’échantillons récents. Une ligne verticale signifie un contenu mono ; un cercle signifie une stéréo décorrélée ; une ligne horizontale signifie un matériel à polarité inversée qui s’annulera jusqu’au silence en lecture mono. L’affichage n’approxime pas : il dessine les paires d’échantillons réelles.

Mid et side sont dérivés de la somme et de la différence habituelles : M = (L + R) / 2, S = (L – R) / 2. Nous prenons la valeur RMS de chacun sur tout le programme ; le rapport side sur mid, divisé par 1,5 et plafonné à 1, est la largeur stéréo que nous rapportons (0 est mono, 1 est large).

La vue spectrale en temps réel utilise l'AnalyserNode intégré au navigateur, qui implémente en interne une FFT avec une fenêtre de Blackman. Pour l’analyse hors ligne, nous utilisons une fenêtre de Hann et une FFT à 4096 points, avec 50 % de recouvrement. Ce choix de fenêtre dégrade légèrement la plage dynamique par rapport à Blackman, mais préserve une meilleure résolution du lobe principal, utile pour la lisibilité visuelle de l’affichage de l’analyseur.

Le meter à sept bandes regroupe les bins de la FFT en bandes réparties de façon perceptuelle. Les choix correspondent aux conventions courantes des outils de mastering :

Sub          20  Hz –   60 Hz
Bass         60  Hz –  200 Hz
Low-mid     200  Hz –  500 Hz
Mid         500  Hz –   2 kHz
High-mid      2 kHz –   4 kHz
Presence      4 kHz –   8 kHz
Air           8 kHz –  16 kHz

Chaque bande rapporte la magnitude spectrale moyenne des bins situés dans ses limites, mise à l’échelle pour que la bande la plus forte vaille 1. Les sept valeurs sont relatives entre elles, pas des niveaux en dBFS. L’espacement des bins à 48 kHz avec une FFT de 4096 points est de 11,7 Hz ; la bande sub ne compte donc qu’environ quatre bins et c’est la plus grossière des sept.

VoiceLab QA rapporte des mesures séparées, pas une note unique. Elles sont tranchées, conçues pour les producteurs de podcasts et de voix off, et explicitement pas une mesure clinique. Ce qui suit est ce que le moteur fait aujourd’hui. Quand une mesure s’est révélée fausse, la section 08 le dit.

• Détection de la parole : le niveau (RMS) est pris toutes les 20 ms sur une fenêtre de 40 ms, et une phrase est un passage au-dessus d’un seuil tiré des propres percentiles de niveau de cet enregistrement : la plus grande valeur entre trois fois le 10e percentile et le milieu entre le 10e et le 70e, jamais sous environ −55 dBFS, et plafonné à la moitié du 70e percentile là où il se situerait sinon au-dessus du 95e et ne trouverait plus rien. Les trous de moins de 160 ms sont comblés et les passages de moins de 100 ms sont écartés. C’est une porte de niveau et pas un reconnaisseur de parole, et on peut la tromper. Nous avons mesuré de combien, sur 111 enregistrements avec la phrase source propre comme vérité de terrain : à 10 dB de rapport signal sur bruit, elle trouve en moyenne 1,2 s de parole en moins, à 5 dB 2,4 s. Cette parole tombe alors en dehors du niveau de parole et du SNR.
• Ce qu’est le matériau actif : chaque trame reçoit l’étiquette voix, musique, bruit ou silence d’après son niveau et la variation de son taux de passages par zéro sur environ une demi-seconde de chaque côté (la parole alterne consonnes et voyelles, la musique est spectralement plus régulière). Les limites ont été ajustées sur un corpus étiqueté : de la parole dans 32 conditions de bruit et de réverbération, de la musique tonale et rythmée, et du bruit de pièce nu. Le résultat se lit comme voix à partir de 60 % de trames proches de la voix, comme mixte à partir de 40 %, sinon comme musique ou bruit. Le retour écrit ne juge ni le SNR, ni le débit, ni les sifflantes sur un matériau qui ne se lit pas comme de la voix.
• Plancher de bruit et SNR : le plancher de bruit est le 10e percentile du niveau. Le SNR global est le niveau moyen de parole moins ce plancher. Un téléviseur ou un camion qui passe ne relève le plancher que sur une partie d’une prise ; le moteur donne donc aussi un SNR par phrase, contre le plancher dans une fenêtre d’environ une demi-seconde autour de cette phrase, et le pire dixième de ceux-ci : une seule phrase inintelligible suffit à rater une annonce, et une moyenne le cache. Les phrases de moins de 200 ms n’ont pas de SNR propre.
• Débit : la fréquence de modulation dominante de l’enveloppe de la parole entre 2 et 8 Hz, en syllabes par seconde, sur l’intervalle de la première à la dernière phrase, pauses comprises. Elle est traduite en une étiquette lent, normal ou rapide. Compter les pics de l’enveloppe a été essayé puis abandonné : sur une phrase lue à trois vitesses, dont le vrai rapport était 1,63 : 1,00 : 0,69, cela donnait 1,12 : 1,00 : 0,98.
• Sifflantes : dans des trames de 4096 échantillons fenêtrées de Hann, la part de la magnitude spectrale entre 5 et 9 kHz. La médiane sur les trames, fois cinq et plafonnée à 1, donne le score : faible sous 0,25, moyen sous 0,55, élevé au-delà.
• Brillance : dérivée du centroïde spectral, pondérée en puissance et comptée seulement jusqu’à 8 kHz. Au-dessus, la parole n’a presque rien, et les milliers de bins presque vides décidaient autrefois du résultat : un plancher de bruit à −96 dBFS, très en dessous de l’audible, faisait passer la brillance de 0,513 à 0,590.
• Écrêtage : compte les suites d’échantillons consécutifs posés sur le pic et classe ce nombre : aucun, faible, moyen ou élevé.
• Intelligibilité, comme approximation : la plus faible de deux rampes : le pire dixième du SNR par phrase et le niveau de parole au-dessus du fond dans les pauses. Chacune vaut 0 à 3 dB et 1 à 18 dB, et est abaissée de 15 % pour un écrêtage moyen et de 40 % pour un écrêtage fort. Clair à partir de 0,65, limite à partir de 0,35, sinon noyé, et seulement avec au moins deux phrases mesurables. C’est une approximation et elle s’appelle ainsi : pas un Speech Transmission Index, qui demande un signal de test joué dans la pièce. C’est une approximation de la facilité qu’aurait un auditeur à suivre la voix, pas de la précision de la reconnaissance vocale : dans notre propre test de 1 248 transcriptions, elle n’a pas prédit les erreurs de reconnaissance (voir son statut sur la page des lentilles).

Il n’y a pas de note composite unique. Les mesures reviennent comme des champs séparés, donc vous fixez vous-même ce qui compte comme réussi. L’étiquette d’intelligibilité est la seule exception, et elle se dit approximation. Une version antérieure de cette page décrivait une note de 0 à 100 ; le moteur n’en a jamais renvoyé.

SignalLab découpe un fichier audio quelconque en régions étiquetées : voix, musique, bruit, silence et écrêtage. C’est un seul pipeline, que VoiceLab partage.

1. Étiquettes de trame : niveau (RMS) et taux de passages par zéro toutes les 20 ms. Chaque trame reçoit son étiquette de son niveau et de la variation de son taux de passages par zéro sur environ une demi-seconde de chaque côté : la parole alterne consonnes et voyelles (un écart de 0,05 ou plus), la musique est spectralement régulière (0,02 ou moins). Les limites ont été ajustées sur un corpus étiqueté (parole dans 32 conditions de bruit et de réverbération, musique tonale et rythmée, bruit de pièce nu) et non devinées, et VoiceLab utilise la même fonction : les deux labs ne peuvent donc pas être en désaccord sur ce qu’est la voix.
2. Fusion des régions : les trames consécutives de même étiquette forment une région, et les régions de moins de 0,3 s sont absorbées par la précédente. L’écrêtage est une passe à part : un passage où, dans une fenêtre, plus de trois échantillons sont à 0,98 de la pleine échelle ou au-delà devient une région d’écrêtage, pour les fichiers très écrêtés.

Les étiquettes de régions sont heuristiques ; le schéma de tags est publié à /docs/signallab/tag-schema. Elles sont utiles pour la navigation et le filtrage en masse. La chronologie des régions vient de ce classifieur de trames simple ; pour une indexation de production à grande échelle, il faudrait là aussi un modèle appris.

Le verdict de fichier, le type de contenu (voice, music, mixed, noise ou unknown), est une étape à part. Sur le site, il vient d’un petit modèle appris (v2) sur 25 caractéristiques simples par fenêtre de 10 secondes ; dans l’API, c’est une option (contentModel v2) jusqu’au 15 janvier 2027, date à laquelle il devient la valeur par défaut. Nous avons testé le premier modèle sur de vraies prises le 12 octobre 2026 : 600 extraits de 20 secondes du corpus MUSAN (200 de parole, 200 de musique et 200 de bruit), une seule passe, rien réglé après coup. Il n’a pas atteint le seuil fixé à l’avance (rappel et précision d’au moins 0,80 pour les trois classes) : il a trouvé 164 des 200 extraits de parole, 91 des 200 extraits de musique et 3 des 200 extraits de bruit. Nous avons ensuite testé v2 une fois, de la même façon, sur les mêmes 600 extraits plus 90 extraits de trois environnements qu’il n’avait jamais vus : il a trouvé 197 des 200 extraits de parole (précision 0,95), 190 des 200 extraits de musique (0,86) et 40 des 90 extraits de bruit stationnaire (précision 1,00 ; la circulation et le métro sont surtout restés unknown). Il atteint le seuil pour la parole et la musique, pas pour le bruit, et reste donc un proxy. Les chiffres complets figurent sous signal.contentType sur /lenses.

Chaque mesure que produit le moteur porte l’un de quatre statuts, et les mêmes mots figurent sur la page des lentilles, la page de l’API, le document OpenAPI et les descriptions des outils MCP. Bêta signifie qu’il n’y a pas encore de test contre une vérité terrain, pas que la mesure est fausse. Une mesure n’est validée qu’avec un test enregistré contre une valeur connue, avec une tolérance, et un proxy reste un proxy jusque-là.

Chaque mesure de la page des lentilles (en anglais) dit contre quoi elle a été testée, contre quoi elle ne l’a pas été, et ce qu’elle n’est pas. La plupart des valeurs de loudness sont validées contre les signaux de test de l’EBU ; les mesures de scène, de contenu et d’intelligibilité sont des proxys ; le score de réverbération qui a échoué a été retiré (voir les corrections ci-dessous). Chaque mesure dit aussi comment elle fonctionne : traitement du signal classique, ou traitement du signal avec un petit modèle appris, qui est alors nommé, avec ce sur quoi il a été entraîné.

On ne peut se fier à une mesure que si son auteur dit quand elle était fausse. Voici les cas de septembre et d’octobre 2026. Chacun a été trouvé en confrontant une affirmation à quelque chose de mesuré, et chacun est corrigé dans le moteur, pas seulement dans le texte.

• Un score de réverbération qui ne mesurait pas la réverbération. L’étiquette de réverbération de VoiceLab (Dry, Tight, Live, Reverberant) montait avec le bruit de fond, pas avec la réverbération. Contre les temps de réverbération mesurés de 24 pièces, de 0,18 à 1,71 s, sa corrélation de rang était de 0,06, et une pièce de 1,71 s obtenait moins qu’une cabine de 0,18 s. Retirée le 27 septembre du moteur, des applications, de l’API et du serveur MCP. Le nombre reste sous le nom de ce qu’il mesure, l’énergie dans les pauses après la parole, et n’abaisse plus l’approximation d’intelligibilité. L’analyse avec les chiffres. Une nouvelle mesure de réverbération ne pourra s’appeler ainsi qu’après avoir passé le même test.
• Des chiffres sans parole. Sur un morceau de musique avec chant, VoiceLab n’a trouvé aucune phrase et a pourtant rapporté un SNR de −66 dB, un débit de 0,0 syllabe par seconde, un risque de sifflantes moyen et 14,3 s de silence. Aucun des quatre n’était mesuré. Ils sont maintenant vides quand aucune parole n’est trouvée, et le lab dit ce que le matériau semble être.
• Deux labs, deux réponses. VoiceLab et SignalLab calculaient chacun leur propre courbe de niveau et leur propre seuil, et divergeaient sur le même fichier : 14,3 s de silence contre 6,3 s de voix. Ils partagent maintenant un seul jeu de faits, et un contrôle sur un fichier synthétique les y tient.
• Une plateforme qui ne se comporte pas comme supposé. Après la normalisation YouTube, un envoi faible apparaissait au-dessus du plafond, mais YouTube, d’après des mesures de tiers, ne relève pas les envois faibles. Spotify le fait, jusqu’à 1 dB de marge. Un résultat après normalisation n’est désormais montré que là où la plateforme publie ce qu’elle fait, et là où elle ne le publie pas, l’outil le dit.
• Les chiffres de loudness et la norme. Cette page disait d’abord que le moteur concordait à 0,05 LU près avec l’implémentation de référence de l’EBU. Le benchmark compare aux valeurs attendues publiées par la norme, jamais à une autre implémentation, et le pire cas est de 0,06 LU. Le texte le dit maintenant.

Des contrôles qui tournent à chaque build empêchent le retour de ces erreurs : la page des prix contre le code, les points d’accès documentés de l’API contre les vrais, les pages de confidentialité contre ce qui charge réellement, les affirmations retirées contre le texte, la loudness contre les signaux EBU Tech 3341 et 3342, et un autotest par module. Un passage séparé casse des choses exprès pour prouver que chaque contrôle peut passer au rouge.

Ne pourrais-je pas faire construire ça par une IA en un après-midi ?

Une interface peut se générer, et une page qui affiche des chiffres se fait vite. Ce qui ne se génère pas, c’est ce qui rend un chiffre digne de confiance : le confronter à quelque chose de mesuré. Notre loudness est contrôlée contre les signaux que définit la norme EBU et reste, au pire, à 0,06 LU. Notre score de réverbération a été confronté à 24 pièces aux temps de réverbération mesurés, a échoué et a été retiré ; la section ci-dessus donne les chiffres. Une copie jamais testée garde un tel score. Ce qui reste n’est pas le code mais les tests, une liste honnête de ce que nous ne mesurons pas, et un seul moteur derrière les labs du navigateur, l’API et le serveur MCP.

Est-ce open source ?

Non. Le moteur de mesure est propriétaire. Ce qui est public : la spécification de l’API sur /openapi.yaml, le serveur MCP et le SDK IA sur npm, et un dépôt public pour le serveur MCP sur github.com/Audio-Launch/audiolab-mcp-server. Les normes que nous implémentons et les signaux de test contre lesquels nous contrôlons sont publiés par leurs propriétaires, et la section sur la loudness explique comment refaire les contrôles vous-même. Les labs du navigateur n’envoient aucun audio chez nous, et l’onglet réseau de votre navigateur vous le montre.

Une IA l’a-t-elle écrit, et est-ce du vibe coding ?

Une bonne partie du code est écrite avec des outils d’IA, et ce n’est pas du vibe coding. La différence tient à ce qui se passe une fois le code écrit. Faire du vibe coding, c’est accepter ce qui sort et le publier parce que ça tourne. Être assisté par l’IA, c’est qu’une personne décide ce qui est mesuré et contre quoi, et que rien n’est cru sur parole : chaque push lance le benchmark de loudness contre les signaux de test EBU, un autotest par module, et des contrôles que la page des prix, la documentation de l’API et les pages de confidentialité correspondent à ce qui tourne vraiment. Quand une mesure se révèle fausse, elle est retirée et la page le dit. La section ci-dessus recense ces cas ; un travail jamais relu ni testé n’en a aucun à citer.

Les chiffres sont exacts dans les tolérances documentées ci-dessus, mais il s’agit d’un analyseur basé sur le navigateur qui tourne sur le CPU de l’utilisateur. Ce n’est pas un substitut à :

• Un loudness-mètre matériel calibré pour les audits de conformité broadcast.
• Un analyseur audio de qualité laboratoire pour tester amplificateurs ou convertisseurs.
• Un instrument d’audiométrie clinique : HearLab est explicitement non médical.
• Un encodeur/décodeur de référence pour vérifier la conformité d’un codec.
• Un réverbéromètre pour un enregistrement. VoiceLab rapporte l’énergie dans les pauses après la parole, qui monte avec le bruit comme avec la réverbération. Pour la réverbération, RoomLab la mesure à partir d’un claquement de mains.
• Un compteur de mots, de tics de langage ou de changements de locuteur. Aucune lentille ne les compte.

Ce qu’il est, dans l’esprit du reste du site : une mesure fonctionnelle, rapide et défendable que vous pouvez exécuter dans les labs du navigateur sur n’importe quel fichier audio sans rien téléverser sur un serveur, avec les calculs entièrement documentés et le chemin de code pouvant être relié depuis chaque démo jusqu’ici.