"Writing/encoding library" information

[Android-X13]

Hello,

opusenc from opus-tools adds the comments ENCODER and _ENCODEROPTIONS which can be modified or deleted via opustags fine. Is it possible to modify or delete the encoding library information however? For an .opus file that has been encoded with opusenc for example, this information is shown by MediaInfo's "Writing library" parameter as "libopus 1.3, libopusenc 0.2.1".

My skills in C are very poor (almost zero). Looking at the code here, here and here, I believe this information is stored in the comment header, so differently than the other comments? Can this be accessed by opustags?

I was able to change the string via modifying the relevant code and compiling opus-tools as a test, but if this is stored in the comment header I'm not sure if it can be removed.

EDIT: Obviously the encoding library information is not only written by opusenc (like the ENCODER and ENCODER_OPTIONS tags) but by other tools as well (ffmpeg stores its own string).

[Android-X13]

After reading this I realize that the vendor string and the comments are all stored in the "comment header", but the question still stands (i.e. can the vendor string be accessed/modified/removed via opustags).

[fmang]

opustags does read and preserve the vendor string, and I think it could easily modify it if we added the proper CLI flags.

Out of curiosity, what do you need that feature for?

[Android-X13]

I don't really "need" it, I'm mostly curious how to do things and it's always nice to know that you can have complete control over what's going on. But I also hate it when open source tools add all kinds of metadata that can't be removed. Some tools don't do this, for example x265 allows the user to bypass writing of the encoding settings with a CLI option, but x264 doesn't, also opusenc adds the ENCODER and ENCODER_OPTIONS tags without an option to avoid that, etc. They all insert this "library" information though.

Just to clarify, this vendor string can be modified, but can it also be entirely removed from the comment header? Or is it some kind of structural requirement?

[fmang]

The vendor string is a structural requirement of the comment header packet, but it may be empty.

According to RFC 7845:

This tag is intended to identify the codec encoder and encapsulation implementations, for tracing differences in technical behavior. User-facing applications can use the 'ENCODER' user comment tag to identify themselves.

https://tools.ietf.org/html/rfc7845#section-5.2

[Android-X13]

I see. Thanks for the info. Consider this a feature request then, in case you'd like to implement it

[gitoss]

The vendor string is a structural requirement of the comment header packet, but it may be empty. According to RFC 7845: This tag is intended to identify the codec encoder and encapsulation implementations, for tracing differences in technical behavior. User-facing applications can use the 'ENCODER' user comment tag to identify themselves. https://tools.ietf.org/html/rfc7845#section-5.2

+1 for this feature request for a "anonymous" metadata swith. My issue with these metadata tags is that it's an implicit date tag that cannot be gotten rid of.

I can see the appeal to have as much specifics in the metadata as possible for debuging purposes, but the RFC doesn't explicitly require a version and the "Writing library" could just be a generic "libopus, libopusenc"?

Anyway, I guess someone very keen to get rid of this could simple modify the source code for a local binary.

[fmang]

+1 for this feature request for a "anonymous" metadata swith. My issue with these metadata tags is that it's an implicit date tag that cannot be gotten rid of.

I’ll probably make a --vendor flag to get the vendor string, and a --set-vendor flag to set it. You’ll be able to do --set-vendor '' to clear the string.

I was also considering adding a special tag so that the vendor string could be edited like other tags, but that doesn’t feel too right. Besides, this need is quite niche.

[fmang]

Ready for the next release.