klarify-opus-processing

Klarify small window silence detection

Setup

Make sure you have Rust installed first.

Once rust is installed, run bun install to install dependencies & bun run build to build the project for testing+benching.

Modifications

Make any modifications in src/lib.rs, and if the API signature changes, be sure to update the benchmark/bench.ts and __test__/index.spec.ts files accordingly.

Audio censorship

This package can also rewrite WebM/Opus audio into deterministic synthetic audio for privacy-safe service testing. The sanitizer does not use voice activity detection as its privacy boundary: every Opus audio packet it can parse is decoded, summarized by loudness/peak statistics, and replaced with generated noise. Non-audio WebM bytes are preserved, and Opus packets are padded back to their original byte length when possible.

import { censorAudio, censorAudioChunk, censorAudioFile } from '@wundero/klarify-opus-processing'

const censoredChunk = await censorAudioChunk(webmHeader, webmClusterChunk, {
  mimeType: 'audio/webm',
  seed: 123,
})

const censoredFile = await censorAudio(fullWebmBuffer, { mimeType: 'audio/webm' })

const result = await censorAudioFile('/tmp/input.webm', '/tmp/censored.webm', {
  mimeType: 'audio/webm',
})

The v1 sanitizer only supports WebM/Opus with unlaced Opus blocks. It rejects unsupported, malformed, or non-Opus inputs rather than returning original bytes. Passing strictByteLength: true makes size preservation mandatory; otherwise the sanitizer preserves byte length where packet padding fits and rewrites WebM element sizes when the replacement packet has to change length.

This is an audio-content sanitizer, not a general metadata scrubber. Container metadata is intentionally kept mostly unchanged so upload and ffmpeg processing edge cases remain reproducible.

Publishing

Preparing to publish

Commit any changes without changing the version number first, and make sure to run bun format to improve code style.

Once ready to publish, increment the version number in package.json (if you break the API spec, make sure to use a major version increase) and then run bun version. Once the command finishes, commit the staged changes with the same version number as you put in the package json file.

Example flow:

# ...make changes to lib.rs
bun run build # Regenerate index.d.ts
# ...update api usages as needed
bun run test # Run tests. Note: the "run test" instead of just "test" here is important!
# set package.json version to 1.2.3
bun version
git commit -m "1.2.3"
git push

This will trigger a deployment and publish the new version to npm.

Importantly, we currently only use main so its a bit unstable, but we can improve this if further work is needed here. At some point, having this flow be fully automated would be ideal, but that's not really necessary at the moment.