Adding new discogs fields

[msil]

This adds some extra tags for discogs identifiers. It is used by the following PR adding extra discogs fields to beets: beetbox/beets#3413

[sampsyo]

Hi! Thanks for looking into this. When we add new tag mappings to MediaFile, it's important to justify them by looking at existing software that uses the tags so we can be sure we maximize compatibility. Have you found other music software that uses Discogs tags?

[msil]

If I'm being totally honest, no I can't justify this at all :) I've yet to see software handle those particular tags. It's more of a personal/selfish thing. I'd to be able to grab the discogs IDs out of my collection without having to query the beets DB for various reasons. I understand if you'd rather not merge this PR.

With regards to beetbox/beets#3413, I would like to see the discogs plugin leave the MusicBrainz fields alone and only use it's own fields to store discogs data. If I were to make that change and this PR is not accepted, then I'm left in a situation where no album/artist/label IDs are tagged in the media files themselves.

[slogsdon7]

I'd actually argue these are almost entirely unnecessary, since if you have the discogs release_id, then you have easy access to the label_id and release_id if you need them.

I know Yate saves discogs label/artist URLs to tags, and I know there are media players which support using links from metadata in the user interface. I'm not sure if that usage is common enough to justify adding those fields, though.

[henry-oberholtzer]

Old PR, but I know these fields, or at least similar ones, are used & written by the Foobar2000 plugin discogger.

[JOJ0]

@henry-oberholtzer I can't seem to find the exact names of the tags foobar2000 writes. Can you post them.

And yes actually I don't think it hurts to write these fields to file too. We could actually merge this @semohr what do you think?

[semohr]

I don't mind! @henry-oberholtzer you want to pickup this PR?

More of a general question, but could we make this progress more dynamic? Keep in mind I might not have the full vision for this package, but it seems a bit weird to me that we have to manually define all tags we want to be able to write. Maybe adding a way to write fields in a more dynamic way without having to push a new mediafile version could be useful? Also thinking about the discussion in beetbox/beets#6076
A registry or something alike could work 🤷

[henry-oberholtzer]

Yeah, I think having set fields for standard ID3 / Vorbis tags and a dynamic system for almost everything else would be good.

Classes are in session for me again, but I'll try and give this a look this week.

[semohr]

Thanks! No rush at all, this isn’t time-sensitive. Your studies should definitely take priority 😊. I might even have some spare time to continue modernizing things here a bit, the repo could really benefit from some typehint sparkles and a bit of restructuring.

[henry-oberholtzer]

Yes - maybe we can get this ready for a 1.0.0 release after four years of sitting at 0.9.0!

[JOJ0]

@semohr wereyou aware that we also have another way of adding mediafields? A plugin can use an add_mediafield method. That's the dynamic way you are looking for I guess.

Let me find details on that later...

Update: This is what I ment: https://beets.readthedocs.io/en/latest/dev/plugins/other/mediafile.html

In case you were aware already, appologis, just wanted to make sure!

[semohr]

Awesome! Did not know about that.

I think this is also what should be used in the discogs plugin. No need to add this to mediafile definitions or am I missing something crucial?

[henry-oberholtzer]

@JOJ0 Oh terrific! I agree with @semohr - this makes a lot more sense to add to the discogs plugin than a new mediafile definition.

[JOJ0]

In that case I agree with both of you, Discogs plugin could be advanced for thoses fields. I'm closing this one. Adding to mediafield directly as far as I understand it, is something other applications/users, not Beets, would benefit from.

[endcredits33]

Just for my understanding, assuming the Discogs plugin gets updated as per the method above, would the additional tags become available simply as long as the plugin is enabled? I ask because I personally don't use the beets autotagger (I use the foobar discogger plugin referenced above) so never actually invoke the Discogs plugin.

[JOJ0]

Does foobar 2000 discogger plugin use this library (mediafile) to tag files? Is foobar 2000 a python program? sorry couldn't quickly find that out on their website? https://www.foobar2000.org/SDK

[henry-oberholtzer]

The tags would be written to files if we add it to the plugin! Could also instruct the plugin to check for those fields when importing too.

Foobar2000 is a music player / management application written in C++, foo_discogger, a third party plugin for it, is written in C++ as well. https://github.com/ghDaYuYu/foo_discogger

Discogger lets you modify the name of the tags it writes but by default it writes to these mappings.

discogs_release_id
discogs_label_id
discogs_artist_id

Unfortunately that doesn't quite line up with our tags for ids:

discogs_artistid
discogs_albumid

Don't think that's a good reason to change it on our end. Seeing as the Discogger plugin has adjustable mapping, if anyone is in that in between use case, they could just modify the mapping on Foobar.

[kowalcj0]

@henry-oberholtzer I can't seem to find the exact names of the tags foobar2000 writes. Can you post them.

And yes actually I don't think it hurts to write these fields to file too. We could actually merge this @semohr what do you think?

Here's the list of the tags for

• ID fields: https://github.com/ghDaYuYu/foo_discogger/blob/master/tags.h#L23-L26
• and all other ones: https://github.com/ghDaYuYu/foo_discogger/blob/master/tags.cpp#L15 + https://github.com/ghDaYuYu/foo_discogger/blob/master/tags.cpp#L76