Earlier quoted context omitted.
Then maybe you’re not the target audience
the target audience is practically non-existent. nobody with 40 year old hardware is clamoring for a new audio codec.
Have you heard about IoT and low-end consumer devices?
QOA, the Quite OK Audio Format
71–80 of 83 posts
Re: QOA, the Quite OK Audio Format
#72I made little endian formats and didn't notice any complications.
int quantized = (slice >> 57) & 0x7;
You wouldn't need this shift with a little endian format. If you store samples in order and read them as big endian, the first sample will be in high bits and the last sample in low bits, which is unnatural for shift and mask, that's what I call complication.
Re: QOA, the Quite OK Audio Format
#73Earlier quoted context omitted.
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…
RLE doesn't really work for photos even at 8 bit depth, the noise is noticeable even there. It's mainly useful for drawn/rendered content, where solid colored areas are far more common. That won't be much different at 16 bit depth.
Re: QOA, the Quite OK Audio Format
#74It'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…
I think maybe they are using complexity to mean something other than instructions per second?
Re: QOA, the Quite OK Audio Format
#75Earlier quoted context omitted.
the target audience is practically non-existent. nobody with 40 year old hardware is clamoring for a new audio codec.
Have you heard about IoT and low-end consumer devices?
oh, you mean things like the ESP8266, which costs mere dollars and can definitely can already decode and play MP3s? 40 lines of code to play MP3s on an ESP32 as well.
Re: QOA, the Quite OK Audio Format
#76Earlier quoted context omitted.
Have you heard about IoT and low-end consumer devices?
oh, you mean things like the ESP8266, which costs mere dollars and can definitely can already decode and play MP3s? 40 lines of code to play MP3s on an ESP32 as well.
Yes, there's only chips with a huge community sourced eco system like Espressif out there. Nothing else.
Re: QOA, the Quite OK Audio Format
#77Earlier quoted context omitted.
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…
RLE doesn't really work for photos even at 8 bit depth, the noise is noticeable even there. It's mainly useful for drawn/rendered content, where solid colored areas are far more common. That won't be much different at 16 bit depth.
A possibly better example for photos would be the 8 bit tag that says a pixel is within -2 to +1 in each of RGB. In 8 bit, there are a lot of cases where this is a big enough range to capture the noise of a static color (and or a gradient). In a 16 bit image, a lot of the time there might be 3-4 bits of noise which will mean that the tag is a lot less useful.
Re: QOA, the Quite OK Audio Format
#78Back 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.
Ah misremembered, thanks.
Re: QOA, the Quite OK Audio Format
#79Re: QOA, the Quite OK Audio Format
#80Quite OK article :) A few years ago, a guy made his own video compression format, but I can't find it anymore, is it still available online?
Are you looking for this series of articles? The author makes his own video codec for a video chat app, and has a lot of test videos of faces. https://bengarney.com/2016/06/25/video-conference-part-1-the...
exactly!