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 compression and 470KB for decompression, which are small enough that I don't even minify them.
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 SIMD optimizations, which would improve performance even more. Still on my todo list.
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.
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.
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.
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.
One fairly significant advantage is seek-ability. I can see it being really useful for a game to just dump all of their audio into a single file and specify which clip with just a start and end frame.
That is indeed commonly done in games. Egosoft's X series had (has?) just one massive 8+ hour, 128kbps MP3 file with all voice clips in the game, and just seeks to the needed position.
The games also used DirectAudio or some other horrible mess that relied on registering codecs to the OS, so one of the most common tech support complaints was that the game didn't play any voices (regular SFX were uncompressed WAV), because the user only used media players that bypassed Windows' central codec registry.
Re-encoding everything to WMA (guaranteed to be a registered codec) was suggested several times to management, but since they all used Windows Media Player with properly registered codecs, they never really got the severity of the problem, and didn't care that the fix would cost them nothing (the community had already done all the re-encoding work). I imagine it got changed later, when the games were ported to other OSes, but I had left by that point. (And my NDA expired a long time ago, too.)
So, yes, something like QOA that you can just drop into any C(++) codebase, as games tend to be, without licensing problems or run-time overhead, would have been really, really useful 20 years ago. The file size differences might have been a headache in the CD games era, but by the time DVDs became standard it wouldn't have been a problem.
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.
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.
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.
It's an important difference if you're trying to predict how browsers will behave in the future. They're generally very conservative about removing platform features that people depend on, but this doesn't cover plugins.
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.
This looks interesting! Do you have a link to the source code of the opus encoder and decoder? The code in the github repo (html/opusjs/decoder.js) looks generated and is hard to understand.
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.
[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 compression and 470KB for decompression, which are small enough that I don't even minify them.