Should you build your own Apple Music?

Build a closest honest personal substitute for Apple Music in an empty repository.
Use Python 3.12, FastAPI, SQLite, ffmpeg, and a local web interface; do not offer alternative stacks.
The core loop is: organize legally owned or user-created tracks, index and analyze local files, and serve private playback of a personal music library across a private network.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Index only user-selected folders and preserve source audio without modification.
Read tags and artwork, calculate loudness and waveform data, and detect exact duplicates by hash.
Provide albums, artists, playlists, search, queue, favorites, and resumable local playback.
Add optional creator tools for trim, normalize, split stems through a local model, and export new files.
Keep all rights and source information attached to imported tracks and display it during export.
Document that the application does not provide music, licensing, distribution, or royalty collection.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Do not claim to reproduce proprietary data, network liquidity, regulated access, or frontier infrastructure.
Deliberately leave out copyrighted catalog acquisition or sharing.
Deliberately leave out streaming-service circumvention.
Deliberately leave out royalty accounting, label distribution, and global content delivery.
Finish by running the tests and listing the exact commands used.