Live data from Hacker News

Google open-sources the Lyra audio codec

opensource.googleblog.com

81–90 of 145 posts

Re: Google open-sources the Lyra audio codec

#81
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.

> Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers?

That was perfectly ordinary compression?

The phenomenon is all over the place, most visible in autocorrect.

Re: Google open-sources the Lyra audio codec

#82
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.

> Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? That was perfectly ordinary compression? The phenomenon is all over the place, most visible in autocorrect.

It was ordinary compression, something called JBIG2. It did not mistranscribe, but mark slightly different number or character blocks as same, resulting replaced parts in images.

In other words, its match tolerance is a bit too lax, so it get poisoned by blocks in its own dictionary, thinking it already has the blocks for things it had just scanned.

More details can be found in [0] and [1].

[0]: https://www.theregister.com/2013/08/06/xerox_copier_flaw_mea...

[1]: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...?

Re: Google open-sources the Lyra audio codec

#83
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.

> Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers? That was perfectly ordinary compression? The phenomenon is all over the place, most visible in autocorrect.

Yes! This is why I always turn off autocorrect! It’s true that I absolutely make more typos without it, but at least they’re obvious as typos, and not different words that potentially change the meaning of the sentence.

Re: Google open-sources the Lyra audio codec

#84
Another reason for end-to-end speech encryption: to keep your cleartext voice signal away from these overaggressive codecs changing the words. I can understand the need for a super low bandwidth codec on top of Mt. Everest, but 64 kbit PCM was good enough for our grandparents' landlines (or 13 kbit GSM for their mobiles) and it's good enough for us.

Re: Google open-sources the Lyra audio codec

#85

In practical terms, very impressive. Anyone know what latency is like? Feels a domain where people who have not experienced low latency full duplex cannot fully appreciate why voice has faded in everyday life...

Sounds like at least +40ms of latency:

> features, are extracted in chunks of 40ms, then compressed and sent over the network

Re: Google open-sources the Lyra audio codec

#86
Doesn't seem that better compared to Codec2 which is already fully Open Source (LGPL), even taking into account that Codec2's examples originals are already of much worse quality than the ones on Lyra's website. I'd be curious to hear both working on the same set of audio samples.

https://www.rowetel.com/?page_id=452

Re: Google open-sources the Lyra audio codec

#87
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.

[disclaimer: Personal opinion, not that of my employer.]

I had a coworker play me before/after of an early version of the codec "babbling" and it was definitely uncanny valley. It looks like some work has been done on the problem since then.

The second paper linked in the README.md of the repo talks about talks about a few strategies to reduce 'babbling' or 'babble'. For your reference, here's the citation and the link to the PDF.

Denton, T., Luebs, A., Lim, F. S., Storus, A., Yeh, H., Kleijn, W. B., & Skoglund, J. (2021). Handling Background Noise in Neural Speech Generation. arXiv preprint arXiv:2102.11906.

https://arxiv.org/pdf/2102.11906.pdf

Re: Google open-sources the Lyra audio codec

#88

Another reason for end-to-end speech encryption: to keep your cleartext voice signal away from these overaggressive codecs changing the words. I can understand the need for a super low bandwidth codec on top of Mt. Everest, but 64 kbit PCM was good enough for our grandparents' landlines (or 13 kbit GSM for their mobiles) and it's good enough for us.

What a spectacular failure of imagination. Why change anything ever, right? I supposed dial-up modems were good enough for you too.

Everyone is imagining that codecs like this will "change your words" but no-one has provided examples of that actually happening. I don't believe it.

Re: Google open-sources the Lyra audio codec

#90
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.

Back when Lyra was announced [0], I listened to the released samples and it changed an "m" sound to an "l" sound.

[0]: https://news.ycombinator.com/item?id=26309553

Post reply on HN