/docs · VoiceLab · Practical
Trouver les paquets perdus dans un enregistrement
Le profil chain compte les trous de silence numérique qu’un paquet perdu laisse au milieu de la parole. Comment il décide, les chiffres du test, ce qu’il ne voit pas et pourquoi la mesure d’écho et de slapback n’est pas proposée.
Mis à jour 13 oct. 2026
Quand un appel ou un flux perd des paquets et que le lecteur ne le masque pas, l’audio a un trou : quelques dizaines de millisecondes de silence numérique au milieu d’un mot. Le volume, le bruit et le spectre sont tous corrects, et c’est pourquoi rien d’autre dans le moteur ne le voit. Le profil chain de POST /v1/analyze/profile compte ces trous. C’est un preset payant, comme tout profil sauf basic.
curl https://audiolab.tools/v1/analyze/profile \
-H "Authorization: Bearer $AUDIOLAB_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/call.wav", "profile": "chain"}'Ce qui revient
| Lens | Ce que c’est |
|---|---|
chain.dropoutCount | Le nombre de trous abrupts de silence numérique, 8 à 500 ms, dans le son. |
chain.dropoutSec | Leur longueur totale en secondes. |
chain.dropoutMaxMs | Le plus long en ms, null s’il n’y en a pas. Un paquet perdu fait en général 20 ms ; 60 ms ou plus, ce sont plusieurs à la suite. |
Les trois sont validées. Un enregistrement de moins de 2 s n’obtient aucune valeur.
Comment il décide
Un trou compte s’il est du silence numérique (chaque échantillon sous un demi-pas de 16 bits, ce qu’une pièce ou un microphone ne donne jamais), dure 8 à 500 ms et coupe le son : dans les 5 ms avant et après, le niveau est à moins de 20 dB du niveau actif de l’enregistrement. Une pause naturelle, ou la porte d’un suppresseur de bruit, laisse d’abord le son s’éteindre et ne compte pas. Un trou tout au début ou à la fin du fichier ne compte pas non plus.
Jusqu’où lui faire confiance
Éprouvé le 13 octobre 2026 sur des données sur lesquelles la mesure n’avait pas été développée, avec des critères écrits à l’avance (PREREG-DROPOUT.md dans le dépôt du moteur) :
- Sur 160 enregistrements construits de parole lue avec 11 337 trous découpés dedans, dont 8 411 coupaient le son : il en a trouvé 99,8 pour cent, et 99,9 pour cent des 8 406 trous qu’il a signalés étaient réels (un trou compte quand son début et sa longueur sont à moins de 2 ms de ce qui a été découpé). Le nombre était à moins de 5 pour cent, ou d’un trou, pour les 160 enregistrements.
- Aucune fausse alerte dans 1 615 enregistrements sans trous : 40 propres, 40 avec des pauses naturelles de silence numérique et 1 535 enregistrements de voix synthétiques dans 32 situations (bruit, réverbération, bande téléphonique, écrêtage, parole rapide).
- Sur une perte de paquets simulée (paquets de 20 ms mis à zéro, 47 enregistrements), il a trouvé les 1 539 trous qui coupaient le son, et chaque trou signalé était réel.
Ce qu’il ne voit pas
- C’est une borne inférieure. Sur les 2 554 trous faits dans le test de perte de paquets, 1 539 coupaient le son. Le reste tombait dans des pauses ou des passages calmes, où une perte ne se distingue pas d’une pause, et ne compte pas.
- Une perte que le lecteur a masquée (répétée, interpolée ou remplie de bruit de confort) ne laisse aucun trou.
- Un bruit ajouté après la perte remplit le trou.
- Le silence qu’un codec met dans les pauses n’est pas une perte : 48 enregistrements à travers un codec téléphonique à faible débit contenaient 1 936 séquences de zéros exacts, aucune avec du son des deux côtés, et aucune n’a été comptée.
- Il n’a pas été éprouvé sur de vrais appels avec une quantité connue de perte.
La mesure d’écho et de slapback n’est pas proposée
Le registre a aussi chain.slapbackDelayMs, chain.slapbackLevelDb et chain.slapbackScore : le retard et le niveau d’une copie retardée du son. Elles ne sont pas proposées par l’API ni par le serveur MCP, et la réponse les laisse de côté.
Le test dit pourquoi. La mesure a trouvé chaque copie construite, au bon retard et au bon niveau (100 pour cent, le retard à 0,03 ms près). Mais elle a aussi signalé une copie dans 27 pour cent des enregistrements qui n’en avaient pas, presque tous des voix synthétiques (53 pour cent pour une voix, jusqu’à 100 pour cent pour trois voix avec accent), contre 0 sur 40 enregistrements de parole réelle. Une mesure qui signale ce qui n’est pas là est pire qu’aucune mesure : elle reste donc dehors jusqu’à ce qu’un second test sur de nouvelles données remplisse les critères. Rien n’a été ajusté après le premier.
À lire aussi
More in VoiceLab docs
- Intro
Pourquoi la densité de mots de remplissage compte plus que leur nombre
Compter les « euh » est la mauvaise mesure. La densité dit s'ils posent problème.
- Practical
Une cible de loudness pragmatique pour les podcasts
La bonne cible de loudness pour les podcasts parlés n'est pas la même que pour la musique. Voici les chiffres et le pourquoi.
- Deep
Ce que mesure vraiment la décroissance après la parole
Nous avons construit un estimateur de réverbération bon marché à partir de la décroissance après chaque phrase, puis nous l’avons testé contre 24 pièces mesurées. Il ne mesure pas la réverbération. Voici les chiffres et ce que nous avons changé.
- Practical
Mesurer avec un seul claquement combien de temps une pièce résonne
Le profil room lit le temps de réverbération par bande d’octave à partir d’un claquement, d’un éclatement de ballon, d’une réponse impulsionnelle ou d’un balayage. Comment l’enregistrer, comment lire la réponse et jusqu’où les chiffres sont éprouvés.
- Practical
Hauteur et qualité de la voix : ce que le profil donne et ce qu’il retient
Le profil pitch lit où se situe une voix, de combien elle bouge, à quel point l’enregistrement est voisé et à quel point la voix est propre. Les chiffres du test, les limites et pourquoi la gigue et le scintillement ne sont pas encore proposés.