Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Quite OK Audio (QOA)... anyone ? (Read 13302 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Quite OK Audio (QOA)... anyone ?

Reply #25
...
SIMD: yes, the algorithm doesn't seem to be very friendly to SIMD optimizations. I tried writing some intrinsics and only made it slower than my compiler's -O3. The problem is manly that the prediction needs a horizontal accumulation of all 4 weights * history and these are bog slow on x86. Updating the LMS state every sample in itself isn't too bad. On my aging i7-6700k decoding sits at around 3500x realtime (one thread). I'm still looking for ways to make it faster.
...
Would you mind sharing even if it's slower? I'm not competent with intrinsics and only just started an AVX2 port attempt. Used _mm256_madd_epi16 to do the multiply and half the gather, _mm256_hadd_epi32 to finish the gather. The goal is to be able to decode 4 channels at once with AVX2 (either 4 frames or more likely 2 dual channel frames for better memory locality). Currently researching how to vectorise the qoa_dequant_tab lookup, apparently shuffle instructions can be used for small lookup tables but no idea if qoa_dequant_tab fits that criteria or how to go about it yet.


Re: Quite OK Audio (QOA)... anyone ?

Reply #27
@john33 - any chance you could make a compile of QOA that also support input of wav, mp3, flac & qoa as the binary encoder you compiled earlier suggests?

Re: Quite OK Audio (QOA)... anyone ?

Reply #28
Noise shaping: there's an experimental branch where I implemented some very simplistic noise shaping. code here. I made a comparison page with all test samples with and without this noise shaping: https://phoboslab.org/files/qoa-samples/noiseshaping.html – The difference in 32_triangles-triangle_roll_stereo is night and day.

Great, moving quantization noise from lower to higher seems to work in 32_triangles-triangle_roll_stereo.
I believe that the high freq metallic sound of the triangle is good at masking the higher freq sound, so this conceals the now-higher quantization noise well. Lower-freq quantization noise is reduced, where this is more audible in this particular sample.
Can't we do it adaptively, so that quantization noise is moved to the insensitive part of the frequency due to auditory masking; for example, when the content is louder in lower freq, you move the quantization noise from higher to lower, so that we won't hear the hisses... sound. It is the typical case.

Re: Quite OK Audio (QOA)... anyone ?

Reply #29
Wouldn't doing all that make the encoding way more complex and computationally expensive?
Though that seems like it's probably OK in a lot of use cases for something like this, at least within reason

Re: Quite OK Audio (QOA)... anyone ?

Reply #30
Indeed, the noise shaping should be done adaptively, and indeed, it does come with a complexity overhead in the encoder. In my Master's thesis around 2007, I designed an ADPCM codec very similar to this one (but not operating on quadruples of samples IIRC), which used two noise shaping filters - a fixed highpass-like one (quite like QOA's experimental one) and a signal adaptive one (using a LPC filter). My supervisor and I wrote a freely available DAFx paper on it, which you can still find at

http://legacy.spa.aalto.fi/dafx08/papers/dafx08_40.pdf

Since then I found this dual fixed/adaptive shaping approach  to be very useful and performant. I even implemented such a psychoacoustic approach in the exhale encoder.

Chris
If I don't reply to your reply, it means I agree with you.

Re: Quite OK Audio (QOA)... anyone ?

Reply #31
I have never compiled for Windows so I am wondering if someone would like to compile QOA encoder with noise shaping to test out? Thanks in advance.

Re: Quite OK Audio (QOA)... anyone ?

Reply #32
Nevermind. I managed to not be lazy so I figured it out.

Re: Quite OK Audio (QOA)... anyone ?

Reply #33
@john33 - any chance you could make a compile of QOA that also support input of wav, mp3, flac & qoa as the binary encoder you compiled earlier suggests?
A little late in the day, but here is a compile with noise-shaping, and mp3 and flac input enabled (64bit compile). ;)

https://www.rarewares.org/files/QOAconv.zip

Re: Quite OK Audio (QOA)... anyone ?

Reply #34
@john33 - any chance you could make a compile of QOA that also support input of wav, mp3, flac & qoa as the binary encoder you compiled earlier suggests?
A little late in the day, but here is a compile with noise-shaping, and mp3 and flac input enabled (64bit compile). ;)

https://www.rarewares.org/files/QOAconv.zip

Thnx a lot John :)


Re: Quite OK Audio (QOA)... anyone ?

Reply #36
Interesting codec. Sounds quiet nice actually. Would it be possible to make this support hybrid mode with a lossless correction layer?

Re: Quite OK Audio (QOA)... anyone ?

Reply #37
I'd be interested to see someone better at this and more patient than me ABX this.

Complexity-focused codecs are currently a weak suit on HA comparison, because they will always lose on bitrate (save for some major theoretic breakthrough).

Perhaps someone can come up with a more concrete version of the comic sans complexity vs bitrate chart: complexity can be quantified by hyperfine, quality quantified by GstPEAQ (it's okay), and bitrate is, well, already quantified. Then we can chart a "pareto frontier" of say bitrate-complexity for a given quality.


Re: Quite OK Audio (QOA)... anyone ?

Reply #38
On a different note, the specification was set and published late April (between replies #30 and #31).
Fits a single page: https://qoaformat.org/qoa-specification.pdf
Blog post announcement with an impressive but not-too-rigorous speed test: https://phoboslab.org/log/2023/04/qoa-specification

(Hm, how come ffmpeg can decode AAC faster than other formats? Better code?)

Re: Quite OK Audio (QOA)... anyone ?

Reply #39
"I suspect that ffmpeg itself has some considerable overhead, with the data traveling through many layers of abstractions."

How yes, no, I'm astonished by such scientific and rigorous research. Nothing to see here, move along.
Please remove my account from this forum.

Re: Quite OK Audio (QOA)... anyone ?

Reply #40
You might be the one who can explain the test results as far as ffmpeg goes, so ... why? (Is it actually QOA that is better than the author wants to brag about?)
And also why ffmpeg decodes AAC/MP3 faster/slower and not the other way around?

Re: Quite OK Audio (QOA)... anyone ?

Reply #41
The ADPCM-MS decoder is slower because it takes same packet multiple times to decode from it multiple frames (when packet size is bigger than block_align specified in wav input file), instead of doing it all at once in one go. I sent patch to fix this.
Please remove my account from this forum.

Re: Quite OK Audio (QOA)... anyone ?

Reply #42
I feel that the final word about lossy codecs for transparent music listening has not been spoken yet, that's why am quite excited about QOA. Musepack is an underrated gem that could have become the advanced heir to MP3 but somehow it didn't happen, OGG Vorbis (not to mention Opus with its own quirks) could be less resource-intensive and faster in terms of decoding, Apple's supervision still casts a shadow on well-tuned (q)AAC. After several weeks of testing QOA, I want to ask for one thing — to improve gapless playback, actually there is an issue on Github.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Quite OK Audio (QOA)... anyone ?

Reply #43
I feel that the final word about lossy codecs for transparent music listening has not been spoken yet, that's why am quite excited about QOA. Musepack is an underrated gem that could have become the advanced heir to MP3 but somehow it didn't happen, OGG Vorbis (not to mention Opus with its own quirks) could be less resource-intensive and faster in terms of decoding, Apple's supervision still casts a shadow on well-tuned (q)AAC. After several weeks of testing QOA, I want to ask for one thing — to improve gapless playback, actually there is an issue on Github.

Have you tried Dualstream ?
http://losslessaudio.org/DualStream.php

Re: Quite OK Audio (QOA)... anyone ?

Reply #44
@shadowking, I spent several days testing Optimfrog Dualstream, which was forgotten, but thanks to you, dug out of oblivion. Bottom line: the output is a size comparable to a hybrid WavPack -b4x, but decoding takes up noticeably more resources. Also, I detect slight delays when seeking within even a five-minute song in Foobar2000 2.1 on my end.

However, I found the comparison with Wavpack 3.97 interesting, and I'd like to know what has changed since then.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Quite OK Audio (QOA)... anyone ?

Reply #45
Since the frog has been mentioned here, I do have an updated fb2k decoder using the original developers source code with minor tweaks for modern fb2k/64bitness...

https://github.com/marc2k3/foo_input_ofr/releases

 

Re: Quite OK Audio (QOA)... anyone ?

Reply #46
QOA is a Quite OK codec for me :D, but it's not too transparent. I made an ABX with Foobar2000 and got 16/16. Here's the link to the drive folder:

https://drive.google.com/drive/folders/1d40gGr2tG4xwBiNR1TR-PBZhorsT56G2?usp=drive_link

Maybe QOA can be transparent at higher sampling rates but looks like it's not transparent at 16kHz etc. I hope a 4-bit version will come (1-bit and 2-bit versions were came) for storing high quality audio with it, but looks like 3-bit is still a good compromise between filesize and quality for most circumstances.

Re: Quite OK Audio (QOA)... anyone ?

Reply #47
Report this to their tracker, looks to me like QOA encoder could be improved a lot.
Please remove my account from this forum.

Re: Quite OK Audio (QOA)... anyone ?

Reply #48
Can anyone make a 4-bit variation of QOA? It's needed because 3-bit quality is sometimes not enough (especially for low sampling rates). I've tried to make it myself via ChatGPT but I got a garbage output. Also, contacting @phoboslab didn't help.

Re: Quite OK Audio (QOA)... anyone ?

Reply #49
First, QOA wasn't constructed to be transparent. It was intended to be "Quite OK" at very light decoding load. But I guess you know.

"Obviously" such a quantization calls for a noise shaping algorithm. How to round off each sample residual to one of the values implied by the dequant table.
Given that the format has been published and frozen - a decoder has found its way into ffmpeg too - then if you want a revision you probably need to (I) give a case for the need for it and (II) what does actually improve.  For (I), not only "but it could sound better" but also why that cannot be solved by noise shaping upon encoding; for (II), not only "I want another bit in the dequant table and I'm willing to reduce the 8 bytes slice coverage to only 15 samples", but what values for the new table.