Method
How Sonic Batch works
Two decoders, one encoder set, no server. The browser’s own decoders handle what they can; a self-hosted FFmpeg WebAssembly build handles the rest. Measurement is implemented to published standards and every number is shown with its method.
Your browser
Checking this browser’s capabilities…
The processing routes
| Route | When it runs | What it means for you |
|---|---|---|
| passthrough | Tag edits where the container does not change. | The audio stream is copied bit-for-bit. Nothing is re-encoded, so no quality is lost at all. |
| native-pcm | WAV output from a file the browser can decode. | No WebAssembly download needed. The fastest path, and exact for PCM sources. |
| ffmpeg-transcode | Ordinary format conversion and compression. | One decode-and-encode pass. Quality depends on the codecs involved, reported per file. |
| ffmpeg-from-pcm | Normalisation, silence removal or power-matched upmixing. | Samples are transformed in JavaScript first — so measurement is exact and auditable — then encoded. |
The route taken is shown in each queue row and recorded in the ZIP manifest, so “was this re-encoded?” is always answerable after the fact.
The engine, and why it is self-hosted
Format work that browsers cannot do — Vorbis on Safari, AMR anywhere, MP3 and AAC encoding everywhere — runs in FFmpeg compiled to WebAssembly. It is copied out of pinned npm packages at build time into version-stamped paths on this domain and served with an immutable cache header.
The alternative that most projects use is to load the WASM core from a public CDN at runtime. That is a third party in the critical path of every conversion, an unpinned dependency, and a request that leaves your device. All three are avoidable, so they are avoided.
The engine is about 31 MB and loads on demand. Pages that only need native decoding never download it at all.
- FFmpeg wrapper
- 0.12.15
- FFmpeg core
- 0.12.10
- Encoders
- libmp3lame, libvorbis, libopus, aac, flac, pcm
- Threading
- Multi-thread when cross-origin isolated; single-thread otherwise
The conversion engine is FFmpeg compiled to WebAssembly (LGPL v2.1 or later), linked with libmp3lame, libvorbis and libopus. Pinned versions: @ffmpeg/ffmpeg 0.12.15, @ffmpeg/core 0.12.10.
Safari and iPhone
Multi-threaded WebAssembly needs SharedArrayBuffer, which needs the document to be cross-origin isolated. This site sends the required COOP and COEP headers and every asset it loads is same-origin, so isolation is available — but Sonic Batch still runs the single-threaded core on iOS unconditionally, and one file at a time on Safari.
That is a deliberate reliability choice rather than a limitation we inherited. iOS reclaims memory from web content aggressively and pthread support there has historically been inconsistent enough that a slow success is worth more than a fast crash. The consequence is honest: batches are slower on Apple mobile devices, and the tool says so on every page rather than discovering it mid-run.
How the measurements are made
Loudness
Integrated loudness follows ITU-R BS.1770-4: a two-stage K-weighting filter (high shelf plus RLB high pass), mean-square power over 400 ms blocks at 75% overlap, an absolute gate at −70 LUFS and a relative gate 10 LU below the ungated mean. Filter coefficients are derived analytically for the file’s own sample rate rather than copied from the 48 kHz table, so a 44.1 kHz or 16 kHz file measures correctly.
Loudness range follows EBU Tech 3342 over 3-second short-term blocks. True peak uses 4× oversampled windowed-sinc interpolation, because inter-sample peaks routinely exceed the highest sample value and that is what clips a DAC or a lossy decoder.
Spectrum and silence
Spectrum analysis uses a 4096-point FFT with a Hann window at 50% overlap, magnitudes averaged across windows and reported in dBFS. The panel states how many windows were analysed out of how many exist, because very long files are sampled to stay inside the memory budget and hiding that would make the number unverifiable.
Silence detection measures RMS level over 20 ms windows against your threshold, requires a run to exceed your minimum duration before it counts, and adds your padding back at each boundary. Leading and trailing trims are separate options from interior removal, because interior removal changes timing and breaks synchronisation.
The limits, and why they exist
- Per file
- 400.0 MB
- Per queue
- 4.00 GB
- Per file duration
- 4:00:00
- Decoded PCM buffer
- 700.0 MB
- ZIP archive
- 1.50 GB
These are enforced ceilings checked before any decoding begins, not measured maximums. A browser tab has finite memory and a decoded float buffer is several times the size of the file that produced it — a 10-minute stereo 48 kHz recording is about 230 MB decoded. Rejecting a file up front is a better outcome than an out-of-memory crash halfway through a batch, so “unlimited” is not on offer anywhere on this site.
On top of the fixed budgets, the scheduler chooses how many files to run in parallel from your CPU count, reported device memory, the size of the largest queued file and whether any job needs a full decoded buffer. You can lower it further from the batch toolbar; it never raises itself past three.
What is deliberately not here
- No AI features: no vocal removal, stem splitting, acapella extraction, transcription, generation or “enhancement”. Every operation is deterministic and reproducible.
- No accounts, no cloud storage, no sync. Results exist in your tab and nowhere else.
- No video conversion — that is a different product with different constraints.
- No invented ratings, review counts or speed claims in the page markup. The structured data describes what the tools do and nothing more.