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.
Google open-sources the Lyra audio codec
21–30 of 145 posts
Re: Google open-sources the Lyra audio codec
#22Encoding takes >40ms? Opus takes 5-26.5ms. Apparently 150ms[1] is the generally accepted upper bound for call latency. I think the article could do with some bandwidth/quality/latency/power comparisons to other codecs. [1] https://en.wikipedia.org/wiki/Latency_(audio)
Ya I was just coming here to say the same thing. 40ms _just in the codec_ feels like a lot. Because that's not even including time to pull in audio from the hardware (could be 20ms or more in Android devices), time to upload, and time to have it across the Internet, and then time to decode + play on the receiver. That adds up pretty quickly. I'm guessing 40ms was chosen because it is some sweet spot of having enough…
From my understanding the 40ms is just the feature extraction part. The encoding also does quantization, which surely adds to this number.
Re: Google open-sources the Lyra audio codec
#23Since this is explicitly targeted at "the next billion users," do we have any sense of how well-optimized this is on non-English audio corpuses? I can't imagine that a model trained primarily on English/Western phonemes would perform as well on the rest of the world.
Re: Google open-sources the Lyra audio codec
#24One 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.
The OCR issue was the first thing I thought about. Machine learning is probabilistic, not deterministic, so in the case of S being converted to 5 (or 6 to 8, etc.), which definitely impacts numerical data in the case of the OCR stuff, we can expect similar voice mis-classifications. Perhaps "You're fine" might get misclassified as "you're fired".
Re: Google open-sources the Lyra audio codec
#25I've been waiting for an audio codec that could actually silently change the words I've said.
https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
Re: Google open-sources the Lyra audio codec
#26One 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.
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.
Re: Google open-sources the Lyra audio codec
#27Why is the demo link towards the bottom of the post pointing to the Basis Universal repository (which is a texture compressor)?
https://github.com/BinomialLLC/basis_universal/tree/master/w...
Copy-pasta error, or did they run the post through Lyra? ;)
Re: Google open-sources the Lyra audio codec
#28It looks like "the model" has 5MB worth of coefficients so it is no problem fitting it into phones, ham radios, etc.
(Radio hams badly need a good digital speech codec for VHF/UHF operation)
Re: Google open-sources the Lyra audio codec
#29Earlier quoted context omitted.
>These speech attributes, also called features, are extracted in chunks of 40ms, then compressed and sent over the network. So while Encoding doesn't take 40ms, the latency + encoding will indeed be 40ms+. 150ms is the End to End Latency, which is basically everything from Encoding + Network + Decoding. We cant beat the speed of light on our fibre network. We can certainly do something with Encoding and Decoding. And…
> We cant beat the speed of light on our fibre network. Speed of light in what? We can absolutely be faster than fibre optics, which are quite slow relatively speaking (2/3rds that of light in a vacuum).
We wont be replacing Glass Fibre with Vacuum Fibre anytime soon. And I have been following this tech for long, but I do wish I am very wrong.
Re: Google open-sources the Lyra audio codec
#30Since this is explicitly targeted at "the next billion users," do we have any sense of how well-optimized this is on non-English audio corpuses? I can't imagine that a model trained primarily on English/Western phonemes would perform as well on the rest of the world.
They say they tested it on 70+ languages.