CUETools treats a CD image as more than its audio tracks

The unit of work is a disc image, where the gap data counts as content

CUETools describes its purpose as lossless audio and CUE sheet conversion with one overriding goal: making sure the album image is preserved accurately. That framing is the whole point of the project, and it separates it from general purpose audio converters. A lossless disc image has to be lossless in two senses at once. The audio samples must survive intact, and the gaps between tracks plus the CUE sheet metadata must survive intact as well. The README uses foobar2000 as the concrete example of an application that drops disc pre-gap information during a conversion and does not handle gaps appended CUE sheets, which is a noncompliant layout that some authoring tools emit. If you rip a disc and lose the pre-gap, you have not preserved the release even though every sample is bit identical. The audience is therefore disc owners and archivists doing bulk conversion work, not streaming engineers working from mastered digital files.

Seven output formats and every CUE sheet style are in scope

The supported formats list names WAV, FLAC, APE, LossyWAV, ALAC, TTA and WavPack as both input and output, and it states a hard constraint on the audio: it must be 16-bit, 44.1kHz samples stereo, that is CD PCM. That single restriction removes any ambiguity about what the converters are for. On the metadata side the claim is broader: every CUE sheet style is supported, with embedded, single file, and gaps appended, prepended or left out variants all covered. Two further input modes widen the practical reach. You can process a directory of audio files with no CUE sheet at all, which covers loose track dumps, and you can feed a RAR archive in as input without unpacking it first. Those two capabilities matter more than they sound, because the archive path means a batch job does not have to expand tens of gigabytes of disc images to disk before converting them.

Building from source means applying five patches to submodules by hand

Prebuilt binaries are offered through the CUETools Download page at cue.tools, but the source route is documented in the README and it is not a single command. You clone the tree first.

git clone https://github.com/gchudov/cuetools.net.git
git submodule update --init --recursive

The recursive submodule step brings in FLAC, taglib-sharp, WavPack, WindowsMediaLib and the MAC SDK, and none of them works unmodified. The README then lists a sequence of patch applications, each targeting a different third party directory.

git apply --directory=ThirdParty/flac ThirdParty/submodule_flac_CUETools.patch --whitespace=nowarn
powershell -c "Expand-Archive ThirdParty/MAC_SDK/MAC_1086_SDK.zip -DestinationPath ThirdParty/MAC_SDK/"
git apply --directory=ThirdParty/MAC_SDK ThirdParty/ThirdParty_MAC_SDK_CUETools.patch
git apply --directory=ThirdParty/taglib-sharp ThirdParty/submodule_taglib-sharp_CUETools.patch
git apply --directory=ThirdParty/WavPack ThirdParty/submodule_WavPack_CUETools.patch
git apply --directory=ThirdParty/WindowsMediaLib ThirdParty/submodule_WindowsMediaLib_CUETools.patch

The MAC SDK archive is expanded with a PowerShell call in the middle of the list, so the sequence is not purely git based. Each patch has to land in the right directory or the build fails later with an obscure error. This is the most tedious part of adopting the project from source, and it is also the point at which a mismatch between your checkout and the upstream submodule commits will show up.

Visual Studio 2017 or newer is the only documented build path

After the patches, the README moves to the IDE. The solution can be built using Microsoft Visual Studio 2017 or newer, and the Community Edition is stated to be sufficient. The required development tools are listed as .NET Framework 4.7 and .NET Core 2.0, along with an appropriate Windows SDK version, for example 10.0.16299.0 or newer, and the Microsoft Visual Studio Installer Projects. You then open cuetools.net\CUETools.solution, select Any CPU under Solution Platforms, and build. Any CPU matters because the repository carries processor specific components, including CUETools.AVX and OpenCL related codecs, so the build produces code paths that will select the right one at runtime on the target machine. The practical consequence is that this is a Windows toolchain end to end. There is no documented Linux or macOS build in the README, so anyone on those platforms is limited to the prebuilt Windows binaries or to porting the solution themselves.

CUERipper covers the disc side without the EAC configuration burden

The suite includes CUERipper, a utility for extracting digital audio from CDs that the README positions as an open source alternative to EAC. The stated difference is a matter of degree: CUERipper has far fewer configuration options, which makes it somewhat easier to use, and it ships inside the CUETools package so you get the ripper and the converter from one install. It supports the MusicBrainz and freeDB metadata databases along with AccurateRip and CTDB for verification. The top level directory listing shows the ripper split across several projects, CUERipper, CUERipper.WPF for the Windows Presentation Foundation front end, and CUETools.Ripper.Console with SCSI and hardware related pieces alongside Bwg.Scsi and Bwg.Hardware. That layout suggests a drive layer built around real optical hardware rather than a wrapper around an external command, though the README does not describe the internals of that layer.

The codec layer is a matrix of interchangeable backends

What stands out in the source tree is the number of parallel codec implementations. The directory listing shows separate projects for ALAC, FLAC, FLACCL, FlaCuda, Flake, Icecast, LossyWAV, MACLib, MPEG, TTA, WMA, ffmpeg, lame_enc, libFLAC, libmp3lame and libwavpack, plus separate modules for audio APIs and output paths such as CoreAudio, DirectSound, CDRepair, ChaptersToCue, CDImage, the DSP mixer and resampler, and the ArcUe and CLParity verification tools. Two of these names point directly at accelerator use: FLACCL and FlaCuda are separate projects alongside a plain FLAC path, and the project topics list OpenCL. The architecture is a converter core with swappable encoders rather than a single hard wired codec, which is how a project can support FLAC and ALAC and LossyWAV in one interface and still offer hardware accelerated variants where the platform supports them. The cost of that flexibility is a large surface area and a lot of third party code to patch and keep building.

A custom licence and a long gap since the last tagged release

Two facts should shape any adoption decision. First, the licence is listed as a custom one that GitHub cannot classify, with the terms living in the LICENSE file in the repository. That is a legal review item rather than a technical one, and it is the reason to read that file before shipping anything built on the code. Second, the release history is thin: the newest tagged release listed is v2.2.6 from 2024-06-28, preceded by v2.2.5 in December 2023 and v2.2.4 in June 2023. The last push was on 2026-09-05, so work has continued in the repository well after that tag. The practical difference matters to anyone tracking versions: there is no newer installer to download from the release list, and the current state of the tree has to be built from source to use.

Editorial conclusion

CUETools fits people who own discs, care about the gap data and the CUE sheet as much as the audio, and work on Windows with Visual Studio available. It is the wrong tool for anyone processing modern lossless files with no disc heritage, for Mac or Linux users who only have the source instructions, and for anyone needing a plain open source licence grant, since the project carries a custom licence file that GitHub cannot classify. Verify three things before adopting it: that your source images are 16-bit 44.1kHz stereo CD PCM, that the CUE sheet style in your image is one the converter handles rather than one it normalises away, and that the terms in the LICENSE file permit the redistribution you have in mind. The last release listed is v2.2.6 from 2024-06-28, while the last push was on 2026-09-05, so plan for building from source rather than expecting a current installer.

Frequently asked questions

Official sources

1. gchudov/cuetools.net on GitHub
2. Issues
3. Project website
4. README
5. Releases