Re-add support for Apple Music (as already proposed in #12).

Currently, songs are only stored by their metadata and e.g. their Spotify ID. It would be nice, however, to be able to map them to actual audio files if the user has the corresponding song locally on their computer (e.g. by providing drum a folder where music is stored).

This matching should ideally be fuzzy (work with a variety of formats, including MP3 tags or when only title and artist are stored in some combination in the title).

Once mapped, the local audio file path should be stored in the track, similar to how Spotify and Apple Music IDs are stored currently.

Local audio file mappings would also let us properly handle services that rely on local paths such as

• #21
• #4

E.g. by ISRC to uniquely identify songs.

One approach would be to automatically match tracks whenever the DB changes across all streaming services, this would potentially be very API-heavy, however, since every configured streaming service would have to be consulted upon every track change.

Another approach would be to match on-demand e.g. when a user tries to push a playlist to Apple Music that only has associated Spotify ids.

The basic CLI infrastructure is managed by a Thor class and should provide:

• show for previewing playlists
• cp for copying playlists across services

Add support for 'smart' playlists, i.e. saved queries that carry a list of (possibly hierarchial) rules, combined using logical operators (AND, OR, ...).

Being able to sync these with services, even if those have no notion of 'smart' playlists, would be nice too.

Integrate the Apple Music REST API, e.g. using this library.

...as e.g. emitted by Mixxx.

With RSpotify::AudioFeatures::find we can fetch audio features for up to 100 tracks at once, thereby making it possible to query them efficiently without spamming the API.

Integrate with the Mixxx database and in particular make it possible to export/import playlists both as playlists and crates. Since the Mixxx database seems to be a standard SQLite database, this shouldn't be too hard to do, but would probably benefit from having #20 implemented already.

Add a service that uses files (e.g. m3u) and folders to store playlists and music.

Add a minimal web frontend for browsing and managing the local database using webrick. To launch the server, a new command like web could be added.

Add a service implementation for YouTube.

Display a progress bar e.g. when pulling playlists.

Use an XML parser like Nokogiri to parse/update the local iTunes library. Alternatively, a higher-level library could be used, most of these are, however, not actively maintained anymore or only offer read access:

• https://github.com/asciamanna/ImprovedItunesParser/
• https://github.com/rojosinalma/itunes_parser
• https://github.com/kylewelsby/itunes-library
• https://github.com/jornado/itunes2spotify
• https://github.com/Ilink/iparse

Integrate support for the Spotify API using rspotify. This includes:

• Adding the API and implementing authentication (both app-level and OAuth)
• Implementing download
• Implementing upload

The Apple Music API 1.1+ seems to offer an API for accessing and modifying playlist folders, which we could integrate into the AppleMusicService by mapping Playlist.paths to the corresponding folder structures, creating folders as needed on-the-fly.

Support playlist-level pushing/pulling and add a confirmation prompt when the user attempts to push the entire library at once.

E.g. support pulling Playlist-URLs/IDs from Spotify

Fetching tracks and metadata from Spotify's new blend playlists seem to confuse rspotify (we might want to add a ticket upstream too).

Both Spotify and Apple Music seem to provide ISRCs for songs, so it would be nice to also perform song matching with them instead of the currently used search-based (possibly imprecise) matching.

Add a simple CSV-style format for playlists.

We should implement a proper backoff strategy to avoid spamming the API