Pick some fields from a metadata source, and some other elsewhere?

I’d like to default to Musicbrainz for every fields, but fetch genre & style from Discogs, and audio features from Spotify.

The best way I found in my minimal test is to do 3 imports, and choosing the right source each time. This is indeed time consuming and some fields get overwritten as I didn’t found a way to limit the fields a source can fetch & save.

How should I proceed in your opinion?

1 Like

There is an open feature request to allow configuring which fields should be overwritten. Currently, a plugin overwrites everything that it can find.

1 Like

I’ve been drafting something that solves my problem: GitHub - raphaelyancey/beets at filters

Takes 4 steps and 3 configs but it works :smile:

# Initial MusicBrainz import
beet import foobar/

# Discogs genre/style
beet -c config_discogs.yaml import foobar/

# Spotify audio features
beet -c config_spotify.yaml import foobar/
beet -c config_spotify.yaml spotifysync


plugins: discogs

    enabled: no

      - genre 
      - discogs_albumid
      - discogs_labelid
      - discogs_artistid
    append_style_genre: true


plugins: spotify

    enabled: no

      - spotify_album_id 
      - spotify_artist_id
      - spotify_track_id
      - spotify_track_popularity
      - spotify_acousticness
      - spotify_danceability
      - spotify_energy
      - spotify_instrumentalness
      - spotify_key
      - spotify_liveness
      - spotify_loudness
      - spotify_mode
      - spotify_speechiness
      - spotify_tempo
      - spotify_time_signature
      - spotify_valence
      - spotify_updated

I like the idea of splitting up the configs. However, multiple imports are going to be tough for a large library. More importantly, these things are connected already, we just need to figure out a way to translate identifiers from one service to other.

@jojo is already working on extracting Discogs id from MB. It will be great if we can extend it to have a generic function to translate attributes.

It will indeed. It’s mostly a workaround with the aim of writing as less code as possible to do what I needed.

Wouldn’t the UI need to be revamped anyway? At the moment you have to manually choose a candidate from a specific source. With n multiples sources, you would have to pick n choices anyway wouldn’t you?

The way I anticipate this to work is that we still only import once and use that information to match with other services. For example, let us say we use MB as a tag source. We can then use the mb_album_id to obtain the identifier for the other services (assuming it is available in MB). See this discussion for additional information.

@ryancey BTW…do you use the -W flag to prevent writing the tags on subsequent imports (and only get the values for the database)? For example, I want to use the tags from Spotify (in the first import) and then only want to obtain the MB_IDs in the subsequent import without overwriting the tags.

Yes as a global option in my configs, but that was kind of custom in my case so I didn’t include it in the examples.

For your case my code won’t help you because it only skip fields for Discogs & Spotify plugins, but it could easily be set as a top-level property now that I think of it… And then you’d use multiple configs to enable/disable sources including MB.

For the record, my goal is then to set “meta-genres” based on Spotify audio features, like # Danceable or # Acoustic.

I’d achieve it with something like

beet modify spotify_danceability:0.6..1.0 genre='$genre; # Danceable'
beet modify spotify_acousticness:0.8..1.0 genre='$genre; # Acoustic'

so it is somewhat “standard” and can be used in any library manager (Emby in my case) to create smart playlists for example.

Looks like musicbrainz does not allow configuring fields to be imported. It overwrites everything :frowning:

Probably one of the first features that’s required for making some of the ideas in this thread work: Making MB plugin configurable. I think there is a thread/issue/discussion open already for that. Let me check…

The issue discussing this feature request currently has a misleading title but here it is: discogs: Add a configuration option to avoid providing the genre field · Issue #4087 · beetbox/beets · GitHub