mekhi/IdealMusicTagger
Watch
1
0
Fork
You've already forked IdealMusicTagger
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
No description
12 commits 1 branch 0 tags 499 KiB
  • Rust 95.5%
  • Svelte 4.3%
  • TypeScript 0.1%
  • HTML 0.1%
Find a file
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
mekhi f963a43a6f add a README 
The public repo had a README containing only a title, which reads as
abandoned rather than unfinished. This describes the three-crate
workspace layout and leans on docs/adr, which is where the actual
reasoning already lives.

Framed on the design decisions rather than the feature list: per-field
confidence so a matched artist is not trusted like a guessed year, and a
review queue rather than automatic writes.
2026-09-29 11:28:08 -04:00
crates Catch Up 2026-09-17 16:32:08 -04:00
docs Catch Up 2026-09-17 16:32:08 -04:00
.gitignore A lot of progress made in local branch, too much for one commit 2026-06-10 22:27:37 -04:00
Cargo.lock Catch Up 2026-09-17 16:32:08 -04:00
Cargo.toml A lot of progress made in local branch, too much for one commit 2026-06-10 22:27:37 -04:00
CONTEXT.md initial commit with CLI and core setup 2026-06-10 13:49:56 -04:00
LICENSE Initial commit 2026-06-10 15:33:02 +00:00
README.md add a README 2026-09-29 11:28:08 -04:00
STRUCTURE.md A lot of progress made in local branch, too much for one commit 2026-06-10 22:27:37 -04:00

README.md

IdealMusicTagger

A local music tagger: scans a library, reads and writes audio metadata, and enriches it from online sources without sending the library anywhere.

The design assumption is that the collection is private and the tool should stay out of the way. Enrichment is opt-in per field, every remote call is cached, and there is a review queue so nothing overwrites a tag you set by hand without showing you first.

Workspace layout

A Cargo workspace with three crates:

crates/ideal-tagger-core    the library everything else is built on
  config/          TOML configuration, validation, secrets resolution
  db/              SQLite via sqlx, with migrations and repositories
  tagger/          reading and writing tags across audio formats
  external/        MusicBrainz and other enrichment sources, with caching
                    and per-field confidence scoring
  ingestion/       library scanning and duplicate detection
  lyrics/          synced lyrics
  organization/    collection status tracking
  field_verification/  checking which fields are trustworthy

crates/ideal-tagger-cli    the `ideal-tagger` command line tool
  config init | show | set-required-fields
  scan, list
  tag set | remove
  enrich, review
  fetch-lyrics, lyrics show

crates/ideal-tagger-gui    Tauri front end

The core is deliberately independent of the CLI and GUI, so both are thin.

Decisions worth reading about

The reasoning behind the design lives in docs/adr/. The ones that shaped the code most:

  • A remote-storage abstraction up front, so a sync target can be added without rewriting the tagger around it.
  • SQLite as the primary datastore — a local tool for a local collection does not want a server.
  • A tag-mapping architecture separating what a format can express from what the user means, since MP3 ID3, FLAC Vorbis comments, and MP4 atoms each model this differently.
  • Per-field confidence on enrichment, so a high-confidence artist match and a guessed release year are not treated as equally trustworthy.
  • A review queue rather than automatic writes, because auto-tagging a library you care about is a good way to ruin it.

Status

The workspace builds and its test suite passes. The GUI crate is still a placeholder; issue #11 covers the foundation.

cargo build --workspace
cargo test --workspace

Issue-by-issue status is in docs/issues/, and the product spec is docs/PRD-001-ideal-music-tagger-v1.md.