# Chromaprint Audio Fingerprinting for AcoustID > Chromaprint is a focused C and C++ library for compact fingerprints used to identify near-identical audio through AcoustID. It suits file identification, duplicate detection and long-stream monitoring, but deliberately trades fingerprint precision and resilience for search performance. **acoustid/chromaprint** — C library for generating audio fingerprints used by AcoustID - Repository: https://github.com/acoustid/chromaprint - Stars: 1,416 · Forks: 178 - Language: C++ - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-11-03 · Language: en - Canonical page: https://hysenlabs.com/projects/acoustid-chromaprint ## Chromaprint's AcoustID Identification Scope Chromaprint solves a specific problem: producing compact fingerprints for near-identical audio so an audio search service can identify matching material. It was developed for AcoustID and is not presented as a general-purpose audio fingerprinting solution. That boundary matters when selecting a library. Chromaprint is aimed at full audio file identification, duplicate audio file detection and monitoring long audio streams. These workloads reward small fingerprints and efficient searching, which is why the project explicitly trades some precision and resilience for search performance. The fingerprint is therefore one part of a larger identification flow. Chromaprint generates the representation, while the AcoustID project provides the search context associated with using these fingerprints. A developer embedding Chromaprint should not assume that generating a fingerprint also identifies a track against a database. The README documents no general matching API, acoustic database or universal similarity engine. Its target is identification through AcoustID-compatible fingerprints, not arbitrary comparison of every kind of audio. This specialization also explains the project scope. It can be reasonable for recognizing a complete recording, finding duplicate files in an AcoustID-aware catalog, or monitoring a stream for known audio over time. It is less suitable when the requirement is fine-grained musical similarity, general media similarity, arbitrary time alignment, or a fingerprinting method intended for a different search index. The README does not document guarantees for those cases. ## FFT Selection and fpcalc Audio Processing Based on the repository layout, the implementation is centered under `src/`, with package metadata, CMake modules, tests and generated API documentation configuration at the repository root. The README documents support for four FFT backends: FFmpeg, FFTW3, KissFFT and vDSP. FFmpeg is preferred on systems other than macOS, while the standard vDSP framework is preferred on macOS. KissFFT acts as the bundled fallback when the build system cannot locate another FFT library. The backend is configurable through `FFT_LIB`. This choice affects both implementation and licensing. FFmpeg supplies the FFT functionality and is also used by `fpcalc` for audio decoding and resampling. FFTW3 can perform the FFT work, but the README warns that its GPL license also makes the resulting Chromaprint binary GPL licensed. KissFFT is described as slower, but it has a permissive license and is included with Chromaprint, which can simplify builds on systems without packaged FFmpeg or FFTW3. vDSP is the platform-specific choice documented for macOS. Chromaprint is the library, but `fpcalc` is the associated command-line utility produced when tools are enabled. The README identifies it as the utility used by projects such as MusicBrainz Picard. FFmpeg supplies its decoding and resampling path. The README does not list `fpcalc` command-line options. ## Building the Library and fpcalc Utility The documented build requires CMake and FFmpeg libraries. The following is the common Release build with the tools enabled. It builds Chromaprint as a shared library and includes `fpcalc`; the final command installs the resulting artifacts under the permissions available to the current user. ```bash cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TOOLS=ON . make sudo make install ``` The README does not give a first `fpcalc` invocation, accepted media formats, output interpretation or example fingerprint. For a build where FFmpeg is installed outside a standard location, the documented option is `FFMPEG_ROOT`: ```bash cmake -DFFMPEG_ROOT=/path/to/local/ffmpeg/install . ``` That command configures the source tree against the specified local FFmpeg installation. The README says that FFmpeg is preferred, although it also tries to support libav. It documents no supported operating system versions, package-manager packages, binary archives or installation paths. ## KissFFT and FFTW3 Build Trade-offs A source build can select KissFFT explicitly when its licensing or portability properties fit the application better than the preferred FFmpeg or vDSP backends. The documented command is: ```bash cmake -DFFT_LIB=kissfft . ``` This selects KissFFT for the FFT component. The README calls KissFFT the slowest of the available options, but it also describes it as easy to build and permissively licensed. The repository ships a copy, and that fallback can help when the build cannot find FFmpeg, FFTW3 or another supported FFT library. These are trade-offs rather than universal recommendations. A deployment may accept slower processing in exchange for simpler source integration or different license obligations. FFTW3 follows a different approach. It is an external FFT library rather than the bundled fallback described for KissFFT. Its GPL license has a direct consequence for distribution according to the README: linking or building with it makes the resulting Chromaprint binary GPL licensed. That statement should be reviewed against the actual build configuration and applicable license obligations when packaging software. The repository's licence is reported as NOASSERTION rather than a standard SPDX identifier, and the root contains a `LICENSE.md`. The README does not reproduce those terms, so the classifier alone is insufficient for an adoption decision. Review `LICENSE.md` directly, then account for the selected FFT and FFmpeg components. Those dependencies form part of the build choice rather than a separate installation detail. ## Tests, Documentation and Upgrade Surface The repository includes a `tests/` directory and documents a CMake-driven test build. Enabling tests also requires the sources of Google Test: ```bash cmake -DBUILD_TESTS=ON . make check ``` These commands configure the test suite and invoke the build's `check` target. The README does not list test cases, platform coverage or supported compiler matrix, so the existence of the suite does not by itself establish compatibility with a particular deployment. It does give integrators a project-specific validation step beyond the Release build. Doxygen is also supported for generating HTML API documentation: ```bash make docs ``` The generated result is placed at `doc/html/index.html`. The API documentation is the relevant place to inspect exact function signatures and lifecycle rules because the README does not list them. Upgrade work appears concentrated around releases and build configuration. The repository records `v1.6.0` on 2025-08-28, `v1.6.1` on 2026-07-28 and `v1.6.2` on 2026-10-15. The last push was on 2026-10-15, and the repository is not archived. That establishes a recent commit and a recent release, but the README does not describe release compatibility, migration notes, ABI policy or a supported upgrade path. An integrator moving from `v1.6.0` or `v1.6.1` therefore has to consult the release contents and generated API documentation rather than assume compatibility. ## When Chromaprint Is the Wrong Tool The clearest wrong-tool case is a general audio similarity problem outside the stated targets. Chromaprint prioritizes compact output and search performance over precision and resilience. Applications that need the highest matching tolerance among altered or noisy versions may find that trade-off unsuitable, particularly if their indexing and search requirements differ from AcoustID's model. It is also a poor fit when the expected workflow is a self-contained identification service. The library generates fingerprints, but the README does not promise a fingerprint database, lookup service, track metadata resolver or end-to-end AcoustID client. The caller would still need a compatible search or identification system and a way to interpret its results. Assuming those responsibilities are included would turn a focused library into a product architecture it does not document. Language wrappers provide alternatives where C++ integration is inconvenient. The README lists Python, Rust, Ruby, Perl, Raku, JavaScript, Go, C#, Pascal, Scala, Vala and Swift bindings or reimplementations. Some entries are bindings or wrappers, while others are explicitly labeled reimplementations. Their compatibility and license terms are not described in the README. They differ in integration language and implementation strategy, but should not be treated as interchangeable without reviewing their own repositories. FFmpeg and GStreamer integrations are also listed, offering a different approach when fingerprint generation belongs inside an existing media-processing pipeline. ## Conclusion Adopt Chromaprint when the task is compact audio identification tied to the AcoustID approach, especially whole-file lookup, duplicate detection or continuous stream monitoring. Do not treat it as a general fingerprinting engine for unrelated similarity search. Before integration, verify decoding and resampling behavior in your target FFmpeg environment, inspect LICENSE.md, and confirm that the precision and search-speed trade-off suits your acceptance criteria. ## FAQ ### How do I build Chromaprint and the fpcalc utility? Install the FFmpeg libraries, run CMake with `-DBUILD_TOOLS=ON`, then build and install the project. The README also documents `-DFFT_LIB=kissfft` and `-DFFMPEG_ROOT=/path/to/local/ffmpeg/install` for backend and non-standard FFmpeg selection. ### Which FFT backends does Chromaprint support? Chromaprint supports FFmpeg, FFTW3, KissFFT and vDSP. FFmpeg is preferred except on macOS, where the standard vDSP framework is preferred, while KissFFT is shipped as a fallback. ### Can Chromaprint be used as a general-purpose audio fingerprinting library? No. The README explicitly says it is not a general-purpose audio fingerprinting solution. It targets full audio identification, duplicate file detection and long audio stream monitoring, trading precision and resilience for search performance. ## Sources - [acoustid/chromaprint on GitHub](https://github.com/acoustid/chromaprint) - [Issues](https://github.com/acoustid/chromaprint/issues) - [README](https://github.com/acoustid/chromaprint/blob/master/README.md) - [Releases](https://github.com/acoustid/chromaprint/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/acoustid-chromaprint