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

QOA, the Quite OK Audio Format

phoboslab.org

Post reply on HN
Print view View original

61–70 of 83 posts

Re: QOA, the Quite OK Audio Format

#61

Post by hcs »

phoboslab wrote: post #46
ogurechny wrote: post #31

Nice, but if 24_tuba_arpegio_melodious_phrase_stereo on the samples page is not a conversion error, it might explain why at least basic psychoacoustic model and/or post-processing filter are expected. That static beat is noticeable precisely because of its repetition.

Good catch! That's likely an artifact of the LMS state being quantized[1] at every frame border. I will look for ways to improve this. [1] https://github.com/phoboslab/qoa/blob/master/qoa.h#L324-L336

Given how large the frames are in QOA, it doesn't seem like too much overhead to have the full history and weights stored per frame (if seeking to any frame is required).

Re: QOA, the Quite OK Audio Format

#62

Post by mprime1 »

bsder wrote: post #59
phoboslab wrote: post #26

Earlier quoted context omitted.

Curiosity mostly. As stated in the article, Opus is excellent and better than QOA in every way except in complexity (and as a result, performance). A possible application for QOA is games, where you need to play dozens of audio files immediately. I haven't done any formal benchmarks, but with a simple `time` on the command line QOA encodes 10x faster and decodes 7x faster than Opus. QOA should be quite suitable for S…

> (and as a result, performance) Citation, please. Opus (at that time it was called CELT) does have more resource requirements in terms of memory than an MP3 decoder. However, I have run the decoder on things as small as a 33MHz ARM7 and still had lots of CPU left over. An MP3 decoder had no hope on that system.

> (and as a result, performance)

> Citation, please

The parent did provide some data. Admittedly very simple.

Couls you try a different simple benchmark that shows the opposite?

That would be interesting.

Re: QOA, the Quite OK Audio Format

#63

Post by nigeltao »

phoboslab wrote: post #26
jefftk wrote: post #18

It's not clear to me why Opus doesn't meet their needs. They write it off for not being simple, but is the problem that it's too slow for their application? Are they doing something where they need a very small compiled size [1]? Aesthetically prefer things that are simpler? [1] I ship an Opus encoder and decoder to the browser to support https://www.jefftk.com/p/bucket-brigade-singing and it's just 310KB for compres…

Curiosity mostly. As stated in the article, Opus is excellent and better than QOA in every way except in complexity (and as a result, performance). A possible application for QOA is games, where you need to play dozens of audio files immediately. I haven't done any formal benchmarks, but with a simple `time` on the command line QOA encodes 10x faster and decodes 7x faster than Opus. QOA should be quite suitable for S…

I'd be curious to know if SIMD cares about the big-endian design decision. You can always do SIMD shuffles near where you load and store the bytes, but it'd be simpler and probably faster if you don't.

Similarly, BSWAP / MOVBE might be cheap or free on x86_64 but IIUC RISC-V doesn't guarantee a dedicated instruction for that (and RISC-V is little-endian). "Does [endianness] really matter?" It might, for embedded devices a few years from now. I can't really say without real hardware to get real CPU profiles. But that question is entirely avoidable by just picking little-endian.

Re: QOA, the Quite OK Audio Format

#64

Post by nullc »

phoboslab wrote: post #26
jefftk wrote: post #18

It's not clear to me why Opus doesn't meet their needs. They write it off for not being simple, but is the problem that it's too slow for their application? Are they doing something where they need a very small compiled size [1]? Aesthetically prefer things that are simpler? [1] I ship an Opus encoder and decoder to the browser to support https://www.jefftk.com/p/bucket-brigade-singing and it's just 310KB for compres…

Curiosity mostly. As stated in the article, Opus is excellent and better than QOA in every way except in complexity (and as a result, performance). A possible application for QOA is games, where you need to play dozens of audio files immediately. I haven't done any formal benchmarks, but with a simple `time` on the command line QOA encodes 10x faster and decodes 7x faster than Opus. QOA should be quite suitable for S…

Encoder speed in opus is configurable. If you're comparing performance with something less space efficient you probably should be setting the encoder at the fastest setting. :)

Though of course, it's no shock that something simple could be fast. There are also lossless codecs which are much faster to decode than opus.

Re: QOA, the Quite OK Audio Format

#65

Post by nayuki »

> All in all FLAC is not a complicated format. Not quite 400-lines-simple, but far from the complexities of Opus.

Actually, FLAC is under 400-lines-simple.

> This is my independent implementation FLAC, optimizing the code for clarity to a human reader. The decoder is implemented in about 300 lines of source code, and the encoder in ~200 lines.

-- https://www.nayuki.io/page/simple-flac-implementation

Re: QOA, the Quite OK Audio Format

#66

Post by rasz »

jefftk wrote: post #18

It's not clear to me why Opus doesn't meet their needs. They write it off for not being simple, but is the problem that it's too slow for their application? Are they doing something where they need a very small compiled size [1]? Aesthetically prefer things that are simpler? [1] I ship an Opus encoder and decoder to the browser to support https://www.jefftk.com/p/bucket-brigade-singing and it's just 310KB for compres…

Diagram at the beginning of the article putting Opus at over 2x computation complexity of mp3 is misleading (if not outright wrong). Opus is lighter than mp3 while delivering similar fidelity at almost half the bitrate.

Opus decoding consumes ~10MHz of modern CPU core per one 128kbit stereo full-band track, or ~30MHz of Armv8. This translates to Raspberry pi3 at 1.2GHz decoding ~30 stereo tracks in parallel on single core.

Re: QOA, the Quite OK Audio Format

#67

Post by bsder »

mprime1 wrote: post #62
bsder wrote: post #59

Earlier quoted context omitted.

> (and as a result, performance) Citation, please. Opus (at that time it was called CELT) does have more resource requirements in terms of memory than an MP3 decoder. However, I have run the decoder on things as small as a 33MHz ARM7 and still had lots of CPU left over. An MP3 decoder had no hope on that system.

> (and as a result, performance) > Citation, please The parent did provide some data. Admittedly very simple. Couls you try a different simple benchmark that shows the opposite? That would be interesting.

Opus can encode a packet in real-time at 10ms per packet at 48kHz using a 66MHz MIPS32 chip. Decode is even faster and can be done on a 33MHz ARM7 with CPU left over. Decode of Opus (nee CELT) is sufficiently fast that you can unpack it in real-time on an audio thread callback on Android.

TOA is citing about 300kilobits per second which is roughly 30kilobytes per second which is too much data for a 33MHz ARM7 to be able to process let alone do anything to it.

The reason for "The Triangle of Neglect" is that your chips are either under 100Mhz (often significantly as you are on bare metal) and this is too much data or above 1000MHz (you are running Linux) and nobody cares.

ADPCM was more useful back when chips didn't have hardware multipliers.

Re: QOA, the Quite OK Audio Format

#69

Post by weepy »

bartwe wrote: post #7

Very interesting, when better formats like vorbis were too cpu intensive for my game I ended up with striped and delta encoded wav compressed using lz4hc for something that was somewhat compressed, streamable and light on the cpu, this seems somewhat close to that.

what is delta encoded ? ADPCM ?
Post reply on HN