pdeljanov/Symphonia: nineteen Rust crates and a status table that tells you what to expect

This is a workspace of nineteen crates, not a library you drop in

Symphonia presents itself as one thing, a pure Rust audio decoding and media demuxing library covering AAC, ADPCM, AIFF, ALAC, CAF, FLAC, MKV, MP1, MP2, MP3, MP4, OGG, Vorbis, WAV and WebM. Underneath, Cargo.toml declares a workspace with resolver = "2" and nineteen members, from the facade crate down through symphonia-core, symphonia-common, symphonia-metadata and symphonia-play, with each codec and container in its own crate.

That shape is the main design decision, and it is a good one. It means a program that only needs to read FLAC does not compile AAC and MP4 parsers it will never call, and it means an unmaintained codec can be forked or dropped without touching the rest. It also means your dependency graph is more interesting than a single line, and that reading the source means knowing which of the nineteen crates owns the piece you care about.

The workspace metadata is where the toolchain story is told plainly:

[workspace.package]
edition = "2024"
homepage = "https://github.com/pdeljanov/Symphonia"
license = "MPL-2.0"
rust-version = "1.85"
version = "0.6.1"

Edition 2024 with rust-version 1.85 is a current baseline rather than an old one, and the MSRV badge in the README points at the 1.85.0 release announcement, which is a small sign the badges are maintained on purpose. Licensing is MPL-2.0, file-level copyleft, which is a reasonable choice for a library you link into closed source software: modified files of the library stay open, your own calling code does not have to.

What the four status labels commit the project to

Most media libraries list what they can read. Symphonia grades it, and the grading definitions are specific enough to be useful. Excellent means all media streams play, with no audible or inaudible glitches and all required features supported. Great means most streams play, inaudible glitches may be present, most common features supported. Good means many streams play, and some may panic, error, or produce audible glitches. A dash means in work or not started yet.

The definitions carry the weight. The README states that Excellent is only assigned after a feature passes all compliance tests, and that where compliance tests are not readily available, Excellent is granted if the output matches a reference implementation, or ffmpeg, over a large test corpus. That is a falsifiable standard with a named comparison target, which is a much stronger claim than a checkmark.

It also sets a realistic ceiling for reading the table. Nothing here is rated Excellent except Wave, FLAC, MP3, Vorbis and PCM in their respective rows. ISO/MP4, AIFF, OGG, AAC-LC and ALAC are one step down at Great. CAF, MKV and ADPCM are Good. So the honest summary of the 0.6.1 tree is that uncompressed and losslessly compressed formats are in very good shape, the widely deployed commercial codecs are usable with caveats, and the long tail is unfinished.

The gapless column adds a second axis, and its footnote matters: gapless playback requires support from both the demuxer and the decoder. A codec marked Yes is not enough on its own. WAV, FLAC, MP3, Vorbis and ADPCM carry Yes in both tables and are the combinations you can rely on for sample-accurate playback and loop points.

Two rows where the table disagrees with itself

This is the part worth slowing down on. In the codecs table, Opus is listed with status dash, gapless dash, feature flag opus, and default Yes. WavPack appears two rows further down in the same shape: status dash, feature flag wavpack, default Yes.

So the table simultaneously tells you that Opus decoding is not started or in work, and that every default build turns it on. Both statements sit in the same row. Neither is obviously a typo. The likely reading is that the crates exist and are wired into the default feature set as forward declarations, with the implementations not yet rated. And the tree backs that reading, because symphonia-codec-opus and symphonia-codec-wavpack are both real directories at the workspace root and both appear in the members list of Cargo.toml.

Rather than pick a winner, treat the two facts as two different questions. The default column answers what gets compiled. The status column answers what is finished. If your build is silently paying compile time for an Opus decoder whose status is a dash, that is the default column doing its job. If you were planning on Opus in a player because it comes on by default, the status column is the one that matters, and it says the decoder is not rated for real use.

There is a second, softer contradiction in the same file. The features list promises 100% safe Rust and fast with no compromises in performance, while the Good definition in the same document says some streams may panic. Both can be true at once, and the resolution matters: safe Rust rules out undefined behaviour from the library's own code, while a panic is still a defined but unpleasant outcome. The 0.6.1 release notes show the project treating that gap as real work, recording that all unwraps were either replaced with expect or made to return a runtime error, and that demuxers were hardened against allocating obscene amounts of memory on maliciously crafted files. Workspace lint configuration also warns on unwrap_used:

[workspace.lints.clippy]
unwrap_used = "warn"

A library that parses untrusted media from arbitrary files and holds a Good rating on three containers is making a defensible choice, not a careless one. Just know that Good means it.

The 0.6 rewrite aimed at video and subtitles

The release history explains the breaking changes. Version 0.5.5 on 2025-10-11 was explicitly a maintenance release with no new features, stating that all new development was happening on the 0.6 branch. Then 0.6 on 2026-05-15, described as two years of effort to rework Symphonia from an audio-focused multimedia framework into one that can be extended to support video and subtitles.

That release added registration with a preference tier for format readers and decoders, and self-description methods on format and metadata readers. Both are small-sounding additions that are exactly what you need for a registry that will eventually hold video and subtitle entries alongside audio ones. The migration guide is a separate document at docs/guides/migration/0p6.md, which is the correct place for that work and a good sign about the maintainer.

The contradiction between roadmap documents is worth naming. The README's planned features section lists a C API for integration into other languages and a WASM API for web usage. The 0.6 release notes describe groundwork for video and subtitle support, which the README's planned list does not mention at all. Neither statement is false. A reader could reasonably come away thinking the next milestones are bindings for other languages, or that the next milestone is video support, and the README does not reconcile the two.

Version 0.6.1 on 2026-08-13 is a follow-up rather than a redefinition. It added a clock time helper to TimeBase, made audio buffers and slices cloneable and sliceable, parsed channel information for Opus tracks inside ISO BMFF containers, fixed silent sections being skipped in some MP3 files, fixed Xing and VBRI tags being ignored when the frame carried a CRC, and fixed mono MP1 decoding. That last group is the shape of a mature library being maintained rather than one being built.

How to judge it before you commit to it

Three numbers frame the decision. Stars sit at 3405 with 243 forks, which for a media parsing library is a serious audience. Open issues stand at 85, which is high in absolute terms and expected for a project with this many format matrices, since a single bug can appear in six containers. Last push was 2026-08-13, so the project is active on a normal maintenance cadence rather than abandoned or frantic.

The topics list is the most useful signal for picking a subset. Twenty tags including aac, adpcm, alac, apple-lossless, flac, id3v1, id3v2, m4a, mkv, mp2, mp3, mp4, ogg, pcm and vorbis describe a library whose metadata handling is a first-class concern, not an afterthought. The feature list agrees, listing metadata and tagging reading alongside decoding and demuxing, and the repository has a dedicated symphonia-metadata crate to match.

So the practical judgement comes down to which formats your input actually contains. If it is WAV, FLAC, MP3, Vorbis or PCM, you are reading the Excellent rows and the only work is wiring the API. If it is AAC or ALAC or MP4, read Great and expect rare glitch reports. If it is CAF, MKV or ADPCM, read Good and make sure your process can survive a panic, because the table tells you it might raise one. If it is Opus, HE-AAC or WavPack, the table tells you the decoder is not rated yet, whatever the default feature set does.

Two more things to check in your own context. BENCHMARKS.md at the repository root means the performance claim in the features list is at least measured somewhere, and symphonia-check is a workspace member you can point at a corpus to find out how a given file behaves. For a library whose best feature is an honest status column, the right response is to read the row for your format and let it decide. Symphonia has already done the classification work. Repeating it is your choice, but it is not a necessary one.

Editorial conclusion

Symphonia earns trust by publishing a status column that most audio libraries would leave out, and the two rows where the table contradicts itself are exactly the rows to check before you enable a feature. Pin 0.6.1, enable only the formats you need, and read docs/guides/migration/0p6.md first if you are coming from 0.5.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. pdeljanov/Symphonia on GitHub
4. README
5. Releases