Print all tracks in the library of the Music.app in macOS.
This command line tool sorts tracks by artist, album, and track name without regard for case or diacritics and then prints a line with the artist, album, and track name for each track.
To use @grr/tracklist, you need to first install the tool and supporting code.
Since we are installing into a newly created directory, npm complains about a
lack of manifest and lockfile. You can ignore that.
mkdir inventory
cd inventory
npm install @grr/tracklistOnce installed, you can run @grr/tracklist in two different ways corresponding
to two very different ways of accessing the track data. First is access to track
data by scripting the Music.app itself. Luckily, we don't have to fall back onto
AppleScript but can use JavaScript instead:
osascript -l JavaScript ./node_modules/@grr/tracklist/tracklist.jsSecond is access to track data through an XML property list that captures a library's metadata. In this case, we parse the property list with expat, a streaming XML parser. As the code in parse.js illustrates, correctly handling callbacks can get rather involved. At the same time, it enables us to ignore irrelevant data in the library's property list and thereby avoid building the corresponding object graph only to discard it again.
node ./node_modules/@grr/tracklist/tracklist.js <Library.xml>The JXA and XML versions co-exist in the same module, since both versions sort
and print a tracklist the same. For that to be possible, the XML version does
not use static imports and uses the dynamic import() form only indirectly,
i.e., by dynamically creating a function that imports a module. Otherwise,
osascript would reject the module.
I wrote @grr/tracklist when I encountered problems migrating my music library
onto a new Mac. Since I store the actual tracks on a networked drive, I was
trying to simply import the Library.xml I had previously exported on the old
machine. That worked for the most part. Though Music.app notified me that it
couldn't import some tracks. Since my library contains well over 27,000 tracks,
that error message was exceedingly unhelpful. Clearly, I needed some tool to
compare the two libraries. The data in such an exported Library.xml file is in
Apple's generic property list format. That makes it unsuitable to textual
comparison (diff). In theory, Apple's property list tool plutil can convert
XMl-based property lists to JSON. But in practice, the tool refuses to convert
Music.app libraries because JSON lacks support for dates. Hence I wrote my own
tool.
Once I started diff-ing the output produced with @grr/tracklist, the reason
for Music.app dropping tracks became apparent: The metadata for all dropped
tracks differed from other tracks by the same artist or on the same album only
in capitalization. That can be problematic when deriving file names from
metadata, as Music.app does, since macOS defaults to case-preserving file
systems while my networked disk, which runs Linux, has a case-sensitive file
system. It actually speaks to the software quality of iTunes that this hasn't
caused any issues before. Since library import doesn't handle this correctly, I
fixed the metadata and file names to have the same consistent casing on my old
machine. I did the same normalization for quotes and diacritics. Thereafter, I
reset Music.app to a blank slate (by starting the application with the option
key pressed and selecting a fresh library directory) and imported the library
without a hitch.
@grr/tracklist is © 2020 Robert Grimm and licensed under MIT terms.