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.

format:*, sample-rate:*, channels:*, bit-depth:*

Des faits techniques. Utiles pour filtrer (« montre-moi uniquement les voix off en 48kHz/24-bit ») et pour router les fichiers vers le bon pipeline (« les fichiers compressés passent d’abord par une étape de réencodage »).

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
content-confidence:0.82
format:audio/wav
sample-rate:48000
channels:stereo
bit-depth:16-bit
brightness:balanced
dynamics:modern
duration:720
peak:-2.1dB
rms:-19.4dB
noise-floor:-52.1dB
hint:has-headroom

Douze tags. On peut interroger chacun, filtrer sur chacun, et chacun a été calculé automatiquement. 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