thebigmunch / audio-metadata

A library for reading and, in the future, writing audio metadata. https://audio-metadata.readthedocs.io/
https://forum.thebigmunch.me
MIT License
53 stars 11 forks source link

Should all tag values be lists? #23

Open thebigmunch opened 4 years ago

thebigmunch commented 4 years ago

So, the reason this is the case now in audio-metadata, mutagen, and many, if not most, other audio metadata libraries is that Vorbis comment fields and some ID3 fields support/make sense with multiple values. But, some ID3 fields and other tag systems (like MP4, RIFF, and others) do not. Some people have even suggested in style guides that some Vorbis comment fields should not be given multiple times, as they don't make sense as multiple-value fields.

Making these lists has some advantages, mainly keeping the API consistent across all tag formats and fields. However, there are some disadvantages:

So, the question is whether the API consistency is worth all the other hassles. Or vice versa.

thebigmunch commented 4 years ago

As another point of reference, many tag editors don't allow users to set multiple values for most multi-value fields.

thebigmunch commented 4 years ago

In #16, I propose a refactor related to tags. It relieves some of the disadvantage of having all tag fields be lists (in the refactor proposal, a TagList).

But the question remains open for thoughts, opinions, and ideas.

thebigmunch commented 4 years ago

After https://github.com/thebigmunch/audio-metadata/issues/16#issuecomment-598180845, I'm pretty sure that not everything should be lists. Not just because it makes more sense intellectually, but also because it makes more sense for implementation.

Whether we stick to a style guide (existing or newly created) for the appropriate formats remains to be seen. It's unlikely that many of the obvious single-value feilds (track number, album, copyright, etc) would occur multiple times in say, Vorbis comments, but it wouldn't be right to just ignore multiples (without warnings, at least).

JuniorJPDJ commented 3 years ago

I'd go with internal implementation as list and some sort of user-friendly overlay with list of multiple-values-accepting tags.

thebigmunch commented 3 years ago

I'd go with internal implementation as list and some sort of user-friendly overlay with list of multiple-values-accepting tags.

I honestly have no idea what you mean by this. Could you give a more detailed idea/example of what you mean?