You have an audio file beside your code. You want to hear a few seconds, see what's happening in the frequencies, and check whether one channel is behaving differently.
With AudioLens, you can do all three in VS Code: play the audio, inspect its waveform and spectrogram, then select a region to look closer.
I maintain AudioLens. It's free and open source under Apache-2.0. Here's what the workflow looks like.

Separate channel tracks, one shared timeline. Switch each track between waveform, spectrogram, and both.
Get AudioLens for VS Code · Source on GitHub
Hear the exact part you're looking at
Press Space to play or pause. Seek along the timeline. Drag across the waveform or spectrogram to select a passage and listen to that range.
That gives you a small, repeatable inspection loop:
- Find the part that sounds unusual.
- Select it and listen again.
- Inspect the same interval visually and numerically.
For multi-channel audio, use Solo to hear one channel or Mute to leave it out. Each channel also has gain and pan controls, so you can inspect the tracks separately.

A time selection connects what you hear with the measurements for the active channel. View the full-size animation.
The selection panel includes RMS, sample peak, clipping ratio, dominant frequency, and spectral centroid. You can check the level of a quiet section or investigate a peak without exporting that passage first.
See what the waveform can't tell you on its own
A waveform shows amplitude over time. A spectrogram shows how frequency content changes over time. Having both on the same timeline makes it easier to connect a sound with its visual pattern.
For example, a sustained tone can appear as a horizontal band; a brief broadband event can spread vertically. Those patterns give you a place to investigate, and selection playback lets you hear that exact moment.
AudioLens lets you adjust the STFT window and FFT size, frequency range, brightness, and color palette. Frequency scales include Linear, Log, Mel, Bark, and ERB.
Start with the combined view. Zoom into a short passage, listen, and then adjust the display for the question you're trying to answer. A picture alone doesn't diagnose the recording.
Open the file your pipeline actually produced
Audio work doesn't always arrive as a tidy WAV file. Sometimes your script leaves you with a raw .pcm or .raw dump.
AudioLens asks for the sample rate, channel count, encoding, byte order, and byte offset explicitly. These values determine how the bytes become audio: interpreting the same samples at the wrong rate changes both playback speed and pitch.

Set the PCM parameters before inspecting or listening to a raw dump.
Go from a path in your manifest to the sound
If you're checking a dataset, the audio path may already be in a manifest, transcript, or log. Hover over a supported path and choose Open in AudioLens.

Keep the recording beside the text that points to it.
Two other details matter for speech workflows:
- Remote SSH: inspect audio from a remote workspace without manually copying files into a separate local audio application.
- Kaldi WAV Ark: open archive entries containing RIFF/WAVE audio. Support is specific to WAV entries, not every Kaldi archive type.
Try it with one recording
Install AudioLens from the Marketplace, or run:
code --install-extension simzhou.audiolens
Open an audio file. If another viewer opens, choose Reopen Editor With… → AudioLens. Switch to the combined view, select a few seconds, and press Space.
Want a sample with known problems? This Python standard-library fixture generates a silent channel interval, hard clipping, and a PCM sample-rate mismatch, with reference measurements. The GIFs here are separate product demonstrations.
Which would help your workflow most: spectrogram inspection, listening to individual channels, or opening remote audio? I'd like to hear which part you would use and what's missing.
Disclosure: this post was drafted by an AI agent; AudioLens was developed primarily with AI-generated code.
Top comments (0)