What I learned about MP3 encoding
braheezy.github.io
braheezy.github.io
The author seems to have spent considerable effort on learning as little about it as possible. Most of this article talks about translating C to Go mechanically, without understanding the code. There is even a cameo of the Bullshit Eng—, er, ChatGPT.
In other words, the title is misleading clickbait.
I agree that the article content was a bit of a letdown after I read the article title.
I actually, really, did want to learn about MP3 Encoding.
What a ridiculous concept. IP needs to die an ugly death.
Many people would like to see the death of the latter kind of IP but not necessarily the “enforced sharing” version that GPL invented.
Sure, these licensing terms are meant to protect against said evils. They would also be unnecessary in a world that discarded the idea of owning data. And they're still ridiculous—especially copyleft.
Given the popularity of the library I'd imagine it's quite well tested. I also fail to understand why he attempts to port libshine from C to Go when he could just port the header files from LAME as FFI bindings instead. That should also ensure comparability with windows, as I'm sure such a library us also buildable on windows, given that ffmpeg uses it and ffmpeg works on windows.
Pure Go can be cross-compiled easily, but that goes out the window once you include C code. You can make it a bit easier by using Zig as your c compiler, but it's still a bit of a pain. If you want to expose your code as a Go package, the situation gets even more complicated.
Thank you for sharing.
The best open source MP3 encoder, which still makes LAME very important. If you need the absolute best MP3 encoder, ABX testing against Fraunhofer’s encoder tells the tale.
https://podcastengineeringschool.com/itunes-uses-fraunhofer/
It's iTunes' AAC encoder that's good.
What's amusing is that speakers may have been optimizing themselves for LAME, since it's pretty much the dominant encoder.
It had AOL chat coms. Ha.
Do open-source and hobbyist developers really care about patents? I would rather think that's only the case when they plan to commercialize.
[0] https://arstechnica.com/tech-policy/2013/01/patent-trolls-wa...
For others, I do care and go to reasonable lengths to avoid infringing on any.
I swear I'm not trying to sound like an uppity, badass Real Programmer here, but this seems... not too bad? 16 kloc of C for what is apparently the gold standard in lossy audio encoding is actually less than I would have guessed.
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.
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.
Haha, yep. This is partly why there were so many recordings that sounded like ass back in the infancy of music sharing and partly why we cared about bitrate.
We have many more options today. Today's music sounds great at 96Kbps with AAC or Ogg Vorbis encoding, which is a big reason why streaming became, and continues to be, viable.
I can hear up to around 21.5kHz, which I know because I have a 48kHz DAC. However those frequencies are almost always just unnecessary to include in a signal anyway.
It honestly isn't, it's actually more complicated than later codecs like LC-AAC for no benefit because of the weird filterbank thing. Though, I would start with ADPCM.
eg: https://hydrogenaud.io/index.php/topic,77128.msg674479.html#...
I'm considering creating an small project that (as a part of a bigger task) needs to be able to play users' sound files. I'd be happy to know that I don't need to support mp3s anymore, but so far I've failed to convince myself that it's a right choice.
I would like to ask, why was this blogpost written? What is the purpose?
There are multiple products using LAME on Windows. You've mis-identified the product that isn't portable here.
IOW, LAME works on Windows in products written in C, C++, Python, etc. It's just that this particular Go library doesn't support Windows.
I fail to see how that is a C portability problem, when the C bits already work on Windows.
[EDIT: Looking at the Go LAME project that he references, it appears he didn't even log an issue about whatever it was that went wrong on his Windows build. I'm more inclined to believe that he did something wrong than that LAME doesn't work on Windows using the referenced library.]
[1] For example, Rust `openssl` crate was notably annoying to compile for a long time, even on macOS (it took literally years to make the typical experience smooth enough). And yet it was an essential component for HTTPS! Today we would use the `native-tls` crate instead that avoids OpenSSL on Windows and macOS.
I broadly agree, but in this particular case:
1. LAME compiles just fine using multiple different compilers on Windows (including an older MSVC - newer ones will error out on the use of unsafe functions, fixed by passing a #define in a flag).
2. LAME has no dependencies to download.
3. LAME is successfully used from many other languages on Windows.
So, yeah, if it's not working for him but works for everyone else, you can't blame C for portability here.
OTOH, because LAME is written in C, you have even more options - don't compile it yourself. Download the compiled LAME .dll and just use it from Go.
Author didn't even try the easiest option, said easiest option being possible only because it was written in C.
I think he's trying to show an alternative MP3 encoder to LAME for Go projects. It does seem that he has fallen foul of the Shine license though.
In his own words, he transformed Shine from C to Go mechanically, but he put the result under a license incompatible with Shine's original LGPL license.
(I wonder if he is reading this thread)
I think this line sells it short:
It's battle-tested code. Like SQLite, forget about the language used to implement it; the fact that it runs on multiple architectures, used by multiple products, from multiple different programming languages, deployed to multiple platforms ... means that I have more confidence in the software than in a new project made in a safe language.