search

quodlibet / mutagen

Python module for handling audio metadata
https://mutagen.readthedocs.io
GNU General Public License v2.0
1.55k stars 158 forks source link

Add format-agnostic common tagging interface #186

Open lazka opened 10 years ago

lazka commented 10 years ago

Originally reported by: Ben Ockmore (Bitbucket: LordSputnik, GitHub: LordSputnik)

There should be a common interface to access as many tags as possible from every single format mutagen supports, to hide the various quirks of formats from the end user and make tag editing as simple as possible.

This idea expands on the existing Easy interfaces for ID3 and MP4, which would be deprecated and replaced by the new system.

Some mutagen users already implement something similar (eg. Quod Libet, MB Picard) - it'd be good to take into account these use cases and make sure they work with the new system.

Some examples and chatlogs:

lazka commented 9 years ago

Original comment by Ben Ockmore (Bitbucket: LordSputnik, GitHub: LordSputnik):

I agree with Christoph that it's better to keep it separate at first. But after it's fairly stable, we could bring it back into the main package. Perhaps for "mutagen2" if/when that becomes a thing :)

lazka commented 9 years ago

Original comment by Samuel Messner (Bitbucket: obskyr, GitHub: obskyr):

I'd like to see it be a part of Mutagen. It'd pretty much make Mutagen the solution for audio tagging with Python. It already is, to a certain extent, but that would cement it.

lazka commented 9 years ago

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

I just like to add here that this doesn't have to end up in mutagen itself and can be a separate project.

And for the API example in the first post: please don't forget about multi value tags.

lazka commented 9 years ago

Original comment by Samuel Messner (Bitbucket: obskyr, GitHub: obskyr):

Sounds wonderful. Once you get the connection in place, I might be able to help out with the conversion modules.

About this, though... perhaps bind mutagen.File(easy=True) to this new monolithic handler class? It'd preserve some compatibility quite nicely.

lazka commented 9 years ago

Original comment by Ben Ockmore (Bitbucket: LordSputnik, GitHub: LordSputnik):

Effectively that's my plan already, but instead of implementing an individual Easy class for each format, I'd create a single class on the front-end, and have one module per format to deal with the conversion to/from the "Easy" format in the background.

lazka commented 9 years ago

Original comment by Samuel Messner (Bitbucket: obskyr, GitHub: obskyr):

I've been getting around this by writing wrappers for everything. For example, setting cover art practically needs a slightly more complicated wrapper just to support both Vorbis comments and ID3.

What I'm thinking is perhaps we don't need a new system for uniform tagging? Perhaps it's a good idea to just expand the "Easy" concept onto every other format Mutagen supports? For example, trying to set the tag coverart in an EasyVorbis would set the METADATA_BLOCK_PICTURE with all of the necessary conversion and such.

Then just make sure all of the Easy classes have the same tag names, and we've got a nice uniform solution.

lazka commented 9 years ago

Original comment by scribbled_pixels (Bitbucket: scribbled_pixels, GitHub: Unknown):

@clee704 I think what @LordSputnik meant, was if it makes sense to use your library as the basis for developing that format-agnostic common tagging interface. It wouldn't be included as is, but with lots of changes (additions and improvements). And having a small library isn't necessarily bad.

lazka commented 9 years ago

Original comment by Choongmin Lee (Bitbucket: clee704, GitHub: clee704):

Unfortunately, mutagenwrapper is very small and still in development. It is made to suit my specific needs (managing my Foobar2000 library). Although concise in design, it is incomplete to be included in a famous, production-ready library like mutagen. If you want to implement a hard coded mapping quickly, I recommend you look at Beets and how it's doing the job.

lazka commented 9 years ago

Original comment by Ben Ockmore (Bitbucket: LordSputnik, GitHub: LordSputnik):

Thanks for your input - I was going to ask you about mutagenwrapper - how complete is it, and would it be beneficial to use it as a starting point for fixing this issue?

lazka commented 9 years ago

Original comment by Choongmin Lee (Bitbucket: clee704, GitHub: clee704):

I'm the author of mutagenwrapper. I made it to manage my library from command line, along with Foobar2000, which is my favorite music player. Therefore, my priority was to reflect the mapping that Foobar2000 uses as accurate as possible. However, there are subtle differences between different mapping (MusicBrainz Picard, Foobar2000, Beets, etc.). For example, album sort order in Vorbis is ALBUMSORT in MusicBrainz and ALBUMSORTORDER in Foobar2000.

If mutagen is to implement an unified tagging interface, it should be flexible to address those differences. Or as @scribbled_pixels mentioned, instead of hard coding the mapping in mutagen, it may be better to expose an API that simplifies creating different interfaces.

Below are links that may be useful:

lazka commented 10 years ago

Original comment by scribbled_pixels (Bitbucket: scribbled_pixels, GitHub: Unknown):

@LordSputnik

I think that's a great idea! And if it exposes everything that is needed by those users (e.g. Quod Libet) you mentioned, they could use that new interface thus cleaning up their their code.

btw. There is a library called mutagenwrapper (LICENSE) that tries to achieve something like what you proposed. So, maybe we could use some code from that, but I guess the first step would be to collect all the requirements to make sure we don't miss anything.

phw commented 1 year ago

My personal opinion is also that this is better suited inside a separate library, as such a abstraction will always be opinionated in some way or another. mutagen can focus on the lowe level stuff, and something like https://github.com/beetbox/mediafile can be used by those wanting such an abstraction.

Related discussion in #489