Just discovered this new "fast, lossy audio compression" format that claims:
QOA is fast. It decodes audio 3x faster than Ogg-Vorbis, while offering better quality and compression (278 kbits/s for 44khz stereo) than ADPCM.
QOA is simple. The reference en-/decoder fits in about 400 lines of C. The file format specification is… not yet released.
They provide online samples to evaluate it: https://qoaformat.org/samples/
Official blog: https://phoboslab.org/
Official website: https://qoaformat.org/
Official GIT: https://github.com/phoboslab/qoa
I'd wonder how this compares to, say, AptX. or the elephant in the room, mp3?
(And FWIW, given that an ancient chip like, say, dual core ARMv4 at 100MHz can decode ogg vorbis at multiple times realtime, I'm not entirely sure if there's a use case for this if its only benefit is "It's fast" )
If anyone wishes to give this a try: https://www.rarewares.org/files/QOA.zip (https://www.rarewares.org/files/QOA.zip)
This contains qoaconv.exe, the encoder, and qoaplay.exe, the player. These are Windows x64 compiles and the input to the encoder is only compiled for .wav files.
Command line to encode: quoconv in.wav out.qoa
and, to play: qoaplay file.qoa
Tested on a couple of tracks and I have to say I have heard a lot worse!! ;)
Decoder for foobar2000 is also available - https://www.foobar2000.org/components/view/foo_qoa
I'd be interested to see someone better at this and more patient than me ABX this.
If this is doing what I assume this is, when it isn't transparent it should be less annoying than something like mp3 getting it wrong, but how often do modern lossy codecs get it annoyingly wrong in the general vicinity of 256 kbps
Decoder for foobar2000 is also available - https://www.foobar2000.org/components/view/foo_qoa
And works with the output from the above executable. :)
I'd wonder how this compares to, say, AptX. or the elephant in the room, mp3?
(And FWIW, given that an ancient chip like, say, dual core ARMv4 at 100MHz can decode ogg vorbis at multiple times realtime, I'm not entirely sure if there's a use case for this if its only benefit is "It's fast" )
Intended use cases seem to include audio in games, including music, sound effects, where ADPCM formats have been used, and other applications where the computation savings would count, I guess.
Doesn't seem to be meant to compete with more traditional lossy codecs for applications where only one or just a few concurrent streams are meant to be used.
https://phoboslab.org/log/2023/02/qoa-time-domain-audio-compression
The same guy invented QOI, a simple lossless image codec. In that case he was competitive with PNG on size and much quicker, a lot of that is thanks to PNG being archaic. QOA is likely uncompetitive with complex audio codecs, but has a fighting chance of being competitive with quick codecs. It'll be interesting how they fare creating a lossy codec.
From the source:
/* The Least Mean Squares Filter is the heart of QOA. It predicts the next
sample based on the previous 4 reconstructed samples. It does so by continuously
adjusting 4 weights based on the residual of the previous prediction.
The next sample is predicted as the sum of (weight[i] * history[i]).
The adjustment of the weights is done with a "Sign-Sign-LMS" that adds or
subtracts the residual to each weight, based on the corresponding sample from
the history. This, surprisingly, is sufficient to get worthwhile predictions.
This is all done with fixed point integers. Hence the right-shifts when updating
the weights and calculating the prediction. */
QOA specification is still not frozen last time I checked.
Out of curiosity, I compared this against a 32kHz-downsampled, FLAC compliant "FSLAC -2" encoding (using this preliminary 1.3.4 binary (https://hydrogenaud.io/index.php/topic,122390.msg1010561.html#msg1010561)), which results in a similar bitrate. The reason for the comparison against FLAC is that, as ktf demonstrated in his lossless codec analysis, the FLAC reference software is extremely fast at low and medium presets as well.
Due to an apparent lack of psychoacoustic noise shaping in QOA (the quantization noise is spectrally almost white) and high efficiency (due to the extremely simple compression algorithm), FSLAC sounds quite a bit better to my ears, and so does LossyWAV+FLAC, I would assume. Especially on samples such as "Triangle", see the FSLAC thread here (https://hydrogenaud.io/index.php/topic,122390.msg1010629.html#msg1010629).
Is there any other feature in QOA that F(S)LAC doesn't offer?
Chris
Other than up to 255 channels and guarantees about footprint and consistency, no. Flac is very fast but qoa is so simple that it should be an order of magnitude faster when optimised, if IO allows. The reference qoa decoder processes one sample at a time which can probably be improved without using SIMD and there may also be other speedups from where it stands.
Flac is very fast but qoa is so simple that it should be an order of magnitude faster when optimised, if IO allows.
I fail to see how this algorithm is much simpler than FLAC's. I haven't looked at this in detail, but having weights being updated each sample is usually something detrimental to SIMD optimizations.
I'm noodling trying to do multiple sample decodes at once (not full SIMD but packing into uint64_t), the residual is easy to unpack 4 at a time like that but haven't figured out the predictor yet. You may be right that the predictor cannot really be SIMD per channel, it definitely could be by decoding a single sample from every channel at once ("subchannels" are interleaved) but that involves more spread out memory access which may need twiddling and defeat the purpose, and limited benefit as most input is likely 2 channel. There's no stereo decorrelation which helps. FWIW the weights for a channel fit in a uint64_t, so does the history (which the ref updates separately to the output, but it looks like the output could be used directly which may or may not be a benefit).
What is a lot simpler are the memory accesses, they're fixed and so is the structure of the data. If we're really lucky a few common channel counts could be auto-vectorised but I don't have much faith in that. Order of magnitude may be pushing it, currently the ref takes half the user time to decode as flac -8 no md5 which admittedly may not be a fair fight.
I haven't looked at this in detail, but having weights being updated each sample is usually something detrimental to SIMD optimizations.
Updating weights each frame, not each sample, sounds promising.
Possible improvements include:
- Adding noise shaping
- Use vector quantization, like E8 lattice, or PVQ to minimize the average root-mean-square error.
- Use QMF (Quadrature mirror filter) to split the input into subbands, and encode each subbands separately, like aptx do.
Author of QOA here. Cool to see that it transpired to this forum - and that it's not met with immediate disgust!
To address some questions/remarks:
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.
Noise shaping: there's an experimental branch where I implemented some very simplistic noise shaping. code here. (https://github.com/phoboslab/qoa/blob/noise_shaping/qoa.h#L363-L369) 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. Though I have a hunch that this noise shaping hurts some other samples. E.g. the the voice in julien_baker_sprained_ankle. But I'm not sure if I'm not making this up. My ears (and/or my equipment) are not the best. Feedback welcome!
QMF: I actually tried that and it didn't make a difference, but made the code much more complex. So, not terribly exited about that.
E8 lattice, or PVQ: I guess I have some reading to do...
Very interesting improvements. I will follow this thread for sure!
I have been interested in time-domain lossy audio compression for a long time, and this is a very cool idea and implementation! As mentioned in the blog there are two obvious competitors. On the simpler side there is 4.0 bps ADPCM and on the more complex side there is 2.5 bps WavPack lossy. I have done experimentation in the past and found that those two are roughly equivalent quality-wise, and I have successfully used both of them in embedded canned audio applications. I suspected from the blog description that this codec, at 3.2 bps, would fit right in between.
I ran some quick tests using a 44.1 kHz stereo music sample and a 16 kHz mono voice sample. For ADPCM I used my ADPCM-XQ encoder (https://github.com/dbry/adpcm-xq) at the highest quality setting my patience would allow and for WavPack lossy I used the default mode with -x6. Both my ADPCM encoder and WavPack use dynamic noise shaping, so to make the comparison valid I turned that off (and verified that all three codecs generated flat noise).
In short, the results were exactly as I expected with all three codecs generating similar noise levels, within a dB or so. Of course, the encoding speed of ADPCM and WavPack were much slower than QOA, but that's irrelevant for canned audio. The decoding speed was too fast to measure with these samples and setup, but I imagine that they would line up according to complexity on embedded systems. Not sure where FLAC would fit in, but probably close to QOA.
In addition to noise shaping, which has been discussed, there is one other low-hanging quality improvement to consider: mid-side encoding (sometimes called joint stereo). The advantage that this can bring to this kind of lossy encoding is not obvious nor easy to measure, but in cases where there is a significant amount of centered audio (e.g., a lead vocal) then by using mid-side encoding most of the quantization noise will also be centered spatially, which makes it more easily masked by the source. Of course in cases where the left and right channels are completely different, then left-right encoding is better, so there has to be some sort of heuristic to choose. This is obviously impossible with ADPCM without breaking existing decoders, but WavPack lossy uses this by default, and in all the -x modes switches it in and out dynamically.
Having a viable alternative to proprietary ADPCM codecs seems like a worthy goal. The initial QOA blog post mentions video game applications, but as far as I can tell, QOA is missing one key feature for this purpose -- looping. As an example, CRI's ADX has three playback modes:
- No loop (play the whole file once)
- Loop all (upon reaching the final sample, continue playback from the first sample)
- Loop specific (upon reaching end sample y, continue playback from first sample x)
Method 2 requires you to cut the audio's start and end points ahead of time to ensure a seamless loop. Method 3 is required if the track has an introduction that is not repeated within the loop. In order to implement this in QOA, you'd need to allocate some space in the header for a loop type flag (0-2), as well as to store the starting and ending sample/block values.
ADX generally ignores the end loop position and treats the end of the file as the loop end, and then only uses the loop start position for the beginning of the loop. Since ADX was designed for CD-based games, it also requires that the loop start position lie on a CD sector boundary, i.e. you can only loop back to a sample that lies at the beginning of a 2048-byte CD sector. You probably don't need to replicate such a restriction in QOA, since most games no longer use optical media, but it might be useful if people are using QOA for homebrew games on older platforms. Built-in looping support would be a big selling point for using QOA in games, though.
Thanks bryant! Your "this is a very cool idea" comment means a lot me :]
Mid-side encoding: it somehow never occured to me that this could improve quality. I always thought of it as a way to allow quantizing one channel even more (which, now that I write this, makes it obvious that the quality would increase if you don't quantize more). Would be cool to allow that on a per frame basis, but I'm not sure if the added complexity would be worth it for the intended use cases. I'm trying to keep it really simple.
Looping: maybe I'm not understanding the issue, but I fail to see why the file format needs to support this. Ultimately it's the application's choice how and where to loop a file; and this info should imho be provided out of band.
I also just finished a new draft of the file format specification:
https://qoaformat.org/qoa-specification-draft-02.pdf
@phoboslab - Any plans on updating your foobar2000 decoder component to support v2 x64?
https://www.foobar2000.org/components/view/foo_qoa
That plugin is not mine. I sadly had to stop using foobar when I switched to linux a few years ago.
The foobar plugin is being developed by pfusik, here: https://github.com/pfusik/qoa-ci - maybe open an issue there. Is there any documentation of how (if at all) the plugin API changed for v2? If there's only minor changes, it may not be a all too difficult.
Looping: maybe I'm not understanding the issue, but I fail to see why the file format needs to support this. Ultimately it's the application's choice how and where to loop a file; and this info should imho be provided out of band.
The problem is that the loop start position will be different for every track, so unless the file format has a place to store the start sample number as metadata, you'd have to hardcode a table containing the start sample number for each track somewhere in an external file, which makes less sense than storing the metadata as part of the file itself, so that changes to the music do not require updating a separate file.
If QOA supports tags like ID3 or Vorbis comments, then you could just as easily store the start sample in a tag field, instead of the file header. I didn't see any mention of which (if any) tag format QOA uses, though. ADX just uses the file header, since it doesn't officially support any kind of tagging.
That plugin is not mine. I sadly had to stop using foobar when I switched to linux a few years ago.
The foobar plugin is being developed by pfusik, here: https://github.com/pfusik/qoa-ci - maybe open an issue there. Is there any documentation of how (if at all) the plugin API changed for v2? If there's only minor changes, it may not be a all too difficult.
Will make a request over there then. Thnx
I also just finished a new draft of the file format specification:
https://qoaformat.org/qoa-specification-draft-02.pdf
I see that you follow FLAC's channel order
and allocation, where 4 resp. 5 channels are 4.0 and 5.0, and not 3.1 resp. 4.1.
I don't know what is actually the best, but you should think twice. The WAVEFORMATEXTENSIBLE channel order has LFE as channel four. And BL as channel five, so deciding that "an N channel signal MUST BE the first N in WAVEFORMATEXTENSIBLE" is not appropriate, at least not unless you can code one as "not present" for each block.
At https://xiph.org/flac/format.html there has "since forever" been a loose mention of SMPTE/ITU-R recommendations that aren't referenced properly - and also, those are superseded over time. Revision 9 of ITU-R BS.2159 is here: https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.2159-9-2022-PDF-E.pdf . You see channel orders.
I have a hunch that no "standard" ever did prescribe FLAC's
allocation - only the order
among the channels that are actually included. At least it seems to be that way by now. Apparently, DVD-Audio can accommodate four channels as FL FR + any among the following four: (FC LFE), (LFE BC), (FC BC) or (BL BR).
So ... careful. Which means you might want to consider whether
uint8_t num_channels; // no. of channelsshould be something else.
...
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.
Quite OK Audio (QOA) Decoder have been updated to support foobar2000 v2 x64 now also
https://www.foobar2000.org/components/view/foo_qoa
@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?
Noise shaping: there's an experimental branch where I implemented some very simplistic noise shaping. code here. (https://github.com/phoboslab/qoa/blob/noise_shaping/qoa.h#L363-L369) 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.
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
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
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.
Nevermind. I managed to not be lazy so I figured it out.
@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 (https://www.rarewares.org/files/QOAconv.zip)
@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 (https://www.rarewares.org/files/QOAconv.zip)
Thnx a lot John :)
Seems to have better quality/bitrate than typical ADPCM but still has obvious artifacts in some cases, for example this file:
https://hydrogenaud.io/index.php?action=dlattach;topic=120491.0;attach=18922
Interesting codec. Sounds quiet nice actually. Would it be possible to make this support hybrid mode with a lossless correction layer?
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.
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?)
"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.
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?
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.
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 (https://hydrogenaud.io/index.php/topic,116605.msg1039662.html#msg1039662)) could be less resource-intensive and faster in terms of decoding, Apple's supervision still casts a shadow (https://hydrogenaud.io/index.php/topic,114363.msg1039511.html#msg1039511) 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 (https://github.com/braheezy/goqoa/issues/12) on Github.
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 (https://hydrogenaud.io/index.php/topic,116605.msg1039662.html#msg1039662)) could be less resource-intensive and faster in terms of decoding, Apple's supervision still casts a shadow (https://hydrogenaud.io/index.php/topic,114363.msg1039511.html#msg1039511) 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 (https://github.com/braheezy/goqoa/issues/12) on Github.
Have you tried Dualstream ?
http://losslessaudio.org/DualStream.php
@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 (https://hydrogenaud.io/index.php/topic,124188.msg1040034.html#msg1040034).
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
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.
Report this to their tracker, looks to me like QOA encoder could be improved a lot.
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.
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.
@Porcus (I) At lower sampling rates, noise shaping can't push the noise into the inaudible frequencies because they are above the Nyquist limit. (I) I don't know the ideal values.
AFAIC noise shaping is not implemented in QOA reference encoder.
@Porcus (I) At lower sampling rates, noise shaping can't push the noise into the inaudible frequencies because they are above the Nyquist limit. (I) I don't know the ideal values.
AFAIC 3bit should be enough for low sample rates.
@mycroft First answer: This does not change anything, noise shaping still can't push the noise into the inaudible frequencies at these lower sampling rates because they are above the Nyquist limit.
Second answer: 3-bit is pretty easy to ABX, here's an example: https://drive.google.com/drive/folders/1d40gGr2tG4xwBiNR1TR-PBZhorsT56G2?usp=drive_link . I did another ABX ang got 15/16 again, here's the link: https://drive.google.com/drive/folders/1MFflZFOMUDgiFV0bNuLcPGU7BAYOY2o2?usp=drive_link . Looks like QOA is pretty noisy in low sampling rates. Also, according to my ears, it has lower quality than 5-bit Flash ADPCM in most cases.
Thus my valid claim that QOA encoder can be improved: adding noise shaping, improving current encoding.
Noise shaping need not push noise into the inaudible frequencies: https://en.wikipedia.org/wiki/Noise_shaping#In_digital_audio
And even if it does not attain transparency, it already serves a mission if it makes the noise less annoying.
@Porcus At a low sampling rate like 5512.5Hz, you can't even access to 4kHz. Having another option for higher quality does not hurt someone.
I agree with all three of you. Hence my previous (https://hydrogenaud.io/index.php/topic,123838.msg1023913.html#msg1023913) two posts (https://hydrogenaud.io/index.php/topic,123838.msg1024634.html#msg1024634) in this thread, where the latter includes a solution for (relatively) simple but robust noise shaping.
Psychoacoustically, a high coding SNR is needed especially in lower frequencies. In case of a CDish sampling rate, you could achieve that by noise shaping during quantization, but with lower sampling rates, you can't. So in the latter case, indeed increasing the bit-depth is the only option I see.
But I don't think the QOA developer intends to change the QOA spec in that regard, am I right?
Chris
A mighty 3 octaves down from CDDA is quite a departure, and you wouldn't expect quality reproduction of music there in any case. But it does something to your need for bitrate.
* How dows it compare to https://github.com/dbry/adpcm-xq ?
* How low can you go with LossyWAV --> flac -8pb512 ? The 1.4.3 beta has a few new presets at the low end:
https://hydrogenaud.io/index.php/topic,109239.msg1045012.html#msg1045012
@Porcus Sampling rate is independent from quality and it is not an unusable sampling rate, some Flash games were used it in their musics.
As ADPCM-XQ does not use predictions, it can't reach QOA's quality in most cases. Also, LossyWAV uses frequency domain if I understood correctly and this makes it very complex from beginning.
I don't understand why you don't want having a 4-bit variation of QOA. I think it will be very useful as Flash ADPCM also has 2, 3, and 5 bit variations and they are very useful.
Sampling rate is independent from quality
*sighs*
I don't understand why you don't want having a 4-bit variation of QOA.
I didn't say that.
You need to realize that <freeware developer> isn't obliged to to create <software to your demand> for you for free.
If you need an altered version in <software project>, feel free to take note that it is MIT licensed.
@Porcus Yes, <freeware developer> isn't obliged to to create <software to my demand> for me for free, but you should not sigh because sampling rate (and channels as well) are independent from quality. As the sampling rate increases, the average quality that you will get with the same codec at the same bitrate will decrase, and vice versa. For example, 32kbps MP3 is pretty transparent to me, but only at a relatively low sampling rate (for example 11025Hz) with mono. But, the MP3 stream must be at least ~96kbps to be transparent to me at 22050Hz stereo. However, this value isn't ~192kbps for 44100Hz stereo because my hearing cutoff starts to affect the sound at this point. This is not quality. Speed (sampling rate or cutoff), channels, and quality are completely independent variables.
From "sampling rate is independent from quality" to at the same bitrate in one goalpost displacement.
Also, 11025 kHz at 64 bits/sample is the same bitrate as CDDA.
You're right.
By the way, I was sleepy when writing one of the messages above. I mean "and got 16/16" by "ang got 15/16", and the log in the drive folder verifies this.
I have wrote QOA encoder, it distorts less higher frequencies and helps a lot for
@Klymins 16000Hz sample (still not perfect, but at least it does not give those harsh sounds that make it trivially easy to ABX especially at lower sample rates) at cost of little smaller dB of SDR/PSNR score.
@mycroft How can I get it?
@Porcus 11025 kHz?
You mean 11.025 kHz or 11025 Hz. 11.025 kHz at 64 bits equals the same bitrate as CDDA.
@mycroft How can I get it?
Librempeg code. (I got couple of clicks when converting >2 hour OST 48kHz music to .QOA dunno is it bug because of my changes or because of original algorithm) but for 16kHz speech sample rate in your short sample its 99% transparent.
In case anyone is interested, I made an alternative QOA decoder component for foobar2000 using a self-written decoder based on the specs. The component can be downloaded here: https://foobar.hyv.fi/?view=foo_input_qoa (https://foobar.hyv.fi/?view=foo_input_qoa).
This component should implement all QOA features. Channel support has no artificial limits, streaming format is supported, the correct channel maps are used as documented in the specs. Seeking is sample-accurate. Tagging is supported and I added custom support for overriding default channel order with a tag.
@mycroft How can I get it?
Here's a Win64 compile of librempeg with mycroft's QOA encoder.
Librempeg code. (I got couple of clicks when converting >2 hour OST 48kHz music to .QOA dunno is it bug because of my changes or because of original algorithm)
I encoded a test audio album with librempeg and had very nasty beeps and squeks in the first track at around time mark 2:45. I verified the same track with the reference qoaconv encoder and it didn't produce any glitching.
@mycroft, the QOA encoder in librempeg glitches because you disabled the reference encoder's weights overflow penalty check.
Here's win64 compile of qoaconv modified with mycroft's encoding changes but with weight checks in place. Doesn't glitch in my test file and produces audibly identical results from Klymins' samples with librempeg.
Edit: Added qoaconv_mod.zip with a version of qoaconv that doesn't reject WAVE_FORMAT_EXTENSIBLE WAV files and includes three different encoding modes.
Usage: qoaconv [mode] input.wav output.qoa
Mode '0' is the default, reference encoder. '1' uses the Librempeg-inspired version and '2' is based on reference encoder's noiseshaping branch.
I also have small patch to fix initial samples prediction if they are not 0. But whole codec design and exp implementation is flawed/limited. My idea is to always recompute weights at start of frame but that causes artifacts ...