Een bruikbaar tagschema voor audio-archieven

De meeste audio-archieven gaan ten onder aan hetzelfde probleem: slechte metadata. Bestanden worden geüpload als final_v2_FINAL.wav met een vage mapnaam, en een jaar later kan niemand meer iets terugvinden.

Een tagschema dat overleeft, heeft een paar harde regels en veel ruimte voor de rest. Dit is het schema dat SignalLab voor elk geïndexeerd bestand uitstuurt, en waarom elke tag zijn plek verdient.

De kerntags

Elke tag volgt het patroon namespace:value, zodat downstream-tools netjes kunnen filteren en groeperen.

content:*

De belangrijkste. voice, music, mixed, noise of silence. Dit is de tag die je editor als eerste nodig heeft, nog vóór al het andere. Is een bestand content:silence, dan hoeft niets downstream er nog naar te kijken.

noise betekent ruis die er de hele tijd is (brom, sis, airco, een menigte), niet elk geluid dat geen spraak en geen muziek is. mixed betekent dat een deel van het bestand als spraak leest en een deel als muziek; het herkent geen spraak over muziek. Het contenttype is een proxy. De site, en de API met contentModel: "v2", gebruiken het nieuwe model: op 600 echte fragmenten plus drie omgevingen die het nooit zag vond het 197 van de 200 spraakfragmenten, 190 van de 200 muziekfragmenten en 40 van de 90 met stationaire ruis (straatverkeer en metro heten vooral unknown). Het eerste model, dat de API tot 15 januari 2027 teruggeeft, deed het veel slechter: het herkende ruis in maar 3 van de 200 en hield veel muziek en ruis voor spraak. Gebruik het contenttype als hint voor triage, niet als resultaat. De cijfers staan bij signal.contentType op de pagina Lenses.

sample-rate:*, channels:*

Technische feiten, handig om op te filteren (“laat me alleen de 48 kHz stereo voice-overs zien”) en om bestanden naar de juiste pipeline te routeren. Let op: de indexer geeft geen containerformaat en geen bitdiepte uit. Hij werkt op gedecodeerde audio, dus tegen de tijd dat hij draait zijn dat eigenschappen van het decoderen, niet van het signaal.

brightness:*, dynamics:*

Buckets voor spectraal en dynamisch karakter: dark/balanced/bright/very-bright en flat/compressed/modern/dynamic. Die zijn nuttig voor zoeken én voor downstream-verwerkingsbeslissingen. Een voice-over met brightness:very-bright heeft waarschijnlijk een de-esser nodig.

issue:*

De meest bruikbare familie. issue:clipping, issue:noisy, issue:dc-offset, issue:lots-of-silence. Die koppelen direct aan QA-workflows: “laat elk bestand met issue:clipping bij ingest falen” is een regel van één regel.

hint:*

Zachtere signalen. hint:has-headroom, hint:loud, hint:mono-content-in-stereo. Die zijn voor tools die context willen, maar er niet op zouden moeten falen.

Wat het schema bewust niet bevat

• Stemmingstags (happy, melancholic, enz.). Die zijn onbetrouwbaar op basis van het signaal alleen en zetten je vast in een gecontroleerd vocabulaire dat slecht veroudert.
• Genretags. Hetzelfde probleem, maar erger. Genreclassificatie is een taak voor de gebruikerskant, niet voor de metadatalaag.
• Sprekeridentiteit. Persoonlijk identificerend. Hoort opt-in te zijn en in een aparte namespace te leven.
• Vrije-tekstbeschrijvingen. Heerlijk voor mensen, vreselijk voor downstream-automatisering.

De discipline is: tag alleen wat betrouwbaar berekend én betrouwbaar geconsumeerd kan worden. De rest hoort thuis in een door mensen samengestelde laag of in de gebruikersgerichte app, niet in het schema.

Een uitgewerkt voorbeeld

Voor een podcastinterview van 12 minuten op 48k/16-bit stereo:

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

Zes tags op een schoon bestand. Een bestand met problemen krijgt er issue:* bij (issue:clipping, issue:dc-offset, issue:noisy, issue:lots-of-silence), en de andere hint:*-waarden zijn hint:loud en hint:mono-content-in-stereo. Zeven namespaces in totaal: content, brightness, dynamics, sample-rate, channels, issue, hint. Op elke kun je zoeken, op elke kun je filteren, elke werd automatisch berekend. De getallen die je misschien als tag verwacht (duur, piek, RMS, ruisvloer, de zekerheid van het inhoudstype) komen terug als velden op het resultaat, niet als tags, want bereiken filteren slecht als tekst. Geen “interview”, geen “Alex_and_Sara_episode_42”, geen “leuke aflevering maar de kamer klinkt raar”. Die horen in je CMS.

Waarom dit ertoe doet

Audio is een ellendig formaat om doorheen te grep’en. De enige reden dat een audio-archief verder schaalt dan een paar duizend bestanden, is de metadatalaag. Een schema als dit is precies wat een downstream-editor laat zeggen: “Laat me elk voice-content-bestand onder de vijf minuten, geen clipping, brightness balanced, opgenomen sinds maart.” Zonder dat vraag je iemand om te gaan luisteren.

Gerelateerd

• Streaming clippingdetectie op schaal
• Sprekerwisseling-segmentatie: de pragmatische stack