6 ms·
Quite OK Audio Format
- dang 3y agoRelated: QOA, the Quite OK Audio Format - https://news.ycombinator.com/item?id=34625573 https://news.ycombinator.com/item?id=34625573 - Feb 2023 (78 comments)
- dryanau 3y agoFeels like it gets posted every other week.
- dang 3y agoThis is an interesting case because it looks like this is the entire list of submissions on the topic: Quite Ok Audio Format Benchmark Results and File Format Specification - https://news.ycombinator.com/item?id=35729036 https://news.ycombinator.com/item?id=35729036 - April 2023 (0 comments) QOA Benchmark Results and File Format Specification - https://news.ycombinator.com/item?id=35721419 https://news.ycombinator.com/item?id=35721419 - April 2023 (0 comments) The Quite OK Audio Format [pdf] - https://news.ycombinator.com/item?id=35203976 https://news.ycombinator.com/item?id=35203976 - March 2023 (1 comment) QOA, the Quite OK Audio Format - https://news.ycombinator.com/item?id=34625573 https://news.ycombinator.com/item?id=34625573 - Feb 2023 (78 comments) A sequence like that, if you happen to see all of the posts, can make a topic feel over-represented, but I'd say this isn't really excessive, wouldn't you? Keep in mind that on HN, reposts are fine if a topic hasn't had significant attention in the last year or so (https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html). In this case there was a major thread back in Feb but I decided not to treat the current post as a dupe because the two articles seemed to differ significantly.
- ComputerGuru 3y agoMaybe it is being confused with the series of posts on the quite ok image format? We had a number of posts on that one. (I don’t mind. The comments are always interesting.)
- ricardobeat 3y agoInteresting find: one of the implementations is written in “Ć”, which transpiles cleanly into multiple languages: https://github.com/pfusik/cito https://github.com/pfusik/cito Haxe comes to mind but this seems a lot simpler.
- nkurz 3y agoLots of discussion from a couple years ago on the Ć Programming Language (although most of it is about the name): https://news.ycombinator.com/item?id=28805825 https://news.ycombinator.com/item?id=28805825
- kevin_thibedeau 3y agostatic inline int qoa_clamp_s16(int v) { if ((unsigned int)(v + 32768) > 65535) { ... } This code is wrong. It assumes int is at least 32-bit which is not true in C. It should either use long or int32_t.
- vardump 3y agoYeah. Bitten me not-too-long-ago...
- ReactiveJelly 3y agoIt's also odd that everything is big-endian, but then the official format is C structures (which will be LE on every PC and phone that would ever run this) And in that C struct.... is `char` and also `uint8_t`. I can never remember if `char` is signed or not. It should be `int8_t` or `uint8_t`. This reminds me of the Farbfeld image format. So simple that I'm content to just make my own little-endian ad-hoc implementation and ignore the official spec.
- kevin_thibedeau 3y ago> I can never remember if `char` is signed or not. char is effectively a trivalent type. Only use it when signedness is inconsequential. This is addressed in C23 with char8_t expressly to avoid the problems that happen with UTF-8 bytes as accidental signed chars.
- audunw 3y ago
- userbinator 3y agoA lossy codec that has only a single bitrate/quality? How does it compare to other lossy codecs in terms of audio quality? All values, including the slices, are big endian. In a world where LE basically won, that's an astonishingly stupid decision --- especially if you care about tiny differences in performance.
- snvzz 3y agoI would argue Big Endian won in network protocols and file formats.
- userbinator 3y agoFor network protocols, that's true only at the lower layers, and largely due to historical reasons. The majority of file formats I've worked with are LE.
- audunw 3y agoBE is still common in very resource constrained applications like microcontrollers. You know, applications where having to do endianess swap actually has a significant impact? Applications where it might actually make sense to use this kind of codec? I was really thankful that Doom WAD file was big endian (side effect of being developed on NeXT?) when I ported doom to an nRF microcontroller.
- hcs 3y agoIf you're exporting assets for a game, and the swap would be significant, shouldn't it really be generating big or little endian depending on the target? Many audio engines do this, using e.g. RIFX on big endian targets and RIFF on little.
- pluijzer 3y agoI believe that in the case with Doom, and many other games that released there code as open source; the game assets are not in public domain and remain closed.
- KerrAvon 3y agoWhy is this approach better than adding an extension with the same compression scheme to AIFF?
- hcs 3y agoI guess because the implementations aren't intending to support a lot of different input codecs, so there's no benefits to the flexibility of AIFF/AIFC. Also avoids having to deal with an 80-bit extended precision float just for the sample rate.
- JD557 3y agoHijacking this comment in case you (or someone from HN) knows. Is there any particular reason that AIFF uses an 80-bit extended float precision for the sample rate, instead of a 32-bit integer like WAVE? I assume this was an oversight at the time, but I'm curious if there are actual applications where sub-Hz (or 2^32Hz) precision is needed.
- snvzz 3y agoHow well does it handle less bit depth? (like 8 bit) What about lower sample frequency? (such as 28kHz) If it could scale down, it'd be extremely useful for new productions for "retro" platforms.
- atoav 3y agoIf I had to guess the codec isn't meant to handle this well. To me this looks like a codec that wins because it is optimized for one specific use case (when you need "quite ok" audio on a modern day platform. It could be that it handles slower sampling rates well, but I am not sure about the bits.
- snvzz 3y agoFrom a glance at the 1-page PDF, it seems freq is variable, but depth is hardcoded to 16bit.
- CameronNemo 3y agoSemi-relatedly, is there anyone working on hardware encoders or decoders for audio codecs that are plausibly patent-free (e.g. mp3, vorbis, flac, opus)? AIUI decoding for some of these formats can be a battery drain, particularly for devices with tiny batteries like ear buds, watches, ipod nanos.
- deleted 3y ago[deleted]
- hcs 3y agoLooks like this fixes the issue raised in the last discussion [1] by no longer re-quantizing the decoder state at the start of every frame. I still think it's not worth the extra complexity over a simpler fixed set of second order linear predictors like BRR or ADX, though that clocks in at over 4 bits per sample. Might still be ok with 3 and more predictors? Regarding clamping, might it be better to require the encoder to never generate QOA that would overflow? I've seen at least one ADPCM implementation (GameCube "AFC") that takes this approach. Seems like it wouldn't produce more distortion than clipping would. [1] https://news.ycombinator.com/item?id=34630543 https://news.ycombinator.com/item?id=34630543
- bradrn 3y agoSee also, the Quite OK Image format: https://qoiformat.org/qoi-specification.pdf https://qoiformat.org/qoi-specification.pdf (discussed previously at https://news.ycombinator.com/item?id=34035024 https://news.ycombinator.com/item?id=34035024).
- bentt 3y agoI came here to say the extension should be .QOK and pronounced “kwok” and that’s that.