thebigmunch

> Any thoughts on resorting to docstrings placed above the attribute assignment, instead of comments? Generally tools and documentation styles (e.g. Google) use the convention of docstring follows the thing...

Thanks for testing. I'm not sure everyone knows just how much I need people to test this stuff on their own files. About the multiple tags, yeah, I hadn't gotten...

Just pushed a new version that supports multiple covers.

And, now it should set the codec description for your AAC-HE file. Plus, I found and fixed a bug along the way.

Yeah, for the cover art, apparently it can be set as the ``IMPLICIT`` MP4 atom type. I don't know enough about MP4 to know if that's wrong or just nonsensical....

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...

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...

> 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...

Changed the label to ``enhancement``, since it's not technically a bug to error out on invalid input. But audio-metadata should definitely handle this case gracefully as well as ``ParserError``.