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

51–60 of 83 posts

Re: QOA, the Quite OK Audio Format

#51

Post by ant6n »

skrebbel wrote: post #35

Back in the day I made a few GameBoy Advance demos and we generally stored ADPCM encoded audio streams for the music, at like 4x the space of an equivalent MP3. Thing is, cartridge space was effectively uncapped but CPU speed (4MHz iirc) was very limited. If we had gone for MP3 (or even a reasonably complex tracker module), we’d hardly have had any CPU left for the visuals. QOA would have likely been the perfect alte…

GBA has a 16MHz 32-Bit Arm. The Game Boy original had a 4Mhz 8-bit cpu (but it really only ran at 1Mhz, since all instructions took a multiple of 4 clock cycles).

But yes, not quite fast enough for mp3.

Re: QOA, the Quite OK Audio Format

#52

Post by jll29 »

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…

Aesthetically, intellectually and scientifically (Occam's razor), a simpler method is a better method, because one shows to have understood the essence of the problem or natural phenomenon that has been modelled.

From a software point of view, more complex methods are also more prone to implementation error. Dominic's post is not opposed to Opus or the other formats, but argues (to me, convincingly) there is a valid spot on the map of audio formats for very simple format that still has more decent audio quality than other very simple formats. The result has compact file sizes, rapid decode times and still sounds well.

EDIT: The post is a good educational read (as any good software developer IMHO should aspire to creating simple code), initially and/or eventually. His other posts (e.g. the one on his Pagenode CMS) also show this simplicity-seeking mind set.

Re: QOA, the Quite OK Audio Format

#53

Post by jefftk »

Turing_Machine wrote: post #50
jefftk wrote: post #40

Earlier quoted context omitted.

> the native APIs builtin to browsers have a tendency to shift every few years The web platform is incredibly backwards compatible; I'm having trouble thinking of any cases where they've dropped a format (which doesn't mean there aren't any!) On the other hand, while the browsers generally ship with many codecs [1] the APIs for interacting with them are pretty terrible. [1] https://developer.mozilla.org/en-US/docs/We…

> I'm having trouble thinking of any cases where they've dropped a format Flash?

Flash was a plugin, not a "native API built into browsers".

Re: QOA, the Quite OK Audio Format

#55

Post by creshal »

adgjlsfhk1 wrote: post #45
creshal wrote: post #44

Earlier quoted context omitted.

I wonder how much complexity it would add to support 10 or 16 bit per channel in the file format.

you'd have to totally redesign the format. QOI is very specialized on 8 bits per channel (and RGBA)

The physical layout, sure, but would it conceptually involve more than just defining twice as large chunk types for 16 bit channels? Unless I'm missing something, it should be fairly uncomplicated code-wise?

Re: QOA, the Quite OK Audio Format

#56

Post by [deleted] »

phoboslab wrote: post #21
Jasper_ wrote: post #16

Earlier quoted context omitted.

Yeah, I don't understand the disparaging of 4-bit ADPCM as being terrible quality when this is effectively a 3-bit ADPCM. Most ADPCM codecs I've seen shipped have a similar table based system with a frame header with coefficients for your two history samples rather than the weight update scheme here, and it works quite well.

Traditional ADPCM is not terrible, it's just "meh". Compare: - Original, 4039kb: https://phoboslab.org/files/qoa-samples/adpcm_comp/orig.wav - MS ADPCM, 1022kb: https://phoboslab.org/files/qoa-samples/adpcm_comp/ms_adpcm.... - QOA, 812kb: https://phoboslab.org/files/qoa-samples/adpcm_comp/qoa.wav IMA ADPCM is in the same ballpark as MS ADPCM. ADX (not listed) comes close to QOA, but at 1136kb is also larger than thos…

[deleted]

Re: QOA, the Quite OK Audio Format

#57

Post by nyanpasu64 »

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…

One factor I'm not sure I'd relevant to games, is that psychoacoustic codecs are specialized for a specific sampling rate, and may have audible artifacts if the sound is repitched. Whether these artifacts are better or worse than ADPCM distorting audio (especially treble) is another question.

Re: QOA, the Quite OK Audio Format

#58

Post by adgjlsfhk1 »

creshal wrote: post #55
adgjlsfhk1 wrote: post #45

Earlier quoted context omitted.

you'd have to totally redesign the format. QOI is very specialized on 8 bits per channel (and RGBA)

The physical layout, sure, but would it conceptually involve more than just defining twice as large chunk types for 16 bit channels? Unless I'm missing something, it should be fairly uncomplicated code-wise?

Not really. QOI's opcodes are very specifically designed based on the characteristics of 8 bit images. For example, there is an 8 bit opcode for a run of up to 64 identical pixels. This makes a lot of sense for an 8 bit image, but is a lot less likely to appear in a 16 bit picture. For a 16 bit photo, the minimal QOI modification would almost certainly be worse than uncompressed since noise in the sensor will prevent any of the 8 bit opcodes from working.

Re: QOA, the Quite OK Audio Format

#59

Post by bsder »

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…

> (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.

Re: QOA, the Quite OK Audio Format

#60

Post by mattdesl »

jefftk wrote: post #40
mattdesl wrote: post #37

Earlier quoted context omitted.

I'm interested this for JS. Most codecs are either patent-heavy or hugely complex (requiring hundreds of kilobytes of WebAssembly), and a lot of the native APIs builtin to browsers have a tendency to shift every few years. It would be nice to have a pure JS alternative to WAV that provides some file reduction.

> the native APIs builtin to browsers have a tendency to shift every few years The web platform is incredibly backwards compatible; I'm having trouble thinking of any cases where they've dropped a format (which doesn't mean there aren't any!) On the other hand, while the browsers generally ship with many codecs [1] the APIs for interacting with them are pretty terrible. [1] https://developer.mozilla.org/en-US/docs/We…

WebAudio has had a couple: e.g. user gesture requirement which has broken many websites, and even things as simple as using AudioContext to decode a WAV file to a buffer. Another one is script processor nodes.

Beyond API shifts, there are constant regressions and incompatibilities across browser implementations, especially in rich media APIs like image, audio, and video.

Post reply on HN