Alexander d664439746 Implement Week 2 metadata extraction and cache database
Week 1 fixes:
- Move hex to workspace dependencies
- Add cargo-criterion, protobuf, grpcurl to flake.nix

Week 2 implementation:
- musicfs-metadata: MetadataParser with symphonia 0.5 for FLAC, MP3,
  Opus/Vorbis, M4A/AAC (2 tests)
- musicfs-cache: SQLite schema per architecture 4.3.6 with track/disc
  columns, TEXT content_hash, all required indexes
- musicfs-cache/db.rs: Database with upsert, CRUD, mtime lookup (9 tests)
- musicfs-cache/metadata.rs: MetadataCache with store/lookup/is_fresh/
  invalidate (2 tests)
- musicfs-core: Added Metadata error variant

22 tests pass total. Oracle-verified against architecture doc.
2026-05-12 18:15:44 +02:00
2013-05-27 14:47:31 +02:00
2010-07-16 18:39:16 +01:00
2026-05-12 14:02:55 +02:00
2013-05-27 13:34:52 +02:00

Organising a music library can be a hassle. With the wealth of online stores all providing music tagged in various formats, it can be a nightmare to unify them all.

This is where beetFs comes in. Derived from beets, beetFs presents a FUSE filesystem that is based on your tags.

Modifying the tags within the beetFs mountpoint will not change the data on the hard disk, merely update the beet database. When an application requests a music file from within the beetFs mountpoint, beetFs provides tag information from its own database, instead of from the original file, but music data from the on-disk location.

This enables completely transparent modification of tags within an audio file with no change to the underlying on-disk data. 
S
Description
No description provided
Readme 1.1 MiB
Languages
Rust 96.8%
Python 2.9%
Nix 0.3%