Notes
Watermarking every render, and the bug that taught us how
Disclosure you can prove beats disclosure you promise.
Published 2026-08-11 · Last checked 2026-08-14
In short
Every Naadly render carries an inaudible AudioSeal watermark, a response header declaring the audio synthetic and a provenance record, because platforms, broadcasters and procurement all now ask. Getting there exposed a real bug: the watermarker's gradient state is thread-local, so it worked once and then broke every subsequent request until its lifecycle was fixed.
Why it is not optional
An optional watermark is worthless to the person who needs it: the customer filling in a platform's synthetic-media field, the agency answering a broadcaster, the training team facing a procurement questionnaire. Making it unconditional is what makes it evidence.
What is actually attached to a render
- An inaudible AudioSeal mark in the audio itself, which survives mp3 encoding and trimming - that is the point of using a learned watermark rather than metadata.
- A response header declaring the audio synthetic, so a pipeline can act on it without listening.
- A provenance record naming the voice, the engine and the time, which is the part a human being can read out in a meeting.
None of that is protection, and we are careful not to sell it as such: a watermark is evidence about where audio came from. It cannot stop a person re-recording a speaker through a microphone, and it is not a detector for anyone else's output.
The bug, for anyone doing the same thing
The watermarker held torch state that is thread-local. Created once and used across request threads, it succeeded on the first request and failed on every one after - and because it was cold on top of that, the first failure consumed the whole router timeout, so every voice looked broken. Two unrelated symptoms, one lifecycle mistake.