qaac: a command line AAC and ALAC encoder built on Apple's CoreAudio tools

Apple's encoders, driven from a terminal

The project is a command line QuickTime AAC and ALAC encoder, and the mechanism is worth stating plainly because it determines everything else about how it behaves. qaac does not implement AAC. It drives Apple's own CoreAudio encoding components, which live in the CoreAudio directory of the repository alongside headers and wrapper code such as CoreAudioEncoder, CoreAudioPaddedEncoder, AudioConverterX and AudioFileX, and a separate ALAC directory holding the Apple Lossless encoder sources, with ALACEncoderX and AudioConverterXX at the root. The Apple Lossless reference encoder is what a separate program, refalac, exposes, and that program is the one that can be built and used on Linux and macOS. The practical consequence of the design is that the output is bit-exactly what Apple produces, which is the reason people reach for this tool rather than a third-party encoder, and the corresponding consequence is that the tool inherits Apple's dependencies, including on some platforms a specific version of CoreAudioToolbox. The project description calls it a CLI QuickTime AAC and ALAC encoder, and the licence field on the repository says GitHub cannot classify it, with a COPYING file at the root.

The CoreAudioToolbox glitch notice applies to CBR only

The first thing in the documentation is a dated notice, and it is the most important thing for anyone about to encode a large catalogue. It says that CoreAudioToolbox 7.9.8.x or greater, up to 7.10.9.0 which was the latest version at the time of writing, can produce glitches on the encoded result, and that the issue is only found on AAC CBR mode. The version immediately before, 7.9.7.x, is fine, but obtaining it requires a very old iTunes installer that was released in 2012. The notice links to a discussion on hydrogenaud for the detail. Two things follow. The scope is narrow, since constant bitrate is the mode that is affected and variable bitrate is not mentioned, so a workflow that deliberately uses VBR is not exposed to this particular problem. And the fix is unpleasant, because downgrading CoreAudioToolbox to a 2012 version on a modern macOS is not a routine operation. If you are encoding an archive that has to be trusted, the sensible approach is to test a short sample first, check for the glitch pattern, and only then commit a batch job to the encoder. A note dated 2024-12-21 describing a defect in a current OS component is also a reminder that this project's output depends on software you do not control.

Building on macOS needs the Command Line Tools and nothing else

The macOS build is the least fussy of the three and it is the path most users will take. The requirements are the Xcode Command Line Tools, for clang, which also provide the SDK and iconv, plus cmake and either ninja or make. The build itself is the two line cmake invocation that the project uses everywhere:

cmake -B build -G Ninja .
cmake --build build

The drop of the -G Ninja flag selects the default generator instead, which means make on Linux and macOS or a Visual Studio solution on Windows, and you can also pass the Unix Makefiles generator explicitly if you prefer make over ninja. The optional codec libraries are the other macOS specific point. FLAC, libsndfile, Opus, WavPack, libsoxr and similar libraries are loaded at runtime through dlopen rather than linked at build time, so they are not needed to build but are needed to use the corresponding features, and the documentation gives the Homebrew line to install them:

brew install flac libsndfile opus wavpack libsoxr

The runtime loading design is what lets one binary handle whatever the host has, and it is also why a missing library shows up as a missing feature at run time rather than as a build failure. The repository root shows the scale of the codebase, with a src directory holding the main sources including main.cpp, a filters directory, an input directory, an include directory, a libsoundio directory, an fft4g directory, an implib directory, an ALAC directory and a CoreAudio directory, and files for the pieces a real encoder needs such as bitstream handling, metadata, channel mapping, cue sheets, filters and a logarithmic decibel display.

Linux gets refalac, and iconv is the dependency to watch

On Linux the situation is narrower and that is stated directly: only refalac is available. The requirements are a C or C++ toolchain, either gcc or clang, cmake, and ninja or make. The dependency that catches people out is iconv, because refalac links against it, and the documentation says to make sure the libc's iconv development headers are installed. On glibc based distributions that is normally already pulled in with the rest of the toolchain, for example as part of the libc6-dev or glibc-devel packages, but if CMake's find_package for Iconv with the REQUIRED flag fails to find it, you have to install the distribution's iconv or glibc development package explicitly. The ALSA development headers, libasound2-dev on Debian and Ubuntu, are described as optional, and the consequence of not having them is specific: refalac still builds, but the play option loses its ALSA backend and falls back to the silent dummy backend. So the build never fails over audio, it just quietly stops being able to play anything. The optional codec libraries work the same way as on macOS, loaded through dlopen at run time, and the same cmake invocation is used.

Windows has six documented toolchain routes

Windows is the messiest of the three and the documentation enumerates the options rather than picking one. The base requirement is the platform SDK for the Win32 API, so on Windows you always build from a Visual Studio Developer Command Prompt, or a shell that has run the environment setup script, except when using MinGW-w64. The known working toolchains are MSVC from a Developer Command Prompt, clang-cl from a Developer Command Prompt, clang targeting the MSVC ABI from a Developer Command Prompt, MinGW-w64 GCC from MSYS2 which needs no Developer Command Prompt, and cross-compiling from Linux with the mingw-w64 toolchain, for example llvm-mingw or a distribution's mingw-w64-gcc. The MSVC, clang-cl and clang routes all use the same two cmake commands as the other platforms, and the cross-compile route passes the system name and the cross compilers, with the compiler target set to the MSVC ABI. The 32-bit variant is the same command with a different target triple. There is one non-command-line route, and it is the one many Windows developers will prefer: from Visual Studio 2017 or later, use the Open Folder command on the repository and the built-in CMake support will configure it and let you build and debug directly from the IDE. Both the UCRT environment from MSYS2 and the legacy MSVCRT environment are said to build and work with the MinGW route.

What a project like this is actually for

It is worth being direct about the use case, because the tool does one narrow thing and the reason to reach for it is a specific constraint rather than a general preference for better audio. The common reason is scripting, since a command line encoder can sit in a build pipeline, a batch job or a container image where a GUI encoder cannot go. The second reason is the Apple Lossless requirement, since ALAC on Linux and macOS is exactly what refalac provides, and the Apple Lossless reference encoder is not otherwise distributed as a usable tool. The third is bit-exactness, since wrapping Apple's own implementation means the output matches what Apple produces, which matters when you are matching a reference or when other tools in your pipeline are built around Apple's encoder. The cost of all three is the same dependency on Apple's platform components, and on Windows that means a heavier build environment than a self-contained encoder would require. If your requirement is simply a good AAC file with no Apple constraint, a self-contained open source encoder is less work to deploy. If your requirement is specifically Apple Lossless on a non-Apple machine, or scripting around the CoreAudio encoders, this project is the direct answer.

Editorial conclusion

qaac is a good fit for a pipeline that needs scriptable AAC or ALAC output from Apple's encoders, and refalac in particular is the answer for a Linux or macOS build that needs Apple Lossless without a Mac. It is the wrong tool if you need a modern, actively maintained AAC encoder on Linux, since the AAC path on that platform is not what this project provides, and it is the wrong tool for a Windows user who does not want to deal with Visual Studio command prompts. Before using it, read the notice at the top of the documentation, because CoreAudioToolbox 7.9.8 and later can produce glitches in AAC CBR mode, and the only clean version is one that needs a 2012 iTunes installer. The licence is a custom one GitHub cannot classify, and the last push was on 2026-09-10.

Frequently asked questions

Official sources

1. Issues
2. nu774/qaac on GitHub
3. README
4. Releases