audio-metadata
audio-metadata copied to clipboard
thebigmunch
Should all tag values be lists?
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:
- It's harder/uglier to abstract in the code. This can also make it harder/uglier for advanced usage.
- It's some extra trouble/confusion for users to get information from what should be single value fields.
- It can make users think single-value fields actually support multiple values.
So, the question is whether the API consistency is worth all the other hassles. Or vice versa.
As another point of reference, many tag editors don't allow users to set multiple values for most multi-value fields.
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.
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).
I'd go with internal implementation as list and some sort of user-friendly overlay with list of multiple-values-accepting tags.
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?