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.

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