spotify, deezer: Store IDs in dedicated fields instead of MusicBrainz fields

[aaronk6]

Description

Previously the Spotify and Deezer plugins wrote their IDs into the MusicBrainz fields. This prevents those files from being imported into Music Assistant, which checks for valid MusicBrainz IDs during import and refuses to import those files (error: “Invalid MusicBrainz identifier”).

I considered fixing this in Music Assistant, but it seemed cleaner to store Spotify and Deezer IDs in separate fields from the start.

This change adds dedicated fields when tagging and leaves the MusicBrainz ID fields untouched:

• Spotify: spotify_track_id, spotify_album_id, spotify_artist_id
• Deezer: deezer_track_id, deezer_album_id, deezer_artist_id

I’m curious whether the current behavior is considered a feature or a bug. That is, if there are any cases where populating MusicBrainz ID fields with non-MusicBrainz values is actually useful.

If this turns out to be controversial, making it configurable could be a solution, allowing users to preserve the old behavior.

Looking forward to your thoughts!

To Do

• Documentation. Could potentially be extended, e.g., with commands to update existing files tagged before this change.
• Changelog.
• Tests.

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.97%. Comparing base (d65e37c) to head (81cd3da).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6349      +/-   ##
==========================================
+ Coverage   68.95%   68.97%   +0.01%     
==========================================
  Files         140      140              
  Lines       18685    18699      +14     
  Branches     3058     3060       +2     
==========================================
+ Hits        12885    12897      +12     
- Misses       5153     5154       +1     
- Partials      647      648       +1     

Files with missing lines	Coverage Δ
beetsplug/deezer.py	20.68% <100.00%> (+4.02%)	⬆️
beetsplug/spotify.py	52.55% <100.00%> (+0.40%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[semohr]

This is a long-standing issue and, in my view, an inconsistency that stems from Beets’ shift from MusicBrainz as the primary metadata source to treating it as just one of several common metasource plugins.

You are doing two things here which I would split into two PRs/issues imo.

1. Introducing changes to AlbumInfo and ItemInfo, which will propagate into the database (see here.
2. Adding new metadata to the files using mediafile.

---

Regarding 1

Have you considered migration paths for older databases that currently store Spotify or Deezer IDs in MusicBrainz fields?

If we change this behavior, existing databases would need to be migrated to the new format; otherwise, we risk introducing a significant number of inconsistencies. Planning a robust migration strategy is essential to maintain data integrity across different metadata sources.

For context: this is one reason we haven’t tackled this yet, fully migrating the behavior will likely snowball and require careful coordination with all metasource plugins to ensure consistency.

---

Regarding 2

This seems like a useful addition if there is software that actually reads these tags and does something meaningful with them. Can you provide examples of software that uses them? If not, I would lean toward not adding the metadata to the files.

What you describe as issue seems more like a bug to me: album_id should not be written as metadata tags if the data_source isn't musicbrainz. Some investigation into why this is happening in the first place and removing/fixing that behavior might be a better way forward.