fetchart: Use MusicBrainz' Bandcamp/Discogs/... association to fetch art

[JOJ0]

Discussed in #4676

^{Originally posted by evur February 12, 2023}
There are instances where covers are only available from one of these and not from the currently implemented sources.

The Discogs ID can be retrieved from the MusicBrainz data. This allows for finding a cover precisely should Discogs have it and MusicBrainz (via CoverArtArchive) not.

[sampsyo]

Hi! I think we already have Discogs covered in #429. And just to be technical about it, MusicBrainz itself doesn't have cover art—it hosts stuff at CoverArtArchive, which fetchart does already support. (I think, following the discussion from #4676, that the goal may be to use MB's Discogs association to fetch art?)

[arsaboo]

There are other sources that provide cover art - Spotify and JioSaavn (a plugin that I added). Both of them provide the image url for the cover art that can be easily retrieved.

[sampsyo]

I guess the question is: is the idea that the cover art would be retrieved without the fetchart plugin? Or are we talking about simply adding additional data sources to fetchart itself? Or a third option I haven't considered?

[arsaboo]

At the very least, we should be able to pass an image URL (including from any user defined plugin) that embedart can use to retrieve and embed cover art. For official plugins (e.g., Spotify), it is fine to add the data source to fetchart itself.

BTW, I do have a related open PR that allows passing an image URL to the embedart plugin. It may not address the problem, but will be a step in that direction.

[JOJ0]

I tried to clarify the title of the issue and improved the description (CoverArtArchive).

Does this reflect what the actual feature request is? @snejus @arsaboo ?

[arsaboo]

Actually, it should be applicable to any service that provides album art. For example, Spotify also provides album art. I am assuming once we implement it for one service, it can be extended to others.

[snejus]

From what I gathered, there seems to be two main ideas floating around

1. Fetching art in a more datasource-agnostic manner

For example, we use album data from MusicBrainz but we are able to fallback to other data sources when MusicBrainz does not provide cover data.

I think this is a great idea. I've experimented with something similar in this dev branch of beetcamp, where I attempted to query discogs for some of the data missing on bandcamp.

I've been thinking about this from a more general perspective - as a user, I would love the ability to combine data coming from various sources instead of having to pick just one of them.

2. Either make fetchart easier to extend dynamically or consider a cover art URL coming from an external data source a legitimate cover art source

I wish I was aware of this issue less 😁 beetcamp comes with a cover art source, however it relies on some nasty monkey-patching in order to work

class BandcampPlugin(...):
    ...
    def loaded(self) -> None:
        """Add our own artsource to the fetchart plugin."""
        for plugin in plugins.find_plugins():
            if isinstance(plugin, fetchart.FetchArtPlugin):
                fetchart.ART_SOURCES[self.data_source] = BandcampAlbumArt
                fetchart.SOURCE_NAMES[BandcampAlbumArt] = self.data_source
                fetchart.SOURCES_ALL.append(self.data_source)
                bandcamp_fetchart = BandcampAlbumArt(self._log, self.config)
                plugin.sources = [bandcamp_fetchart, *plugin.sources]
                break

Ideally, I'd want to drop BandcampAlbumArt, and replace it with a field in the album data, - say cover_art_url, which may get inspected by fetchart which then decides what to do about it.

[sampsyo]

Thanks for expanding on this a little bit!

The way that fetchart currently works is that it also has several backends, and it tries each one (in order), taking the first "valid" image that one is able to supply. To state the perhaps-obvious, I can see three ways to get cover images from Bandcamp:

1. The Bandcamp autotagger source plugin retrieves the image—and fetchart isn't involved at all.
2. We add a new Bandcamp source to the fetchart plugin. This works by looking to see if there is a Bandcamp album ID associated with the newly-imported album and then, if so, looking up the associated image from the Bandcamp API. Critically, the Bandcamp plugin can provide this ID, but it need not actually be involved at all: things would still work if the user did something like beet modify bandcamp_album_id=foo followed by beet fetchart.
3. We somehow provide an import-pipeline-only way for the Bandcamp plugin to communicate directly with the fetchart plugin. That is, the Bandcamp plugin determines a candidate image URL, which it then supplies to the fetchart plugin, which can only see this information during the import process. There is no way to do the same thing later with a beet fetchart command. This would require building some new way for import pipeline stages to communicate ephemeral data with each other, apart from the metadata on music files themselves.

I'd be interested to hear others' thoughts on the trade-offs here. I kinda think the most natural option is 2 above: just add a new Bandcamp backend to the fetchart plugin, possibly informed by the IDs that the Bandcamp source plugin provides. The main drawback here would be that the fetchart plugin may need to duplicate some basic API communication stuff that the Bandcamp plugin also includes. But it's not clear to me yet how extensive that duplication would be.

[JOJ0]

I like option 2 :-)