Shine: A super fast fixed-point MP3 encoder
github.com
github.com
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).
In 1999 I was the 2nd employee at what became one of the world's biggest music streaming services. I was working from home as we didn't have offices yet, and my broadband got cut off because I hadn't been paid yet and I was broke. I ended up having to re-encode the entire music catalog at 8000bps so I could stream it all over my 9600bps cell connection via the serial port of my Nokia 9000, when I was testing the system.
Opus is simply magic. Iirc, they now even have a 6kbps mode.
The thing is (and maybe this is a nitpick), once you are down to several hundred bps for speech, its getting to be more like speech-to-text (the encoder) and text-to-speech (decoder) than an audio codec.
I am actually not aware of any non-speech audio codecs which can go that low. Any links?
Spent about 4 months porting and then optimizing the wma decoder on a proprietary very-low-power dsp. It was hard work, but I got it down to about 12mhz for real-time decode on the dsp. The product this was intended for was going to be powered by a watch battery - hence the extreme optimization requirement. The source code, as received, used to consume ~400mhz on an athlon iirc. But with a lot of assistance from the dsp hardware and 4 months of elbow grease it could decode in less than 12mhz - for some profiles. Insane codebase!
I wonder if the decoder source is in the Windows source code leaks? I guess Windows Media Player source will be in there. That'd be worth a look for me to see how utterly horrible it actually was.
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. :)
A DX4/100 could just barely do it if you were running a performant MS-DOS player and doing nothing else at the same time (the 486 of course had dramatically worse floating point performance than a Pentium clocked at the same frequency).
My old 233 MHz MMX Pentium machine could decode MPEG-4 standard definition video with an MP3 audio track, under Linux. Though I had to set my video player to real-time priority if I wanted it to not drop frames.
Of course back then, much of my collection was in XM format.
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.
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 think I ended up playing them in DOS on that machine.
You can use Opus or AAC, even most car systems should work with one of them.
Because the latter are called "MP4 players" and the files are meant to have ".m4a" extension. Also because dedicated media player devices stopped being something ordinary people need (because smartphones) sooner than MP4 became a thing.
TLDR: for Youtube, transit bw is expensive and rapidly evolving codec cornucopia is cheap enough to cover with the bw savings.
This code was dug out from the dusty crates of those times before internet and github. It apparently was created by Gabriel Bouvigne sometime around the end of the 20th century.
First, most people here recognize that this is something from the past.
Second, some people work with older systems which do not support AAC due to patent reasons. This is not about libre software, just the fact that MP3 is easy to support because its patent fees (at the time anyway) are lower than AAC and the circuitry can be placed for tenth of a US cent (which Opus don't have advantage of). There are new standalone players (built into speakers or radios) out there which don't support AAC purely because of patent fees (MP3 no longer have active patents). This makes MP3 a lowest-common denominator of compatibility.
It's patent-free and well supported everywhere by everything.
For example, if you want to use audio on a webpage, and you want it to work *everywhere*, and you don't want to have to encode multiple formats/containers then MP3 is the only option. You can't use Opus because of course Safari (it does support it, but only in a Safari-specific container), and AAC is not support on Firefox in certain situations (because it doesn't actually include an AAC codec and relies on the OS to decode it).
Or did you mean native playback from sd cards/usb sticks?