Recognizing Apple files & provider-aware IN LIBRARY / DOWNLOADED badges #18

Activity

1. ranokay

   added

   wayfinder:grillingWayfinder grilling ticketWayfinder grilling ticket

   on Sep 1, 2026
2. ranokay

   added a parent issue on Sep 1, 2026

   • Wayfinder map: Apple Music as a second provider in Waves #1
3. ranokay

   marked this as blocking on Sep 1, 2026

   • Write the decision-complete spec #15
4. ranokay

   self-assigned this

   on Sep 1, 2026
5. ranokay commented on Sep 1, 2026

   

   ranokay

   on Sep 1, 2026

   OwnerAuthor

   More actions

   Resolution

   Recognition decided: one tag family, one library tree, two different badge questions, Atmos as a Version. Builds on the Provider seam's mechanics (namespaced ids, generic tag beside legacy tags, provider-scoped gates) and the dual-download placement.

   1. The on-disk tag family

   A generic WAVES_* family written by both providers going forward:

   Tag	Content
   WAVES_ITEM_ID	the namespaced id (tidal:… / apple:…)
   WAVES_ARTIST_IDS / WAVES_ALBUM_ARTIST_ID	the multi-credit id groundwork, now namespaced
   WAVES_AUDIO_TYPE (new)	stereo / atmos — recognition never depends on codec sniffing

   On MP4 (Apple ALAC/AAC/Atmos and TIDAL Atmos) these ride the existing freeform-atom mechanism (----:com.apple.iTunes:WAVES_ITEM_ID); on FLAC, vorbis comments. TIDAL downloads keep writing the legacy WAVES_TIDAL_* tags alongside — every file already in a library stays recognized. The scan reads generic-first, legacy-fallback; the codec sniff (_file_audio_mode_is_atmos) retires to a legacy fallback only.

   2. Path templates: shared, not per-provider

   Apple files land through the same template system as TIDAL — one Artist/[Year] Album/… tree, one Plex-readable library, provider-neutral tokens. The only special placement remains the Dolby Atmos files template (shared across providers per the dual-download decision). Per-provider template variants are rejected for v1.

   3. Badge semantics: two different questions

   • IN LIBRARY / PARTIALLY / MAYBE — scan-based, provider-blind. They answer "does this music exist on disk?"; the scan matches by tags whoever saved it, as it does today for files Waves didn't create. Owning the TIDAL master does badge the Apple search result IN LIBRARY — the music is in your library. MAYBE-proof and the MusicBrainz arbiter work unchanged.
   • DOWNLOADED / HAVE / REDOWNLOAD — ownership-based, strictly per-provider. They answer "has Waves saved this provider's version?". Owning TIDAL's HI-RES never shows Apple's row as DOWNLOADED. The queue's HAVE marking is per-provider likewise.
   • Quality upgrades stay per-provider: each provider's quality setting governs its own re-fetch ladder (the existing convergence-gate logic, now with explicit audio type). No cross-provider upgrade interaction — wanting Apple's ALAC when TIDAL's copy exists is a deliberate choice, and both copies coexist as separate Versions (CONTEXT.md: Ownership is per-provider; the library is just your music).

   4. Atmos files in the scan

   An Atmos file is a Version attached to its canonical track, never a duplicate:

   • The scan counts the non-Atmos files as the album's canonical track set — the "7 OF 10 IN LIBRARY" arithmetic and multi-disc folding run on it.
   • Atmos copies attach by track, matched within the album folder and its Atmos subfolder, audio type read from WAVES_AUDIO_TYPE (codec sniff as fallback).
   • Album cards earn a small ATMOS TOO micro-badge when Atmos versions exist.
   • A fully Atmos-only track (TIDAL's atmos-only ids) is its own canonical entry — no stereo twin to attach to.
6. ranokay

   closed this as completedon Sep 1, 2026