Library / SDK
iver56/audiomentations avatar
iver56/audiomentations

Audiomentations: Waveform Augmentation for Audio ML Pipelines

A Python library for audio data augmentation. Useful for making audio ML models work well in the real world, not just in the lab.

2,316 stars222 forksPythonMIT

At a glance

What is it?
Audiomentations is an MIT-licensed Python library that applies randomised waveform transforms to audio before it reaches a model. Its API mirrors albumentations, it runs on CPU, and its value depends on whether your augmentation belongs before feature extraction or inside the GPU graph.
Who is it for?
Adopt audiomentations if your augmentation has to happen on raw samples before feature extraction, if you want the same Compose object to serve both a PyTorch DataLoader and a tf.data pipeline, or if you need a transform such as AddBackgroundNoise or ApplyImpulseResponse that depends on external audio files. Do not adopt it if your training loop is GPU-bound and you want augmentation to execute on the device; torch-audiomentations exists for that case.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 155 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap between clean training audio and messy inference audio

Speech and music models are usually trained on recordings captured under controlled conditions, then deployed against phone microphones, compressed streams and rooms with unpredictable acoustics. Audiomentations targets that mismatch by perturbing the waveform itself, before it becomes a spectrogram or an embedding. The README frames the goal as making models "work well in the real world, not just in the lab", and the transform list backs that framing up: Gain, AddBackgroundNoise, Mp3Compression, Aliasing and ApplyImpulseResponse all simulate conditions a model will meet after deployment but rarely sees during training. The audience is audio ML engineers working in Python, particularly those already using albumentations for images and expecting the same mental model. The README also notes the library has been used in Kaggle competitions and by companies building audio products, though it gives no numbers, and the repository supplies none either. Treat those as directional claims rather than evidence.

Compose is the whole architecture

There is no graph, no scheduler and no dataset abstraction. Every transform is a callable that receives samples and a sample_rate and returns a modified array. Compose holds an ordered list of those callables and applies them in sequence. The README example constructs one with AddGaussianNoise, TimeStretch, PitchShift and Shift, then calls it as augment(samples=samples, sample_rate=16000). Each transform carries its own p parameter, the probability that it fires on a given call, so randomness is distributed across the chain rather than controlled centrally. Parameters such as min_amplitude, max_amplitude, min_rate and max_semitones define ranges that are sampled per invocation. That design keeps augmentation inside the training loop: you call the Compose object in a Dataset __getitem__ or a tf.data map function, and each epoch produces different audio. The README states the library supports mono and multichannel audio and runs on CPU.

Installing and wiring it into a training loop

Installation is a single PyPI command: pip install audiomentations. The README lists Linux on arm and x86, macOS on arm and Windows on x86 under the OS badge, so the supported platform matrix is narrower than the Python version range alone suggests. The documented usage imports Compose and the individual transforms, builds a numpy float32 array, and passes it with a sample rate. Nothing in the README shows a DataLoader or a Keras Sequence, so integration is left to the reader: the transform call is synchronous and returns an array, which means it slots into any pipeline that can call Python. The p=0.5 values in the example are per-transform, not global, so a four-transform chain applies all four roughly one time in sixteen. That is a detail worth checking against your own expectations before you copy the example verbatim.

What the transform catalogue actually covers

The list is long and splits into recognisable groups. Noise injection: AddGaussianNoise, AddGaussianSNR, AddColorNoise, AddShortNoises and AddBackgroundNoise, the last of which mixes in another sound file. Filtering: BandPassFilter, BandStopFilter, HighPassFilter, LowPassFilter, HighShelfFilter, LowShelfFilter and PeakingFilter, each randomised within parameters. Time and pitch: TimeStretch, PitchShift, Shift, AdjustDuration, Padding and GainTransition. Codec and distortion artefacts: Mp3Compression, BitCrush, Clip, ClippingDistortion and Aliasing. Loudness and dynamics: Gain, Normalize, LoudnessNormalization and Limiter. Room and propagation: ApplyImpulseResponse and AirAbsorption. There is also Lambda for user-defined transforms. The breadth is the library's main argument. Several transforms, notably AddBackgroundNoise and ApplyImpulseResponse, require you to supply external audio files, so the effective quality of your augmentation depends on the provenance of those files as much as on the library.

CPU-only execution is the constraint that decides adoption

The README states plainly that audiomentations runs on CPU, and the homepage badge lists GPU support only for torch-audiomentations, the PyTorch-specific alternative it links to. That is the sharpest limitation. If your model is already GPU-bound and your DataLoader workers are saturated, waveform augmentation on CPU becomes a throughput tax on every epoch. Torch-audiomentations addresses this by operating on tensors and running on the GPU, but the README does not claim API compatibility between the two, so switching means rewriting transform construction and call sites rather than changing an import. The other boundary is that audiomentations is a waveform library. If your pipeline augments spectrograms or mel features, the transforms here do not apply directly, and the README does not present a spectrogram path. A third practical constraint: the transform names and parameters have changed across the 0.42 and 0.43 releases, so pinning a version in requirements is safer than tracking main.

torch-audiomentations and the difference in approach

The README's own pointer is to torch-audiomentations, from the Asteroid team, described as a PyTorch-specific alternative with GPU support. The difference is not cosmetic. Audiomentations takes numpy arrays and sample rates, which makes it framework-neutral: the same Compose object can serve a PyTorch Dataset, a Keras generator or a plain preprocessing script. Torch-audiomentations takes tensors and executes on the GPU, which makes it faster inside a PyTorch training loop but useless outside one. If you are training in PyTorch, are GPU-bound, and have no need for the augmentation to run during offline preprocessing, torch-audiomentations is the more natural fit. If you need one augmentation definition shared across frameworks, or you are doing CPU-side preprocessing ahead of training, audiomentations is the one that stays framework-agnostic. The README does not benchmark either against the other, so the choice rests on where your bottleneck is, not on published numbers.

Licence, maintenance and the cost of keeping up

The project is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive enough for most products, but it covers the library only. The impulse responses and background noise files you feed into ApplyImpulseResponse and AddBackgroundNoise carry their own licences, and the README does not bundle or vet them. That is a separate compliance question and not one this review can answer. On maintenance, the release history shows v0.42.0 in July 2025, v0.43.0 in September 2025 and v0.43.1 a few days later, with the repository's last push timestamped April 2026. Frequent minor releases during a period of active development mean the upgrade cost is real: transform names and parameters have shifted, and pinning a version is the cheap insurance. The library sits at 0.x, so the maintainers have not declared the API stable. Budget for reading the release notes before any bump, not just for the pip install.

Editorial conclusion

Adopt audiomentations if your augmentation has to happen on raw samples before feature extraction, if you want the same Compose object to serve both a PyTorch DataLoader and a tf.data pipeline, or if you need a transform such as AddBackgroundNoise or ApplyImpulseResponse that depends on external audio files. Do not adopt it if your training loop is GPU-bound and you want augmentation to execute on the device; torch-audiomentations exists for that case. Before committing, check three things: the Python version your environment runs against the PyPI classifiers, the licence and provenance of every impulse response and background noise file you pass in, and whether the transform names you need appear in the current docs, since the catalogue has grown across the 0.42 and 0.43 releases.

Official sources

  1. iver56/audiomentations on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Community notes

Community notes