4 ms·
That's what Opus did. The RFC[1] has a base-64 encoded libopus.tar.gz appendix (Appendix A), which is the "primary normative part of this [Opus] specification."
by cornstalks 3y ago
That's what Opus did. The RFC[1] has a base-64 encoded libopus.tar.gz appendix (Appendix A), which is the "primary normative part of this [Opus] specification." If the prose and source code disagree, the source code takes priority and "wins" when it comes to which is normative.
I have a love-hate relationship with this approach.
[1]: https://datatracker.ietf.org/doc/html/rfc6716 https://datatracker.ietf.org/doc/html/rfc6716
- dfox 3y agoThat is common for codec standards, the normative part of many MPEG specifications is the parser/decoder in C-like pseudo-code. What is somewhat unique for Xiph is that their normative reference decoders are actually usable.
- Eduard 3y agofunny, the RFC even includes a shell command pipeline to extract the base64 out of the awkward RFC formatting. Using the C source code still leaves room for ambiguities / under-specification, no? After all, the semantics rely on the particular gcc release used for compiling the code.
- cornstalks 3y agoThere is still the possibility of a bug or under-specification, but that's always the case in any spec. At least with Opus they document what implementation-defined behavior they require, so assuming there aren't any hidden bugs then you should get consistent output across compilers.
- Eduard 3y agobut the semantics change depending on the build tool version and other factors.