[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.
[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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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/Web/Media/Formats/A...
Flash?
Flash used to run on every standard browser.
Now it doesn't exist.
Beyond API shifts, there are constant regressions and incompatibilities across browser implementations, especially in rich media APIs like image, audio, and video.
(Normally this would be in the commit description but it looks like we forgot to include that https://github.com/jeffkaufman/bucket-brigade/commit/d96b6f3...)
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.