SoylentNews is people
SoylentNews
Lyra: A New Very Low-Bitrate Codec for Speech Compression
Since the inception of Lyra, our mission has been to provide the best quality audio using a fraction of the bitrate data of alternatives. Currently, the royalty-free open-source codec Opus, is the most widely used codec for WebRTC-based VOIP applications and, with audio at 32kbps, typically obtains transparent speech quality, i.e., indistinguishable from the original. However, while Opus can be used in more bandwidth constrained environments down to 6kbps, it starts to demonstrate degraded audio quality. Other codecs are capable of operating at comparable bitrates to Lyra (Speex, MELP, AMR), but each suffer from increased artifacts and result in a robotic sounding voice.
Lyra is currently designed to operate at 3kbps and listening tests show that Lyra outperforms any other codec at that bitrate and is compared favorably to Opus at 8kbps, thus achieving more than a 60% reduction in bandwidth. Lyra can be used wherever the bandwidth conditions are insufficient for higher-bitrates and existing low-bitrate codecs do not provide adequate quality.
[...] The implications of technologies like Lyra are far reaching, both in the short and long term. With Lyra, billions of users in emerging markets can have access to an efficient low-bitrate codec that allows them to have higher quality audio than ever before. Additionally, Lyra can be used in cloud environments enabling users with various network and device capabilities to chat seamlessly with each other. Pairing Lyra with new video compression technologies, like AV1, will allow video chats to take place, even for users connecting to the internet via a 56kbps dial-in modem.
This should help make an 8 MiB copy of Shrek sound even better.
Also at CNX Software and Phoronix.
(Score: 0) by Anonymous Coward on Monday March 01 2021, @04:08AM (2 children)
The old telephone transmitted voice signal at analog 4khz band.
Explain to me how it compares to this 3kps band.
(Score: 2, Informative) by pTamok on Monday March 01 2021, @09:20AM
A standard uncompressed voice channel uses PCM (Pulse Code Modulation [wikipedia.org]) with 8-bit samples. The standard for analogue telephone bandwidth [wikipedia.org] is 4 kHz, which is sampled at 8,000 times per second (the Nyquist rate [wikipedia.org]), so a standard digitalised telephone voice channel, with no compression is 8,000 8-bit samples per second, which is 64,000 bits per second, or 64 kbit/s. In the USA, 1-bit was used for in-band signalling (robbed-bit signalling [wikipedia.org]), leading to standard digitalised voice channels being effectively 56 kbit/s for the audio, with a corresponding drop in quality.
(Score: 0) by Anonymous Coward on Monday March 01 2021, @03:07PM
It's 1 better. It goes up to 4.
(Score: 0) by Anonymous Coward on Monday March 01 2021, @04:24AM
Civilian consumer stuff, even in crummy countries, isn't so constrained.
Police and fire departments might contemplate it, at least in calm conditions, for centralized encrypted communication. (but might as well use ordinary cell networks for calm conditions) In a disaster situation, unencrypted peer-to-peer AM is a far better bet for reliable communication.
The military might like it. They often use HF links, trying to allow for a war in which all satellites are nuked. HF is low-bandwidth, and encryption would be highly desirable.
(Score: 0) by Anonymous Coward on Monday March 01 2021, @05:42AM
s/t
(Score: 3, Insightful) by fakefuck39 on Monday March 01 2021, @06:00AM (5 children)
Umm, yeah, when you compare it to a general purpose audio compressor, of course - what an amazing breakthrough. But those aren't used to compress voice. Funny how google gives the Opus (used in the wrong mode) bitrate, then mentions other codecs but doesn't give their bitrate (which is comparable to google's).
DoD's CELP, speex, etc, are all under 5kb/s, which is what this should be compared to. Heck, CDMA2000, the 3G technology America was using a long time ago when the rest of the world was stuck with 2G GSM, used VMR (designed by Nokia) - about 4-6kb/s. I'll just assume later tech is even better. Strange, I don't remember my phone sounding "robotic" unless I get real crappy reception.
>Opus can be used in more bandwidth constrained environments down to 6kbps
actually it's 5kb/s, because it has a narrowband mode, which is what should be used for voice, so not only is the comparison to Opus in the article a strawman, it even (purposely?) compares it to the higher bandwidth full band mode in Opus.
Why? Oh, because this is a story published by google, to make their non-groundbreaking tech that is not any better than existing codecs, appear better than it is. Here's the real non-news: google products are all shine, and are buggy amateur crap you're beta testing.
so, google. great work. you've given a 25% incremental improvement over voice codecs from a decade ago. good job, seriously. but nothing spectacular or ground breaking. just expected. just like google lying.
(Score: 3, Informative) by linuxrocks123 on Monday March 01 2021, @07:05AM (4 children)
They did compare it with SPEEX at 3kbps. SPEEX at 3kbps sounded very glitchy in their sample.
Can you elaborate on what they did wrong with Opus? I used opusenc --bitrate 6 and got pretty much what they got.
(Score: 0) by Anonymous Coward on Monday March 01 2021, @02:13PM
I can't answer the question, but I know that Opus is not a codec, it's a hybrid between the codecs SILK from Skype and CELT.
(Score: 2) by fakefuck39 on Tuesday March 02 2021, @01:45AM (2 children)
my point is they either compare full-band opus at 32 or speex at 3. speex at 5 would be the real comparison. but they don't do that test at all, because it doesn't fit the narrative. for opus narrowband, look ayt narrowband on the opus wiki.
(Score: 2) by linuxrocks123 on Tuesday March 02 2021, @03:51AM (1 child)
They did opus at 6, not opus at 32. After looking around, I don't think they did anything wrong with opus. Like I said, I did opusenc --bitrate 6 and got pretty much what they did. The encoder should be using the right algorithm automatically, I think.
Why should they do speex at 5? If they're 3, the right comparison is anything at 3. opus only goes down to 6, though, at least opusenc only goes down to 6.
(Score: 2) by fakefuck39 on Tuesday March 02 2021, @05:36AM
so why didn't they use opys at 3 using your logic? oh, because they're claiming bitrate reduction for same quality. so that's why they'd use speex at 5. a reduction of 40%. and that's the right comparison. and they did opus at 32 and 8, it's right in the summary. you didn't read the opus wike, did you. it should have linked you to codec2. mostly because opus is a container, which uses several codecs. what it appears you did is use opus, the container, with a codec that's optimized for higher bitrate. both you and google tested transporting a piano in a sports car and brilliantly concluded your new truck works better.
(Score: 4, Insightful) by zeigerpuppy on Monday March 01 2021, @06:35AM
did Google include the sentence about Opus being open-source so that people would think Lyra is too?
The less we rely on google codecs, 'standards' and infrastructure, the better in my opinion.
(Score: 1) by pTamok on Monday March 01 2021, @08:11AM (2 children)
The comments on the Phoronix article about Google's Lyra [phoronix.com] pointed me towards LPCNet:
A Real-Time Wideband Neural Vocoder at 1.6 kb/s Using LPCNet [jmvalin.ca]
The LPCNet source code is available under a BSD license.
(Score: 1) by pTamok on Monday March 01 2021, @09:27AM
The paper on arxiv.org describing Lyra references LPCNet (reference 10)
Google LLC: GENERATIVE SPEECH CODING WITH PREDICTIVE VARIANCE REGULARIZATION [arxiv.org]
(Score: 0) by Anonymous Coward on Monday March 01 2021, @07:40PM
Very good read. Thanks for the link!
(Score: 0) by Anonymous Coward on Monday March 01 2021, @07:23PM (2 children)
(Score: 0) by Anonymous Coward on Monday March 01 2021, @10:30PM (1 child)
You're footing the bill. They will use high-bitrate FLAC.
(Score: 2) by leon_the_cat on Tuesday March 02 2021, @04:21AM
Meh pretty sure they will use raw audio with a metadata tag that has entire wikipedia.