Sonic Visualiser: reading a music recording on a spectrogram

A spectrogram with layers on top

Sonic Visualiser is described as a free, open source, cross-platform desktop application for music audio visualisation, annotation and analysis, and the project subtitle is a program for viewing and analysing the contents of music audio files.

The list of what you can do with it is the clearest description of the tool.

You load audio files in various formats, including WAV and AIFF, Ogg, Opus and MP3, and view their waveforms. You look at audio visualisations such as spectrogram views, with interactive adjustment of the display parameters, which is the part that separates it from a plain waveform editor: the spectrogram parameters are adjustable while you listen, so you can zoom into a frequency band until a harmonic series becomes legible.

You annotate the audio by adding labelled time points and defining segments, point values and curves. Those are layers, and the layering is the core idea of the interface. A spectrogram is one layer, a beat track is another, a pitch contour is a third, and they stack on the same timeline so they can be read against each other.

Everything else in the list supports that: playback of the original audio with synthesised annotations, taking care to synchronise playback with the display position, slowing down and speeding up playback, looping segments of interest including continuous looping of complex non-contiguous areas, and exporting annotations and audio selections to external files.

Automatic annotation through the Vamp plugin framework

Manual annotation is only half the job, because most analyses are automated.

Sonic Visualiser can run feature extraction plugins to calculate annotations automatically, using algorithms such as beat trackers, pitch detectors and so on, and the plugin ecosystem is the separate Vamp plugins project at vamp-plugins.org.

The separation matters architecturally. The Vamp plugin SDK is a separate library with its own licence, credited in the README to Chris Cannam and QMUL under a BSD licence, and the LADSPA plugin SDK is also supported, credited to Richard Furse and others under the LGPL. So the analyser ecosystem is not locked to one framework: a plugin you already have as a LADSPA module can be run inside Sonic Visualiser.

The other import path is annotation data itself. Sonic Visualiser can import annotation data from various text formats and from MIDI files, which is how you get an analysis produced elsewhere into the same view where you can compare it against the audio.

For a researcher this is the whole point. You run a beat tracker, see where it disagrees with what you hear, adjust the parameters, re-run, and export the result. The plugin list and the Vamp site are where the available algorithms live.

Remote control over OSC and the built-in sample audio

Two smaller capabilities are worth knowing about.

The first is remote control. Sonic Visualiser can be controlled remotely using the Open Sound Control protocol, if support is compiled in. The conditional matters, because this is a build-time option rather than a runtime toggle, and the repository has a dedicated README_OSC.md for it. The OSC library it uses is liblo, credited to Steve Harris under the GPL. This is how you drive the visualiser from a controller, a script, or another piece of live performance software.

The second is the samples directory, which holds a set of short audio files used for trying things out. The list is a percussion and keyboard set: bass, beep, bounce, clap, click, cowbell, electric piano, hihat, kick, organ, piano, silent, snare, stick, strike and tap, each as a .wav file with a samples/README alongside.

That is a practical convenience rather than a feature. Being able to load a two second kick drum and a snare means you can test a beat tracker or a tempo estimator in seconds instead of hunting for a recording.

The main/ directory holds the application itself, and the i18n/ directory holds the interface translations, which is covered by a separate TRANSLATION.md with notes on how to update the UI translation strings.

Building it: meson, three platforms, three CI builds

The build system is meson, with meson.build at the repository root and meson_options.txt beside it. The version is generated from version.h.in, and the icon and desktop integration files are present for Linux.

The README does not try to hide the difficulty of compiling this, and instead sends you to three separate documents, one per platform: COMPILE_linux.md, COMPILE_macos.md and COMPILE_windows.md.

Those three platform builds are checked through continuous integration, with separate workflows for Linux, macOS and Windows, and each has a build status badge in the README. So a change that breaks one platform is caught by CI rather than by a user.

The dependency list in the README is where the real work is. The GUI is Qt6, distributed under the LGPL. Audio input and output go through JACK, credited to Paul Davis and Jack O'Quin, also LGPL, and PortAudio, credited to Ross Bencina and Phil Burk, under a BSD licence.

Then the codecs and processing libraries. An Ogg decoder from CSIRO Australia under BSD, a MAD mp3 decoder from Underbit Technologies under the GPL, an Opus decoder from Xiph.org under BSD, libsamplerate and libsndfile from Erik de Castro Lopo, FFTW3 from Matteo Frigo and MIT under the GPL, and the Rubber Band Library from Particular Programs Ltd under the GPL, which is the time stretching and pitch shifting component that makes the variable speed playback with annotations work.

There is also Vamp and LADSPA for plugins, RtMIDI by Gary Scavone for MIDI, Cap'n Proto from the Sandstorm Development Group for serialisation, and the Sord, Serd and Redland libraries from David Robillard and Dave Beckett for the RDF metadata handling.

Two decades of institutional history

The credits section tells a story that is unusual for an open source application, and it explains why the project has the shape it has.

Sonic Visualiser was devised and developed up to release 4.2 at the Centre for Digital Music at Queen Mary University of London, primarily by Chris Cannam, with contributions from Christian Landone, Mathieu Barthet, Dan Stowell, Jesús Corral García, Matthias Mauch and Craig Sapp. Special thanks go to Professor Mark Sandler for initiating and supporting the project.

The 4.3 to 4.5 releases were developed by Chris Cannam at Particular Programs Ltd, a company that appears repeatedly in the credits because Chris Cannam runs it. The 5.0 release was supported once again by the Centre for Digital Music at Queen Mary.

That is a development history with a gap, a commercial interlude and a return to academia, which is worth knowing if you are considering depending on the project.

The funding list is equally concrete. The work was partially funded by the European Commission through the SIMAC project IST-FP6-507142 and the EASAIER project IST-FP6-033902, by the Arts and Humanities Research Council through its Research Centre for the History and Analysis of Recorded Music project, and by the Engineering and Physical Sciences Research Council through the OMRAS2 project, the Musicology for the Masses project and the Sound Software project.

For sponsorship, the README asks you to contact Particular Programs Ltd if you want to sponsor future general development or need something specific with funding available. For citation, there is a CITATION file in the repository, and the README asks that you see it if you use Sonic Visualiser in research work for publication.

Licence, releases and what it is not

Sonic Visualiser is free software distributed under the GNU General Public License version 2 or later, with the COPYING file in the distribution giving the details. The copyright lines cover 2005 to 2007 Chris Cannam, 2006 to 2020 and 2024 to 2025 Queen Mary University of London, and 2020 to 2023 Particular Programs Ltd, with exceptions noted in individual source files.

Translations carry their own attribution. The Russian translation was initially provided by Alexandre Prokoudine and updated by Sergey Kazorin, and the Czech translation by Pavel Fric.

The release history is steady and the tags are named after the version. The listed releases are sv_v5.2.1 from 2025-03-21, sv_v5.2 from 2025-03-07 and sv_v5.0.1 from 2024-10-01. The repository is not archived and the last push was on 2026-10-18, so work continues after the last tagged release.

It is worth being clear about what this is not. It is not a digital audio workstation. There is no mixing console, no track timeline, no effects rack, no mastering chain. It is not a tagger for the kind of metadata a music player displays. And it is not a live performance tool in the sense of a real time instrument, though the OSC control and the variable speed playback mean it can be driven during a performance.

What it is, is a microscope for audio with a plugin ecosystem and a layer model, and for the questions a musicologist, a producer or a sound designer actually asks about a recording, that is the tool.

Editorial conclusion

Adopt Sonic Visualiser if you need to inspect a music recording closely, to find where a beat lands, to annotate a passage, or to run a beat tracker or pitch detector over a file and inspect the output against the waveform. Do not adopt it as a general audio editor or a live performance tool, since it is an analysis environment rather than a DAW, and expect a C++ build with its Qt6 and audio stack if you compile it yourself. Verify first that your platform has a current prebuilt binary at sonicvisualiser.org, that your operating system has the required audio and graphics libraries if you build from source, and that you read the CITATION file if the analysis ends up in a publication, because the project asks for it explicitly.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. sonic-visualiser/sonic-visualiser on GitHub