Mark Harris wrote:
None of my proposals should break already-encoded files, so that should not be an issue. I think that the only potential issue is that insufficient guidance in the Ogg Opus draft may lead to newly encoded files being handled poorly by older tools that are not aware of later extensions. It would be best for this document to provide additional guidance even if details such as anything specific to attached pictures is specified later in another document.
To resolve this, I'm proposing (as an individual) the following text, to be added in a new paragraph at the end of Section 4.2:
"The comment header MAY contain additional binary data which is not specified here. If the least-significant bit of the first byte of this data is 1, then editors SHOULD attempt to 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 be truncated or discarded as desired."
Any binary extension for album art, etc., is going to have to be compatible with the Vorbis framing bit if we're going to use it for Vorbis as well, so I think this gives us a good extension mechanism with minimal restrictions while still allowing people to pad the comment header for in-place editing (so you can, e.g., update the comments without rewriting the whole file). Current tools use all-zero bytes for this padding, so they wouldn't have to change.
_______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
