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).
That's interesting you were running at such a low bit-rate.
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.
What codec did you use for your 8000bps? In my experience opus is the only codec that can encode general audio to an "acceptable" (for low values of acceptable) quality at that bitrate. There are speech codecs that can go below 2kbps, but they are useless for non-speech audio (and are also very computationally expensive).
Opus is simply magic. Iirc, they now even have a 6kbps mode.
Deep-learning-based compression techniques may one day be able to get speech down to several hundred bits per second, and non-speech audio in not much more. (They share the computational expensiveness problem though; even more so.) Google's Lyra seems to perform similarly to Opus for speech, at less than half the bitrate: https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-...
I am aware of lyra. Its pretty good. Very computationally expensive though - no audio application I have ever worked on had even close to the power/thermal budgets that would allow use of the deep-learning codecs. Maybe someday we will get very low-energy hardware accelerators for them, but until then, these are a non-starter for things I work on.
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?
Ah yes, should have guessed. WMA was pretty big in the early 2000s. Around 2004 I even had access to the official wma source from Microsoft.
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!
Ah, I would have loved to see that. Never got to, even though I was a Windows Media MVP, I was NDA'd to the Moon, and I was the main tech guy in exec level meetings at Microsoft about Windows Media and the company I was working for was probably the biggest user of WMA in the world.
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.
On x86, a Pentium 75 was just about the absolute minimum for playing the common 128 kbps stereo MP3s of the time.
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 Pentium 166 MMX running Windows 95 and Winamp 0.x got 100% loaded while playing my first ever mp3 file - brought home on 3 floppy disks. That's why games of that era were using CD Audio for soundtrack or tracker music like Unreal or Deus Ex.
Part of that is was probably just Windows 9x's terrible multitasking, coupled with a badly-written MP3 decoder. We generally suffered software in those days that really held back those machines from what thy were capable of. The MMX Pentiums were perfectly capable of decoding an MP3 in real time.
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.
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.
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.
Exactly right. Due to the missing psycoacoustic model, Shine can't really compress well. Don't even bother with bitrates lower than 128kbps if you want your audio to sound decent. But exactly due to the lack of the psycoacoustic model, its very light on cpu and memory, and perfect for the specific embedded use cases where encoded bitrate is not a concern.
> 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.
> Why do people insist on still using MP3, when better stuff is available?
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).
> Why do people insist on still using MP3, when better stuff is available?
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.
For tech giants optimizing for transit, the complexity and engineering costs of improvements are easily paid for by even small savings, and because it's just transit, you can support multiple formats simultaneously. And everything you do is ephemeral: You could have a new codec every day and not ruin any archivist's day with long term support requirements (excepts the ones they try to shake off anyway).
TLDR: for Youtube, transit bw is expensive and rapidly evolving codec cornucopia is cheap enough to cover with the bw savings.
If your comment was aimed at shine specifically, here is an excerpt from the bottom of the readme:
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.
Stopped using Opus after encountering bluetooth speakers that could not decode it. Having my collection with me is only useful if i can listen to it. Now i use high VBR mp3 in 48k, no need to upsample on playback.
Bluetooth Speakers don't directly use the compressed format, but another format (in the worst case SBC) recompressed by the player. I've never seen one that supported MP3 compression.
Or did you mean native playback from sd cards/usb sticks?
Had my music on my phone as opus. Did not work on the bluetooth speaker of a woman i was involved it. Better sound at lower bitrate is worthless if you can't play it.
Well currently it would be royalties from licensing it out (the patent is expired so it's technically not needed anymore). There is also a benefit since consumers are more familiar with the word MP3 as opposed to AAC. However I think marketing in the past is much more relevant. I have heard of "MP3 players", but not "AAC" players.
> I have heard of "MP3 players", but not "AAC" players.
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.
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).