aubio: audio and music analysis in C, with a Python module and command line tools

What aubio detects, and who needs that

aubio is a library that listens to audio signals and attempts to detect events. The README puts it plainly: when a drum is hit, at which frequency a note sits, or what tempo a rhythmic melody runs at. Those are three different outputs from one codebase, and they map onto three different jobs.

The first job is segmentation. You have a long recording and you want the timestamps where new sounds start. The README describes segmenting a sound file before each of its attacks, and the aubiocut tool slices sound files at onset or beat timestamps. That is the workflow for chopping a drum loop into one-shots or splitting a live set into tracks.

The second job is measurement. aubiopitch attempts to identify a fundamental frequency, or pitch, for each frame of the input sound. aubiomfcc computes Mel-frequency Cepstrum Coefficients, which is the standard feature vector for timbre work. aubioquiet extracts quiet and loud regions. These are the primitives behind key detection, instrument classification and dynamics analysis.

The third job is rhythm. aubiotrack outputs the time stamp of detected beats, and aubionotes emits midi-like notes with an onset, a pitch and a duration. The README also mentions producing midi streams from live audio.

Who is this for? The setup.py classifiers say Intended Audience :: Science/Research and Topic :: Multimedia :: Sound/Audio :: Analysis. That is accurate. It is for people who can work with frame-level signal processing and want the algorithms already written, rather than for someone who wants a finished product with a GUI. The name itself is a warning: aubio comes from audio with a typo, and the README notes that some errors are likely to be found in the results. Treat the output as an estimate, not ground truth.

Onset, pitch, tempo and MFCC: the algorithms behind the tools

The README lists the routines the library provides: several onset detection methods, different pitch detection methods, tempo tracking and beat detection, MFCC, FFT and phase vocoder, up/down-sampling, digital filters including low pass and high pass, spectral filtering, transient/steady-state separation, sound file read and write access, and mathematics utilities for music applications.

That list is the architecture. aubio is not a single detector; it is a set of building blocks that share a common front end. Audio comes in, gets resampled if needed, gets windowed and transformed through the FFT or phase vocoder, and then one or more detection routines operate on the spectral frames. The filters and spectral filtering routines exist because different detection methods want different preprocessing. The transient/steady-state separation is the same idea applied at a higher level: split a signal into the part that changes abruptly and the part that holds steady, then analyze each differently.

The command line tools are thin wrappers over those blocks. aubioonset, aubiopitch, aubiomfcc, aubiotrack, aubionotes and aubioquiet each expose one detector with a file input and a text output. The repository layout confirms this: examples/ contains aubiomfcc.c, aubionotes.c, aubioonset.c, aubiopitch.c, aubioquiet.c and aubiotrack.c, alongside shared helpers in utils.c, utils.h, parse_args.h and jackio.c. The presence of jackio.c and jackio.h is the live-audio path, since JACK is the low-latency audio server used on Linux.

Two tools are different in kind. aubio and aubiocut come with the Python module rather than the C library, per the README. aubio extracts information from sound files; aubiocut slices them at onset or beat timestamps. The split matters because the Python module can be built either against a locally compiled libaubio or on its own, and setup.py carries a commented-out TODO about tracking whether the package is built against libaubio. In practice you should check which one you have, because the two builds can behave differently.

Installing aubio and running a first pitch detection

The README points to the manual's installing page for full instructions, and gives the short version for a source build. On Linux, Mac OS X, Windows, Cygwin and iOS, aubio compiles, and the top-level Makefile wraps the waf build system. The Makefile's own header lists the rules: make configure, make build, make install, make test_python.

If you are building from a clone, the Makefile fetches waf for you before configuring:

make configure
make build
make install

The Makefile sets PREFIX to /usr/local by default, with LIBDIR, INCLUDEDIR, DATAROOTDIR and MANDIR derived from it, so the install lands in the usual places unless you override PREFIX. The configure step passes --enable-double if HAVE_AUBIO_DOUBLE is set in your environment, which switches the library to double precision. If you need that, export the variable before running make.

For the Python module, the README gives a different command:

./setup.py build

setup.py compiles the extension from the C sources in python/ext and links against numpy's headers if numpy is importable. On macOS it adds the CoreFoundation and AudioToolbox frameworks; on win32 it adds the /utf-8 compile flag. requirements.txt lists numpy and pytest, so installing those first is the safe order. If you would rather not build at all, the README's badges reference PyPI and conda-forge distributions of aubio, so pip and conda are the two package routes the project itself points at.

Once installed, the fastest real use is the pitch tool. aubiopitch attempts to identify a fundamental frequency for each frame of the input sound and prints a timestamp and frequency per line. Point it at a file and read the second column. If the tool is on your PATH after make install, no wrapper is needed. The Python module gives the same detectors as objects, and python/README.md is where the README sends you for that API.

Where aubio fails: monophonic assumptions and silent documentation

The most important limitation is implicit in the algorithm list. aubiopitch identifies a fundamental frequency, singular, per frame. That is a monophonic model. Feed it a full mix with several simultaneous instruments and the detector has to pick one answer for a frame that contains many, so the output becomes unstable rather than wrong in an obvious way. If your input is polyphonic, pitch detection is the wrong tool here and you should look at the onset and beat tools instead, which are more tolerant of dense material.

The second limitation is documentation coverage. The README documents what the library does and where the manual lives, but it does not document rollback, downgrade paths or version compatibility between the Python module and libaubio. The setup.py file even carries a TODO about finding a way to track whether the package is built against libaubio, which tells you the project itself considers that ambiguity unresolved. If you need a guaranteed reproducible environment, pin the version you build against and record whether the module was built standalone or against a system libaubio.

The third is the release cadence. The most recent release listed is 0.4.9 from 2019-02-27, and the release before that was 0.4.8 from 2018-11-22. The README displays a Commits since last release badge, which is the project acknowledging that the gap is visible. The last push to the repository was on 2026-04-10, so development activity exists, but it is not packaged into releases. Anyone who depends on tagged versions is depending on a 2019 tag. If your process requires regular releases, this is the wrong project for you.

aubio against librosa and Essentia

The obvious alternative for Python audio analysis is librosa, which is a Python library built on numpy and scipy rather than a C library with Python bindings. The difference in approach is where the work happens. aubio is C first: the detectors live in src/, the command line tools are compiled binaries in examples/, and the Python module is an extension module wrapping the C. librosa is Python first, so its algorithms are expressed in numpy operations and its performance profile follows from that.

That has practical consequences. With aubio you can install the CLI tools on a machine with no Python at all and run aubiopitch or aubiotrack from a shell script. With a Python-first library you need a Python environment to do anything. Conversely, if you want to modify a detector's internals, aubio means editing and recompiling C, while a Python-first library lets you change the algorithm in place. aubio also exposes lower-level pieces that pure analysis libraries often keep internal: the phase vocoder, up/down-sampling, digital filters and spectral filtering are all listed as part of the public feature set.

Essentia is the other comparison worth making. It is also a C++ library with Python bindings aimed at music analysis, and it covers a broader feature surface for music information retrieval. The trade-off is build weight: aubio's Makefile is a thin waf wrapper with a short list of dependencies in requirements.txt, while a heavier MIR toolkit brings a larger dependency tree. If you want a small C library you can embed, aubio's footprint is the argument for it. If you want the widest set of extractors out of the box, look elsewhere.

Licence and the cost of staying on 0.4.9

aubio is GPL-3.0, either version 3 of the License or, at your option, any later version. That is the single most consequential fact about adopting it, and it is not a detail you can defer. GPL-3.0 is a copyleft licence. Linking aubio into a proprietary application, or shipping a binary that incorporates it, brings the licence's distribution obligations with it. If your product cannot ship under GPL-3.0 terms, aubio is the wrong dependency regardless of how well the detection works. If you are building internal tooling that never leaves your organization, the calculus is different. This is a description of the licence, not legal advice; read COPYING in the repository and talk to someone qualified before you ship.

The upgrade cost is the second half of the maintenance picture. The last release is 0.4.9 from 2019-02-27, and the last push to the repository was on 2026-04-10. That gap means fixes and improvements may exist in the tree without a corresponding tagged release. Building from master gets you whatever is there, but it also means you are tracking an untagged state with no release notes to diff against. The project supports several build systems at once: CMakeLists.txt, meson.build and wscript all sit at the top level, alongside .circleci/, .travis.yml, azure-pipelines.yml and .appveyor.yml for continuous integration across platforms. That breadth is good for portability and bad for knowing which path is the maintained one. Pick one build system, pin the commit you built, and keep the build recipe with your source.

Editorial conclusion

Adopt aubio if you need onset, pitch, beat or MFCC extraction from files or live audio and GPL-3.0 fits your distribution model; the Python module and the CLI tools cover most analysis jobs without writing C. Do not adopt it if you need a permissively licensed dependency, a release train newer than 0.4.9 from 2019-02-27, or documented rollback and upgrade procedures, because the README does not document either. Verify first that your platform build works, since the README lists Linux, Mac OS X, Windows, Cygwin and iOS as supported, and check the manual's installing page for the flags your build needs.

Frequently asked questions

Official sources

1. aubio/aubio on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases