How AudioLab measures things.

The maximum sample value in a digital recording is not the same as the maximum value of the underlying continuous waveform. Between two samples that both sit comfortably under 0 dBFS, the reconstructed analogue signal can briefly exceed 0 dB, a so-called inter-sample peak. Limiters that only look at sample values miss these. Streaming-platform reference decoders don't.

BS.1770-4 Annex 2 specifies 4× oversampling via an FIR interpolator, followed by peak detection on the upsampled signal. AudioLab uses a 4-point cubic interpolator that inserts three intermediate samples between every pair of originals. The maximum absolute value across the upsampled buffer is reported as the true peak.

Cubic interpolation is sufficient for the 4× factor that BS.1770 calls out (the standard's reference uses a 12-tap FIR; we benchmark within 0.1 dBTP on standard test signals). For mastering-grade analysis a higher-order kernel is preferable; the AudioLab readout is intended for diagnostic loudness work, not as a substitute for a calibrated lab instrument.

Stereo correlation in MixLab is the Pearson correlation coefficient between the left and right channels, computed sample-wise over the entire programme (offline) or over a rolling 1024-sample window (during playback). Values range from +1 (perfectly mono) through 0 (decorrelated) to –1 (perfectly inverted; any mix that lands here will collapse to silence in mono).

The phase scope is a Lissajous figure: a 2D plot of L on one axis and R on the other, drawn from a rolling window of recent samples. A vertical line means mono content; a circle means uncorrelated stereo; a horizontal line means polarity-inverted material that will collapse to silence in mono playback. The display does not approximate: it draws actual sample pairs.

Mid and side are derived from the standard sum and difference: M = (L + R) / 2, S = (L – R) / 2. We take the RMS of each over the whole programme; the ratio of side to mid, divided by 1.5 and capped at 1, is the stereo width we report (0 is mono, 1 is wide).

The realtime spectrum view uses the browser's built-in AnalyserNode, which implements an FFT with a Blackman window internally. For the offline analysis we use a Hann window and a 4096-point FFT, with 50% overlap. The window choice slightly worsens dynamic range vs Blackman but preserves better main-lobe resolution, which helps with visual readability in the analyser display.

The seven-band meter aggregates FFT bins into perceptually-spaced bands. The choices match common mastering-tool conventions:

Sub          20  Hz –   60 Hz
Bass         60  Hz –  200 Hz
Low-mid     200  Hz –  500 Hz
Mid         500  Hz –   2 kHz
High-mid      2 kHz –   4 kHz
Presence      4 kHz –   8 kHz
Air           8 kHz –  16 kHz

Each band reports the mean spectral magnitude of the bins inside its edges, scaled so that the strongest band reads 1. The seven values are relative to each other, not levels in dBFS. Bin spacing at 48 kHz with a 4096-point FFT is 11.7 Hz, so the sub band holds only about four bins and is the coarsest of the seven.

VoiceLab QA reports separate measurements, not a single score. They are opinionated, designed for podcast and voiceover producers, and explicitly not a clinical measure. What follows is what the engine does today. Where a measure turned out to be wrong, section 08 says so.

• Speech detection: the loudness (RMS) is taken every 20 ms over a 40 ms window, and a phrase is a stretch above a threshold taken from that recording's own loudness percentiles: the greater of three times the 10th percentile and the midpoint of the 10th and 70th, never below about −55 dBFS, and capped at half the 70th percentile where it would otherwise sit above the 95th and find nothing. Gaps shorter than 160 ms are bridged and runs shorter than 100 ms are dropped. This is a loudness gate, not a speech recogniser, and it can be fooled. We measured by how much, on 111 recordings with the clean source sentence as ground truth: at 10 dB signal-to-noise it finds on average 1.2 s too little speech, at 5 dB 2.4 s. That speech then falls outside the speech level and the SNR.
• What the active material is: each frame is labelled voice, music, noise or silence from its loudness and from how much its zero-crossing rate varies over about half a second either side (speech alternates consonants and vowels, music is spectrally steadier). The limits were fitted on a labelled corpus: speech in 32 noise and reverb conditions, tonal and beat-driven music, and bare room noise. The result reads as voice from 60 % voice-like frames, as mixed from 40 %, and otherwise as music or noise. The written feedback does not judge SNR, pace or sibilance on material that does not read as voice.
• Noise floor and SNR: the noise floor is the 10th percentile of the loudness. The overall SNR is the mean speech level minus that floor. A television or a passing lorry raises the floor in one part of a take only, so the engine also reports an SNR per phrase against the floor in a window of about half a second around that phrase, and the worst tenth of those: one unintelligible sentence is enough to miss a notification, and an average hides it. Phrases under 200 ms get no SNR of their own.
• Pace: the dominant modulation frequency of the speech envelope between 2 and 8 Hz, in syllables per second, over the span from the first to the last phrase, pauses included. It is mapped to a Slow, Normal or Fast label. Counting envelope peaks was tried and dropped: on one sentence read at three speeds, where the true ratio was 1.63 : 1.00 : 0.69, it reported 1.12 : 1.00 : 0.98.
• Sibilance: in 4096-sample Hann-windowed frames, the share of spectral magnitude between 5 and 9 kHz. The median over the frames, times five and capped at 1, is the score: Low below 0.25, Medium below 0.55, High above.
• Brightness: derived from the spectral centroid, power-weighted and counted only up to 8 kHz. Above that speech has almost nothing, and the thousands of nearly empty bins used to decide the number: a noise floor at −96 dBFS, far below hearing, moved brightness from 0.513 to 0.590.
• Clipping: counts runs of consecutive samples sitting at the peak and grades the count None, Low, Medium or High.
• Intelligibility, as a proxy: the weaker of two ramps: the worst-tenth per-phrase SNR and the speech level over the background in the pauses. Each reads 0 at 3 dB and 1 at 18 dB, and is lowered by 15 % for medium clipping and 40 % for high. Clear from 0.65, borderline from 0.35, otherwise buried, and only with at least two measurable phrases. It is a proxy and called one: not a Speech Transmission Index, which needs a test signal played in the room. It is a proxy for how well a listener could follow the voice, not for speech-recognition accuracy: in our own test of 1,248 transcriptions it did not predict recognition errors (see its status on the lenses page).

There is no single composite number. The measurements come back as separate fields, so you set your own thresholds for what counts as a pass. The intelligibility label is the one exception, and it is called a proxy. An earlier version of this page described a 0–100 score; the engine has never returned one.

SignalLab indexes an arbitrary audio file into labelled regions: voice, music, noise, silence and clipping. It is one pipeline, shared with VoiceLab.

1. Frame labels: loudness (RMS) and zero-crossing rate every 20 ms. Each frame is labelled from its loudness and from how much its zero-crossing rate varies over about half a second either side: speech alternates consonants and vowels (a spread of 0.05 or more), music is spectrally steady (0.02 or less). The limits were fitted on a labelled corpus (speech in 32 noise and reverb conditions, tonal and beat-driven music, raw room noise) and not guessed, and VoiceLab uses the same function, so the two labs cannot disagree about what is voice.
2. Region merging: consecutive frames with the same label become one region, and regions shorter than 0.3 s are absorbed into the previous one. Clipping is a separate pass: a stretch where, in a window, more than three samples sit at or above 0.98 of full scale becomes a clipping region, for files with a lot of clipping.

The region labels are heuristic. The tag schema is published at /docs/signallab/tag-schema. They're useful for navigation and bulk filtering. The timeline of regions comes from this simple frame classifier; for production indexing at scale you would want a learned model for it too.

The file verdict, the content type (voice, music, mixed, noise or unknown), is a separate step. On the website it comes from a small learned model (v2) over 25 simple features per 10-second window; in the API it is an opt-in (contentModel v2) until 15 January 2027, when it becomes the default. We tested the first model on real recordings on 12 October 2026: 600 excerpts of 20 seconds from the MUSAN corpus (200 each of speech, music and noise), one run, nothing tuned afterwards. It fell short of the bar we had set in advance (recall and precision of 0.80 or more for all three classes): it found 164 of the 200 speech excerpts, 91 of the 200 music excerpts and 3 of the 200 noise excerpts. We then tested v2 once, the same way, on the same 600 excerpts plus 90 excerpts of three environments it had never seen: it found 197 of the 200 speech excerpts (precision 0.95), 190 of the 200 music excerpts (0.86) and 40 of the 90 steady-noise excerpts (precision 1.00; street traffic and the metro mostly read unknown). It met the bar for speech and music and not for noise, so it stays a proxy. The full numbers are under signal.contentType on /lenses.

Every measurement the engine produces carries one of four statuses, and the same words are used on the lenses page, the API page, the OpenAPI document and the MCP tool descriptions. Beta means there is no ground-truth test yet, not that the measure is wrong. A measure becomes validated only with a recorded test against a known value, with a tolerance, and a proxy stays a proxy until then.

Each measure on the lenses page says what it was tested against, what it was not tested on, and what it is not. Most of the loudness numbers are validated against the EBU test signals; the scene, content and intelligibility measures are proxies; the room-echo score was withdrawn (see corrections below). Each measure also says how it works: classical signal processing, or signal processing with a small learned model, which is then named, with what it was trained on.

A measurement is only worth trusting if its maker says when it was wrong. These are the cases from September and October 2026. Each was found by testing a claim against something measured, and each is fixed in the engine, not only in the wording.

• A reverb score that did not measure reverb. VoiceLab's reverb label (Dry, Tight, Live, Reverberant) rose with background noise, not with reverb. Against the measured reverberation times of 24 rooms, from 0.18 to 1.71 s, its rank correlation was 0.06, and a room of 1.71 s scored below a booth of 0.18 s. Withdrawn on 27 September from the engine, the apps, the API and the MCP server. The number stays under the name of what it measures, energy in the pauses after speech, and no longer lowers the intelligibility proxy. The write-up with the numbers. A new reverb measure may only be called reverb once it passes the same test.
• Numbers without speech. On a music track with a vocal, VoiceLab found no phrase and still reported an SNR of −66 dB, a pace of 0.0 syllables per second, a sibilance of Medium and 14.3 s of silence. None of the four was measured. They are now empty when no speech is found, and the lab says what the material seems to be.
• Two labs, two answers. VoiceLab and SignalLab each computed their own loudness curve and threshold, and disagreed about the same file: 14.3 s of silence against 6.3 s of voice. They now share one set of facts, and a check on a synthetic file holds them to it.
• A platform that does not behave as assumed. After YouTube normalisation a quiet upload was shown as over the ceiling, but YouTube, according to third-party measurements, does not turn quiet uploads up. Spotify does, up to 1 dB of headroom. A result after normalisation is now shown only where the platform publishes what it does, and where it does not the tool says so.
• Loudness numbers and the standard. This page first said the engine agrees with the EBU's reference implementation to within 0.05 LU. The benchmark compares against the standard's published expected values, never against another implementation, and the worst case is 0.06 LU. The text now says that.

Checks that run on every build keep these from coming back: the pricing page against the code, documented API endpoints against real ones, the privacy pages against what actually loads, withdrawn claims against the text, loudness against the EBU Tech 3341 and 3342 signals, and a self-test per module. A separate sweep breaks things on purpose to prove each check can go red.

Could I not prompt an AI to build this in an afternoon?

You can prompt an interface, and a page that shows numbers is easy to get. What you cannot prompt is what makes a number worth trusting: testing it against something measured. Our loudness is checked against the signals the EBU standard defines and lands within 0.06 LU in the worst case. Our reverb score was checked against 24 rooms with measured reverberation times, failed, and was withdrawn; the section above has the numbers. A copy that is never tested keeps a score like that. What is left is not the code but the testing, an honest list of what is not measured, and one engine behind the browser labs, the API and the MCP server.

Is it open source?

No. The measurement engine is closed source. What is public: the API specification at /openapi.yaml, the MCP server and the AI SDK on npm, and a public repository for the MCP server at github.com/Audio-Launch/audiolab-mcp-server. The standards we implement and the test signals we check against are published by their owners, and the loudness section says how to rebuild the checks yourself. The browser labs send no audio to us, and the network tab of your browser shows you that.

Did AI write it, and is it vibe-coded?

Much of the code is written with AI tools, and it is not vibe-coded. The difference is what happens after the code exists. Vibe-coding means accepting what comes out and shipping it because it runs. AI-assisted means a person decides what is measured and against what, and nothing is trusted on its own word: every push runs the loudness benchmark against the EBU test signals, a self-test per module, and checks that the pricing page, the API documentation and the privacy pages match what really runs. When a measure turns out wrong it is withdrawn and the page says so. The section above lists those cases; output that was never reviewed or tested has none to list.

The numbers are accurate to within the tolerances documented above, but this is a browser-based analyser running off the user's CPU. It is not a replacement for:

• A calibrated hardware loudness meter for broadcast compliance audits.
• A lab-grade audio analyser for amplifier or converter testing.
• A clinical audiometry instrument (HearLab is explicitly non-medical).
• A reference encoder/decoder for verifying codec compliance.
• A reverberation meter for a recording. VoiceLab reports the energy in the pauses after speech, which rises with noise as well as with reverb. For reverb, RoomLab measures it from a clap.
• A counter of words, fillers or speaker turns. No lens counts them.

What it is, in the spirit of the rest of the site: a working, fast, defensible measurement you can run on any audio file in the browser labs without uploading anything to a server, with the math fully documented and the code path linkable from each demo back to here.