Vorbis is the royalty-free audio format with a reference C library

A public domain format with a reference implementation

Vorbis is a general purpose audio and music encoding format, contemporary to MPEG-4's AAC and TwinVQ, and positioned as the next generation beyond the MPEG audio layer 3. The point of the format, as the README puts it, is that unlike the MPEG sponsored formats and other proprietary formats such as RealAudio G2, the Vorbis codec specification belongs to the public domain. All the technical details are published and documented, and any software entity may make full use of the format without license fee, royalty or patent concerns. That is the reason Vorbis still appears in every media stack, because the legal question that constrains codecs simply does not arise here. This repository is the reference implementation of that specification, and the Xiph.Org Foundation maintains both the format and this code, with the Ogg homepage at xiph.org/ogg/ and the Vorbis homepage at xiph.org/vorbis/, where up to date technical documents, contact information, source code and pre-built utilities can be found.

Three libraries with different jobs

The package contains three distinct libraries, and the split is the practical thing to understand. libvorbis is the core, a BSD-style licensed software implementation of the Vorbis specification by the Xiph.Org Foundation, and it does the actual codec work. libvorbisfile sits on top and is described as a convenience library built on Vorbis designed to simplify common uses, which in practice means the whole-file read and write operations that most applications actually want. libvorbisenc is the third and is the one you reach for when encoding, described as a library that provides a simple, programmatic encoding setup interface. The source distribution also ships example code making use of libogg, libvorbis, libvorbisfile and libvorbisenc, and the examples directory shows the shape of each: a decoder example, an encoder example, a vorbisfile example that uses the convenience layer, a seeking example for random access into a file, a chaining example, and a frameview.pl script. The library headers live in include/, the source in lib/, and the documentation in doc/.

Building from a tarball or from git

The development source is under git revision control at gitlab.xiph.org/xiph/vorbis.git, and building from it needs the newest versions of autoconf, automake, libtool and pkg-config, because a configure script is provided in the tarball distributions rather than the repository. From a checkout you run the autogen script, then configure, then make, and optionally make install as root.

    ./autogen.sh
    ./configure
    make

From a tarball the configure script is already there, so it is configure, make and optionally make install as root. The install puts the static and shared Vorbis libraries into /usr/local/lib, the headers into /usr/local/include and the API manpages into /usr/local/man, once the project gets around to writing them. Building the documentation needs xsltproc and pdfxmltex. The repository also carries the packaging inputs for the platforms that matter, with debian/ holding the rules for building .deb packages, a libvorbis.spec.in file for RPMs, a Brewfile, macosx/ and win32/ project files, symbian/ and contrib/ directories, and the .pc template files that let pkg-config find the installed libraries.

The CMake route covers four platforms

CMake support is documented alongside the autotools build, and the README describes CMake as a meta build system that generates native projects for each platform. To generate projects you run cmake with a generator substituted for the placeholder.

    cmake -G YOUR-PROJECT-GENERATOR .

By default cmake generates projects that build static libraries, and to get dynamic libraries you set the BUILD_SHARED_LIBS option.

    cmake -G YOUR-PROJECT-GENERATOR -DBUILD_SHARED_LIBS=1 .

There are platform specific notes for the three systems that matter. On Windows you use the generator matching your Visual Studio version, with a Visual Studio 12 2013 example given. On Mac OS X you use the Xcode generator, and to build a framework you add BUILD_FRAMEWORK=1.

    cmake -G Xcode -DBUILD_FRAMEWORK=1 .

On Linux the Makefile generator is the default, so the build is cmake followed by make. The top level of the repository confirms the shape of the project: CMakeLists.txt alongside configure.ac, Makefile.am, autogen.sh, the m4/ directory for the autoconf macros, a cmake/ directory, a pkg-config template for each of the three libraries, and a test/ directory.

Building RPM packages needs a dist tarball

The RPM route is a two step affair that assumes you have already configured the tree. You make a distribution tarball with make dist, and then you build the packages from it.

    make dist
    rpm -ta libvorbis-<version>.tar.gz

The reason it is a separate step rather than a make target is that the package build runs from the tarball, which means what ends up in the package is exactly what a user would get from the release archive, with the same autotools-generated configure script rather than your local autoconf versions. That matters for reproducibility. The release artefacts themselves are tracked in the repository, with a releases.sha2 file holding the checksums, and the CHANGES file alongside it. The project also carries continuous integration for several systems at once, with GitLab pipeline status from the xiph GitLab, a Travis build status, an AppVeyor status badge for the Windows build, and a .gitlab-ci.yml at the root.

Where Vorbis is the wrong choice today

Three limits, and none of them is about the code quality. The first is age of the format relative to what exists now. Vorbis was designed as the next generation beyond the MPEG audio layer 3, and it is a lossy codec from an era when that was the comparison. If you are starting a new lossy compression project, the codecs that came after it are the ones to evaluate, and the README does not argue otherwise. The second is what Vorbis does not do. There is no lossless mode and no spectral gapless handling in this package, so a project that has to serve both lossless and lossy masters has to carry another library alongside this one. The third is the build and packaging surface. A C library with autotools, CMake, pkg-config templates, Windows project files, Mac framework targets and a spec file is a lot of moving parts, and the project ships the packaging inputs rather than a modern cross-platform build system, so distributors end up maintaining their own recipes. The maintenance record is worth stating precisely: the last push was on 2026-08-04, but the only tagged release listed is v1.3.7 from 2020-07-04, and the copyright line in the licence notice still reads 1994-2020.

Editorial conclusion

Adopt libvorbis when you need royalty-free compressed audio and you are willing to link the reference libraries, since the format specification is public domain and the code is a mature C implementation with a package-file layer and an encoding API. Skip it if you need a modern codec, because Vorbis predates the current generation of lossless and high efficiency formats, and skip it if you want a maintained build for a current toolchain, since the last tagged release is v1.3.7 from 2020-07-04 even though the last push was on 2026-08-04. Before you build from source, install libogg, which is distributed separately, and decide whether the autotools or the CMake route suits your platform better.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. xiph/vorbis on GitHub