Controleren of een audio-opname is bewerkt of geknipt

De vraag of een audio-opname bewerkt of geknipt is komt bijna altijd op in situaties waar de integriteit van het geluid er écht toe doet. Denk aan een journalist die een ingesproken verklaring ontvangt, een advocaat die een telefoongesprek als bewijsstuk beoordeelt, een content creator die wil weten of een bestand al is geconverteerd door een platform, of een onderzoeker die geluidsfragmenten uit een archief vergelijkt met een nieuwe versie die online circuleert. In al die gevallen gaat het niet om een gevoel van “dit klinkt raar”, maar om controleerbare technische aanwijzingen die kunnen laten zien dat een bestand is aangepast, opnieuw geëncodeerd of samengesteld uit meerdere stukken. Dat is precies waar technische documentatie helpt: niet om te zeggen wie er heeft gesproken of wat er bedoeld werd, maar om vast te leggen wat er technisch in het bestand zit en of dat consistent is met een onbewerkte bron. FilesAudit is gebouwd voor dat soort verificatiewerk. Je uploadt een bestand en krijgt een gestructureerd overzicht van containerinformatie, codecparameters, metadata en cryptografische vingerafdrukken die bruikbaar zijn voor rapportage en vergelijking. Dat overzicht maakt het mogelijk om veranderingen aan te tonen zonder in te hoeven gaan op inhoudelijke interpretatie.

Audiobewerking laat bijna altijd sporen achter in de technische laag, ook al is het geluid zelf zorgvuldig gemixt. Bij de meeste distributieformaten zoals MP3, M4A, OGG en AAC zit er metadata in de container of in de headers die informatie bewaart over de encoder, de gebruikte software, de instellingen voor bitrate en sample rate, en soms over de tijd waarop het bestand is gemaakt of laatst gewijzigd. Bij een WAV of AIFF bestand is er vaak minder beschrijvende metadata, maar zijn de headerwaarden en de audiochunks wel erg gevoelig voor herschrijving. Zodra een opname is geknipt, opnieuw geëxporteerd of door een editor is gehaald, verandert er meestal iets aan die technische parameters. Een oorspronkelijk constante VBR bitrate kan bijvoorbeeld veranderen in een constante CBR bitrate, de encoder signature kan wisselen van “LAME 3.100” naar “iTunes 12.9”, of er verschijnt een nieuwe tag zoals “Encoded by Audacity”. Ook de duur, het aantal samples en de totale bestandsgrootte wijken dan af van wat je zou verwachten bij een directe opname. Bij verliesvrije formaten als FLAC is dat bijzonder interessant, omdat elke hercompressie een nieuwe checksum oplevert en vaak nieuwe metadata blokken toevoegt met een andere schrijftijd. Zelfs wanneer iemand probeert de metadata handmatig schoon te vegen, blijven er vaak inconsistenties bestaan tussen de container en de daadwerkelijke audiostream, bijvoorbeeld een mismatch tussen de gerapporteerde duur en het aantal frames, of een plotselinge sprong in de encoder geschiedenis.

Een hash is de har