In the side by side comparisons I've seen between opus and lyra at 6kbps, lyra sounds remarkably better.
Google open-sources the Lyra audio codec
121–130 of 145 posts
Re: Google open-sources the Lyra audio codec
#122Earlier 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...
> > You can buy a Grandstream HT802 analog telephone adapter for ~$30 and its DSP can decode Opus today
almost entirely irrelevant if you're making calls to or from the PSTN, since your SIP trunking provider most likely only supports G.711 alaw/ulaw, or even if they support you handing them a call as G.722 or any other codec, their upstreams almost certainly don't support anything other than G.711.
Re: Google open-sources the Lyra audio codec
#123Earlier quoted context omitted.
> 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 fo…
> is the difference between 12.6Kbps and 17.6Kbps meaningful at that point
It is when you are sending video as well. One of the stated purposes of this work is to enable video conferencing over 56Kbps dial up modems.
> 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
How annoying! Still - the point is that hardware capability isn't likely to be the issue.
Re: Google open-sources the Lyra audio codec
#124My immediate thought: train a Transformer (or Tacotron2) that transforms text to the encoded Lyra codes... And, we will finally have a good real-time open-source text-to-speech system running on mobile devices.
Re: Google open-sources the Lyra audio codec
#125Earlier quoted context omitted.
This one too: https://petapixel.com/2020/08/17/gigapixel-ai-accidentally-a...
Thats not a compression algorithm
A supersampling algorithm is a (de)compression algorithm. You give it an image and it gives you an "decompressed" image. It's not a very good one though.
Re: Google open-sources the Lyra audio codec
#126Earlier 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...
Isn’t the Pixel 2 much more powerful than a Raspi Zero?
Re: Google open-sources the Lyra audio codec
#127Does anyone know how it compares to Codec2? Opus is great down to ~12kbps but Codec2 is the real contender down at the bottom. And I bet it uses way less CPU than Lyra
Re: Google open-sources the Lyra audio codec
#128"Please note that there is a closed-source kernel used for math operations that is linked via a shared object called libsparse_inference.so. We provide the libsparse_inference.so library to be linked, but are unable to provide source for it. This is the reason that a specific toolchain/compiler is required.* - README
Yes, that will have to be removed as part of the effort of porting it to new platforms.
Any idea why this is proprietary? Is it third party? The only references I find online to "libsparse" is an MIT-licensed Python library.
Re: Google open-sources the Lyra audio codec
#129Re: Google open-sources the Lyra audio codec
#130One 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 problem with JBIG2 and why it mistranscribed is that it worked by average error, instead of something sensible like maximum error.