Every time-frequency transform, now in one C library

What it does

audioFlux is a C library with Python bindings that extracts audio features for machine learning. It wraps time-frequency transforms, spectral features, and music information retrieval algorithms into decoupled modules so you can feed the results straight into classification, separation, or ASR pipelines. Think of it as a modular factory that turns raw waveforms into Mel spectrograms, chroma vectors, pitch tracks, or onset detections.

The interesting bit

The library treats transform diversity as a first-class feature. It implements BFT, NSGT, CWT, PWT, CQT, VQT, S-Transform, and several wavelet variants, then lets you project most of them onto Linear, Mel, Bark, Erb, Octave, or Log scales. It even bundles synchrosqueezing algorithms to sharpen the resulting spectrograms, which is the kind of obsessive completeness usually found in academic toolboxes rather than streamlined production libraries.

Key highlights

• Core algorithms are implemented in C and the project supports Linux, macOS, Windows, iOS, and Android.
• The transform module includes reassignment and synchrosqueezing methods (reassign, synsq, wsst) for sharpening time-frequency representations.
• The MIR module covers eight pitch estimation algorithms (YIN, CEP, PEF, NCF, HPS, LHS, STFT, FFP) plus pitch-shifting, time-stretching, and a recent instrument tuner called TuneTrack.
• The architecture uses a data-stream design that decouples transforms, features, and MIR tasks to allow multi-dimensional feature extraction.

Caveats

• The README advertises “hundreds of corresponding time-domain and frequency-domain feature combinations,” but only documents four feature categories (spectral, xxcc, deconv, chroma), so the full scope is unclear.
• The benchmark section shows a chart image but offers no textual numbers or methodology, making performance claims hard to evaluate from the README alone.

Verdict

Grab it if you are building audio ML models and want to experiment across many transforms without assembling a Frankenstein dependency chain. Skip it if you already have a fixed signal-processing stack and just need one reliable transform.