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: Need advices for listening tests (Wavpack lossy) (Read 10588 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Need advices for listening tests (Wavpack lossy)

Hello everyone,

For some time now, I’ve been considering conducting tests on the Wavpack format (hybrid/lossy). My goal is to establish a detailed overview of the format's performance at different bitrates, with various settings and samples.

Wavpack is very easy to use. Like most audio formats in the world, it allows you to set an approximate bitrate. The user can then choose from 4 modes (fast, normal, high, very high) that affect encoding speed, decoding speed, and of course, quality. Within these 4 modes, the user can also increase the analysis complexity and slowness (x1 to x6), which improves quality without increasing decoding complexity. To be exhaustive, there are other advanced options, but they are less intended for production than for occasional testing.

In summary, for a given bitrate, there are 4 × 7 combinations, resulting in 28 presets, whose results are most likely very close to each other. This is why it is unnecessary, and above all unthinkable, to test them all in the same row.

My goal is to select a few relevant combinations. I have chosen a few, but before embarking on a testing procedure that will probably take me several weeks, I think it would be much more sensible to seek the advice of knowledgeable users.

To be clear, I plan to test Wavpack first at ~200 kbps, then again at 250 kbps, 300 kbps, probably 350 kbps, and possibly 400 kbps. There would therefore be 4 to 5 separate tests, one for each bitrate. For each test, I want to get an overview of the roles played by the “fast” to “very high” modes and by the -x coefficients.

Currently, I am leaning towards the following solutions:
  • -f: The most user-friendly mode, as it is the fastest for both encoding and decoding. Also the most convenient for the tester, as the quality is at the lowest of a scale composed of 28 steps.
  • -gx: -g is the default mode, -x adds an additional layer of analysis with minimal impact on performance.
  • -hx4: -h is the high mode. Decoding is already slower (which is not a problem nowadays; it might slightly reduce battery life and impact the speed of transcoding). -x4 considerably reduces file production speed but remains acceptable in 2025.
  • -hhx6: -hh is the slowest mode, -x-6 as well. This is the 28th step of the 28 steps proposed by Wavpack, thus the maximum quality. Encoding is very slow, with encoding time multiplied by at least 40 compared to the -f mode.

I would prefer not to exceed 4 presets; beyond that, the difficulty and fatigue become exponential. I am open to any opinions on the matter and feel free to comment my choices and suggest something different.

I would also like to reserve a place for a LOW ANCHOR, and possibly a HIGH ANCHOR. These elements are important, I think, for comparing the results of the tests with each other. If I decide to use a HIGH ANCHOR, it will probably be the best encoding of the entire series: -b400hhx6 or -b4hhx6.

However, for the LOW ANCHOR, I am much more hesitant. I am reluctant to use a low bitrate MP3-Like, because the flaws are vastly different from what the Wavpack, DualStream, QOA, and LossyWAV encoders produce. Even with modern formats like OPUS or USAC, some encodings are perfectly transparent at 64 kbps. But transparency is not what we ask of a LOW ANCHOR. I am tempted to use a format that produces noise as the main flaw for this purpose. ADPCM seems a bit too high-quality. On the other hand, what works quite well is a simple 8-bit resampling, without compression, with or without dithering and/or noise shaping. What would you choose for LOW ANCHOR?

Regarding the choice of samples: to be clear, my test will not be oriented towards classical music, but it will still include a small group of samples that will be useful to me and reward my efforts. I also want to avoid a test exclusively focused on killer samples (as the results would then be biased) or one that completely disregards them.

Here are the samples I plan to use:
- The 20 samples used by Kamedo2 in his numerous tests
- The 12 samples selected by IgorC in his tests
- 10 classical music samples, the same ones already selected in several tests conducted in 2020 and 2021. Samples that are not identified as problem samples (although one or two might cause issues for several high-bitrate encoders)
- 10 current music samples, the same ones already selected in several tests conducted in 2020 and 2021.
- About ten killer samples, already identified to challenge Wavpack.

This brings the total to approximately 60 samples. It's a considerable amount, but it ensures a mix of standard music, challenging samples (selected by Igor & Kamedo), and truly problematic ones. Similarly, I am open to opinions and suggestions and don't hesitate to suggest some samples.


Estimated test duration: several weeks to several months. I want to do things well, but I need to proceed slowly and when I can.

Test feasibility: I have serious doubts about being able to obtain relevant results, especially with non-pathological samples. I also do not intend to obsessively search for differences. If it is obvious during blind listening that two files sound the same, the encoding will get a score of 5 and I will move on to the next one.


Thanks for reading and for your advices  :)


PS : Comparing Wavpack with other formats would obviously be fascinating, but that is not the objective of this test. I want to first have a comprehensive understanding of the format before considering any comparisons.

PPS : translated in english with the help of an IA
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #1
In case you'd want to know: https://hydrogenaud.io/index.php/topic,127455 .

You may consider using 2-bit (or 3-bit) Flash ADPCM as the low anchor. It is a variation of IMA ADPCM that also supports 2-, 3-, and 5-bits per sample.

I didn't think time-domain codecs have killer samples (maybe except for very tonal sounds), do they?

Re: Need advices for listening tests (Wavpack lossy)

Reply #2
Thanks for your suggestion Klymins.
I could try this. Does a standalone encoder exists? I honestly don't plan to install Adobe Flash in 2025  :D
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #3
However, for the LOW ANCHOR, I am much more hesitant. I am reluctant to use a low bitrate MP3-Like, because the flaws are vastly different from what the Wavpack, DualStream, QOA, and LossyWAV encoders produce. Even with modern formats like OPUS or USAC, some encodings are perfectly transparent at 64 kbps. But transparency is not what we ask of a LOW ANCHOR. I am tempted to use a format that produces noise as the main flaw for this purpose. ADPCM seems a bit too high-quality. On the other hand, what works quite well is a simple 8-bit resampling, without compression, with or without dithering and/or noise shaping. What would you choose for LOW ANCHOR?

I understand your concern. Not exactly the quality one would imagine from a 'low anchor', but these contenders will be interesting, because those who use Wavpack would be using the codec because of simplicity(decoder binaries are small, DAP batteries will last longer) and reproducibility(bit-to-bit exact output across environments).

  • lossyWAV in.wav --quality extraportable
  • ADC (Adaptive Differential Coding)
  • simple 8-bit resampling(as you've mentioned)

aptX is simple, but I know it is way too good for this purpose, and setting the sample rate 32kHz or 24kHz defy the usefulness of the contender. Setting the sample rate to 22.05kHz will be simple but sound will be radically different. Ogg Vorbis is extremely stable and safe, and in extremely low bitrates (-q-2) it sounds like sandpaper, but still this is not close enough to the Wavpack. YAMAHA ADPCM-A and ADPCM-B is close, and still have some application in retro-computing, but it might be a hassle to actually start using them.


Re: Need advices for listening tests (Wavpack lossy)

Reply #4
Thanks for your suggestion Klymins.
I could try this. Does a standalone encoder exists? I honestly don't plan to install Adobe Flash in 2025  :D

I don't know but even if there isn't it probably can be made easily. Be aware that Adobe Animate is essentially the same thing as Adobe Flash.

Re: Need advices for listening tests (Wavpack lossy)

Reply #5
ffmpeg has ADPCM Shockwave Flash encoder.

Re: Need advices for listening tests (Wavpack lossy)

Reply #6
Since you want to test several bit rates, maybe you can even drop one of the four compression settings?
 You suggest not to do "-g".  Since you already will have to answer "But how about the default?" a few times (that "downside" is already incurred) - just save yourself one of the presets.
 Consider, to make life easier for yourself, to: replace -gx & -hx4 by "-hx". Then it reduces to: Keep the fastest -f, the slowest -hhx6, and the -hx which the developer himself uses (although that post didn't refer to lossy ...)

transparency is not what we ask of a LOW ANCHOR. I am tempted to use a format that produces noise as the main flaw for this purpose. ADPCM seems a bit too high-quality.
I'm lost, but a possibly relevant thread: https://hydrogenaud.io/index.php/topic,115284.0.html

Re: Need advices for listening tests (Wavpack lossy)

Reply #7
I understand your concern. Not exactly the quality one would imagine from a 'low anchor', but these contenders will be interesting, because those who use Wavpack would be using the codec because of simplicity(decoder binaries are small, DAP batteries will last longer) and reproducibility(bit-to-bit exact output across environments).

  • lossyWAV in.wav --quality extraportable
  • ADC (Adaptive Differential Coding)
  • simple 8-bit resampling(as you've mentioned)
Hi Kamedo2, thanks for your reply.

Yes, I admit myself that my LOW ANCHOR would rather look to a MID-ANCHOR. I don't want something really bad (4 bit PCM would then be good choice) but something preventing me from an excessive reaction during the test. An anchor with a rating around 3.0/5 should be OK.
I downsampled some files to 8-bit PCM: noise is always audible except for very loud and saturated samples. Except those samples, it makes a rather could candidate for my purpose.

• LossyWAY extraportable: bitrate is higher than Wavpack 2 bit-per-sample, and sound quality is probably too high. I don't think it's a good choice.
• ADC: I forgot about this one. Nice idea :) I'll try.
• I'll avoid downsampled files because (I can't compare muffled sound vs bright/noisy one)
• Vorbis and the coarse sound signature! I remember it very well. The suggestion is really nice, but from my souvenirs a starvating Vorbis also lead to several distortions and it's not what I'm looking for. But I just tried. And to be honest, it's not noisy but badly metallic. Maybe -q-1 or q0 is more suitable but as said, I'm very reluctant to use a transform encoder as low anchor.

Thanks for all your suggestions Kamedo2
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #8
Since you want to test several bit rates, maybe you can even drop one of the four compression settings?
 You suggest not to do "-g".  Since you already will have to answer "But how about the default?" a few times (that "downside" is already incurred) - just save yourself one of the presets.
 Consider, to make life easier for yourself, to: replace -gx & -hx4 by "-hx". Then it reduces to: Keep the fastest -f, the slowest -hhx6, and the -hx which the developer himself uses (although that post didn't refer to lossy ...)

I must say that's a brilliant suggestion.
Three settings instead of four is definitely better for my mental health. Keeping the default untouched is obviously better than tweaking it. Thanks for this suggestion. Now I'm very enthusiastic about testing : fastest-slowest-default. Perfect :)

Quote
I'm lost, but a possibly relevant thread: https://hydrogenaud.io/index.php/topic,115284.0.html
The link to the original software is dead.
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #9
ffmpeg has ADPCM Shockwave Flash encoder.
Thanks for suggesting it. I tried with the following setting: -i pipe:0 -y -c:a adpcm_swf %d
Batch encoding with foobar2000 is fine. Around 4bps. But quality is too close to transparency :/
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #10
@guruboolez Doesn't it have a switch for selecting the bits-per-sample value?


Re: Need advices for listening tests (Wavpack lossy)

Reply #12
I can encode the samples using Flash too, if you don't want to install Flash. I want to say that I don't think it's right to make the low-anchor just uncompressed PCM with a low bit depth because its noise is much different than WavPack's.

Re: Need advices for listening tests (Wavpack lossy)

Reply #13
Keeping the default untouched is obviously better than tweaking it. Thanks for this suggestion. Now I'm very enthusiastic about testing : fastest-slowest-default. Perfect :)

I have to correct myself   O:)
Porcus suggested fastest - high (-hx) - highest. Which suits to me as well.

Klymins: thanks for the suggestion. I would be interested to see how sound Flash ADPCM at 2 bps if possible. Could you try with some samples posted by Kamedo2:
https://hydrogenaud.io/index.php/topic,98003.msg815018.html
Thanks!
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #14
Wow, thanks for even considering such a ambitious project! I will surely be very interested in the results!

A couple things come to mind after reading this thread. The first is that you don’t specifically mention whether you’ll be targeting the full hybrid mode (with correction files) or just pure lossy mode. It turns out that there is a compromise when creating the correction files with respect to the dynamic noise shaping (DNS) feature.

In pure lossy mode the dynamic shaping is calculated and applied for each sample, and every block is filled to the maximum number of samples, which is all ideal. However, when creating a correction file this won’t work because of a fundamental difference between the hybrid and pure lossy modes. In the pure lossy modes, the decoder simply decodes each sample and is completely unaware of what kind of noise shaping, if any, was used.

However, in the hybrid mode the decoder must be aware of the noise shaping because of the way the “correction” data is encoded (essentially, the noise shaping must be undone before the sample can be corrected, which improves the efficiency of the correction data storage). What this limitation means is that the noise-shaping can’t change every sample and must be linear during the frame (basically values for the start and end of the frame are sent). If the DNS is rapidly changing then the frame size must be truncated to allow this scheme to get reasonably close to the optimum shaping, and this hurts efficiency. Note that this became worse with the new DNS because it reacts more quickly to changing audio, and frames can actually be as short as just 16 samples!

The net result of all this is three things:

  • The lossy bitrate when creating correction files will be higher than the pure lossy bitrates at the same setting
  • The subjective quality of the lossy mode is likely to be worse when creating correction files (although I suspect not significantly)
  • The lossless compression ratio is about 1% worse due to the new DNS (compared to 5.7.0)

None of this is true when using the fixed noise-shaping options (-s<n>), but I believe that the subjective improvement of DNS is worth the cost (although possibly not in all samples).

I know that you have been using the hybrid mode with correction files, and your signature currently suggests the same, but you should be aware of the compromises. Of course, if your results are only using correction files then it would be presumed that the results with pure lossy mode can only be an improvement.

As for the low-anchor, there is discussion of low-bitrate ADPCM. It turns out that my ADPCM encoder can now also create 2, 3, and 5 bps APDCM files, and also incorporates almost the identical dynamic noise shaping from WavPack. This is a very reasonable low-anchor if you want characteristics similar, but worse than, WavPack lossy. ADPCM requires [very] roughly 1.5 bps more than WavPack lossy for the same quality, so 3 bps should be a little worse than any WavPack lossy mode, and 2 bps even worse than that (based on my limited objective testing).

Note that ADPCM files that aren’t 4 bps are not widely supported at all, and that FFmpeg’s decoder (which does support them) contains a non-standard optimization that makes it unsuitable for this purpose. See here. Fortunately, my program can also decode back to WAV, so that should work fine. The latest version of the program can be found here:

ADPCM-XQ on GitHub

Of course, maybe using a low-anchor encoder from the same author as the target might be too close. That’s your call, obviously.

Finally, I have never strongly recommended settings below 3 bps, and after your findings last year and more experimentation I am even more hesitant to do so. While I have made some improvements that fixed the egregious failures you uncovered, there is still a decorrelation noise feedback issue that makes those settings always suspect.

For your testing it make sense to experiment with those rates, especially since your goal is to explore the performance limits of the codec, and I am interested in the results, but this caveat should be kept in mind. 

The funny thing is that there is a significant amount of added complexity to the entropy encoder to allow settings below 3 bps, and this complexity slows the encoding and decoding to some degree. And because this complexity is used even in the pure lossless mode (for consistency), it affects the performance of that too! If I had it to do all over again, I would probably skip all that mess and make 3 bps the bottom, but it is what it is.

Thanks again, Guru, and feel free to let me know if you have other questions or run into trouble!

Re: Need advices for listening tests (Wavpack lossy)

Reply #15
Attached. Sorry, I didn't rename them. Also, these are the undecoded FLV files because the WAV's exceed the allowed size.

Re: Need advices for listening tests (Wavpack lossy)

Reply #16
Keeping the default untouched is obviously better than tweaking it. Thanks for this suggestion. Now I'm very enthusiastic about testing : fastest-slowest-default. Perfect :)

I have to correct myself   O:)
Porcus suggested fastest - high (-hx) - highest. Which suits to me as well.

I did, but sure -f -g -hhx6 also amount to only three.
Also after the information that lossy and lossy-part-of-hybrid differ so much, you have to take a stand on that too. Maybe "low bitrate hybrid" "mid bitrate hybrid" "mid bitrate lossy" and "higher bitrate lossy"?
@bryant , any thoughts on how much "bitrate is lost" by compressing hybrid & discarding the correction files - and do you know whether -hx makes a big difference here?

Also, --cross-decorr ... "can increase noise slightly and increases CPU requirements during hybrid lossless decoding". Since the high "-x" are doing who-knows-what stuff: is there anything the guru should know about that switch?

Re: Need advices for listening tests (Wavpack lossy)

Reply #17
Whats exactly wrong with adpcm decoder in ffmpeg any why you havent created patch for this already?

Re: Need advices for listening tests (Wavpack lossy)

Reply #18
There was a link to https://github.com/dbry/adpcm-xq/issues/29 there.

I don't speak code, but can you (and @bryant) check if the code before the change at  https://github.com/FFmpeg/FFmpeg/commit/9937e686fe86cc463577208d67431dabe74ad2ae was closer to correct?

Re: Need advices for listening tests (Wavpack lossy)

Reply #19
Many thanks for your detailed answer, David!

About hybrid vs lossy:
The situation is tricky. I think the best thing to do is to stay focused on a single objective and not spread myself too thin. My idea is to map the sound quality of Wavpack encoding techniques. I will most likely stick to the highest quality mode, which does not use a correction file and relies on DNS. I do not exclude conducting a complementary test at the end, which would schematically evaluate the difference between the pure lossy mode and the hybrid mode. David already believes that the difference is negligible and this is encouraging. I compared the two on a highly pathological sample: I thought I heard a difference, but I end with an ABX score of 4/16. The difference between the pure lossy mode and the lossy part of the hybrid mode is worth investigating further (especially since I use myself the hybrid mode), but that will not be the focus of this test. Thank you anyway for drawing my attention to this difference; I was still under the impression that the two were identical as long as the -cc switch was not used.

Regarding my LOW or MID-LOW ANCHOR:
thank you, Klymins, for taking the time to create and send me the *.flv files. However, I admit that I am unable to play them (failure with MPC-HC/VLC/foobar2000/AUDITION). Regarding ADPCM-XQ, I like the idea a lot. An executable is available on GitHub, and even for me, it's quite easy to use. The idea of having a relationship with Wavpack lossy is not bothersome; I would even say it is an advantage as an ANCHOR since I am looking for defects with comparable properties but with greater intensity. At 2 bits per sample, the defects are clearly audible and more intense than Wavpack lossy at the same bitrate.
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #20
You're welcome.

Re: Need advices for listening tests (Wavpack lossy)

Reply #21
I just finished a pre-test. Purpose: looking for adequate low anchor.
Sample tested: 3 samples in one, Metallica-Vivaldi-MichaelJackson, with fading between each (created with foobar2000 preview tool).

Tested settings:
  • adc 0.7 -q128 (1,18 Mb)
  • ADPCM-XQ 2 bit (648 Kb)
  • ADPCM-XQ 3 bit (973 Kb)
  • PCM 6 bit dithered
  • PCM 7 bit dithered
  • PCM 8 bit dithered
  • WavPack 5.80 -b2f (748 Kb)


Result:
Quote
ABC/HR for Java, Version 0.5b, 19 février 2025
Testname: low anchor test

Tester:

1L = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adpcm.3.wav.wav
2R = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adpcm.2.wav.wav
3L = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.6bit.wav
4L = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.7bit.wav
5R = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.8bit.wav
6R = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adc128.wav
7L = D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image_WVb2f.wav

---------------------------------------
General Comments: Listening # 1 (first seconds): 2R, 3L and 5R have obvious noise issues.

ABX range: 11.53 - 13.20
very fast ABX test (looking for obvious issue)
---------------------------------------
1L File: D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adpcm.3.wav.wav
1L Rating: 4.0
1L Comment: Slight hiss, bright sound. String orchestra sound sounds the worst (grainy/sandy sound)
---------------------------------------
2R File: D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adpcm.2.wav.wav
2R Rating: 3.0
2R Comment: Grainy sound, not very pleasant with Metallica, very annoying with Vivaldi, but quite good with Michael Jackson
---------------------------------------
3L File: D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.6bit.wav
3L Rating: 1.2
3L Comment: White noise, very audible and annoying
---------------------------------------
4L File: D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.7bit.wav
4L Rating: 1.7
4L Comment: White noise, not as strong as 3L, but close and still annoying even with loud music
---------------------------------------
5R File: D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.8bit.wav
5R Rating: 2.2
5R Comment: Background hiss, annoying on Metallica and Vivaldi, but almost hidden on the last part.
---------------------------------------
7L File: D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image_WVb2f.wav
7L Rating: 4.5
7L Comment:
---------------------------------------

ABX Results:
Original vs D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image_WVb2f.wav
    15 out of 16, pval < 0.001
Original vs D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adc128.wav
    7 out of 16, pval = 0.772


---- Detailed ABX results ----
Original vs D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image_WVb2f.wav
Playback Range: 11.534 to 13.202
    1:51:21 PM f 0/1 pval = 1.0
    1:51:23 PM p 1/2 pval = 0.75
    1:51:27 PM p 2/3 pval = 0.5
    1:51:29 PM p 3/4 pval = 0.312
    1:51:31 PM p 4/5 pval = 0.187
    1:51:33 PM p 5/6 pval = 0.109
    1:51:39 PM p 6/7 pval = 0.062
    1:51:42 PM p 7/8 pval = 0.035
    1:51:44 PM p 8/9 pval = 0.019
    1:51:46 PM p 9/10 pval = 0.01
    1:51:53 PM p 10/11 pval = 0.005
    1:51:54 PM p 11/12 pval = 0.003
    1:51:57 PM p 12/13 pval = 0.001
    1:51:59 PM p 13/14 pval < 0.001
    1:52:01 PM p 14/15 pval < 0.001
    1:52:04 PM p 15/16 pval < 0.001

Original vs D:\samples WAVPACK\PERSO TEST 2025\PRETEST\Image.adc128.wav
Playback Range: 11.534 to 13.202
    1:52:48 PM f 0/1 pval = 1.0
    1:52:51 PM p 1/2 pval = 0.75
    1:52:53 PM f 1/3 pval = 0.875
    1:52:56 PM p 2/4 pval = 0.687
    1:52:59 PM f 2/5 pval = 0.812
    1:53:00 PM p 3/6 pval = 0.656
    1:53:03 PM p 4/7 pval = 0.5
    1:53:06 PM f 4/8 pval = 0.636
    1:53:08 PM f 4/9 pval = 0.746
    1:53:10 PM f 4/10 pval = 0.828
    1:53:12 PM p 5/11 pval = 0.725
    1:53:15 PM f 5/12 pval = 0.806
    1:53:18 PM p 6/13 pval = 0.709
    1:53:20 PM f 6/14 pval = 0.788
    1:53:23 PM p 7/15 pval = 0.696
    1:53:31 PM f 7/16 pval = 0.772

Conclusion:
  • ADC was transparent on a quick ABX comparison, and can't be used as low anchor
  • ADPCM-XQ 2 bit-per-sample quality is not constant: quite acceptable with the third part (M. Jackson) but very peculiar noise/sand scratching noise on Vivaldi
  • ADPCM-XQ 3 bit-per-sample produces more subtle issues
  • Dithered PCM (with Smart Dither component on foobar2000) is very easy to spot here. The hiss is nonetheless much harder to detect with Michael Jackson
  • Wavpack lossy at minimal quality (200 kbps, fast) was not very hard to spot with the Vivaldi sample (15/16). I'm not sure I could do the same with Metallica or Thriller

From these scores, both dithered PCM and ADPCM are suitable as LOW or MID-ANCHOR.
According to WV worst lossy quality on normal music, I'll suffer during this test and I'm sure that many files will end at 5/5
Wavpack Hybrid -c4hx6

Re: Need advices for listening tests (Wavpack lossy)

Reply #22
Whats exactly wrong with adpcm decoder in ffmpeg any why you havent created patch for this already?
As I mentioned in the issue thread, the problem is using multiplies instead of shifts+adds to expand the nibble code.

I did consider creating a patch, but I didn’t because I could not figure out an elegant way to do the calculation. Your code uses a single calculation that works for every bit depth and I assumed that you knew its output didn’t exactly match the reference. I’ve never heard the difference with 4-bit codes (although it’s measurable), but with 5-bit codes it’s audible in quiet passages.

The only way I could think of to do it that matches the reference would be to do the calculations in a loop (which is what Rockbox does) or use a completely separate loop for each size (which is what I have).

I didn’t think that either would get approved.

Re: Need advices for listening tests (Wavpack lossy)

Reply #23
Well I fixed 3 and 5 bit decoding (2bit is fine), 4bit is all over code used so I will not change it, and errors are not that huge like with 5bit. The feature was initially added but check was not made with 5bit to see its soo  bad decoded output, and to be blunt I was not aware of errors at all, so at least the patch would raise awareness of bugs present in code.

Re: Need advices for listening tests (Wavpack lossy)

Reply #24
@bryant , any thoughts on how much "bitrate is lost" by compressing hybrid & discarding the correction files - and do you know whether -hx makes a big difference here?
In this post @shadowking suggests around 3% increase in bitrate. That certainly sounds reasonable, but it does depend on the material.

If the source analysis results in the DNS being constant (e.g., full minimum or full maximum) then there won't be any difference. The mode should not make any difference either.

Quote
Also, --cross-decorr ... "can increase noise slightly and increases CPU requirements during hybrid lossless decoding". Since the high "-x" are doing who-knows-what stuff: is there anything the guru should know about that switch?

I haven't experimented with that switch in so long, I wouldn't be surprised if it was broken. Needless to say, not recommended. :) And especially for a test like this, one wants to assume that the default settings are preferred.