From the deadwax

What Apple Music Actually Knows About Your Files

apple-musicownershipmetadatacollections

Your Apple Music library isn't one thing. It's at least four different kinds of files mixed together, and Apple's own APIs can't always tell you which is which.

If you have a library that spans purchased iTunes tracks, ripped CDs, imported FLACs, and Apple Music subscription content, the tracks sitting next to each other in the same album view can have completely different ownership, completely different rights, and completely different rules about what you can do with them.

Most tools treat them all the same. That's where problems start.

The four kinds of tracks

Open any long-running Apple Music library and you'll find:

Local imports. Files you ripped, purchased from Bandcamp, downloaded from HDTracks, or dragged into Music.app. These are yours. Standard M4A, MP3, FLAC, or AIFF files sitting on your disk. You can read them, write to them, move them anywhere.

iTunes Store purchases. Tracks bought from Apple. Since April 2009 these are DRM-free AAC files at 256kbps. They contain a purchase info atom with your Apple ID but no encryption. Fully writable, fully portable. You own them.

Apple Music subscription tracks. Content downloaded through an Apple Music subscription. These use FairPlay DRM. The file extension is .m4p instead of .m4a, and the audio codec in the container is drms instead of the standard mp4a. You can read the container structure but the audio is encrypted. If your subscription lapses, these files become unplayable.

Ghost tracks. Library entries that point to files that no longer exist. The file was deleted, the drive was disconnected, or Apple Music changed a track's cloud status and the local copy was cleaned up. Music.app shows these with an exclamation mark: "The song could not be used because the original file could not be found." Apple's support communities have years of threads from users discovering hundreds of these in their libraries.

A single album can contain all four kinds. The same disc, the same tracklist, different rights on every track. Music.app doesn't surface this. It shows them all in one list and plays whichever version is available.

Where the APIs get it wrong

Apple provides an ITLibrary framework for reading the Music.app library. Each track has three booleans that describe its status: isPurchased, isDRMProtected, and isCloud.

These look straightforward. They aren't.

isDRMProtected is unreliable for cloud-only tracks. DRM is a property of the file, not the library entry. If the file hasn't been downloaded yet, there's no file to inspect. In our testing, cloud-only subscription tracks return isDRMProtected == false. Download that same track and you get a FairPlay-encrypted .m4p. The boolean said it was unprotected. It wasn't.

isCloud describes the current state, not the capability. A purchased track you've downloaded has isCloud == false even though it exists in iCloud. Offload it from disk and it flips to true. This boolean tells you where the file is right now, not what kind of track it is.

isPurchased is the most reliable ownership signal. If it's true, you bought it from the iTunes Store. If it's false, you need to look at other signals to determine whether it's an import or subscription content. But at least this one doesn't change based on download state.

The duplicate problem

Libraries that have been active for more than a few years accumulate duplicate entries for the same song. A track you ripped from CD in 2010 might have three library entries today: the original MP3 import, an Apple Music "matched" cloud reference, and a downloaded purchased copy from when you re-bought the album. All three share the same title, artist, and track number.

Music.app handles this silently. It has a Show Duplicate Items feature under File > Library, but it only finds exact metadata matches and doesn't help you decide which version to keep. For any tool that writes to files, duplicates create confusion. An artwork press succeeds on the local import, fails on the DRM track, and errors on the ghost entry. You get partial results with no obvious explanation.

Handling this correctly requires understanding which version of each track is the canonical one for your purposes. That's harder than it sounds when the API gives you the same album title and track number for three entries with completely different rights.

What AppleScript knows that ITLibrary doesn't

Music.app's AppleScript dictionary exposes a cloud status property that's far more detailed than ITLibrary's three booleans:

Status Meaning
purchased Bought from iTunes Store
matched iTunes Match recognized and matched to Apple's catalog
uploaded User's original file uploaded to iCloud
subscription Apple Music subscription content
removed Was in cloud, removed by Apple
no longer available Licensing revoked
duplicate Library has duplicate entries
not uploaded Local file, not yet uploaded

The difference between matched, uploaded, and subscription matters. A matched track is your music that Apple recognized and made available at 256kbps AAC from its catalog. An uploaded track is your original file stored in iCloud. A subscription track is rented. Three very different ownership situations that ITLibrary collapses into one ambiguous boolean.

The catch is speed. Querying cloud status through AppleScript takes 2-5 seconds per batch. Useful for diagnosing a specific album, not practical for classifying an entire library during a scan.

Why this matters for your collection

If you care about your files, you need to know which ones are actually yours. The ones you can move to a NAS, serve through Navidrome, sync to an iPod, or hand down to someone. The answer isn't obvious from looking at Music.app, and as we've seen, it isn't obvious from Apple's APIs either.

Private Press classifies every track in your library during scan. It knows which tracks are local and writable, which are subscription content that shouldn't be touched, and which are ghost entries pointing to files that no longer exist. It surfaces these as health states in the UI so you can see the real picture of your collection, not the version Music.app paints over the gaps.

The classification is harder than it looks, and most tools don't even attempt it. They treat every track the same, press artwork into a DRM file that rejects the write, and report an error with no context. The result is that people with mixed libraries learn not to trust batch operations.

Your collection is years of deliberate choices. You deserve to know which of them are permanent.