# mackron/dr_libs: Single-file audio decoders for C and C++ > mackron/dr_libs packages FLAC, MP3, and WAV decoding into separate single-header libraries for C and C++. It suits small applications that need direct decoder integration, although the repository does not document a complete installation or first-use workflow. **mackron/dr_libs** — Audio decoding libraries for C/C++, each in a single source file. - Repository: https://github.com/mackron/dr_libs - Stars: 1,842 · Forks: 261 - Language: C - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/mackron-dr-libs ## What dr_libs solves for C and C++ applications dr_libs addresses a narrow part of audio application development: decoding or loading supported audio files without adopting one large multimedia framework. The repository contains separate components for FLAC, MP3, and WAV, each distributed as a header file named `dr_flac.h`, `dr_mp3.h`, or `dr_wav.h`. This makes the repository relevant to C and C++ developers who need one format rather than a complete playback, recording, or effects stack. The audience includes application programmers working with local audio data, tools that ingest compressed files, and software that must hand decoded PCM to another subsystem. That last point is an architectural boundary, not a promise of automatic audio output. The repository describes `dr_flac` as an FLAC decoder, `dr_mp3` as an MP3 decoder based on minimp3, and `dr_wav` as a WAV loader and writer. It does not describe device playback, recording, streaming, seeking behavior, or synchronization. Keeping each library in one source file can simplify dependency management for a project centered on one format. A developer can select `dr_flac.h` for FLAC without importing the MP3 or WAV component. That selection does not remove the need to manage compilation settings, platform compatibility, memory ownership, or output format, because the README does not document those integration choices. ## The repository separates three audio formats The architecture visible in the repository is a collection rather than a unified audio library. The top-level files are `dr_flac.h`, `dr_mp3.h`, and `dr_wav.h`, and the README lists each as a distinct library with its own purpose. There is also a `tests/` directory, `CMakeLists.txt`, and a `.github/` directory, but the README does not explain the test targets, build options, or continuous integration jobs. This structure creates an important selection rule. FLAC callers should start with `dr_flac.h`; MP3 callers should start with `dr_mp3.h`; projects that both load and write WAV data have a different component because `dr_wav` covers both directions. A programmer who assumes the three headers form a shared API could infer relationships that the documentation never establishes. The MP3 component also has a clear provenance distinction. The README says `dr_mp3` is based on minimp3. It does not state that it uses the entire minimp3 project or describe how upstream changes are incorporated. Based on the repository layout, adoption concerns remain local to the relevant header, but exact API and licensing details should be checked in that file before integrating it. ## Obtaining dr_libs and completing a first integration The repository does not provide README installation commands, package-manager instructions, or a documented first decoding example. Its stated distribution model is single-file source code, and the repository root contains the three public headers. The README directs users to tags for the latest version of a particular library. A first integration therefore begins by obtaining the repository or selecting the relevant tag, then inspecting the exact header being incorporated. There is no confirmed command that can be copied from the README, so this review does not invent a build command or decoder invocation. The top-level `CMakeLists.txt` may define a supported build path, but its contents are not documented here. Likewise, the `tests/` directory confirms that tests exist, but the README does not state how to execute them or what they cover. For a first real use, choose one required format rather than copying all three headers. Confirm that the selected header's API matches the surrounding C or C++ code, compile the project through its existing build system, and examine the relevant header for build requirements and sample usage. The repository's format-specific selection is clear, but the complete setup path is not. ## Versioning decisions for decoder-specific headers All released-library development happens on the `master` branch according to the README. Decoder-specific branches may contain work in progress, while tags identify the latest version of a particular library. This creates a concrete version-control choice before adding a header to an application: using `master` follows the documented development location, whereas using a tag pins the entire repository to a particular commit that includes whatever versions were recorded there. The repository has no GitHub releases, so tags are the documented version reference. There is also no release-note history from which to assess decoder changes or compatibility. The last repository push was on 2026-08-31, which is recent enough to distinguish the repository from an archived project, but recency alone does not establish a release cadence or the stability of any individual header. Applications that require traceable builds should record which commit or tag supplied `dr_flac.h`, `dr_mp3.h`, or `dr_wav.h`. Pinning all three through one repository tag may be convenient for shared builds. If formats are adopted independently, the documentation does not explain whether separate header versions are released, so the selected commit and header contents must be inspected directly. ## License and upgrade considerations for embedded headers The README calls dr_libs a public-domain collection, while the repository metadata classifies the license as a custom license that GitHub cannot classify and directs readers to the `LICENSE` file. That difference matters because `dr_mp3` is based on minimp3, and downstream code may need to preserve notices or satisfy separate license terms. This review does not interpret the license or provide legal advice. A source-file dependency also has an upgrade cost. Copying `dr_mp3.h` directly into a repository makes later updates a code change rather than an automatic package update. Replacing the file can introduce API changes, decoding changes, or license changes that the application owner must review. The README does not document a stable API policy, semantic versioning scheme, migration guide, or compatibility matrix. The presence of a single license file for the repository does not prove that every header has identical terms, especially when one component is based on another project. Before distribution, inspect `LICENSE` together with the header comments in the selected source file. For applications using more than one decoder, perform that review separately for `dr_flac.h`, `dr_mp3.h`, and `dr_wav.h`. ## Where dr_libs is the wrong audio choice The clearest wrong-tool case is an application that needs an integrated audio engine rather than decoding alone. The README points to miniaudio as a separate project for audio playback and recording. That is a different approach: miniaudio is described as a public-domain, single-file library for those broader operations, while dr_libs focuses on file decoding and, for WAV, loading and writing. Another limitation is documentation depth. There are no README examples for creating a decoder, supplying a data source, reading frames, handling errors, or releasing memory. No documented API is available to assess callback overhead, thread safety, malformed-file handling, or resource limits. These omissions prevent a grounded performance or production-readiness judgement. Projects that require one unified audio API across formats may also find separate headers inconvenient. The repository does not state that the libraries share common interfaces, so using all three could produce separate integration surfaces. A format-specific parser, command-line converter, or internal game asset tool may fit the distribution model better than a desktop playback application or mobile audio service. ## Conclusion Developers should consider dr_libs when they need separate FLAC, MP3, or WAV components and can work directly with single-header C or C++ code. Projects needing documented setup examples, a unified playback layer, or clear release packages should verify those gaps first. The first adoption check should be the relevant header, its accompanying license text, and the decoder documentation for the exact file format being integrated. ## FAQ ### Which audio formats does mackron/dr_libs support? The repository lists FLAC decoding in `dr_flac.h`, MP3 decoding in `dr_mp3.h`, and WAV loading and writing in `dr_wav.h`. ### How are mackron/dr_libs distributed? Each library is provided as one source header for C and C++. The README identifies `dr_flac.h`, `dr_mp3.h`, and `dr_wav.h` as the separate libraries. ### Does mackron/dr_libs include audio playback or recording? The listed dr_libs components cover decoding, plus WAV loading and writing. The README points to the separate miniaudio project for audio playback and recording. ## Sources - [Issues](https://github.com/mackron/dr_libs/issues) - [mackron/dr_libs on GitHub](https://github.com/mackron/dr_libs) - [README](https://github.com/mackron/dr_libs/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mackron-dr-libs