4 ms·

Is LC3 superior to existing codecs like Opus?

by nwah1 7y ago

0-_-0 7y ago
Opus is not low complexity
- nwah1 7y ago
  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.01.01_60/tr_103590v010101p.pdf https://www.etsi.org/deliver/etsi_tr/103500_103599/103590/01...
  - throw0101a 7y ago
    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 http://www.rowetel.com/?page_id=452 * [1] https://en.wikipedia.org/wiki/Codec_2 https://en.wikipedia.org/wiki/Codec_2
- rasz 7y ago
  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_codec https://www.synopsys.com/dw/ipdir.php?ds=arc_audio_opus_code...
  - makomk 7y ago
    For comparison, Synopsys' LC3 codec implementation: https://www.synopsys.com/dw/ipdir.php?ds=arc_lc3_codec 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.
The_rationalist 7y ago
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.
- Kirby64 7y ago
  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.
  - jonsmirl 7y ago
    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.
    - Kirby64 7y ago
      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.

Is LC3 superior to existing codecs like Opus?

by nwah1 7y ago

Is LC3 superior to existing codecs like Opus?

0-_-0 7y ago

Opus is not low complexity

nwah1 7y ago
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.01.01_60/tr_103590v010101p.pdf https://www.etsi.org/deliver/etsi_tr/103500_103599/103590/01...
- throw0101a 7y ago
  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 http://www.rowetel.com/?page_id=452 * [1] https://en.wikipedia.org/wiki/Codec_2 https://en.wikipedia.org/wiki/Codec_2
rasz 7y ago
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_codec https://www.synopsys.com/dw/ipdir.php?ds=arc_audio_opus_code...
- makomk 7y ago
  For comparison, Synopsys' LC3 codec implementation: https://www.synopsys.com/dw/ipdir.php?ds=arc_lc3_codec 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.

The_rationalist 7y ago

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.

Kirby64 7y ago
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.
- jonsmirl 7y ago
  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.
  - Kirby64 7y ago
    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.