Live data from Hacker News

The Quite OK Audio Format for Fast, Lossy Compression

qoaformat.org

41–50 of 65 posts

Re: The Quite OK Audio Format for Fast, Lossy Compression

#41
post #4
post #3

Earlier quoted context omitted.

> QOA is slower than ADPCM, doesn't compress as much as MP3 and sounds worse than FLAC (duh). But I believe it fills a gap that was worth filling.

MP3 compression is very fast on modern hardware. This may have a niche for low power devices, especially if they are battery constrained.

"very fast" could mean many different things that vary by orders of magnitude

in https://phoboslab.org/log/2023/04/qoa-specification he got ffmpeg on one core of an i7-6700k (which is arguably 'modern hardware') to encode a 9807-second file in mp3 in 146.2 seconds, 67× faster than real time. but qoa was 25.75 seconds, 5.7 times faster than that. qoa decoding was 2.5× as fast as dr_mp3

you can imagine situations where reducing the number of audio encoding servers in your audio encoding cluster by a factor of 6 would be a big win, or where you want to encode 100+ audio streams in real time on your laptop (maybe an sdr tuned to every am radio station at once), but i agree with you that battery-constrained devices are a more likely application area: making your audio recorder battery last twice as long is a much bigger win

Re: The Quite OK Audio Format for Fast, Lossy Compression

#43
post #4

Earlier quoted context omitted.

MP3 compression is very fast on modern hardware. This may have a niche for low power devices, especially if they are battery constrained.

It's probably something we ( https://overte.org/ ) can use. We have a 3D environment with spatial audio. Audio is encoded server-side, and since it's spatial everyone needs their own mix. We're using Opus, and audio encoding turns out to be the usual limiting factor on small servers. So this kind of thing is exactly up our alley: an alternate option that uses less CPU than Opus, but consumes less bandwidth than raw a…

I'm curious, why encode audio server-side? Other games in this genre I've seen seem to have clients do encoding/decoding, and do the spatial audio clientside, with the server just passing each user's audio and position data along from client to client. Especially in VR where ideally there should be no latency between turning your head and the audio shifting. Are there any reasons to do this on the server, or am I misunderstanding something?

Re: The Quite OK Audio Format for Fast, Lossy Compression

#44

What is the tradeoff there?

That in terms of quality per any bitrate it comes nowhere near ubiquitous formats like AAC or MP3 when produced with good encoders. But it's good to have (possibly) patent-free solutions available.

MP3 patents expired a long time ago, no?

Re: The Quite OK Audio Format for Fast, Lossy Compression

#45
post #5

What is the LFE channel? It should be spelled out explicitly, but I figured out the rest L-Left,R-Right,C-Center,FL-Front Left,FR-FrontRight,SL-SideLeft,SR-SideRight,BL-BackLeft,BR-BackRight --- Edit: LFE-LowFrequencyEffects... so subwoofer? https://www.dolby.com/uploadedFiles/Assets/US/Doc/Profession...

LFE audio channel is different from subwoofer output.

Subwoofers come with multichannel audio systems in which directional speakers usually can't cover the lower range of audio frequencies. They are responsible for bass content from all channels, and get it from software or hardware crossover filter which is independent from specific input formats. Placement of low frequency speaker does not matter much because of human perception.

LFE track is an additional effects channel for movie theaters and similar amusement rides in which audio system plays low frequencies from other channels just fine. Dedicated LFE emitter then adds rattling and other wub-wub effects without overloading audio speakers with all that extra energy. Movies that lack car chases and explosions routinely have completely silent LFE tracks.

Re: The Quite OK Audio Format for Fast, Lossy Compression

#47

Earlier quoted context omitted.

It does, and I've tried tweaking that, but the performance difference isn't very significant. I appear to be able to get maybe 30% better performance -- pretty nice, but not nearly big enough especially on low end servers.

I'm not sure much gets better latency than Opus but LyraV2 seemed interesting https://opensource.googleblog.com/2022/09/lyra-v2-a-better-f...

Lyra is a speech-only codec, so it's apples and oranges to compare with Opus for general-purpose audio compression.

Re: The Quite OK Audio Format for Fast, Lossy Compression

#48
post #38

Earlier quoted context omitted.

I guess you mean this one: https://patents.google.com/patent/US5812672 That was an USA patent from Fraunhofer, who made quite some cash from mp3 license fees (100 000 000€ according to Wikipedia).

No. The claim that there are no patents in Germany on this stuff is common internet misinformation(*). There are a great many coding patents from Fraunhofer all around the world, including in Europe. Presumably because it's much easier to get injunctive relief in Germany I've seen more codec related litigation there than anywhere else. (*) Like many pieces of misinformation it has its roots in a seed of truth: Partic…

>2014 (CLS v Alice)

https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern... - this?

>The patents were held to be invalid, because the claims were drawn to an abstract idea, and implementing those claims on a computer was not enough to transform that abstract idea into patentable subject matter.

Re: The Quite OK Audio Format for Fast, Lossy Compression

#50
post #38

Earlier quoted context omitted.

No. The claim that there are no patents in Germany on this stuff is common internet misinformation(*). There are a great many coding patents from Fraunhofer all around the world, including in Europe. Presumably because it's much easier to get injunctive relief in Germany I've seen more codec related litigation there than anywhere else. (*) Like many pieces of misinformation it has its roots in a seed of truth: Partic…

>2014 (CLS v Alice) https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern... - this? >The patents were held to be invalid, because the claims were drawn to an abstract idea, and implementing those claims on a computer was not enough to transform that abstract idea into patentable subject matter.

Yep.
Post reply on HN