Best Python audio processing libraries in 2026 (and when to use a speech-to-text API)

Four years ago we published a video walking through the eight Python libraries we reached for most when working with audio: IPython.display, soundfile, the built-in wave module, PyAudio, sounddevice, pydub, librosa, and torchaudio. It has picked up 85,000 views since, and it still shows up in Google's video results for "python audio processing libraries."

The problem is that a 2022 listicle is a liability in 2026. Two of those eight libraries have changed so much that copying the video's code will now throw errors. Python itself deleted a standard-library module that one of them depends on. And the "king of all audio processing libraries" from that video has since been moved into maintenance mode by its own maintainers.

So this is the updated list. Same job — read, write, record, play, analyze, and transform audio in Python — but with every library checked against its current release, plus one addition that didn't exist in the original lineup and one demotion. At the end, the part the 2022 video only gestured at: where these libraries stop being the right tool and a speech-to-text API takes over.

What actually changed since 2022

Three things, and they all matter before you pick a library.

Python 3.13 removed audioop. PEP 594 deleted a batch of dead standard-library modules, and audioop — the C module that handled sample-width conversion, gain, and mixing — went with it. wave survived. aifc and sunau did not. This is the single biggest gotcha in the list, because pydub imports audioop on almost every operation.

torchaudio went into maintenance. The PyTorch team scoped torchaudio down to "processing audio data for ML," deprecated a set of user-facing features in 2.8, and removed them in 2.9. Audio decoding moved to TorchCodec. The effects pipeline the 2022 video demoed is gone.

librosa shipped 1.0. After a decade on 0.x, librosa reached 1.0.0 in August 2026 and now requires Python 3.12 or newer. The plotting call from the original video (librosa.display.waveplot) was renamed years ago and no longer exists.

Everything else on the list is roughly where it was — which is a compliment, not a criticism. Audio I/O is a solved problem, and the libraries that solved it well have earned the right to be boring.

1. IPython.display — hear your audio without leaving the notebook

Still the fastest way to sanity-check an audio file. It ships with IPython, so if you're in Jupyter, Colab, or any notebook, you already have it.

from IPython.display import Audio, display

display(Audio("example.wav"))

You get a playable widget inline. It accepts a file path, a URL, raw bytes, or a NumPy array with a rate argument — which is the useful case, because it means you can listen to an array you just transformed rather than writing it to disk first.

Use it for: listening to intermediate results while you iterate. Skip it for: anything outside a notebook.

2. wave — the standard library option

Nothing to install, still in the standard library, still WAV-only. The interface is lower-level than the alternatives: you open a file, ask it for parameters, and pull raw frames as bytes.

import wave

with wave.open("example.wav", "rb") as wav:
    n_channels = wav.getnchannels()
    sample_width = wav.getsampwidth()
    frame_rate = wav.getframerate()
    n_frames = wav.getnframes()
    frames = wav.readframes(n_frames)

print(n_channels, sample_width, frame_rate, n_frames)

Writing works the same way in reverse — setnchannels, setsampwidth, setframerate, then writeframes. It's more ceremony than soundfile, but there's a real argument for it: zero dependencies. If you're shipping a small utility or working inside a locked-down environment, wave is the one library on this list you can always count on being there.

Use it for: dependency-free WAV reading and writing, and pairing with PyAudio to dump recorded frames. Skip it for: any format that isn't WAV.

3. soundfile — the default for reading and writing files

soundfile wraps libsndfile and is the library most other libraries quietly depend on. Version 0.14.0 shipped in June 2026 and requires Python 3.10+. It handles WAV, FLAC, OGG, AIFF, and — since libsndfile grew MP3 support — MP3 too.

Install it with pip install soundfile. Two functions cover most of what you need:

import soundfile as sf

data, samplerate = sf.read("example.wav")
print(data.shape, samplerate)

sf.write("example.flac", data, samplerate)

sf.read returns a NumPy array plus the sample rate, and it defaults to float64. That default catches people out: if you're feeding a streaming API or a codec that expects 16-bit PCM, pass dtype="int16" explicitly. Format conversion is just a matter of changing the output extension — libsndfile infers the format from it.

Use it for: essentially all file-based reading and writing. Skip it for: device I/O, which is a different library's job.

4. sounddevice — record and play with three lines

sounddevice gives you Python bindings to PortAudio with a set of convenience functions on top. Version 0.5.6 landed in August 2026, making it one of the most actively maintained libraries on this list.

import sounddevice as sd

samplerate = 16000
duration = 5  # seconds

recording = sd.rec(int(duration * samplerate), samplerate=samplerate, channels=1)
sd.wait()

sd.play(recording, samplerate)
sd.wait()

sd.rec() returns a NumPy array, so it composes directly with soundfile and librosa. sd.query_devices() tells you what inputs and outputs PortAudio can see, which is the first thing to check when a recording comes back silent. For continuous capture there's sd.InputStream with a callback — that's the pattern you want when you're piping audio somewhere else in real time rather than recording a fixed clip.

Use it for: microphone capture and playback in scripts and prototypes. Skip it for: cases where you need fine-grained control over PortAudio's host API selection.

5. PyAudio — lower-level PortAudio access

PyAudio is the other set of PortAudio bindings, and it sits closer to the C API. You create an instance, open a stream with explicit format constants, and read chunks yourself.

import pyaudio
import wave

CHUNK = 1024
FORMAT = pyaudio.paInt16
CHANNELS = 1
RATE = 16000
SECONDS = 5

p = pyaudio.PyAudio()
stream = p.open(format=FORMAT, channels=CHANNELS, rate=RATE,
                input=True, frames_per_buffer=CHUNK)

frames = []
for _ in range(int(RATE / CHUNK * SECONDS)):
    frames.append(stream.read(CHUNK))

stream.close()
p.terminate()

with wave.open("output.wav", "wb") as wav:
    wav.setnchannels(CHANNELS)
    wav.setsampwidth(p.get_sample_size(FORMAT))
    wav.setframerate(RATE)
    wav.writeframes(b"".join(frames))

Note the shape of that code: PyAudio hands you raw bytes, and wave writes them out. That pairing is the reason both libraries are still on this list.

The honest caveat: PyAudio's last release was 0.2.14 in November 2023. It isn't abandoned — it works, wheels exist for current Python versions, and it's still the most widely deployed option — but development is slow, and on Linux you'll usually need PortAudio headers installed before pip install pyaudio succeeds. If you don't specifically need byte-level stream control, sounddevice is the easier choice.

6. pydub — great API, real 2026 problem

pydub's AudioSegment is still the nicest high-level audio API in Python. Slicing with list syntax, boosting gain with + 6, looping with * 2, crossfading — it reads like the thing you meant to write.

from pydub import AudioSegment

song = AudioSegment.from_wav("example.wav")

louder = song + 6
twice = song * 2
faded = twice.fade_in(2000).fade_out(2000)

faded.export("output.mp3", format="mp3")

Here's the problem. pydub's last release was 0.25.1, in March 2021 — over five years ago — and it imports audioop, which Python 3.13 removed. On Python 3.13 or newer, a fresh pip install pydub followed by an import will fail.

There is a workaround, and it's a real one: pip install audioop-lts installs a maintained backport of the removed module (0.2.2, requiring Python 3.13+). Add it and pydub works again. But you're now depending on a five-year-stale library plus a shim for a module the language deliberately deleted, and you still need ffmpeg on PATH for anything that isn't WAV.

Use it for: existing code you don't want to rewrite, pinned to Python 3.12, or with audioop-lts installed. Consider instead: pedalboard, below.

7. pedalboard — the addition to the list

This is the library the 2022 video couldn't have included, and the one we'd point most people at now for manipulation and effects. pedalboard comes from Spotify's engineering team, is written in C++ with Python bindings, reads and writes through its own AudioFile class, and hit 0.9.24 in July 2026.

From the project's own quickstart:

from pedalboard import Pedalboard, Chorus, Reverb
from pedalboard.io import AudioFile

# Make a Pedalboard object, containing multiple audio plugins:
board = Pedalboard([Chorus(), Reverb(room_size=0.25)])

# Open an audio file for reading, just like a regular file:
with AudioFile('some-file.wav') as f:

  # Open an audio file to write to:
  with AudioFile('output.wav', 'w', f.samplerate, f.num_channels) as o:

    # Read one second of audio at a time, until the file is empty:
    while f.tell() < f.frames:
      chunk = f.read(f.samplerate)

      # Run the audio through our pedalboard:
      effected = board(chunk, f.samplerate, reset=False)

      # Write the output to our output file:
      o.write(effected)

It streams by design, so it handles files bigger than memory, and it can host VST3 and Audio Unit plugins — which means the same code that applies a built-in reverb can run a commercial plugin. If you're building an audio augmentation pipeline for model training, this is a faster path than chaining pydub and ffmpeg calls.

Use it for: effects, format conversion, and augmentation at speed. Skip it for: feature extraction and analysis, which is librosa's territory.

8. librosa — still the analysis library

If you need to analyze audio rather than move it around, there's still no real alternative. librosa 1.0.0 arrived in August 2026 and requires Python 3.12+.

import librosa
import librosa.display
import matplotlib.pyplot as plt

y, sr = librosa.load("example.wav")

fig, ax = plt.subplots()
librosa.display.waveshow(y, sr=sr, ax=ax)

centroid = librosa.feature.spectral_centroid(y=y, sr=sr)
print(centroid.shape)

Two changes worth flagging against the 2022 code. librosa.display.waveplot is gone — the function is waveshow now, and it renders adaptively as you zoom. And librosa.load resamples to 22,050 Hz by default and downmixes to mono; pass sr=None when you need the file's native rate, which you almost always do if the output is headed to another system.

Beyond that, the surface is enormous and unchanged in spirit: mel spectrograms, MFCCs, chroma features, onset and beat tracking, pitch tracking, harmonic-percussive separation. Spectrogram plotting is librosa.display.specshow. The documentation is genuinely the reference here — there are more feature extractors than any article can usefully list.

Use it for: features, spectrograms, and music information retrieval. Skip it for: real-time work; librosa is built for offline analysis.

9. torchaudio — narrower than it used to be

The 2022 video called torchaudio "the king of all audio processing libraries." That's no longer the right description. The PyTorch team announced a transition to a maintenance phase, deprecated a set of features in 2.8, and removed them in 2.9. torchaudio 2.11.0 shipped in March 2026 and now works with torch 2.11 and every future torch release.

What survived is the ML-focused core: transforms (Spectrogram, MelSpectrogram, MFCC, Resample), functional operations, dataset loaders, and forced_align.

import torchaudio
import torchaudio.functional as F

waveform, sample_rate = torchaudio.load("example.wav")

resampled = F.resample(waveform, sample_rate, 16000)
print(waveform.shape, resampled.shape)

torchaudio.load still works, but as of 2.9 it delegates to TorchCodec's AudioDecoder under the hood, and the normalize, buffer_size, and backend arguments are ignored and kept only for backwards compatibility. The docs recommend porting to TorchCodec directly. F.resample is fine, and its default resampling_method is now "sinc_interp_hann".

What's gone is torchaudio.sox_effects — the module the video used to change speed, apply a low-pass filter, and add reverberation. That code will not run today. Those transformations belong to pedalboard or ffmpeg now.

Use it for: feeding audio into PyTorch models and GPU-accelerated transforms. Skip it for: general signal processing and effects.

The 2026 comparison table

Where these libraries stop and speech-to-text starts

Every library above manipulates audio as a signal. None of them turn speech into text.

That distinction gets blurry because torchaudio ships model implementations and pipelines, so it looks like you could build your own recognizer. You can. Teams do. And it's usually the wrong call, because the work isn't the model architecture — it's everything around it. Handling accents and code-switching. Punctuation and casing that survive a noisy call. Speaker diarization that holds up when three people talk over each other. Domain vocabulary. Then GPU capacity, autoscaling, and an on-call rotation for all of it.

That's the tradeoff Veed made when they were building a browser-based video editor:

"Assembly allowed our team to focus on what they are best at: Building a collaborative, browser-based video editor and distributing that product at speed and at velocity to our user base."

— Sabba Keynejad and Tim Mamedov, Veed

The practical split looks like this. Use the libraries above to get audio in and out, resample it, and extract whatever features your own models need. Use a speech-to-text API for the recognition step. If you're comparing options for the second half, we've written separately about Python speech recognition and how accurate speech-to-text is in 2026.

Transcribing a file

Install the SDK with pip install -U assemblyai. This is the current quickstart from the Python SDK:

import assemblyai as aai

aai.settings.base_url = "https://api.assemblyai.com"
aai.settings.api_key = "YOUR_API_KEY"

audio_file = "./example.mp3"

config = aai.TranscriptionConfig(
    speech_models=["universal-3-5-pro", "universal-2"],
    language_detection=True,
    speaker_labels=True,
)

transcript = aai.Transcriber().transcribe(audio_file, config=config)

if transcript.status == aai.TranscriptStatus.error:
    raise RuntimeError(f"Transcription failed: {transcript.error}")
print(f"\nFull Transcript:\n\n{transcript.text}")

That's the whole integration. Universal-3.5 Pro is the current flagship for pre-recorded audio at $0.21/hr, and the speech_models list is a fallback chain — it tries the first model and falls back to the next. Speaker labels and language detection are parameters, not separate systems you have to build.

Where sounddevice and PyAudio come back in

For live audio, the two halves connect directly. The AssemblyAI SDK deliberately doesn't capture audio — its own docs note that you supply 16-bit PCM "from sounddevice, pyaudio, a loopback device, files, …". So the capture libraries from this list feed the streaming API over a WebSocket, with Universal-3.5 Pro Realtime handling recognition. That's the pattern behind most real-time transcription in Python: sounddevice reads the mic, the SDK streams the bytes, turn events come back a few hundred milliseconds later.

How to choose

Most audio work in Python needs two or three of these libraries, not nine. A workable default stack for 2026:

• soundfile for files, sounddevice for devices.
• librosa when you need to analyze, pedalboard when you need to transform.
• torchaudio only if PyTorch is already in your stack.
• A speech recognition API for anything involving words.

The thing worth taking from the four years between that video and this post: the libraries that stayed useful are the ones that did one job. soundfile reads files. sounddevice reads devices. librosa analyzes. The library that tried to be the king of everything is now in maintenance mode with its I/O layer handed off elsewhere. Narrow tools age better than broad ones — which is the same reason the recognition layer is worth renting rather than building.

Frequently asked questions

What are some good audio processing libraries in Python?

For 2026, the practical set is soundfile (reading and writing files), sounddevice (microphone capture and playback), librosa (analysis and feature extraction), pedalboard (effects and format conversion), and torchaudio (PyTorch transforms and datasets). The built-in wave module covers dependency-free WAV work. PyAudio still works for low-level PortAudio streams, and pydub has the friendliest API but hasn't shipped a release since 2021.

What is the best Python library for audio analysis?

librosa. It reached 1.0.0 in August 2026 and remains the standard for spectrograms, MFCCs, chroma features, onset and beat tracking, and pitch estimation. Note that librosa.display.waveplot from older tutorials was replaced by librosa.display.waveshow, and librosa.load resamples to 22,050 Hz unless you pass sr=None. Use torchaudio instead only when your features need to be PyTorch tensors on a GPU.

Is pydub still maintained in 2026?

Not actively. pydub's last release is 0.25.1 from March 2021, and it imports the audioop module that Python 3.13 removed under PEP 594, so importing it fails on current Python. Installing audioop-lts restores it, and pinning to Python 3.12 also works. For new projects, pedalboard covers most of the same manipulation and effects work and is actively developed.

What's the difference between librosa and torchaudio?

librosa is a signal-analysis library that returns NumPy arrays and is built for offline, CPU-based feature extraction and music information retrieval. torchaudio returns PyTorch tensors, supports GPU acceleration and autograd, and is scoped to preparing audio for machine learning models. torchaudio also entered a maintenance phase, removing features in 2.9 and handing decoding to TorchCodec, so librosa is the safer default for general analysis.

Can you use Python audio libraries for speech-to-text?

Not on their own. These libraries handle audio as a signal — loading, resampling, filtering, and extracting features — but none of them convert speech into text. You either train and host a recognition model yourself or call a speech-to-text API. In practice the two work together: sounddevice or soundfile prepares 16-bit PCM audio, and the API returns the transcript.

How do I transcribe audio in Python?

Install the AssemblyAI SDK with pip install -U assemblyai, set your API key, and pass a file path or URL to Transcriber().transcribe(). Universal-3.5 Pro is the current flagship model for pre-recorded audio at $0.21/hr, with speaker labels and automatic language detection available as configuration parameters. Full setup instructions are in the AssemblyAI documentation at assemblyai.com/docs.

‍