Live data from Hacker News

Shine: A super fast fixed-point MP3 encoder

github.com

31–40 of 44 posts

Re: Shine: A super fast fixed-point MP3 encoder

#31
post #29
post #22

Earlier quoted context omitted.

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-...

When we have anough compute or the models get much smaller. At this point it seems wasteful to utilize gaming level GPU to decode audio stream.

Re: Shine: A super fast fixed-point MP3 encoder

#32
post #20
post #16

Earlier quoted context omitted.

I remember times when it wasn’ts problem on much less than that… which is what most people had. Guess I’m just old :)

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).

That's exactly how I did it yes. DX4/100, and a dedicated DOS player that could play one song at a time.

Of course back then, much of my collection was in XM format.

Re: Shine: A super fast fixed-point MP3 encoder

#33
post #6

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.

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.

Re: Shine: A super fast fixed-point MP3 encoder

#34
post #29
post #22

Earlier quoted context omitted.

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?

Re: Shine: A super fast fixed-point MP3 encoder

#35

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.

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.

Re: Shine: A super fast fixed-point MP3 encoder

#36
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.

Re: Shine: A super fast fixed-point MP3 encoder

#37
post #33
post #6

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.

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?

Re: Shine: A super fast fixed-point MP3 encoder

#38
post #22

Earlier quoted context omitted.

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 t…

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.

It was Windows Media (WMA) at the time.

Re: Shine: A super fast fixed-point MP3 encoder

#39
post #20

Earlier quoted context omitted.

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.

Unreal, Unreal Return to Napali, and Unreal Tournament used S3M files for music. Not CD Music

Re: Shine: A super fast fixed-point MP3 encoder

#40
post #22

Earlier quoted context omitted.

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.

It was Windows Media (WMA) at the time.

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!

Post reply on HN