And for the other direction, there's minimp3: https://github.com/lieff/minimp3
I've used minimp3 to implement a MP3 player on a STM32 microcontroller. Works great -- it has no problem playing a 256kbps file at 80 MHz. :)
This flared up my nostalgia when I remembered ripping CDs I bought from Graywhale into .wav files and encoding them into mp3s on my windows 95 machine in the mid to late 90s. BladeEnc was amazing and fast. It would sometimes encode up to 1x! Meaning it only took about a minute to encode a 60 second .wav into an .mp3. Nowadays I can encode 32 10-minute wav files in like 2 seconds on my Ryzen 5950x.
More interesting than the code itself is the history at the very bottom of the README.
That's a blast from the past!
Shine's output doesn't sound great. If you need the performance on embedded hardware, that's what it's there for. If you need quality sound and can't afford to crank up the output bitrate, prepare to be disappointed.
> The encoder was converted circa 2001 by Pete Everett to fixed-point arithmetic for the RISC OS
Did this originate on a ye-olde-worlde Acorn Archimedes, or merely get converted to run on that?
Anecdote - I remember the first jpeg renderer on the Arch, written in Basic, so interpreted, and it would take a couple of second to render a jpeg to screen on a 33Mhz CPU with no GPU acceleration.
I haven't thought about CPU usage when it comes to MP3's (and this was for decoding), since my DX4-100 couldn't really play them using Winamp (doing almost anything else in Windows while playing one would cause it to stutter).
I think I ended up playing them in DOS on that machine.
Fixed point math superiority \o/
Why do people insist on still using MP3, when better stuff is available? YouTube hasn't used MP3 for years, with good reason.
You can use Opus or AAC, even most car systems should work with one of them.
Wow, nice seeing this here. Shine was a life saver when I was building the live broadcast capability of othernet.is.
Our Satellite link was really low bitrate ( less than 20kbps). I wanted to keep as much of that as possible for the data-casting part, which was our core offering. So after experimenting with varioud codecs I narrowed down to using Opus@8kbps as my downlink from the satellite to our custom receivers. The problem was, Opus wasn't natively supported as a codec by most browsers (Safari being a major culprit). In fact after analysis, I found the only format that could be reliably played on every browser (including mobile) is mp3. So the solution I derived was to have the downlink in opus, decode that on the reciver, reencode it to mp3, and stream that out to the users browser. Now the reciever was a very low end linux device - 1GHz Arm6, 256MB ram - that ran the entire stack. Satellite receiver, UI server, filesystem maintenance, Wifi Hotspot (softAP). We also didn't want to load it down with large heat sinks or fans as a design goal. So the cpu could not be loaded to its full capacity. Every other MP3 encoder I tried was too heavy duty, and would cause thermal issues for the SoC. But Shine worked perfectly - total cpu consumption remaining less than 10% for real time decoding (from opus) and encoding (to mp3).