Skip to content

musicbrainz: Support extra_tag discogs_catalog - #4321

Closed
JOJ0 wants to merge 1 commit into
beetbox:masterfrom
JOJ0:master
Closed

musicbrainz: Support extra_tag discogs_catalog#4321
JOJ0 wants to merge 1 commit into
beetbox:masterfrom
JOJ0:master

Conversation

@JOJ0

@JOJ0 JOJ0 commented Mar 16, 2022 •
edited
Loading

Copy link
Copy Markdown
Member

Description

  • Some tagging software saves a tag named discogs_catalog when pulling metadata from Discogs.
  • This tag could be used to more precisely search for matches on MusicBrainz and get better distance scores for a candidate.

To Do

  • Documentation. FIXME add discogs_catalog to set of available extra_fields.
  • Changelog.
  • Tests.

@JOJ0
musicbrainz: Support extra_tag discogs_catalog
077e7b8 
- Files might contain a tag named `discogs_catalog` that could be used
  as the value of the `catno` field when searching for matches on
  MusicBrainz.
- Support configuration via adding to musicbrainz.extra_tags list in
  beets config.yaml.
- Requires the tag `discogs_catalog` to be readable. It's to be decided
  if by supporting it via the beets' `add_media_file()` method or adding
  to the mediafile library is the proper approach here.
@JOJ0

JOJ0 commented Mar 16, 2022 •
edited
Loading

Copy link
Copy Markdown
Member Author

To test, add this field to mediafile:

discogs_catalog = MediaField(
    MP3DescStorageStyle('Discogs Catalog'),
    MP4StorageStyle('----:com.apple.iTunes:Discogs Catalog'),
    StorageStyle('DISCOGS_CATALOG'),
    ASFStorageStyle('Discogs/Catalog'),
 )

It's to be decided if it makes sense to support discogs_catalog by mediafile directly or via the add_media_field() method in beets.

This is part of the config in use:

musicbrainz:
    source_weight: 1.0
    extra_tags: [catalognum, label, discogs_catalog]
    search_limit: 10

Metadata of an already quite properly tagged file (using mp3tag + discogs sources definition a couple of years ago):

-- /Users/jojo/Music/Techno/019-spin_12-09_non_tech/Ed_Chamberlain_-_Mixxy_EP_1_-_Baselogic FLAC/04 - Ed Chamberlain - Styge (Ochre Remix).flac
- FLAC, 360.57 seconds, 44100 Hz (audio/flac)
ALBUM=Mixxy EP 1
ARTIST=Ed Chamberlain
BPM=120
COMMENT=BASE 005
DISCOGS_ARTIST_NAME=Ed Chamberlain
DISCOGS_CATALOG=BASE 005
DISCOGS_COUNTRY=UK
DISCOGS_DATE=2008-06-02
DISCOGS_RELEASE_ID=1352426
ENERGYLEVEL=4
INITIALKEY=Ebm
MEDIATYPE=Vinyl 12", EP, 33 ⅓ RPM
ORGANIZATION=Baselogic
...

Snippets of a beets import log of this file:

Looking up: /Users/jojo/Music/Techno/019-spin_12-09_non_tech/Ed_Chamberlain_-_Mixxy_EP_1_-_Baselogic FLAC
Tagging Ed Chamberlain - Mixxy EP 1
No album ID found.
Search terms: Ed Chamberlain - Mixxy EP 1
Additional search terms: {'label': '', 'catalognum': '', 'discogs_catalog': 'BASE 005'}
Album might be VA: False
Searching for MusicBrainz releases with: {'release': 'mixxy ep 1', 'artist': 'ed chamberlain', 'tracks': '2', 'catno': 'base005'}
Requesting MusicBrainz release 04c30a7e-43a8-4536-8ebc-841e27a67289
Sending event: mb_track_extract
Sending event: mb_track_extract
Sending event: mb_track_extract
Sending event: mb_track_extract
Sending event: mb_album_extract
Sending event: albuminfo_received
Candidate: Ed Chamberlain - Mixxy EP 1 (04c30a7e-43a8-4536-8ebc-841e27a67289)
Computing track assignment...
...
...
/Users/jojo/Music/Techno/019-spin_12-09_non_tech/Ed_Chamberlain_-_Mixxy_EP_1_-_Baselogic FLAC (2 items)
Sending event: import_task_before_choice
Sending event: before_choose_candidate
Tagging:
    Ed Chamberlain - Mixxy EP 1
URL:
    https://musicbrainz.org/release/04c30a7e-43a8-4536-8ebc-841e27a67289
(Similarity: 79.7%) (missing tracks, tracks, media) (12" Vinyl, 2008, GB, BaseLogic, BASE 005)
 * Styge (Ochre Remix) FLAC - END DIGI - Ebm - 120 (#4) -> Styge (Ochre remix) (#2) (title, index)
 * Zarathustra Remastered FLAC - Abm - 130 (#1)         -> Zarathustra (remastered) (#3) (index, title)
Missing tracks (2/4 - 50.0%):
 ! Dave (Vent remix)       (# 1) (5:45)
 ! Synthia (Surgeon remix) (# 4) (5:01)
[A]pply, More candidates, Skip, Use as-is, as Tracks, Group albums,
Enter search, enter Id, aBort, eDit, edit Candidates, plaY?

JOJ0
JOJ0 commented Mar 16, 2022
View reviewed changes
Comment thread beets/autotag/match.py
Comment on lines +236 to +240
# Discogs Catalog number.
if likelies['discogs_catalog'] and album_info.catalognum:
dist.add_string('catalognum', likelies['discogs_catalog'],
album_info.catalognum)

@JOJ0 JOJ0 Mar 16, 2022 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not yet sure if what I'm and doing here is correct at all and would need advice from @wisp3rwind or @sampsyo. Do I overwrite something here? We use album_info.catalognum in the block before when handling the regular catalognum field.

I am also not yet sure what should happen when both discogs_catalog and catalognum tags exist on a file to be imported. Which one should be used for the mb-search-field catno then? Maybe it should be configurable which one should be taken if both exist?

@JOJ0

JOJ0 commented Mar 16, 2022

Copy link
Copy Markdown
Member Author

Some more details on the mp3tag "Discogs web sources file":

@sampsyo

sampsyo commented Mar 16, 2022

Copy link
Copy Markdown
Member

Hmm; interesting! Just so I understand it, however, is it the case that an on-disk discogs_catalog tag should be treated identically to catalogno? I guess the thing that's confusing me is that it seems like a catalog number is a catalog number, regardless of where it came from—are there any semantics attached to the fact that the number came from Discogs vs. from MB, for example?

If so, maybe we should just change MediaFile itself to "ingest" catalogno from this additional on-disk tag name…

@JOJ0

JOJ0 commented Mar 17, 2022 •
edited
Loading

Copy link
Copy Markdown
Member Author

Hmm; interesting! Just so I understand it, however, is it the case that an on-disk discogs_catalog tag should be treated identically to catalogno? I guess the thing that's confusing me is that it seems like a catalog number is a catalog number, regardless of where it came from—are there any semantics attached to the fact that the number came from Discogs vs. from MB, for example?

Sure, a catalog number is a catalog number, no matter where it's pulled from. My main goal for this change was to make use of a valuable information when importing already quite well tagged files. It should also lead to getting better distance scores and thus potentially getting closer to auto-tagging those files. Not sure if everything I coded there is entirely correct towards achieving these goals...

When the file is imported the on-disc discogs_catalog tag is of no use anymore because catalognum is there and is more of a standard field. What I am not sure now is what happens with the abandoned on-disk tag. Beets doesn't know about it anymore. But am I right that this is the case with other tags as well? Beets can't know everything right?

If so, maybe we should just change MediaFile itself to "ingest" catalogno from this additional on-disk tag name…

I am not sure if I understand what you mean by ingest but I guess something like: MediaFile should be aware of that both, a discogs_catalog and also a catalognum tag could exist and should pass one or the other when the catalognum attr of the MediaFile object is accessed?

But what now if both tags exist on-disk, which one should then be used for passing to the MB search?

@sampsyo

sampsyo commented Mar 17, 2022

Copy link
Copy Markdown
Member

Sure! To break this down, what I was proposing is that MediaFile not add a new field, but make the existing "logical" catalognum MediaField map to multiple "physical" on-disk tag names. This one-to-many mapping exists for other fields in MediaFIle already—see barcode, for instance:
https://github.com/beetbox/mediafile/blob/4f70ee8a29456ca98c071e59f08310b2b9948afb/mediafile.py#L1965-L1974

That way, beets would be blissfully unaware and would get the data from whatever field existed. If both were defined, MediaFile would need to pick a winner (presumably the current tag mapping).

@JOJ0

JOJ0 commented Mar 18, 2022

Copy link
Copy Markdown
Member Author

That sounds like a great solution. Aha, read only true would be what discogs_catalog on-disk should be.

I'll try this soon. Thanks!

@JOJ0

JOJ0 commented Mar 21, 2022 •
edited
Loading

Copy link
Copy Markdown
Member Author

Closing in favor of a solution, as suggested in mediafile diretly: beetbox/mediafile#61

@JOJ0 JOJ0 closed this Mar 21, 2022
@snejus snejus added the musicbrainz musicbrainz plugin label Jan 22, 2026
@snejus snejus added the discogs discogs plugin label Apr 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot Awaiting requested review from Copilot Copilot will automatically review once the pull request is marked ready for review

Assignees

No one assigned

Labels

discogs discogs plugin musicbrainz musicbrainz plugin

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@JOJ0 @sampsyo @snejus