Un schéma de tags utile pour les archives audio

La plupart des archives audio meurent du même mal : de mauvaises métadonnées. Les fichiers sont téléversés sous le nom final_v2_FINAL.wav dans un dossier au nom vague, et un an plus tard, plus personne ne retrouve quoi que ce soit.

Un schéma de tags qui survit est un schéma avec quelques règles fermes et beaucoup de tolérance sur tout le reste. Voici le schéma que SignalLab émet pour chaque fichier indexé, et pourquoi chaque tag mérite sa place.

Les tags fondamentaux

Chaque tag suit le motif namespace:value, afin que les outils en aval puissent filtrer et regrouper proprement.

content:*

Le plus important. voice, music, mixed, noise ou silence. C’est le tag dont votre éditeur a besoin en premier, avant tout le reste. Si un fichier est content:silence, rien en aval n’a besoin de s’y intéresser.

noise désigne un bruit de fond constant (bourdonnement, souffle, climatisation, une foule), pas n’importe quel son qui n’est ni de la parole ni de la musique. mixed signifie qu’une partie du fichier se lit comme de la parole et une partie comme de la musique ; il ne détecte pas la parole sur de la musique. Le type de contenu est un proxy. Le site, et l’API avec contentModel: "v2", utilisent le nouveau modèle : sur 600 extraits réels plus trois environnements qu’il n’avait jamais vus, il a trouvé 197 des 200 extraits de parole, 190 des 200 extraits de musique et 40 des 90 de bruit stationnaire (la circulation et le métro sont surtout restés unknown). Le premier modèle, que l’API renvoie jusqu’au 15 janvier 2027, a fait bien moins bien : il n’a reconnu le bruit que dans 3 cas sur 200 et a pris beaucoup de musique et de bruit pour de la parole. Servez-vous du type de contenu comme d’un indice pour le tri, pas comme d’un résultat. Les chiffres figurent sous signal.contentType sur la page Lenses.

sample-rate:*, channels:*

Des faits techniques, utiles pour filtrer (« montre-moi uniquement les voix off stéréo en 48 kHz ») et pour router les fichiers vers le bon pipeline. À noter : l’indexeur n’émet ni format de conteneur ni profondeur de bits. Il travaille sur de l’audio décodé ; à ce stade, ce sont des propriétés du décodage, pas du signal.

brightness:*, dynamics:*

Des catégories de caractère spectral et dynamique : dark/balanced/bright/very-bright et flat/compressed/modern/dynamic. Elles sont utiles à la recherche et aux décisions de traitement en aval. Une voix off taguée brightness:very-bright a probablement besoin d’un de-esser.

issue:*

La famille la plus directement exploitable. issue:clipping, issue:noisy, issue:dc-offset, issue:lots-of-silence. Elles se mappent directement sur les workflows de QA : « rejeter tout fichier avec issue:clipping à l’ingestion » est une règle d’une seule ligne.

hint:*

Des signaux plus doux. hint:has-headroom, hint:loud, hint:mono-content-in-stereo. Ils sont destinés aux outils qui veulent du contexte mais ne devraient pas échouer à cause d’eux.

Ce que le schéma exclut délibérément

• Les tags d’humeur (happy, melancholic, etc.). Ils sont peu fiables à partir du seul signal et vous enferment dans un vocabulaire contrôlé qui vieillit mal.
• Les tags de genre. Même problème, en pire. La classification par genre est un travail côté utilisateur, pas un travail de la couche de métadonnées.
• L’identité du locuteur. Donnée personnellement identifiante. Elle devrait être en opt-in et vivre dans un namespace séparé.
• Les descriptions en texte libre. Délicieuses pour les humains, désastreuses pour l’automatisation en aval.

La discipline est la suivante : ne taguer que ce qui peut être calculé de façon fiable et consommé de façon fiable. Le reste a sa place dans une couche curatée par des humains ou dans l’application côté utilisateur, pas dans le schéma.

Un exemple concret

Pour une interview de podcast de 12 minutes en 48k/16-bit stéréo :

content:voice
brightness:balanced
dynamics:modern
sample-rate:48000
channels:stereo
hint:has-headroom

Six tags sur un fichier propre. Un fichier problématique reçoit en plus des issue:* (issue:clipping, issue:dc-offset, issue:noisy, issue:lots-of-silence) et les autres valeurs hint:* sont hint:loud et hint:mono-content-in-stereo. Sept namespaces au total : content, brightness, dynamics, sample-rate, channels, issue, hint. On peut interroger chacun, filtrer sur chacun, et chacun a été calculé automatiquement. Les nombres que l’on pourrait attendre sous forme de tags (durée, crête, RMS, plancher de bruit, la confiance du type de contenu) reviennent comme champs du résultat, pas comme tags : les plages se filtrent mal sous forme de texte. Pas de « interview », pas de « Alex_and_Sara_episode_42 », pas de « super épisode mais la pièce sonne bizarre ». Tout cela a sa place dans votre CMS.

Pourquoi c’est important

L’audio est un format misérable à parcourir avec grep. La seule raison pour laquelle une archive audio passe le cap de quelques milliers de fichiers, c’est la couche de métadonnées. Un schéma comme celui-ci est précisément ce qui permet à un éditeur en aval de dire : « Montre-moi tous les fichiers à contenu vocal de moins de cinq minutes, sans clipping, brightness balanced, enregistrés depuis mars. » Sans cela, vous demandez à quelqu’un d’écouter.

Connexe

• Détection de clipping en streaming à grande échelle
• Segmentation des tours de parole : la pile pragmatique