Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Opus 1.5 released: Opus gets a machine learning upgrade

opus-codec.org

Post reply on HN
Print view View original

141–150 of 151 posts

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#141

Post by thomastjeffery »

samus wrote: post #140
thomastjeffery wrote: post #136

Earlier quoted context omitted.

Yes, but the holes were intentionally constructed such that the end result is predictable. There is a difference between pretending to be the original raw data, and pretending to be whatever data will most likely fit .

And that's why Packet Loss Concealment is only used to fill in the occasional lost packet. That way, the occasional vowel or the end of a syllable could be bridged over. Other improvements exist to prevent packet loss in the first place that are much less in make-samples-up territory.

Yes, I agree that this use case is entirely reasonable. I also agree that it's reasonable to be concerned in the first place.

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#142

Post by samus »

m3kw9 wrote: post #135
samus wrote: post #122

Earlier quoted context omitted.

Sadly, I see it even on forums where one might think people have background in technology...

The tech background is likely IT and not AI. They used ChatGPT and they thought it’s conscious

I get WH40k techpriest vibes reading these posts

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#143

Post by viraptor »

shwaj wrote: post #137
viraptor wrote: post #105

Earlier quoted context omitted.

A person creating a codec doesn't choose if it's globally adopted. System implementors (like for example Slack) do. You're don't have to tell the open source dev anything. You don't owe them to include their implementation. And if their contribution was to the final system, sure, it's the owner's choice what the threshold for acceptable contribution is. In the same way they can set any other benchmark. > Your same ar…

The grandparent provided an argument why we might not want to use an algorithm, even if it provided a Pareto improvement. I suggested that the same argument could be used to say that we should actively degrade performance of the algorithm, in the name of equity. This is absurd, and illustrates that the GP argument is maybe not as strong as it appears.

The argument doesn't make sense in practice. We could discuss it as a philosophy exercise, but realistically if the current result is better overall and biased against some group, you can just rebalance it and still get an overall better result compared to status quo.

Changing codecs in practice takes years/decades, so you always have time to stop, think and tweak things.

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#144

Post by giantrobot »

out_of_protocol wrote: post #133
maep wrote: post #128

Earlier quoted context omitted.

"Inferior" is relative. The main focus of LC3 was, as the name suggests, complexity. This is hearsay: Bluetooth SIG considered Opus but rejected it because it was computationally too expensive. This came out of the hearing aid group, where battery life and complexity are a major restriction. So when you compare codecs in this space, the metric you want to look at is quality vs. CPU cycles. In that regard LC3 outperfo…

Regarding complexity, do you have any hard numbers? Can't find anything more than handwaving

You can check out Google's version which I assume is bundled in Android: https://github.com/google/liblc3

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#145

Post by maep »

out_of_protocol wrote: post #133
maep wrote: post #128

Earlier quoted context omitted.

"Inferior" is relative. The main focus of LC3 was, as the name suggests, complexity. This is hearsay: Bluetooth SIG considered Opus but rejected it because it was computationally too expensive. This came out of the hearing aid group, where battery life and complexity are a major restriction. So when you compare codecs in this space, the metric you want to look at is quality vs. CPU cycles. In that regard LC3 outperfo…

Regarding complexity, do you have any hard numbers? Can't find anything more than handwaving

I remember seeing published numbers based on instrumented code, but could not find it.

I did a quick test with the Google implementation (https://github.com/google/liblc3) which is about 2x faster than Opus. To be honest, I expected a bigger difference, though it's just a superfical test.

A few things that also might be of relevance why they picked one over the other:

  - suitability for DSPs
  - vendor buy-in
  - robustness
  - protocol/framing constraints
  - control

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#146

Post by out_of_protocol »

maep wrote: post #145
out_of_protocol wrote: post #133

Earlier quoted context omitted.

Regarding complexity, do you have any hard numbers? Can't find anything more than handwaving

I remember seeing published numbers based on instrumented code, but could not find it. I did a quick test with the Google implementation ( https://github.com/google/liblc3 ) which is about 2x faster than Opus. To be honest, I expected a bigger difference, though it's just a superfical test. A few things that also might be of relevance why they picked one over the other: - suitability for DSPs - vendor buy-in - robust…

Thanks for checking it, appreciated

- Well, 2x is nothing to write home about.

- DSP-compatibility probably considered but never surfaced as a reason, so hard to guess investigation results. + Pricing and availability of said DSP modules

- Robustness - well, that's one of the primary features of opus, battle tested by WebRTC, WhatsApp etc. (including packet loss concealment (PLC), Bit-Rate Redundancy (LBRR) frames)

- Algorithmic delay for opus is low, much lower than older BT codecs, so that definitely wasn't a deal breaker

- Ability to make money out of standard is definitely important thing to have

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#147

Post by maep »

out_of_protocol wrote: post #146
maep wrote: post #145

Earlier quoted context omitted.

I remember seeing published numbers based on instrumented code, but could not find it. I did a quick test with the Google implementation ( https://github.com/google/liblc3 ) which is about 2x faster than Opus. To be honest, I expected a bigger difference, though it's just a superfical test. A few things that also might be of relevance why they picked one over the other: - suitability for DSPs - vendor buy-in - robust…

Thanks for checking it, appreciated - Well, 2x is nothing to write home about. - DSP-compatibility probably considered but never surfaced as a reason, so hard to guess investigation results. + Pricing and availability of said DSP modules - Robustness - well, that's one of the primary features of opus, battle tested by WebRTC, WhatsApp etc. (including packet loss concealment (PLC), Bit-Rate Redundancy (LBRR) frames) -…

If used in a small device like a hearing aid, a 2x factor can have a significant impact on battery life.

VoIP in general experiences full packet loss, meaing if a single bit flips the entire packet is dropped. For radio links like Bluetooth it's possible to deal with some bit flips without throwing the entire packat away.

Until 1.5 Opus PLC was in my opinion it's biggest weakness, compared to other speech codecs like G.711 or G.722. A high compression ratio causes bit flips to be much more destructive.

As for making moeny, Bluetooth codecs have no license fees.

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#148

Post by derf_ »

maep wrote: post #147
out_of_protocol wrote: post #146

Earlier quoted context omitted.

Thanks for checking it, appreciated - Well, 2x is nothing to write home about. - DSP-compatibility probably considered but never surfaced as a reason, so hard to guess investigation results. + Pricing and availability of said DSP modules - Robustness - well, that's one of the primary features of opus, battle tested by WebRTC, WhatsApp etc. (including packet loss concealment (PLC), Bit-Rate Redundancy (LBRR) frames) -…

If used in a small device like a hearing aid, a 2x factor can have a significant impact on battery life. VoIP in general experiences full packet loss, meaing if a single bit flips the entire packet is dropped. For radio links like Bluetooth it's possible to deal with some bit flips without throwing the entire packat away. Until 1.5 Opus PLC was in my opinion it's biggest weakness, compared to other speech codecs like…

> For radio links like Bluetooth it's possible to deal with some bit flips without throwing the entire packat away.

Opus was intentionally designed so that the most important bits are in the front of the packet, which can be better protected by your modulation scheme (or simple FEC on the first few bits). See slide 46 of https://people.xiph.org/~tterribe/pubs/lca2009/celt.pdf#page... for some early results on the position-dependence of quality loss due to bit errors.

It is obviously never going to be as robust as G.711, but it is not hopeless, either.

Re: Opus 1.5 released: Opus gets a machine learning upgrade

#149

Post by qingcharles »

Dwedit wrote: post #77

I just want to mention that getting such good speech quality at 9kbps by using NoLACE is absolutely insane.

I was the lead dev for a major music streaming startup in 1999. I was working from home as they didn't have offices yet. My cable connection got cut and my only remaining Internet was 9600bps through my Nokia 9000 serial port. I had to re-encode the whole music catalog at 8000kbps WMA so I could stream it and continue testing all the production code.

The quality left a little to be desired...!

Post reply on HN