Make use of padding space when possible

[Zapeth]

Normally when adding or removing tags, the data is just directly inserted or cut out.

With these changes the padding space in the metadata is used instead (overwritten when tags are added, or inserted when tags are removed), to preserve the original file size if the tag changes are small enough.

This works for my use case but I realize the usefulness of this functionality is subjective, so feel free to close this PR if you don't think they are worth including.

[fmang]

Thank you for your proposal.

Here’s what https://datatracker.ietf.org/doc/html/rfc7845.html has to say about the extra_data block:

Immediately following the user comment list, the comment header MAY contain zero-padding or other binary data that is not specified here. If the least-significant bit of the first byte of this data is 1, then editors SHOULD preserve the contents of this data when updating the tags, but if this bit is 0, all such data MAY be treated as padding, and truncated or discarded as desired. This allows informal experimentation with the format of this binary data until it can be specified later.

To be honest, I have no idea what people do with this block, so opustags currently always keeps it intact. Your code seems to assume the extra_data is always padding, but according to the specs that’s not always the case.

Regarding the usefulness of the feature, I don’t undestand why you would like to keep the original file size instead of shrinking it when removing data from the tags. Do you have a use case where preserving the file size matters?

[Zapeth]

Thanks for the reference, I didn't know there was a flag where this extra data should be preserved. I just assumed it was always padding because by default opusenc explicitly adds padded data at the end of the comment header (named as such in its options).

Though I also can't imagine a reason why someone would want to intentionally store something in this extra data or preserve its size, any binary data could be stored as a text-encoded comment (and it usually is, like album art). But since its written in the specs it makes sense to add a check for it.

Regarding the usefulness of the feature, I don’t undestand why you would like to keep the original file size instead of shrinking it when removing data from the tags. Do you have a use case where preserving the file size matters?

Its not necessarily a use case, but more a personal preference. Kind of what you wrote in the project README about being as conservative as possible, only slightly more strict (binary comparison is also easier with unchanged sizes).

[fmang]

Well, since most of the bytes of the file are left unchanged, I think any slightly smart binary comparison tool will align data properly. Regarding conservativeness, it’s unclear which is better between keeping extra_data intact or the file size unchanged.

I’m gonna keep the current state because it’s simpler and safe, unless someone comes with a concrete use case.