To address the grandparent comment, I kinda tend to agree with the OP here. Yes, 16 KLOC is smaller than I would have expected, but that's definitely large enough to be a project that will take some time to grok. And especially for math-heavy c code, less KLOC tends to mean that there's arcane stuff going on. Definitely not out of the realm of approachable, but not a codebase you'll quickly get what's going on without some serious study. And given that the OP's first attempt to convert it to go was to feed it through GPT one function at a time, it may not be something they are ready to modify.
Using ChatGPT one function at a time kinda leads me to believe they aren't super-familiar with c, since pointers alone will definitely not make that approach work. In this case, the OP made the right call by finding a simpler original library to work off of, since production c code isn't necessarily great for learning from. (although I don't like using ChatGPT for a learning tool like this, it adds another layer of abstraction & obfuscation)
Edit: rereading this, it comes off as negative to the OP. Not what I intended, the article was well written and I'm all for exploring new things and documenting them. I actually like writeups like these, since documenting approaching new things is a valuable thing to do, otherwise it makes the discovery part of programming dissappear if the only things that are written up are expert articles.
No, it does not.
Opus is the most efficient audio codec we've got. (For stereo anyway.)
At high bitrates there might be better tuned ones, but also at high bitrates it doesn't really matter what you use as long as it's not MP3.
Generally when I am grabbing audio off Youtube via NewPipe, I generally use the 50kbs OPUS stream if it is just talking/lectures. I cannot tell the difference. That said I once did a FLAC to 128KBit OPUS test on myself with music convinced I would be able to tell the difference. I could not. I just don't have hearing that is sensitive to codec loss it seems.