Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is LC3 superior to existing codecs like Opus?


Opus is not low complexity


Found this:

LC3 at 32 kbps (LC3 32) provides significantly better audio quality than Opus-CELT at 32 kbps and complexity level 0 (OPUS_v114_c0 and COPUS_v114_c0).

https://www.etsi.org/deliver/etsi_tr/103500_103599/103590/01...


I'm of the opinion that Codec 2 [0][1] should pause on trying to perform better at lower and lower bit rates, and put some work into higher ones.

Getting down to 700 and even 450 b/s is neat and all, but there seems (to me) to be a gap between 4000 and 10000 b/s in the patent-free space.

* [0] http://www.rowetel.com/?page_id=452

* [1] https://en.wikipedia.org/wiki/Codec_2


opus_256k can decode in real time on ~40MHz arm9 from 1999, or 16MHz DSP core https://www.synopsys.com/dw/ipdir.php?ds=arc_audio_opus_code...


For comparison, Synopsys' LC3 codec implementation: https://www.synopsys.com/dw/ipdir.php?ds=arc_lc3_codec

It doesn't seem to be a particularly lightweight codec compared to Opus, or particularly performant.


I don't get it, if I watch an opus music on YouTube, will my headphone transmute opus into LC3? Why this indirection and overcompression? Latency shouldn't exist at all with opus anyway, YouTube just has to send cached audio to the headphone.


Because that requires a Bluetooth processor that can decode Opus. Also, it's a lot less simple than that. You aren't sending the raw audio file to the Bluetooth chip, you're sending an internal audio stream which is already getting converted anyways.

The path is almost always: input audio stream -> decode into raw PCM/PDM/TDM/whatever -> convert to whatever sample rate you're using internally -> move it to your output via some sort of audio bus -> output converts to whatever format IT needs (for bluetooth, this would be into packets to send over bluetooth... for a speaker driver, this would be into signals that drive an actual speaker)

Even if you could send Opus directly, I guarantee there's a reason that they went through the effort of developing an entirely new codec. If Opus met all their needs right off the shelf, then you bet they would spend the effort to use what already exists.

There probably is some sort of latency compensation that you could perform to alleviate this for video content (e.g., most receivers have a delay option to compensate for TV latency), but this falls apart for any instantaneous audio (e.g. button presses, video games, or other dynamic content). You want everything to run as quickly as possible.


I suspect the main reason they created a new codec is to collect a few billion in royalties.

The most obvious choice here was to allow MP3 as a codec choice, but the patents are all expired on MP3 so that's not a revenue source. Doing that would have avoided recoding for most music.

Every Bluetooth chip I've seen has enough CPU to decode any of these codecs. The only question would be power consumption during decoding.


You arent wrong. Look at Dolby and their clever injections into every new standard despite both HDMI and Bluray already provisioning uncompressed LPCM 7.1 channel audio.


Sure, most Bluetooth chips CAN decode most codecs... but it's a matter of power efficiency. If you're trying to make things as efficient as possible, you don't want something that can decode a bunch of different codecs. More specialized means it should be more efficient.


In practice, these codecs are all going to be decoded in firmware on a DSP anyway - while the hardware is optimized for efficient implementation of algorithms like this, which one doesn't matter so much. Also, LC3 seems to have roughly the same computational complexity on one as Opus based on the figures I've seen, and about the same quality too.

I have a distinct suspicion that in reality the only relevant feature LC3 has which Opus lacks is that it ensures a nice ongoing stream of licensing money for the Fraunhofer Institute and Ericsson, who designed it and worked to get it into the standard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: