audiotheca

audiotheca is a music library built on metatheca. It keeps the audio (immutable, content-addressed bytes), its metadata (mutable structured facts), and its cover artwork (immutable, content-addressed bytes) strictly apart, so editing an album's artist, year, or title never touches — or re-hashes — a single byte of audio. The library stores only the originals you acquired (a CD rip, or an existing file); every lower-bitrate copy is derived on demand and cached locally, never durably stored; and every tag lives outside the audio bytes.

It is not a CD ripper (that job belongs to its companion ingestion tool, ripcli), not a streaming client, and not a tag-in-place editor. It is the durable store and query surface for a personal audio collection.

Status

Specification at v0.1, covering Phase 1: the entity/fact model, both ingest paths, metadata variants and resolution, audio-storage invariants, on-demand transcoding with the derived cache, pinning and maintained profiles, query, playlists, export, and playback. Early development — APIs, the fact schema, and the import manifest remain unstable. The Rust reference implementation is published on crates.io as audiotheca 0.1.0 (binary audiotheca, suggested alias aud).

Name

audiotheca — Latin audiō ("I hear", whence audio, the near-universal internationalism for sound) + theca (θήκη, "case, repository"). The -theca names what kind of storehouse this is: the store of heard things — recorded sound.

Unlike its siblings apotheca, syntheca, and metatheca, whose prefixes are Greek, audiotheca is a mixed Latin+Greek compound. This deliberately bends the family's no-mixed-roots guideline: audio- is the one root for sound that reads unambiguously to anyone, in any language, and the Greek alternatives (akoustiko-, phōno-) either collide with existing terminology or read worse. The load-bearing family root, theca, is preserved; the prefix names the domain, not the storage property, because audiotheca is an application over the substrate family rather than a new substrate layer.

The three-way separation

• Audio — the originals you acquired, deposited once as content-addressed blobs and never modified. Lower-bitrate renditions are derived on demand into a local, regenerable cache; profiles can be pinned into the vault or maintained on a remote for constrained targets.
• Metadata — artists, releases, tracks, and their attributes live as audio/ facts in the metatheca vault, with variant provenance (embedded tags, online sources, manual edits) and deterministic resolution. Editing metadata never rewrites audio.
• Artwork — cover images as content-addressed blobs, referenced from facts, deduplicated across releases automatically.

Relationship to the substrates

audiotheca is a domain layer, not a substrate: it consumes one metatheca vault (entries, paths, facts, state chain) and models a personal audio collection on top. Everything below — content addressing, dedup, integrity, backend composition, sync — is inherited from syntheca and apotheca through the vault. CD ripping and online metadata acquisition live in ripcli (a separate project); they reach the library only through the import-manifest boundary.