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

Google open-sources the Lyra audio codec

opensource.googleblog.com

Post reply on HN
Print view View original

111–120 of 145 posts

Re: Google open-sources the Lyra audio codec

#111

Post by rpdillon »

bobthechef wrote: post #39
dqv wrote: post #26

Earlier quoted context omitted.

This already happens with existing compression algorithms. Certain vowel sounds get collapsed, so someone will say, for example, "66" and it will come out on the other side as "6". Very annoying because you can't exactly coach a layperson on how to talk "the right way" to not trigger this vowel collapse.

> you can't exactly coach a layperson on how to talk "the right way" to not trigger this vowel collapse I've never noticed. At any rate, we should not coach people to adapt to technology in this way. It is Procrustean and anti-human and unnecessarily places a burden on people that belongs to the software and the developer.

I've always suspected the optimal experience is a balance...we define some intermediate language that both the computers need to be programmed to understand and humans need to be trained to adopt.

The most obvious example is learning to type...I've had by far the most fun working with computers in a keyboard-centric environment, mostly because I'm good enough at pressing keys and the computer is good enough at understanding them.

That said, I agree with both you and GP: trying to train a layperson to talk differently based on the quirks of the codec used to encode their voice seems like a poor choice!

Re: Google open-sources the Lyra audio codec

#112

Post by zmix »

pjc50 wrote: post #14

One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.

You mean like: "Buttle" vs. "Tuttle" ?

Re: Google open-sources the Lyra audio codec

#113

Post by ampdepolymerase »

beagle3 wrote: post #95
pjc50 wrote: post #14

One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.

Are you aware that the same exact uncompressed recording sounds different depending on context? This is known as the McGurk effect. Very worth your two minutes if you're not yet familiar with the effect: https://www.youtube.com/watch?v=2k8fHR9jKVM

It would be curious how the court would interpret this. Just wait for the next high profile SEC shakedown.

Re: Google open-sources the Lyra audio codec

#114

Post by nl »

posguy wrote: post #98
miohtama wrote: post #89

If I remember correctly the original landline audio was 64kpbs, 8000 Hz. So Lyra is 1/20 of this. And probably still sounds better.

PCMU/PCMA (G.711μ and G.711a) are not original landline quality audio, but rather what Bell Systems felt they could get away with passing off as a toll quality call in 1972. Lyra will likely sound better, but the reproduction accuracy is apt to be quite a bit poorer as many others have commented. G.711 was created to require nearly no processing (its nearly raw PCM data from a sound card after all) while operating at…

> Is Lyra a significant improvement over modern Opus at 8Kbps?

It is over 6Kbps Opus[1].

> You can buy a Grandstream HT802 analog telephone adapter for ~$30 and its DSP can decode Opus today

A RaspberryPi Zero will provide more than sufficient power for Lyra (it was originally implemented on a Pixel 2). That's ~$10

[1] https://www.cnx-software.com/2021/02/28/lyra-audio-codec-ena...

Re: Google open-sources the Lyra audio codec

#115

Post by [deleted] »

nl wrote: post #114
posguy wrote: post #98

Earlier quoted context omitted.

PCMU/PCMA (G.711μ and G.711a) are not original landline quality audio, but rather what Bell Systems felt they could get away with passing off as a toll quality call in 1972. Lyra will likely sound better, but the reproduction accuracy is apt to be quite a bit poorer as many others have commented. G.711 was created to require nearly no processing (its nearly raw PCM data from a sound card after all) while operating at…

> Is Lyra a significant improvement over modern Opus at 8Kbps? It is over 6Kbps Opus[1]. > You can buy a Grandstream HT802 analog telephone adapter for ~$30 and its DSP can decode Opus today A RaspberryPi Zero will provide more than sufficient power for Lyra (it was originally implemented on a Pixel 2). That's ~$10 [1] https://www.cnx-software.com/2021/02/28/lyra-audio-codec-ena...

[deleted]

Re: Google open-sources the Lyra audio codec

#116

Post by posguy »

nl wrote: post #114
posguy wrote: post #98

Earlier quoted context omitted.

PCMU/PCMA (G.711μ and G.711a) are not original landline quality audio, but rather what Bell Systems felt they could get away with passing off as a toll quality call in 1972. Lyra will likely sound better, but the reproduction accuracy is apt to be quite a bit poorer as many others have commented. G.711 was created to require nearly no processing (its nearly raw PCM data from a sound card after all) while operating at…

> Is Lyra a significant improvement over modern Opus at 8Kbps? It is over 6Kbps Opus[1]. > You can buy a Grandstream HT802 analog telephone adapter for ~$30 and its DSP can decode Opus today A RaspberryPi Zero will provide more than sufficient power for Lyra (it was originally implemented on a Pixel 2). That's ~$10 [1] https://www.cnx-software.com/2021/02/28/lyra-audio-codec-ena...

> It is over 6Kbps Opus[1].

The overhead from packet headers to send data every 40ms is 9.6kbps, is the difference between 12.6Kbps and 17.6Kbps meaningful at that point? We are sending the same number of packets, likely with the same packet loss rate.

> A RaspberryPi Zero will provide more than sufficient power for Lyra

A Raspberry Pi Zero can't run Lyra, as the proprietary math kernel is only offered in compiled form for x86-64 and android-arm64: https://github.com/google/lyra#license

Re: Google open-sources the Lyra audio codec

#117

Post by mark4o »

posguy wrote: post #101
danaliv wrote: post #51

Earlier quoted context omitted.

It's not a kernel module, it's a compute kernel. Nothing to do with operating systems. They provide versions for android-arm64 and linux-x86_64. The fine README says it builds and runs on Ubuntu 20.04.

Ah, so Lyra today will not work on RISC-V, i386, Power, MIPS, lower end or older ARM chips like the Allwinner H3 (very popular in Single Board Computers) and any other new architecture that comes out?

It won't even work on Windows, macOS, or iOS.

Re: Google open-sources the Lyra audio codec

#120

Post by swiley »

pjc50 wrote: post #14

One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? I don't mind compressing a phoneme to as much as I would mind it compressing it to a clearly audible different phoneme.

IMO: the output of machine learning is correlated garbage. This is confusing to most people who are used to programs that implement an algorithm (reminder that "correctness" is part of the definition of an algorithm.)
Post reply on HN