-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should all tag values be lists? #23
Comments
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 But the question remains open for thoughts, opinions, and ideas. |
After #16 (comment), 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 honestly have no idea what you mean by this. Could you give a more detailed idea/example of what you mean? |
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.
The text was updated successfully, but these errors were encountered: