Timothy B. Terriberry wrote: > 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:
Probably 5.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. I support this change, as it at least allows for later extensions (including binary picture attachments) with less risk that files making use of such extensions will be mishandled by conforming tools. The first sentence is a bit unclear about the location of the binary data; for example, it might be interpreted to mean that a comment may contain additional binary data after the text. It would also be nice to keep zero-padding outside of the category of what is not specified here, as it is currently in use. I propose that the first sentence be worded as: "Immediately following the user comment list, the comment header MAY contain zero-padding or other binary data which is not specified here." - Mark _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
