Import and save Spotify music attributes

[arsaboo]

Spotify has a lot of music-related information that could be invaluable for discovery and creating "smarter" playlists.

1. First, each track has a rich audio analysis that describes the track’s structure and musical content, including rhythm, pitch, and timbre. (API reference). This feature was also requested here. We are already doing something similar with Acousticbrainz (PR), a project which is already slated to end. It may be a good idea to include Spotify attributes as the company will definitely be around and update these attributes.
2. It also provides popularity information of any track included in their library (here's an incomplete/closed PR for reference). There is an archived version of the popularity plugin.

I think those two pieces of information can greatly improve the quality of playlists that beets can generate.

To get started, we will need to save the album_id, and track_id information that Spotify uses to identify albums and tracks. The good news is that the Beets Spotify plugin already refers to album and track ids. I am surprised we are not saving this information anywhere after matching. Even saving this information would be a great starting point.

Once we have the identifiers, obtaining the audio features or popularity information is trivial. The information can be captured at the time of importing and updated on a regular basis (popularity is updated continuously).

I really hope we can get some of these details in Beets soon.

[arsaboo]

Honestly, I am not sure why album_id and track_id information are not saved. Looks like the plugin is returning track_id in TrackInfo and album_id in AlbumInfo.

[sampsyo]

I think all that's necessary for saving these IDs is to provide them as extra keys: spotify_track_id and spotify_album_id. The unprefixed field names are used for other purposes (namely mapped to MBID fields), so we would want to store these in Spotify-specific flexible attributes. Maybe we can start by giving that a shot? Would you be interested in throwing together a PR with a proof of concept?

[arsaboo]

Do you think something like this would work (I added two additional returns for spotify_album_id and spotify_artist_id)?

        return AlbumInfo(
            album=album_data['name'],
            spotify_album_id=spotify_id,
            album_id=spotify_id,
            artist=artist,
            artist_id=artist_id,
            spotify_artist_id=artist_id,
            tracks=tracks,
            albumtype=album_data['album_type'],
            va=len(album_data['artists']) == 1
            and artist.lower() == 'various artists',
            year=year,
            month=month,
            day=day,
            label=album_data['label'],
            mediums=max(medium_totals.keys()),
            data_source=self.data_source,
            data_url=album_data['external_urls']['spotify'],
        )

[arsaboo]

I went ahead and created a PR #4348

Let me know what you think.

[sampsyo]

It would be great to revive #4102 if anyone has the cycles to do so! The implementation got pretty far, but the sticking point was that it adds an extra API request for every track, which potentially makes things quite slow. I would suggest starting by putting this behind a config option (shouldn't be too hard, and would get the PR merged quickly). Then we could open an issue about doing the fetch in a more scalable way, such as the tracks API endpoint suggested by @arsaboo. We just need a volunteer to be in charge of moving that forward!

[arsaboo]

I seriously hope/pray someone can pick this up. This is well beyond my expertise, but I will work with them to test/debug things.

[arsaboo]

Now that Spotify track and album ids are included (#4348), we can work on the next part. The most efficient way (at least for a large library) is to use the tracks API that can request information for up to 50 tracks in one call.

We need to decide if we should make this call during the import or just have another separate call (e.g., beet spotify) to update the popularity information for all tracks (which assumes track_id is already available).

[sampsyo]

Good point! I think a good place to start with prototyping would be to do an explicit command. It will be easier to write and avoid the possibility of slowing down imports; it also naturally makes it easy to opt out.

Much of the Spotify-interacting code was already written in #4102; we should start with that. Even beginning with the less-efficient track API used in that PR would be OK to get started with, if that makes it easier. We would just need to "package" this stuff as an explicit command.

As for a template to see how this works, why not start with the acousticbrainz plugin itself? It's surely more complex than the new command needs to be, but starting with the commands method may illustrate how the top-level workflow works:

beets/beetsplug/acousticbrainz.py

Lines 151 to 166 in e06cf79

	def commands(self):
	cmd = ui.Subcommand('acousticbrainz',
	help="fetch metadata from AcousticBrainz")
	cmd.parser.add_option(
	'-f', '--force', dest='force_refetch',
	action='store_true', default=False,
	help='re-download data when already present'
	)
	def func(lib, opts, args):
	items = lib.items(ui.decargs(args))
	self._fetch_info(items, ui.should_write(),
	opts.force_refetch or self.config['force'])
	cmd.func = func
	return [cmd]

[arsaboo]

@sampsyo I was able to scrape something together. The code is far from optimal, but it is able to recover the popularity information and save it. Can you please take a look at it here before I submit it?

I have included a sleep to avoid the API rate limit. Hopefully, that should be fine for now.

[arsaboo]

So, I have added audio_features as well. The code works and saves everything (popularity and audio features) in the database. Let me know if you have any thoughts before I submit a PR.

[sampsyo]

Great! In fact, submitting a PR is the best way to get folks to take a look. 😃 It's easier to do it that way than to look at the changes "in situ."

[arsaboo]

Created a PR #4351