HydrogenAudio

Good evening.
Long time lurker and first time poster in here.

I found THIS (https://sourceforge.net/p/lame/bugs/506/) great sample by Jari Aalto.
He said he had some problems with LAME's V0 setting so I decided to test it myself including the other encoders, too.

---

MP3 is the most popular lossy codec in the world so let's test it first.
Using latest LAME 3.100.1 from RareWares.
lame -V0 input.wav

Spoiler (click to show/hide)
Very easy to ABX. I also tried --vbr-old switch and results were much better.

---

The second most popular lossy codec in the world, AAC-LC.
Using qaac 2.71 with CoreAudioToolbox 7.10.9.0.
qaac64 -V127 input.wav

Spoiler (click to show/hide)
I went with the highest quality setting -V127 but the problem is still there.
Drum hit at the beginning sounds different. Easy to ABX.

---

Opus, the most promising codec at the moment.
Using opus-tools-0.2-opus-1.3.1.zip from https://opus-codec.org/.
opusenc --bitrate 128 input.wav

Spoiler (click to show/hide)
English is not my primary language so I really don't know how to explain the difference that I can hear.
It is right around half a second. I also included the file encoded at 64 kbit/s that is very easy to ABX
and once you hear the difference you will know what exactly you need to listen to.

As you can see, I also had to change my sound card. My USB sound card just skips first ~two seconds on Opus
so I had to use PCIe card.

---

Everybody is focused on exhale now so let's test it.
Using latest exhale 1.0.8 from RareWares.
exhale 9 input.wav

Spoiler (click to show/hide)
Lower bitrates were not really good so I tried with higher bitrates. Still terrible. Deaf person can ABX this.
Not many people have xHE-AAC decoder so I also included the decoded file.

I cannot edit the original post so I apologize for double posting.
I just noticed this: DSD : WASAPI (event) : Izlaz (ASUS Xonar DGX Audio Device), 24-bit
I don't have any DSD device so I have probably chosen this by mistake.
Anyway, I didn't want that to affect the results so I redid the test using normal WASAPI.
Still not transparent.

Opus:

Spoiler (click to show/hide)
exhale:

Spoiler (click to show/hide)

This may not be of much help but from the Mega download the V0 version created with lame 3.100 has this really obvious additional noise on the beats in the beginning.
Even at V3 with an old 3.98 version this is way better.

AAC & LAME V0 --vbr new both have horrid pre echo clicks enough i don't need ABX to tell. Yet Opus & Vorbis are transparent at 160kbps. Never seen AAC perform so badly here.

Try alternative Noise shaping mode;

-V0  --vbr-new -f

Try alternative Noise shaping mode;

-V0  --vbr-new -f

Or try --allshort V 0 --vbr-new, Had way more gains with samples in the OP.

I tried Helix mp3 encoder on this sample using the -X2 -U2 -V130 setting.
Result is pretty good (good enough for me) though bitrate is rather low.

So it is not necessarily the format when an encoder yields a very bad result.

I also tried the suggestions given in this thread for Lame. To me they don't work. It is true that 3.98 behaves better than 3.100, but is still easy to abx.

 I tried different lowpass settings. listening relaxed on my speakers.
-V0 obvious 'thwack' added to drum.
-V0 -- lowpass 17 up to 18 is an improvement, OR  -V0 --vbr-old
 
--abr 256 ads  'clicks' to the drum
--abr 256 -h same but a bit better
--abr 287 -h sounds fixed or not annoying, I'll need abx with headphones
CBR is OK but -b128, -b160 likely b192 suffers ringing on the 'tssssiiiouuuu' part.
adding -f to CBR mode really helps.
-b224 and -b256 sound good enough than I will need headphone abx.

Given this, I  used cbr 160 gogo and -b160 -f lame on older portables.
For compatibility, size and predictability. My gut instincts turned out right.
I didn't need all the fancy, new or whatever back then. Even now I will use
these settings if needed. Or higher cbr up to 320.  Or, ABR 287 -h. Then --vbr-old also worked
for me well , --preset medium 3.90 which is now -V4 --vbr-old. Lame 3.90 -V2 or aps (vbr-old)
was tough for me in most cases (in the past). On lame3.100 I would use -V1 --vbr-old to get an 'aps' like level.
I've never been fully comfortable with vbr-new (angels fall first) though seduced by its speed.
But no more, stabilty over speed for me.

Update; -f screws up the cbr  on the drums, So it works for certain signals but not for others
like the drum part. Just tried -h or -q2 -b192. Its also ads something like -f but less. On around -b224 -h
its not as obvious. 

Now my opinion for -h or -f isn't clear. But i decided for high bitrates i won't use them
and just stick to the default (-q3) for cbr.  -b192 sound much cleaner without them. Also -ms makes it
worse. I tried -V4 --vbr-old 'preset medium'  and it still holds up. -V5 --vbr-old ads  some noise.

Tried lame 3.90.3 and 3.98.4

vbr new V0 is still faulty on 3.98.4 not hard to hear as halb27 said.
3.90.3 V2 (aps) is ok or close as is aps fast ( --preset fast standard)
Strangely, --preset fast extreme adds some noise not very hard to hear.
--preset extreme is better.  I am not convinced its a lame3.100 only issue.

Tried MPC --radio 92kbps , sounds identical or close.
FAAC also falls hard up to -b256.  On -b320 and -b352 I can't hear it on speakers anyway.

Given this, I am happy with spotify's choice of vorbis  160k and 320k

@shadowking
Are you willing to try Lame 3.100 --abr 256 -f --lowpass 16?
I think it should be better.

Unfortunately,  Wavpack is also a disaster with the default
noise shaping . Setting it to -s0 or -s0.5 sorts it out .

Fortunately, even with default noise shaping its hard to detect around 400k

@shadowking
Are you willing to try Lame 3.100 --abr 256 -f --lowpass 16?
I think it should be better.

Better but still not good. I though abr / cbr behave like  the -Y switch. Not sure.

Fortunately, even with default noise shaping its hard to detect around 400k

So you could say is transparent at 400k?
Did you use additional quality switches like hx4?
I would like to test it at -b450hh which I use but I'm not a trained listener.
Definitely nice sample. :)

Dualstream  needed up to --Quality 7.  Wavpack 500 something.  Using headphones.
If you look at spectum the hf spike causes extra noise in various codecs . That would explain
why lowpass helped.

lame -b320 is abxable, though not bad quality:

foo_abx 1.3.4 report
foobar2000 v1.5.7
2021/07/15 01:29:38

File A: H:\doc\CodecTest 16bit.wav
File B: H:\doc\CodecTest 16bit.mp3

01:29:38 : Test started.
01:29:48 : 01/01  50.0%
01:29:52 : 02/02  25.0%
01:29:54 : 03/03  12.5%
01:30:13 : 04/04  6.3%
01:30:40 : 05/05  3.1%
01:30:48 : 06/06  1.6%
01:30:53 : 07/07  0.8%
01:31:02 : 08/08  0.4%
01:31:04 : Test finished.

 ----------
Total: 8/8 (0.4%)

Quote from: shadowking on 2021-07-14 14:20:58

Fortunately, even with default noise shaping its hard to detect around 400k

So you could say is transparent at 400k?
Did you use additional quality switches like hx4?
I would like to test it at -b450hh which I use but I'm not a trained listener.
Definitely nice sample. :)

With speakers 400k hx4 seemed near transparent, still got 8/8,
with headphones  ;

transparent
500 .. 550k -hx4 -s0.5
530 -hhs0.5
576 -s0.5
576 -hx4
---
450 -hhs0.5 not annoying abxable

@shadowking:
Nice to hear that Lame CBR >200 kbps works pretty good here. Same goes for the lowpass finding.
Thanks for that.

Because of the lowpass finding I tried my own Lame version lame3995o -Q1.7 --lowpass 16 (199 kbps on avg for a collection of mixed pop music).
Works very well. Doing a quick ABX I didn't succeed.
Good enough for me as with normal listening I listen less carefully than even with my quick ABX.
Being old I don't care about lowpass 16. Only young people should, or those with the golden ears.
Guess that's also the reason why Helix behaves that well. Helix isn't HF friendly.

P.S. one day later:
Must have had a bad day yesterday.  -Q1.7 --lowpass 16 is still rather easily to ABX. Though quality isn't too bad for me. But same goes for --lowpass 17 so I prefer this one now.

Quote from: synclagz on 2021-07-14 16:24:12

Quote from: shadowking on 2021-07-14 14:20:58

Fortunately, even with default noise shaping its hard to detect around 400k

So you could say is transparent at 400k?
Did you use additional quality switches like hx4?
I would like to test it at -b450hh which I use but I'm not a trained listener.
Definitely nice sample. :)

With speakers 400k hx4 seemed near transparent, still got 8/8,
with headphones  ;

transparent
500 .. 550k -hx4 -s0.5
530 -hhs0.5
576 -s0.5
576 -hx4
---
450 -hhs0.5 not annoying abxable

Thanks a lot for this testing. ;)
It seems that my setup is not enough. I didn't expect that.
Probably should go to 550hh or something similar to be sure but it's not longer economical (for me).
How would you describe quality at 450k?
Is this noise small and hard to hear or it's noticable immediately?

Tried MPC --radio 92kbps , sounds identical or close.

Would you say this is more down to it being a sub-band codec?

Would it also mean -quality 5 and up as being probably safe choices (to your ears at least)?

550hh

foo_abx 2.0.6d report
foobar2000 v1.6.6
2021-07-14 20:50:02

File A: master.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: 550hh.wav
SHA1: 1bd0b77cac5d8faaf6bebcbf7c18dd40211478b6

Output:
Default : Primary Sound Driver
Crossfading: NO

20:50:02 : Test started.
20:50:18 : 01/01
20:50:22 : 02/02
20:50:26 : 03/03
20:50:45 : 04/04
20:50:48 : 05/05
20:50:57 : 06/06
20:51:03 : 07/07
20:51:11 : 08/08
20:51:23 : 08/09
20:51:27 : 09/10
20:51:27 : Test finished.

 ---------- 
Total: 9/10
p-value: 0.0107 (1.07%)

 -- signature -- 
36ec4cd6873af7c712e52287ca376cd269788b39

Fan is working behind me + ears are filled with seawater.
If I focus it could be 10/10...
Best way to describe it? Like earbud diaphragm shakes little bit more.

Edit: Fan off + clean ears

foo_abx 2.0.6d report
foobar2000 v1.6.6
2021-07-14 21:08:59

File A: master.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: 550hh.wav
SHA1: 1bd0b77cac5d8faaf6bebcbf7c18dd40211478b6

Output:
Default : Primary Sound Driver
Crossfading: NO

21:08:59 : Test started.
21:09:11 : 01/01
21:09:15 : 02/02
21:09:37 : 03/03
21:09:42 : 04/04
21:09:45 : 05/05
21:09:48 : 06/06
21:09:52 : 07/07
21:09:54 : 08/08
21:09:57 : 09/09
21:10:00 : 10/10
21:10:00 : Test finished.

 ---------- 
Total: 10/10
p-value: 0.001 (0.1%)

 -- signature -- 
6540c0afb1ca7afac5d380502729d081a07307aa

Thanks @Markuza97
So even 550hh is not enough. :D
Do you think that you could hear the difference in normal listening situation (wavpack 550hh)?

In normal listening situation? No way.

It has more to do with memory. First I have to spend ~10-15 seconds to actually hear the difference so I can isolate it and focus on it.
Then in the middle of the test my brain.exe will stop working and I will have to re-listen to it once again so I can isolate it and finish the test.

Edit: I recorded the video of me ABXing it. You can clearly see how my brain stops working on third and tenth trial.
Spoiler (click to show/hide)
Edit 2: MPC sounds great! I'm not even going to try to ABX it.
but............. I am still using the old (unsupported) MPC-HC v1.7.13 and file sounds terrible there.
I guess there is something wrong with their decoder. Anyway, once imported into foobar, its sounds great!
So be careful if you use old audio players.

Off-topic: This is not the first time I am impressed with MPC. It really makes me wonder why this format is not more widely supported.

I see. That is imortant for me to know. Hard to make a difference even on abx.
Thanks a lot.

I see. That is imortant for me to know. Hard to make a difference even on abx.
Thanks a lot.

You can use static noise shaping value like -s0.5 (-b450hhs0.5)
This will shift noise to the higher freq.  In this sample the default setting cause the noise to go
down the spectrum where it has a more audiable or static character.
If encoding time isn't an issue, try  -b450hhx4s0.5

There is an updated MPC-HC . Its from one of the mpc developers. Works well for me.
https://github.com/clsid2/mpc-hc/releases

Wow, what on earth is this killer sample? I can ABX it with 100% accuracy even at Apple AAC 320k CVBR (!!!!!!!!!??!?!?). I almost can't believe it. What about this file is so difficult that it trips up even the highest of quality lossy encoding?

Ok, seems like the Apple encoder specifically gets tripped up by it for some reason. Opus manages the sample fine at even 192k VBR.

Wow, what on earth is this killer sample? I can ABX it with 100% accuracy even at Apple AAC 320k CVBR (!!!!!!!!!??!?!?). I almost can't believe it. What about this file is so difficult that it trips up even the highest of quality lossy encoding?

I think its the loud HF noise in the beginning. The drum causes the noise to modulate up and down.
Down the the spectrum it becomes audiable as distortion, ringing, noise etc.
I would be surprised if its from a properly mastered album etc.  A lower lowpass or static noiseshaping
to push the noise up helps.

I think its the loud HF noise in the beginning. The drum causes the noise to modulate up and down.
Down the the spectrum it becomes audiable as distortion, ringing, noise etc.
I would be surprised if its from a properly mastered album etc.  A lower lowpass or static noiseshaping
to push the noise up helps.

I do wonder why Opus handles the file fine compared to CoreAudio encoder. I'm almost tempted to re-encode my mobile library from AAC to Opus due to this killer sample, just due to the implication of libopus' ability to handle edge cases better than CoreAudio can. But maybe I'm just being paranoid and overreacting.

Quote from: synclagz on 2021-07-14 22:33:22

I see. That is imortant for me to know. Hard to make a difference even on abx.
Thanks a lot.

You can use static noise shaping value like -s0.5 (-b450hhs0.5)
This will shift noise to the higher freq.  In this sample the default setting cause the noise to go
down the spectrum where it has a more audiable or static character.
If encoding time isn't an issue, try  -b450hhx4s0.5

Thanks for the advice. ;) I'll play with different settings and this -s0.5 also.

Quote from: shadowking on 2021-07-15 09:19:56

I think its the loud HF noise in the beginning. The drum causes the noise to modulate up and down.
Down the the spectrum it becomes audiable as distortion, ringing, noise etc.
I would be surprised if its from a properly mastered album etc.  A lower lowpass or static noiseshaping
to push the noise up helps.

I do wonder why Opus handles the file fine compared to CoreAudio encoder. I'm almost tempted to re-encode my mobile library from AAC to Opus due to this killer sample, just due to the implication of libopus' ability to handle edge cases better than CoreAudio can. But maybe I'm just being paranoid and overreacting.

If you have natural music or a bit of electronic your fine. If you have lots of this style, with
HF 'pfffftssss' , high pitch tones, etc  You may need to experiment to find a non-annoying setting.
I guess at 320k transparency is expected or at worst case a not-annoying level.

Quote from: shadowking on 2021-07-14 13:08:24

Tried MPC --radio 92kbps , sounds identical or close.

Would you say this is more down to it being a sub-band codec?

Would it also mean -quality 5 and up as being probably safe choices (to your ears at least)?

It may have something with subband. Its immune to pre echo
and some other issues of mp3 /aac.

I tried quality 5 with headphones. It seems transparent.
Yes, Quality 5 is the work horse of mpc, that or Quality 6 gives
a small size - much smaller than 256 or 320k. in mp3 case its -b320k to
get an OK quality (-b256 is bad).  VS mpc --standard 119 k  !!!

Off-topic: This is not the first time I am impressed with MPC. It really makes me wonder why this format is not more widely supported.

Me too. In the past I posted 'I would take Quality 5 or 6 mpc over 256 ~ 320k mp3 / aac'
it did not go down well, But that was my gut instinct. This sample further confirms it for me.

Yes support and lack of interest is frustrating. People figure newer codec = better etc. MPC is seen as old , dead or whatever.
Also at low bitrate less than 96k its no good. But I could care less for that personally. You can have magnificent audio
170k streaming or local. We are not pinned to 128k as there is enough bandwidth today. But for business its all about
32, 64k etc or how far down they can push it.

Quote from: shadowking on 2021-07-15 03:33:03

Quote from: synclagz on 2021-07-14 22:33:22

I see. That is imortant for me to know. Hard to make a difference even on abx.
Thanks a lot.

You can use static noise shaping value like -s0.5 (-b450hhs0.5)
This will shift noise to the higher freq.  In this sample the default setting cause the noise to go
down the spectrum where it has a more audiable or static character.
If encoding time isn't an issue, try  -b450hhx4s0.5

Thanks for the advice. ;) I'll play with different settings and this -s0.5 also.

I managed to get 400k to an acceptable level using -hhx5s0.5 .  I got 6/8 and 7/8
for 384 and 400.  With hhx4s0.5  -  450 was 8/8 though very subtle. I think the x5 helps
quite a bit .

I'll try x5 to see if I can hear any differences.

As for MPC, I think that today with foobar for Android/Windows + Linux (wine) we don't have compatibility issues. For cars someone could connect through BT or even old aux in should do fine. :)

Small request:
Is someone willing to test FhG (winamp) AAC at 320 CBR?
In recent Listening tests, Guruboolez found out that FhG aac is more robust against problem samples (if I remember correctly) so it would be interesting to see if FhG can do something about this sample (when Apple AAC can't)

I also tried a stronger shift -s0.75 and its more difficult to abx. I stopped at
1/4  for -b400hhx5s0.75  . With s0.5, I managed several  5/5 's

for -b450hhx5s0.75 i got 5/8

fhg

--cbr 320
Fail. I keep getting 7/10

--cbr 256

foo_abx 2.0.6d report
foobar2000 v1.6.6
2021-07-15 15:02:40

File A: master.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: cbr256.m4a
SHA1: 9f2b56f5b6241f0a4c78344a21fe88940b990895

Output:
Default : Primary Sound Driver
Crossfading: NO

15:02:40 : Test started.
15:02:49 : 01/01
15:02:58 : 02/02
15:03:05 : 03/03
15:03:14 : 04/04
15:03:19 : 05/05
15:03:25 : 06/06
15:03:27 : 07/07
15:03:30 : 08/08
15:03:32 : 09/09
15:03:41 : 10/10
15:03:41 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

 -- signature --
48b50559f6f0d7692f2a92f6339c92e0d0f267e7

--vbr 6

foo_abx 2.0.6d report
foobar2000 v1.6.6
2021-07-15 14:48:22

File A: master.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: vbr.m4a
SHA1: 5770475576a1270cbcab7341034cc5af567f8669

Output:
Default : Primary Sound Driver
Crossfading: NO

14:48:22 : Test started.
14:48:27 : 01/01
14:48:29 : 02/02
14:48:40 : 03/03
14:48:43 : 04/04
14:48:45 : 05/05
14:48:47 : 06/06
14:48:50 : 07/07
14:48:53 : 08/08
14:48:55 : 09/09
14:48:58 : 10/10
14:48:58 : Test finished.

 ---------- 
Total: 10/10
p-value: 0.001 (0.1%)

 -- signature -- 
6f985f8eef8549cd6960567b9f4b4547fdce9408

@Markuza97
Excellent! Thanks.
FhG @320k should be very good.
Definitely more robust against problem samples. :)

Quote from: includemeout on 2021-07-14 19:06:18

Quote from: shadowking on 2021-07-14 13:08:24

Tried MPC --radio 92kbps , sounds identical or close.

Would you say this is more down to it being a sub-band codec?

Would it also mean -quality 5 and up as being probably safe choices (to your ears at least)?

It may have something with subband. Its immune to pre echo
and some other issues of mp3 /aac.

I tried quality 5 with headphones. It seems transparent.
Yes, Quality 5 is the work horse of mpc, that or Quality 6 gives
a small size - much smaller than 256 or 320k. in mp3 case its -b320k to
get an OK quality (-b256 is bad).  VS mpc --standard 119 k  !!!

As usual, thank you so much for your invaluable, countless testing, SK.

As for MPC, I think that today with foobar for Android/Windows + Linux (wine) we don't have compatibility issues. For cars someone could connect through BT or even old aux in should do fine. :)

Hear, hear!

No to mention for -quality 5 and above - for in-car listening - transcoding into MP3, thanks also to the insignificant amount of time taken in the process these days - it definitely a plausible proposition as well.

Popularity or no popularity, I guess there just ain't many reasons, as it used to be the case 15 yrs ago, for "feeling guilty" for sticking to MPC (if that's your cuppa) - even more so after smartphones came up, given that many recent killer samples, as this one, haven't been making too much of a dent even in its "standard" setting - two frickin’ decades later, FCS!!

Edit:
Musepack may have fallen from grace, but it's still to be proven (for +160Kbps) to be out of shape.

Quote from: shadowking on 2021-07-15 09:19:56

I think its the loud HF noise in the beginning. The drum causes the noise to modulate up and down.
Down the the spectrum it becomes audiable as distortion, ringing, noise etc.
I would be surprised if its from a properly mastered album etc.  A lower lowpass or static noiseshaping
to push the noise up helps.

I do wonder why Opus handles the file fine compared to CoreAudio encoder. I'm almost tempted to re-encode my mobile library from AAC to Opus due to this killer sample, just due to the implication of libopus' ability to handle edge cases better than CoreAudio can. But maybe I'm just being paranoid and overreacting.

Much better handling of HF & hard transients?. This is not the only sample that CoreAudio struggles with, It seems to hate the synth sounds that my Dark Ambient collection uses. V0 Lame with old-vbr is transparent but AAC as a whole fails at 320kbps, Yet MPC wins at a half the bit rate?.

It weird how hostile some here get when Musepack's strengths are pointed out despite the fact there like 12 examples alone in this forum where Q5 pretty much transparent. Both Opus/MPC are the only ones so far that have proved to be robust on killer samples.

It weird how hostile some here get when Musepack's strengths are pointed out despite the fact there like 12 examples alone in this forum where Q5 pretty much transparent. Both Opus/MPC are the only ones so far that have proved to be robust on killer samples.

Can't you at least post results of abx tests and samples so that you can back up your claim?

Besides, there are samples which Musepack struggles with at Quality 5.
https://www.audiosciencereview.com/forum/index.php?threads/musepack-vs-other-codecs.23601/post-791881

Quote from: ani_Jackal3 on 2021-07-16 17:11:04

It weird how hostile some here get when Musepack's strengths are pointed out despite the fact there like 12 examples alone in this forum where Q5 pretty much transparent. Both Opus/MPC are the only ones so far that have proved to be robust on killer samples.

Can't you at least post results of abx tests and samples so that you can back up your claim?

Besides, there are samples which Musepack struggles with at Quality 5.
https://www.audiosciencereview.com/forum/index.php?threads/musepack-vs-other-codecs.23601/post-791881

https://www.audiosciencereview.com/forum/index.php?threads/musepack-vs-other-codecs.23601/#post-849256

Just did that with Q5 MPC both were transparent, There all electronic samples and some old MP3 aimed ones. It just backs up that Pure MDCT codecs can't cope without something breaking and need a encoder patch.

Quote from: ani_Jackal3 on 2021-07-16 17:11:04

It weird how hostile some here get when Musepack's strengths are pointed out despite the fact there like 12 examples alone in this forum where Q5 pretty much transparent. Both Opus/MPC are the only ones so far that have proved to be robust on killer samples.

Besides, there are samples which Musepack struggles with at Quality 5.
https://www.audiosciencereview.com/forum/index.php?threads/musepack-vs-other-codecs.23601/post-791881

We've all been well aware of those. So far nobody said there weren't; at least not in this thread.

That guy is using a lot of DSPs in his test. Is it fair to use DSP effects while doing ABX test?
I mean, I just grabbed a random song, encoded using LAME V2. It sounds great, fully transparent.
Then I activated built-in Equalizer DSP to reduce lower and increase higher frequecies. LAME obviously has lowpass
and lossless will obviously win. Very easy to cheat the ABX.

Besides, there are samples which Musepack struggles with at Quality 5.
https://www.audiosciencereview.com/forum/index.php?threads/musepack-vs-other-codecs.23601/post-791881

Nice link, but we needn't even leave HA's subforums in order to illustrate that:
We've been talking about those all the time - as recently as two years ago - and with people who'd apparently worked closely with the developers, such as @Kristo.

https://hydrogenaud.io/index.php?topic=117174.0

I think the bottom line regarding comments towards MPC here, is that given its mileage (and the aeons that have passed since it was last updated) how its standard setting (or something slightly above/below that but still sticking to fairly average bit rates) still manages to fare quite well when it comes to several killer samples - but not in detriment to this or that "competing" format.

That guy is using a lot of DSPs in his test.

Sorry, but for clarity's sake, you mean the person in the link provided by OLPP, right?

Quote from: Markuza97 on 2021-07-17 13:18:49

That guy is using a lot of DSPs in his test.

Sorry, but for clarity's sake, you mean the person in the link provided by OLPP, right?

Yes. I don't care what anyone says. That test is invalid.
That guy is literally comparing two entirely different files.

That guy is using a lot of DSPs in his test.

That guy is literally comparing two entirely different files.

I am going to assume that 'that guy' in the first quote and the second quote are two different people. I am 'that guy' of the first quote. I use the nickname 'UKPI' in audiosciencereview.

Among those DSP modules, Equalizer and IIR filters are used to match my headphones closer to the Harman target. Nothing more, nothing less. Scale is volume control. Meier crossfeed is crossfeed. The rest is self-explanatory. The difference of frequency responses between different headphones would usually be much larger than the difference of frequency response caused by the DSPs I used. If my test is invalid because of DSP usage, that would mean that only a handful of headphones can be used to test lossy codecs.

Just did that with Q5 MPC both were transparent, There all electronic samples and some old MP3 aimed ones. It just backs up that Pure MDCT codecs can't cope without something breaking and need a encoder patch.

So, you were the 'that guy' of Markuza97's second quote? Okay then.
The result of the second test just proves that different people have different sensitivities to different coding artifacts. Like I said in the link, there are only speculations without a test involving multiple listeners with multiple samples. Also, why did you compare 41_30sec.wv to velvet.mpc?

I think the bottom line regarding comments towards MPC here, is that given its mileage (and the aeons that have passed since it was last updated) how its standard setting (or something slightly above/below that but still sticking to fairly average bit rates) still manages to fare quite well when it comes to several killer samples - but not in detriment to this or that "competing" format.

I do agree with that. I was just tired of posts praising Musepack as "the" superior codec without sufficient evidence.

By the way, sorry for derailing this thread. That sample certainly is interesting.

I am talking about you OLPP-UKPI.
You were using files from "different" sources for ABXing.

I dunno how to explain this properly.........
I will just repeat what I posted above.

Let's take MP3 for example.
Original lossless file doesn't have lots of useful stuff above 16 kHz.
LAME will see this and it will decide to cut it to save space.
Let's add lossless and MP3 file to foobar.
It sounds dull. We can use DSP to enhance higher frequencies. Lossless will sound great because it preserves whole frequency range.
MP3 will sound terrible because it doesn't actually have any higher frequencies to enhance.
If you applied DSP effects to lossless file and then converted to MP3 situation would be different.

I am not saying that MPC is God sent format that nobody can ABX. I am just saying that if you want to do fair test, do not use any DSP effects while playing.

Maybe a little easier way to understand.

You have 1920x1080 PNG image (FLAC). Size is huge. You decided to convert it to JPG (MP3/MPC).
After conversion they will look identical (transparent).
Now you decided to upscale the image to 7680x4320 (DSP).
JPG will look a lot worse because you increased the compression artifacts.
But if you first upscaled the PNG image to 7680x4320 and then converted to JPG it will look identical.

Let's take MP3 for example.
Original lossless file doesn't have lots of useful stuff above 16 kHz.
LAME will see this and it will decide to cut it to save space.
Let's add lossless and MP3 file to foobar.
It sounds dull. We can use DSP to enhance higher frequencies. Lossless will sound great because it preserves whole frequency range.
MP3 will sound terrible because it doesn't actually have any higher frequencies to enhance.
If you applied DSP effects to lossless file and then converted to MP3 situation would be different.

I am just saying that if you want to do fair test, do not use any DSP effects while playing.

Different models of headphones, earbuds or speakers in various rooms all have their own unique frequency responses and distortion levels. Just like DSPs, these all affect the audio chain after decoding the file/stream. Therefore, in the example of the quote above, MP3 that sounds terrible by the boost from the equalizer would still sound terrible when that boost is occurred by a headphone.

What makes changes occurred by DSPs unacceptable while those caused by using different equipment acceptable in lossy codec tests?

Also, tests with files that were processed before encoding do not reflect most real-life use cases. No music downloading/streaming services that I know of provide custom processed lossy streams. Consumers decode the stream and process that.

Yes, they do affect the audio chain after decoding ...
... but encoder does not expect any processing after decoding.
It is tuned/optimized for original unprocessed file.
Encoder has no idea what you are going to do with your files later.

With lossless files you have lots of bits to work with, with lossy ~192 kbit/s you don't.
Any kind of processing will make it much easier to ABX.
This is the reason why we always use lossless files when encoding lossy files.

Using DSPs for listening is okay, but for ABXing is not.
You want to be as neutral as possible.

Sure, some people are using DSPs for lossy files and it sounds good to them because:
1. They are playing music, not doing ABX test
2. They don't have original lossless file to compare it with

It's headphone frequency response equalization filtering. It is tuned based on an accurate digital recording of the headphones' own frequency response curve, and is designed to produce a flat response after the correction is applied. To say that this sort of correction is invalid, is the same thing as saying that testing with any headphones which do not already have a perfectly flat response is also invalid.

It doesn't matter what kind of DSP you are using - the only important thing is that it does processing.
With lossy files it is working with 192000 (you get the idea, no need to nitpick) bits of information.
With lossless files it is working with at least 1411200 bits of information.
DSPs might be transparent, but that doesn't change the fact that chance of audible artifacts is increased.

Using the same logic as you guys, I can grab 128 kbit/s MP3 file, convert it to Opus and cry online because it is not transparent.
Of course it is not transparent because it was already processed by another encoder that reduced the available bits of information.

Like I said above, using DSP for listening is good, but for ABX, big no-no.

You can say the same damn thing about headphones making the audio not transparent and that tests should only be performed with the best studio monitors in a recording studio.

Using the same logic as you guys, I can grab 128 kbit/s MP3 file, convert it to Opus and cry online because it is not transparent.
Of course it is not transparent because it was already processed by another encoder that reduced the available bits of information.

What...?

Okay, that's enough. An equalizer and a lossy encoder are totally different types of processing altogether and you just equated those.

-What does the frequency response of a linear time invariant system tell you about that system?
-What should you do with the frequency domain transfer functions of each linear time invariant system connected in series in order to acquire an accurate frequency response of the entire connected system?
-How do digital equalizers change the frequency level of a signal? Can you explain the difference between FIR and IIR filters?
-What is room correction and why is it absolutely necessary for accurate audio reproduction with speakers unless you are in an anechoic chamber?
-Why is just blindly compensating for the measurements of a headphone not a good way of obtaining a perfect target curve for you even when the measurement of that headphone is accurate?

If you don't know the answer to the questions above, you are talking out of your depth. If you know the answer to those questions and don't tell me a plausible reason why DSPs shouldn't be used in ABX tests when difference between gears and rooms are larger but acceptable, you are trolling and I am not going to take your response seriously.

So, please answer the question: Both DSPs and headphones, earbuds, speakers, and rooms etc. change the frequency response of the signal. Therefore, it can be said that both the former and the latter "process" the signal. Why is processing by the former unacceptable, but that of the latter acceptable in ABX testing? You have to explain the difference between "processing" by the former and latter.

You can say the same damn thing about headphones making the audio not transparent and that tests should only be performed with the best studio monitors in a recording studio.

I've not read most of this thread because it's totally off the rails now. However, I agree with this statement and would add "with qualified listeners".

This is a great example of how ABX testing is only valid for the listener and the files tested. You can't really extrapolate from the results. I mean, for god sake, this test file is just boring, generic dance music. I could find 100 examples of this "filtered white noise over kick drum" technique.

Quote from: synclagz on 2021-07-14 22:33:22

I see. That is imortant for me to know. Hard to make a difference even on abx.
Thanks a lot.

You can use static noise shaping value like -s0.5 (-b450hhs0.5)
This will shift noise to the higher freq.

Do you think that is safe to use -s0.5 in general?

I've finally decided to do an ABX test with Wavpack -b450hh and Apple 320k  CVBR to see if I can hear the artifacts.
WavPack is obvious (unacceptable for my setup). Apple is more subtle and I think I woudn't hear it in normal listening situation (maybe on very loud volume but I'm not sure).

I have to point out that I'm not a trained listener (at least until now :D).

Sound: Lenovo Thinkpad E595 - standard output (Volume 90%)
Headphones: Audio Technica ATH-M40X

WavPack -b450hh

foo_abx 2.0.6c report
foobar2000 v1.4.8
2021-07-19 11:29:42

File A: CodecTest 16-bit.flac
SHA1: fa044d2f4662f4689707666fe971d64d4882093b
File B: CodecTest 16-bit.wv
SHA1: e55b262a8685148d7d4230ca7095683fd1a2479b

Output:
DS : Primary Sound Driver
Crossfading: NO

11:29:42 : Test started.
11:32:44 : 01/01
11:33:06 : 02/02
11:33:32 : 03/03
11:33:45 : 04/04
11:33:56 : 05/05
11:34:02 : 06/06
11:34:14 : 07/07
11:34:22 : 08/08
11:34:27 : 09/09
11:34:31 : 10/10
11:34:31 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

Apple 320k CVBR

foo_abx 2.0.6c report
foobar2000 v1.4.8
2021-07-19 11:39:16

File A: CodecTest 16-bit.flac
SHA1: fa044d2f4662f4689707666fe971d64d4882093b
File B: CodecTest 16-bit.m4a
SHA1: 5c568899f4d3dec7767c77ad45734ff0b305b86e

Output:
DS : Primary Sound Driver
Crossfading: NO

11:39:16 : Test started.
11:41:42 : 01/01
11:41:57 : 02/02
11:42:15 : 03/03
11:42:31 : 04/04
11:42:47 : 05/05
11:43:28 : 06/06
11:43:44 : 07/07
11:43:53 : 08/08
11:44:23 : 09/09
11:44:46 : 10/10
11:44:46 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

Quote from: shadowking on 2021-07-15 03:33:03

Quote from: synclagz on 2021-07-14 22:33:22

I see. That is imortant for me to know. Hard to make a difference even on abx.
Thanks a lot.

You can use static noise shaping value like -s0.5 (-b450hhs0.5)
This will shift noise to the higher freq.

Do you think that is safe to use -s0.5 in general?

Yes. Especially at high bitrate.

Quote from: synclagz on 2021-07-19 10:07:06

You can use static noise shaping value like -s0.5 (-b450hhs0.5)
This will shift noise to the higher freq.

Do you think that is safe to use -s0.5 in general?

Yes. Especially at high bitrate.
[/quote]

Excellent! Thanks. I'll play with s0.5 to see the differecies.

Out of curiosity I've tried to ABX Aften AC3 @320k but I couldn't do it.
I always thought that AC3 is kind of lower quality but this sample surprised me.

@shadowking
I've tried the -s0.5 switch and it really helps.
450hhs0.5 is definitely better than 450hh.

Out of curiosity I've tried to ABX Aften AC3 @320k but I couldn't do it.
I always thought that AC3 is kind of lower quality but this sample surprised me.

Considering that MDCT-based codecs seem to be having a tougher time (than the subbands ones) with this sample in particular, plus you not having done any additional tweakening to AC3's settings, this seems to be really worth mentioning.

At that point, it may even be worth investigating hybrid lossy/lossless codecs, or even lower bitrate ADPCM codecs. Those usually expose degradation as noise, which depending, may not be as noticeable, or may be a less annoying form of distortion. You pick your poison, hissing that's way less than tape hiss, versus smearing artifacts, or other things.

I mean, ADPCM is a preferred A2DP codec, even. AptX and its relatives are a subband ADPCM codec.

Quote from: synclagz on 2021-07-21 06:57:53

Out of curiosity I've tried to ABX Aften AC3 @320k but I couldn't do it.
I always thought that AC3 is kind of lower quality but this sample surprised me.

Considering that MDCT-based codecs seem to be having a tougher time (than the subbands ones) with this sample in particular, plus you not having done any additional tweakening to AC3's settings, this seems to be really worth mentioning.

Especially considering is still very popular for movie audio.

At that point, it may even be worth investigating hybrid lossy/lossless codecs, or even lower bitrate ADPCM codecs. Those usually expose degradation as noise, which depending, may not be as noticeable, or may be a less annoying form of distortion. You pick your poison, hissing that's way less than tape hiss, versus smearing artifacts, or other things.

I mean, ADPCM is a preferred A2DP codec, even. AptX and its relatives are a subband ADPCM codec.

My experience with wavpack so far is very positive. Small, very fine hiss could be heard very rarely on critical samples,
but on this sample is further distorted into  more aggressive noise (it is still minor issue but it stands out - very fine hiss is more blended into music, at least as I percieve it)
Reminds me of shaking wired fence. I don't know how to descibe it more accurately.

Out of curiosity I've tried to ABX Aften AC3 @320k but I couldn't do it.
I always thought that AC3 is kind of lower quality but this sample surprised me.

Interesting. Tried ffmpeg's AC3 (more recent)?

Quote from: synclagz on 2021-07-21 06:57:53

Out of curiosity I've tried to ABX Aften AC3 @320k but I couldn't do it.
I always thought that AC3 is kind of lower quality but this sample surprised me.

Interesting. Tried ffmpeg's AC3 (more recent)?

Yes. Just few days ago I've tried Shanaencoder v5.04 which is basically frontend for ffmpeg. Same thing. I would say same quality (based on this sample).
Maybe someone with better ears and/or equipment could say something more about Aften/ffmpeg AC3 behavior on this sample, but considering how Apple AAC sounds, AC3 is better (to my ears).

I also tried Helix mp3 @320k CBR and V150 VBR (~230k). Also high quality. I didn'tbtry to ABX it but on normal listening throug headphones I coudn't make a difference.
I wonder why is not so popular as LAME is. Not to mention its extremly fast encoding speed.

Tried Lossy FLAC @ Economic 410k and couldn't ABX it.
Good alternative to wavpack, but i have very limited experience with Lossy Flac.
I'll definitely put some free time to LossyFlac testing.
It seems interesting.

It is true that 3.98 behaves better than 3.100, but is still easy to abx.

Even at V0?

Yes, I did it the way the OP did.

@synclagz:

I also wonder why helix isn't that popular. It has proved to be quite robust when it comes to problematic samples.
Guess one point is that HF behavior beyond 16 kHz isn't great with helix. Though this probably isn't a real issue to many people.
The idea of a 20...20000 Hz frequency range just is too popular though the range beyond 16 kHz can hardly be heard by most people older than 30. Also musical contents in the HF range is often of little importance for many pieces of music.

Other than good reasons it's chance to a large extent which controls popularity.

Also problems like this one are interesting but have no practical meaning to most people. These problems are often very artificial. Important are problems related to real instruments. Harpsichord music can be a problem to various encoders. But for people who are not much into this music it hardly applies. Very tonal regions in music can be a problem too when using low or moderate bitrate. Same goes for transients in music. But with a bitrate of roughly 200 kbps on avg. you're safe with many formats and encoders when listening to 'normal' music in a 'normal' listening environment. There are exceptions, but they are rare. Even 128 kbps is very good for many formats and encoders. Even old mp3 is good here when using Lame or Helix. Sure there are better formats like aac or opus, and using 200 kbps or more isn't an issue with today's storage possibilities.

LossyFLAC is a good thing for bitrates in the range you used. I did use lossyFLAC for a long time. However the popular lossy codecs are totally satisfying to me at a much lower bitrate.

@halb27
Hi,

Thanks for clarifying things about Helix. :)
Today I noticed that helix mp3 encoded files have higher track peak value than vorbis or aac (foobar replay gain scanner).
So I'm getting track peak value for some songs in 1.30 - 1.45 range which indicate potential clipping but I can't hear it.
Are these higher peak values of any concern?

As for LossyFlac, I can't find a critical sample to test it. IIRC, you said long time ago that herding_calls doesn't sound right. Do you still have that sample by any chance? I can't find it.

I also noteced that switching off noise shaping (-s o) drastically increases encoding speed of LossyFlac.
Using Standard or High preset sound excellent even without noise shaping.
Do you think that it can be safely switched off for higher presets (400-500k range) without sacrificing quality?

I wouldn't care about peak values >1 in encoded material. In case you do you can lower input in advance with a tool like Audacity or similar.

You can download herding_call from my webspace: http://horst-albrecht.de/misc/herding_calls.flac

I wouldn't switch off lossyFLAC noise shaping.

I wouldn't care about peak values >1 in encoded material. In case you do you can lower input in advance with a tool like Audacity or similar.

You can download herding_call from my webspace: http://horst-albrecht.de/misc/herding_calls.flac

I wouldn't switch off lossyFLAC noise shaping.

Thank you for herding_calls and clarifying things. :)
I'll test LossyFlac to see how this sample sounds on different settings.

EQ everything.  I was told by audiophiles to never do it. I have suffered for
years as a result. The treble is out of control in many speakers and headphones.
It may be a good thing for mixing but not for listening. I think the senheiser sound is
not a bad starting point maybe a bit veiled. I try to duplicate it with EQ. The same EQ
preset works for both speakers and phones.  I leave the low end , dial down mid bass and mid-top end.
it helps with samples like these and also your hearing. You can listen louder with less chances of damage.

 

Speaking of EQ, precise measurement with a calibrated input (microphone with known frequency response to capture the response of speakers in an acoustic dampening chamber, or dummy head with known response to capture headphones or earphones), this can and has been used by both professionals and volunteers to create equalization curves for specific models of speakers and headphones. They're likely to work for most devices in the same product line. They're designed to compensate for the biases or weaknesses in the response curve of the device, so they will produce as flat a response as is possible for the device in question.

As far as equalization is concerned, that's pretty much the only method I'd condone for production, and also for testing.

Hand tuning things can be fine, but could also result in noticing things that shouldn't affect casual listening. I recommend looking around for EQ presets for your exact model of device if you lack the equipment to calibrate it yourself. Of course, calibrating it by ear is probably okay to begin with, and may be better than forcing yourself to listen to horribly out of balance audio.

Check out AutoEq, they may have presets for your device:

https://github.com/jaakkopasanen/AutoEq

I made an interesting discovery today:
AppleAAC is better at 256k ABR q1 (quality 64) then 320 CVBR /ABR and ABR q1
(Complete guessing :D)
I also noticed that using q0 (quality 32) is very similar (the same actually to my ears) to q96 but much faster at inceased bitrate by 3-6%.

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-09-30 20:18:23

Apple AAC 256k ABR -q 1

File A: Electronica (Sample).flac
SHA1: fa044d2f4662f4689707666fe971d64d4882093b
File B: Electronica (Sample).m4a
SHA1: ec6767b7c2283cfc5b5ea9995f7361c688dcbace

Output:
Default : Primary Sound Driver
Crossfading: NO

20:18:23 : Test started.
20:19:11 : 00/01
20:19:20 : 01/02
20:19:46 : 02/03
20:19:52 : 02/04
20:20:15 : 02/05
20:20:33 : 02/06
20:20:50 : 02/07
20:20:57 : 02/08
20:21:09 : 02/09
20:21:35 : 02/10
20:21:35 : Test finished.

 ----------
Total: 2/10
p-value: 0.9893 (98.93%)

Also disappointment at WavPack -b576s0.5 (I thought it's transparent but is not)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-09-30 19:50:04

WavPack -b576s0.5

File A: Electronica (Sample).flac
SHA1: fa044d2f4662f4689707666fe971d64d4882093b
File B: Electronica (Sample).wv
SHA1: f5b91e438edd5fa2ca11d10faed34d07084d0ed2

Output:
Default : Primary Sound Driver
Crossfading: NO

19:50:04 : Test started.
19:51:02 : 01/01
19:51:22 : 02/02
19:51:31 : 03/03
19:51:38 : 04/04
19:51:46 : 05/05
19:51:53 : 06/06
19:52:01 : 07/07
19:52:13 : 08/08
19:52:22 : 09/09
19:52:29 : 10/10
19:52:29 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

And finally decided to test FDK AAC. When it fails even 512k CBR is not helping.

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-09-30 19:55:38

FDK_AAC 512k CBR

File A: Electronica (Sample).flac
SHA1: fa044d2f4662f4689707666fe971d64d4882093b
File B: Electronica (Sample).m4a
SHA1: 74214a5c2cf8ad0b5c8ad3daa189be7506219926

Output:
Default : Primary Sound Driver
Crossfading: NO

19:55:38 : Test started.
19:55:57 : 01/01
19:56:02 : 02/02
19:56:07 : 03/03
19:56:11 : 04/04
19:56:15 : 05/05
19:56:19 : 06/06
19:56:23 : 07/07
19:56:29 : 08/08
19:56:37 : 09/09
19:56:44 : 10/10
19:56:44 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

-a 256 -q 1

foo_abx 2.0.6d report
foobar2000 v1.6.7
2021-09-30 22:45:25

File A: sample.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: sample.m4a
SHA1: f99e74380a5ca37604486744e166cc0431761b19

Output:
Default : Primary Sound Driver [exclusive], 24-bit
Crossfading: NO

22:45:25 : Test started.
22:45:29 : 01/01
22:45:32 : 02/02
22:45:35 : 03/03
22:45:37 : 04/04
22:45:40 : 05/05
22:45:43 : 06/06
22:45:45 : 07/07
22:45:48 : 08/08
22:45:50 : 09/09
22:45:53 : 10/10
22:45:53 : Test finished.

 ---------- 
Total: 10/10
p-value: 0.001 (0.1%)

 -- signature -- 
8387998dc83ab8f6f01fdb9e00561925ee854b80

I gave up on trying to determine what's transparent to me, which is why I only store lossless and stream lossless now. Except for YouTube, who won't provide the option.

I find that old mp3 above 128k works in practically everything.
You can use 160k cbr as the most archaic setting. Even that will rarely cause
issues and works in any player ever made. Even here -b160 -h --lowpass 17 does a lot of work considering its
so antiquated and the small filesize.

The other thing that works is the hybrid encoding of wavpack. On the PC or home LAn,
playback / streaming is lossless.  When the .wv is copied to limited storage, the playback is lossy.
Something like -b256x4c has low overhead. Suppport on PC and Android is good via 3rd party..

AAC, Opus, Ogg  won't cut it for the reason;  Still not lossless,
Its not universal as mp3, rare samples can still be an issue.  Filesize of 256 or 320 is large when considering that the most archaic mp3  settings of -b160 or  192 do a lot of heavy lifting in an overall sense.

For those that only want lossy, MP3 above 128k or -b320 when you don't care for space is great.

Best:

-Use Lossless only if you can
-Use lossy+ lossless or hybrid coder
-If you have physical CD's and won't use lossless; Rip to Mp3

I fully agree with both of you.
Considering how cheap the space is these days, there is really no reason to use lossy anymore.
Unless you have compatibility or space problems, obviously.
16/44 FLACs are perfect.

I consider 128 kbit/s MP3 to not be good enough.
144 kbit/s is good, but you know the rules, once you find what sounds good enough
you should go one step above to play it on the safe side.
So I consider 160 kbit/s to be the lowest I can go with MP3.

One thing that I would really like to see is a test between LAME 3.97 and 3.100 at V0.
Lots of people are saying that LAME got dumbed-down after 3.97.
I personally find older LAME versions to be better at lower bitrates. I did some test at V6.
None of them were transparent of course, but I found 3.97 to sound more pleasant.
And I like older LAME's lowpass better. New one seems to be more generous.
I still don't understand why newer LAME versions have lowpass disabled on V0.

Maybe some qualified listeners such as IgorC, Kamedo2 and guruboolez can give us their opinion about 3.97 vs 3.100.

@shadowking
You said everything. I also agree.
Single, high quality, lossy archive is possible for someone who is prepared to make compromise and to accept rare issues. Otherwise, only lossless is the way to go.
Mp3 is good choice. I would say that AAC is also very well supported.

@Markuza97
Have you tried lame 3.100 -V0 --vbr-old ?
Bitrate is lower and it sound good. On this sample also. Much better than default V0.

@ synclagz

What wavpack setting resolves it using -x4 or more ?
BTW You can go beyond -s0.5 all the way to -s1

My impression was -b576x4 with the default noise shaping was fine.

@ synclagz

What wavpack setting resolves it using -x4 or more ?
BTW You can go beyond -s0.5 all the way to -s1

My impression was -b576x4 with the default noise shaping was fine.

WavPack -b576x4 (very small noise - not transparent)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-03 22:04:46

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit.wv
SHA1: 5563795325d0988b57d5035a76576911ee19ea5f

Output:
Default : Primary Sound Driver
Crossfading: NO

22:04:46 : Test started.
22:05:07 : 01/01
22:05:16 : 02/02
22:05:24 : 03/03
22:05:30 : 04/04
22:05:38 : 05/05
22:05:52 : 06/06
22:05:58 : 07/07
22:06:04 : 08/08
22:06:10 : 09/09
22:06:16 : 10/10
22:06:16 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

WavPack -b600x4 (very small noise still present)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-03 22:08:24

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-600x4.wv
SHA1: c9c64d4bad53ee7755bcee4d0413aa334cfdac7e

Output:
Default : Primary Sound Driver
Crossfading: NO

22:08:24 : Test started.
22:08:39 : 01/01
22:08:45 : 02/02
22:08:52 : 03/03
22:09:00 : 04/04
22:09:12 : 05/05
22:09:17 : 06/06
22:09:23 : 07/07
22:09:32 : 08/08
22:09:37 : 09/09
22:09:42 : 10/10
22:09:42 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

I don't know really. I would guess by 640k but I'm not sure. I'm slightly tired now. I'll try tomorrow.

@shadowking

I've put more effort into it today.
I must say that this was difficult.

WavPack -b560x4s0.5 (super tiny noise still present)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-04 17:48:25

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-b560x4s0.5.wv
SHA1: 0710d011b1450c870b4f142b9f1052e61aaa59d1

Output:
Default : Primary Sound Driver
Crossfading: NO

17:48:25 : Test started.
17:48:42 : 01/01
17:48:55 : 02/02
17:49:00 : 03/03
17:49:12 : 04/04
17:49:17 : 05/05
17:49:28 : 06/06
17:49:42 : 07/07
17:49:55 : 08/08
17:50:10 : 09/09
17:50:20 : 10/10
17:50:20 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)


I thought that going up a noch is going to solve it but I was wrong

WavPack -b576x4s0.5 (super tiny noise - this was hard I must admit)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-04 17:53:37

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-b576x4s0.5.wv
SHA1: 7d3a5399d82e6edca70344dec867479c5a5ca5e1

Output:
Default : Primary Sound Driver
Crossfading: NO

17:53:37 : Test started.
17:54:07 : 01/01
17:54:23 : 02/02
17:54:32 : 03/03
17:54:44 : 04/04
17:54:50 : 05/05
17:55:00 : 06/06
17:55:06 : 07/07
17:55:13 : 08/08
17:55:34 : 09/09
17:55:43 : 10/10
17:55:43 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

And now I've increased bitrate a little bit more...

WavPack -b600x4s0.5 (Super tiny noise - really hard to spot)
I've got 8/10...

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-04 17:58:41

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-b600x4s0.5.wv
SHA1: 85881ad9c5fa8fe43cb07f94cd3f37e87f13e359

Output:
Default : Primary Sound Driver
Crossfading: NO

17:58:41 : Test started.
17:59:39 : 01/01
17:59:45 : 02/02
18:00:14 : 02/03
18:00:20 : 03/04
18:00:31 : 04/05
18:00:39 : 05/06
18:00:51 : 06/07
18:01:01 : 06/08
18:01:21 : 07/09
18:01:36 : 08/10
18:01:36 : Test finished.

 ----------
Total: 8/10
p-value: 0.0547 (5.47%)

I would say that it needs a little bit more bitrate so probably 620-630 x4s0.5 would solve it (with s0.5).

or

-b576x4s0.8 pretty much solves it (I think). I couldn't abx it. Maybe I'll put more effort to try again but I think that this is it. :)

Thanks synclagz.

If you have time, How would something like -hx6 -s0.8 perform ?
Since -x4 is not the strongest wavpack setting.  The bitrate can probably be
lowered. 

@shadowking
Yes, I also think that stronger setting could solve it at lower bitrate.
I'll try tomorrow something like -b512hx6s0.8 and see how it goes.
I even think that maybe 480k could be used with strong setting but it needs testing.
This sample is definitely one of the hardest around. :)

@shadowking

WavPack -b480hx6s0.8 (Tiny noise - hard to spot)


foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-06 18:22:02

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-480hx6s0.8.wv
SHA1: 14ee83127ebd7804f60cc88dbd2f3fae0de36f6a

Output:
Default : Primary Sound Driver
Crossfading: NO

18:22:02 : Test started.
18:22:26 : 01/01
18:22:34 : 02/02
18:22:45 : 03/03
18:23:02 : 04/04
18:23:09 : 05/05
18:23:14 : 06/06
18:23:55 : 07/07
18:24:01 : 08/08
18:24:06 : 09/09
18:24:18 : 10/10
18:24:18 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)



WavPack -b512hx6s0.8 (Super tiny noise - very, very hard to spot)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-06 18:26:16

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-512hx6s0.8.wv
SHA1: 6316b78b34c2af4f129d593863e2088443540292

Output:
Default : Primary Sound Driver
Crossfading: NO

18:26:16 : Test started.
18:26:44 : 00/01
18:26:59 : 01/02
18:27:23 : 02/03
18:27:33 : 03/04
18:27:55 : 03/05
18:28:14 : 04/06
18:28:27 : 05/07
18:28:47 : 06/08
18:28:57 : 07/09
18:29:06 : 08/10
18:29:06 : Test finished.

 ----------
Total: 8/10
p-value: 0.0547 (5.47%)

My observations regarding this few abx tests:
All of them were very hard (for me) - we are "splitting hairs" here. :D

I would say that -b530hx6s0.8 is transparent (for me) I couldn't abx it. 512k is on the edge of my ability/eqipment and I think is still not enough.
i also tried -b512hx6s1 and I couldn't abx it (i'm getting 6/10) but I think that I still hear something. Maybe is my imagination. :D
To be honest this noise is so tiny that there is no way to spot it in normal listening even if you know exactly at which point this noise appear.

So I would say that:
-b530hx6s0.8 is transparent for me.
-b512hx6s1 might be but I'm not sure (but I would say that it is :).

Nice.  So extreme hard to abx quality can be achieved around 448k or more (3:1 compression). 
My theory that around 500 ~ 600k wavpack would converge with lossywav appears true.
Something like -b6hx6s0.75 or -b6.5x6s0.75 would be  530 / 570k.  In simpler terms,
around 512k could be standard and 576k as an extreme setting.

Nice.  So extreme hard to abx quality can be achieved around 448k or more (3:1 compression). 
My theory that around 500 ~ 600k wavpack would converge with lossywav appears true.
Something like -b6hx6s0.75 or -b6.5x6s0.75 would be  530 / 570k.  In simpler terms,
around 512k could be standard and 576k as an extreme setting.

Yes. I think that this settings 512/576 are comparable to lossywav extreme setting.
Last week I've tried to abx lossywav/Flac -q 4 -s o (~450k without noise shaping to get fast encoding) and I couldn't do it (I could try again to be sure). It seems that even without noise shaping is quite capable at 450-480k.
But I also noticed that I had issues with lossy flacs at playback. Some songs were skipping and I hear loud clicks so they were unplayable. I don't know is it a bug or something else. But according to my limited testing with lossywav, I would say that Flacs produced this way are not 100% compatible.

One other thing to mention, last night after abx-ing 480-512k I also tried -b576hs0.8 and I think is comparable to -b512hx6s0.8. I was already tired and couldn't abx it (576hs0.8 ) but I would say that for high quality and very fast encoding, this setting could be used.

I also wanted to try Opus at 180k and 250k and FhG AAC at 384k. Non is transparent. But test was very hard.

Opus 180k (Small pre-echo. Hard to spot)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-07 18:01:54

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-180k.opus
SHA1: 6caec634ed844580d8402b71c766d778041f3ea2

Output:
Default : Primary Sound Driver
Crossfading: NO

18:01:54 : Test started.
18:02:10 : 01/01
18:02:19 : 02/02
18:02:28 : 03/03
18:02:34 : 04/04
18:02:49 : 05/05
18:03:00 : 06/06
18:03:18 : 07/07
18:03:33 : 08/08
18:03:48 : 09/09
18:03:56 : 10/10
18:03:56 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)



Opus 250k (Super tiny pre-echo. Very hard to spot)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-07 18:33:03

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-250.opus
SHA1: 332fbd568c434f8761016b7dcdc50e1683a29636

Output:
Default : Primary Sound Driver
Crossfading: NO

18:33:03 : Test started.
18:33:27 : 01/01
18:33:48 : 02/02
18:33:58 : 03/03
18:34:23 : 03/04
18:34:36 : 04/05
18:34:52 : 05/06
18:34:58 : 06/07
18:35:27 : 07/08
18:35:34 : 07/09
18:35:42 : 08/10
18:35:42 : Test finished.

 ----------
Total: 8/10
p-value: 0.0547 (5.47%)



FhG AAC 384k (Tiny pre-echo. Very hard to spot but somewhat easier than Opus)

foo_abx 2.0.6c report
foobar2000 v1.6.5
2021-10-11 19:38:46

File A: CodecTest 16bit.wav
SHA1: 86786351d337f5065444a841bf07f1b2319869c1
File B: CodecTest 16bit-384fhg.m4a
SHA1: f6d13b21b99cd5eed4bfee2564bac6e61bf822ca

Output:
Default : Primary Sound Driver
Crossfading: NO

19:38:46 : Test started.
19:39:16 : 01/01
19:39:28 : 02/02
19:40:09 : 03/03
19:40:29 : 04/04
19:40:56 : 05/05
19:41:12 : 06/06
19:41:16 : 07/07
19:41:22 : 08/08
19:41:29 : 09/09
19:41:54 : 10/10
19:41:54 : Test finished.

 ----------
Total: 10/10
p-value: 0.001 (0.1%)

Difference between FhG 320 and 384 is very very small. 384k is tiny bit better.

Something like -b6hx6s0.75 or -b6.5x6s0.75 would be  530 / 570k.  In simpler terms,
around 512k could be standard and 576k as an extreme setting.

Interesting, I just might might raise my -bxxx setting.

@Markuza97 Oh, that sample has knocked me off my feet.

@shadowking We talked a lot about Wavpack, I even wondered why you had -s0.5 in your signature, then I settled on -b4x. And now I have to think again about hybrid flags and recompress all those techno compositions. Geez, helix-mp3.exe -V150 -HF2 -U2 and ogg-lancer.exe -q8 sound waaay better and weigh less than Wavpack hybrid in this case. Also thanks for fixing Lame 3.100 -V0 by adding --vbr-old, it's truly a revelation.

@Markuza97 Oh, that sample has knocked me off my feet.

@shadowking We talked a lot about Wavpack, I even wondered why you had -s0.5 in your signature, then I settled on -b4x. And now I have to think again about hybrid flags and recompress all those techno compositions. Geez, helix-mp3.exe -V150 -HF2 -U2 and ogg-lancer.exe -q8 sound waaay better and weigh less than Wavpack hybrid in this case. Also thanks for fixing Lame 3.100 -V0 by adding --vbr-old, it's truly a revelation.

I tried -b4x then -x4 to -x6 with my pc speakers.  With -x6 or possibly -x5 it would likely go unnoticed.
You could use -x4-6 for electronic music and -x for rest.

But is it a properly released sample or a lab made proof of concept?  I am not too worried about 100% artificial,
But do care for CD's that I will rip. I think its rare spectogram and it has low volume and bitrate too. Might be mono or close.
All these atypical switches for 1 sample has me thinking. I don't have a conclusion but am leaning towards a few..

OK, I had another listen last night this time with MS1 headphones and yes its more obvious there.
For Wavpack lossy what its need for good quality at normal listening level is mostly expected (for critical samples) except noise shaping.

Bitrate needs to be in the 400k zone .  -b384hx4s.5 and -b400x5s.5 are good , perhaps there is a small difference in background hiss (without -h) but i think the main issue is greatly reduced. This corresponds to -b4.35 to 4.55 in alternative notation. Also brute force does work to an extent like -hhx5 you can use slightly lower bitrate. Practically speaking, normal mode with -x5 to 6 and -h with -x4 are needed.  They aren't too slow except maybe -x6 on encoding.

I would have thought the key thing here is to ABX one codec with another codec.  It does not seem remarkable that a listener can 100% spot the compressed version when compared with the uncompressed original!

I would have thought the key thing here is to ABX one codec with another codec.  It does not seem remarkable that a listener can 100% spot the compressed version when compared with the uncompressed original!

That can be done too. However, There's distinct differences between errors -  mp3 adds smeared clicks and wavpack hiss/noise..
It will be very easy to tell apart. Key is which can sound most neutral or even transparent and at acceptable bitrates.

@shadowking, have you tried lame3995o (thread (https://hydrogenaud.io/index.php/topic,112036.0.html),  download (https://www.rarewares.org/mp3-lame-bundle.php#lame-current-halb27)) by @halb27?
Put mp3packer (https://www.free-codecs.com/winmp3packer_download.htm) in the same folder, use a new switch -Q1 alone and witness the miracles.

@shadowking, I tried the settings you suggested for WavPack, up to -b4.55x5s.5, and I still hear that hiss. Aggrrrhh! Since this sample sounds more like regular music than a proof of concept, I have a panic at the thought that other music could be compressed in such a low-quality way. So I suspend the use of the hybrid WavPack and hope that @bryant will be able to fix it.

@shadowking, I tried the settings you suggested for WavPack, up to -b4.55x5s.5, and I still hear that hiss. Aggrrrhh! Since this sample sounds more like regular music than a proof of concept, I have a panic at the thought that other music could be compressed in such a low-quality way. So I suspend the use of the hybrid WavPack and hope that @bryant will be able to fix it.

My hunch is that its not from a commercially mastered and sold redbook CD .
Even if its is real , No way to verify the sample hasn't been tampered like a EAC log etc.

@shadowking, have you tried lame3995o (thread (https://hydrogenaud.io/index.php/topic,112036.0.html),  download (https://www.rarewares.org/mp3-lame-bundle.php#lame-current-halb27)) by @halb27?
Put mp3packer (https://www.free-codecs.com/winmp3packer_download.htm) in the same folder, use a new switch -Q1 alone and witness the miracles.

I think I tried 3995o and wasn't much different, Haven't tried mp3packer.  But -b320 isn't 100% too.

@shadowking, I tried the settings you suggested for WavPack, up to -b4.55x5s.5, and I still hear that hiss. Aggrrrhh! Since this sample sounds more like regular music than a proof of concept, I have a panic at the thought that other music could be compressed in such a low-quality way. So I suspend the use of the hybrid WavPack and hope that @bryant will be able to fix it.

You can try stronger shaping like s.8  . I also tried --blocksize=4410 and thought it helped a bit, maybe you can give feeback on  that .
Also I created a 32khz version of this sample and it helped a lot.  An option if you dont hear 16khz and higher in music.

Adding -h makes a significant difference here 2 - 5 db less noise ;

wavpack -b4s.5x4ny codec*.wav

ave noise = -62.53 dB, peak noise = -47.29 dB
created CodecTest 16bit.wv in 1.22 secs (lossy, 309 kbps)


wavpack -b4s.5x4hny codec*.wav

ave noise = -64.24 dB, peak noise = -52.31 dB
created CodecTest 16bit.wv in 1.88 secs (lossy, 311 kbps)

@    Kraeved
Have you considered something like -b6hx4c   Without -s or any hacks.. 540k for 44/16 .
Filesize is similar to lossywav extreme while allowing recovery with .wvc

@shadowking, I do not use -x6, because it significantly increases the encoding time, and -h, because it requires more resources for decoding. Therefore, my attempts to improve the quality look like this: -b3x4, -b4x4, -b5x4, -b6x4, -b7x4. With -b6x4, there is a shadow of hiss, but still a noticeable shadow, which can be suppressed by adding -s.3 or -s.5. But what is -s really, why it's not there by default, what are the downsides? So only with -b7x4 I can breathe a sigh of relief.

But at this point WavPack loses its advantages in the lossy 44 kHz 16 bit segment (except for correction files feature) over FSLAC (https://hydrogenaud.io/index.php/topic,122390.msg1010605.html#msg1010605) -3 (and even Vorbis -q 8, I believe). Alas, @C.R.Helmrich, its author, is still too lazy to bring this project to a brilliant finale with the implementation of 24-bit support and taking into account other shortcomings.

@Kraeved I can see that you have been very active for the past couple of days.
Don't get me wrong - I think you are making your life harder instead of enjoying the music.

Based on your signature, I can see that you are resampling everything to 44.1 kHz.
Most audio devices today have mixer configured to use 48 kHz. This can cause clipping because of resampling.

I want my files to be equally loud. Sometimes peaks can cause little bit of clipping.
Is it worth to reduce whole file by couple of dB when you can instead use limiter to fix small clippings?

There are many different decoders for lossy files. They can also cause clipping.

Why don't you simply use FLAC and be done with it?

@shadowking, I tried the settings you suggested for WavPack, up to -b4.55x5s.5, and I still hear that hiss. Aggrrrhh! Since this sample sounds more like regular music than a proof of concept, I have a panic at the thought that other music could be compressed in such a low-quality way. So I suspend the use of the hybrid WavPack and hope that @bryant will be able to fix it.

Hi @Kraeved,

Look at my ABX tests in this thread. I've managed to ABX Wavpack up to -b576x4s0.5
If you want peace of mind with wavpack lossy, 450k range is not enough for this sample.

As @shadowking said, this sample raises suspicion on how it is recorded/mastered so it could be artificialy created.
No one knows... I would say that this sample is good to "calibrate" other lossy encoders and listen how they work on this sample but
it shouldn't be of any concern in real life music IMO.

If you want really strong setting (and peace of mind) for wavpack lossy for this sample you need something like -b550hx4s0.5.
Anything lower is ABX-able (at least for me). for faster encoding you could try -b576hhs0.8 but this high bitrate defeats purpose of economical encoding to save space.
It's up to you which way you want to go.

@synclagz you are right (i proposed similar bitrate and settings) but I ended up on an alternative path for now.
I did a long abx session last night and after hearing the increased security that the heavy settings bring I went that way.
I wrote a similar post in the past about maximising quality without blowing bitrate. It works similar here too.
Higher -x and  -h levels = decreased motivation vs totally 100% transparent.   That became my new goal.

I arrived at two settings and its a quality 1st approach 'while keeping bitrate constrained ' to save space . Some speed is sacrificed if needed for both encoding and decoding (esp for encoding).  I don't see it as lowering quality to keep bitrate down (hopefully I succeeded to an extent in the goal)- but keep quality high and bitrate low as possible while :

a) decreasing likelyhood of finding problems
b) even if found its impact will hopefully be limited and harder to confirm for multiple listeners.
c) decrease chances of feeling need for higher bitrates & less efficiency. I want to save half or more lossless bitrate.

So the settings
1-   A behemoth heavy duty   -b384hhx6s.5  used with or without correction files.
2-   A fast encoding method with practically tiny impact on quality  -b384hhs.5c

The alternative -b metric is 4.35

I guess this could be adopted to the -h mode with -b400hx5-6s.5 or maybe a bit higher.

Hi @shadowking
Your approach is very good. 384k is reasonable bitrate.
I'll try to ABX this sample with your settings and see how it goes.
I suppose it should be very acceptable.

@shadowking, I do not use -x6, because it significantly increases the encoding time, and -h, because it requires more resources for decoding. Therefore, my attempts to improve the quality look like this: -b3x4, -b4x4, -b5x4, -b6x4, -b7x4. With -b6x4, there is a shadow of hiss, but still a noticeable shadow, which can be suppressed by adding -s.3 or -s.5. But what is -s really, why it's not there by default, what are the downsides? So only with -b7x4 I can breathe a sigh of relief.

But at this point WavPack loses its advantages in the lossy 44 kHz 16 bit segment (except for correction files feature) over FSLAC (https://hydrogenaud.io/index.php/topic,122390.msg1010605.html#msg1010605) -3 (and even Vorbis -q 8, I believe). Alas, @C.R.Helmrich, its author, is still too lazy to bring this project to a brilliant finale with the implementation of 24-bit support and taking into account other shortcomings.

I have a suggestion that won't change bitrate and decoding speed.
Keep using -b4x3 .  For properly released commercial cd's issues are rare.
Create another preset:  -b4x5s.5 for artificial 'music', noises, samples from internet etc.

@shadowking, the official description (https://www.wavpack.com/WavPack.pdf) of WavPack hybrid mode says:

The lossy mode employs no subband coding or psychoacoustic noise masking. Instead, it is based on variable quantization in the time domain combined with mild noise shaping. This mode can operate from bitrates as low as 2.22 bits per sample up to fully lossless and offers considerably more flexibility and performance than the similar, but much simpler, ADPCM. This makes the lossy mode ideal for high-quality audio encoding where the data storage or bandwidth requirements of the lossless mode might be prohibitive.

While analyzing this killer sample, the author comes to the following conclusion (https://hydrogenaud.io/index.php/topic,124188.msg1040589.html#msg1040589):

What would be better is 2nd-order noise shaping or even better would be a noise-shaper peaking at 15 kHz (neither of which WavPack supports). Another thing that would work would be simply detecting that the noise level was above the signal at audible frequencies and boosting the bitrate at that point (I think lossyWAV does something like that with this sample). These are all possible improvements to WavPack lossy that I wish I had time for.

Putting the first and second parts together, I realize that the built-in noise shaping is too simple at present and there are no other automatic tricks under the hood (like psychoacoustics of MP3, Vorbis and Musepack) to mask compression artifacts (-s#.# is a manual one). I believe that the discovered simplicity is a fundamental flaw, and not something that manifests itself only through artificial samples, so I shall wait for a fix. What a relief that WavPack continues to evolve (https://hydrogenaud.io/index.php/topic,120370.msg1040900.html#msg1040900).

I somewhat disagree here.  I think the simplcity does work as in joint stereo + simple fixed shaping works in >99% cases. Difference is always hiss. Even at 256k I would accept it for portable use with the s.5 . Hiss vs clicks I take hiss. I do agree that the default dns does add something more objectionable and improvements are welcome.
If you think there is a fundemental flaw not only in artificial it would be good to prove it via listening tests and some real music samples.

I don't consider psychoacoustics are working in mp3 here.   Going by this all V0 encodings are now garbage that need to be re encoded to V4 which ironically sounds better *only on this sample.* vs 25+ years of HA experience which tells otherwise.  So I would use median quality as an indicator rather than anomaly (clearly this sample seems to be that).

IMO this sample isn't music even electronic music doesn't sound exactly like this. I am not sure if its intentional or not.

If you think there is a fundemental flaw not only in artificial it would be good to prove it via listening tests and some real music samples.

$ wavpack --version
wavpack 5.7.0
libwavpack 5.7.0

$ wavpack -hx4m --threads=4 original.wav -o lullaby.lossless.wv 
$ wavpack -b4x4 original.wav -o lullaby.lossy.wv

Interesting sample. There is massive HF energy from 16khz to 22.  Human vocals don't do this. I do hear a hum in background, Is it a synth no sure..
Why would a properly mastered recording have this  Do you have an artist / cd title ?

It seems to resolve around 400kbits or close to -b4.5..  also,  converting with replaygain  improves it.
I also tried to enable dither in the converter and it helps too.  Maybe the original was down scaled improperly?

Interesting sample. There is massive HF energy from 16khz to 22.  Human vocals don't do this. I do hear a hum in background, Is it a synth no sure..
Why would a properly mastered recording have this ?

This looks exactly like 8-bit dither with high-shibata noise shaping:

Do you have an artist / cd title ?

Lullaby of Woe (The Witcher) ~ Ashley Serena

https://www.youtube.com/watch?v=GglL2SWccb0

The level is so low that the dither is heard,  How can that be  ?
Or, Is the vocal NOT meant to be heard (hidden) without  - amplified to a  level x100 ?

mp3 lame shows RG   +16.5 db    . Also lowpass needs to be high around 20khz .  If lowpass 17 or lower, horrid ringing is heard and RG is +21 db  !

So, What is this stuff ? This is certainly not professional cd audio.

So, What is this stuff ? This is certainly not professional cd audio.

Based on her page (https://www.ashleyserena.com/music), she only releases on spotify and itunes, but the sample attached earlier is definitely not what was released on those platforms.

The level is so low that the dither is heard,  How can that be  ?
Or, Is the vocal NOT meant to be heard (hidden) without  - amplified to a  level x100 ?

It's 8-bit, so maybe it's not that surprising that the dither is heard, but yes, it looks like the level was additionally reduced by 8 dB before the conversion to 8-bits. On top of that it's the beginning of the song and it starts quiet.

In attachment 10 seconds from Spotify (free) (https://open.spotify.com/album/7jJa2m3IqFBZ6JUk2D2o4m?si=OuP0fZwBTQGcyKA7KtSTSg).

@shadowking think of it as a watermarked demo or a bootleg copy or a stream recording with effects added, so as not to lose sleep. The point is that the range from 16 to 20 kHz is not a wasteland and there might be a palpable energy in it that WavPack hybrid must be able to handle in a more intelligent way. After all, it's not for properly mastered CD audio only, right? For example, the energy in this sample reminds me of the noise (hiss to be precise) of an analogue medium like cassette tape.

Update.
If you want to get an MP3 file that sounds good enough here, use either LAME 3995o (https://www.rarewares.org/mp3-lame-bundle.php#lame-current-halb27) -Q1 or Helix (https://hydrogenaud.io/index.php/topic,123331.msg1041803.html#msg1041803) without -HF flag.

lame 320 is not good.  abx 9/10 easy

I think WV 400 does it. I have a new appreciation for the normal mode & a lightweight -x4 using bitrate of 400k. The -s can be adjusted to a personal preference or left as is.   With the wvc its a nice combo.

@shadowking think of it as a watermarked demo or a bootleg copy or a stream recording with effects added, so as not to lose sleep. The point is that the range from 16 to 20 kHz is not a wasteland and there might be a palpable energy in it that WavPack hybrid must be able to handle in a more intelligent way. After all, it's not for properly mastered CD audio only, right? For example, the energy in this sample reminds me of the noise (hiss to be precise) of an analogue medium like cassette tape.

Your right. As a POC there can be room for improvement (esp below 400k).  It real life the 16+ khz region will never have so much energy so the risk is theoretical but practically tiny (at least when using a bitrate of 400k or more ).   

Lame 3995o vbr -q1 cannot be better than any 320cbr.   Helix is old, good yes but still mp3.
From 400k there's going to be way less WV cases (IMO) - even the 3.995o developer has that view.
However, below 400 I agree that a conventional codec like mp3 may be better.

The first interesting thing I noticed here is the lossy version is bigger than the lossless version; so obviously lossless is the way to encode this sample!! In fact, the noise seeming to cut in and out is the encoder switching back and forth from lossless to lossy to hold the desired bitrate. And because it is an 8-bit file (padded to 16-bit) even fiddling with the LSB (of eight) breaks the dither, which then becomes audible.

However, this is not a case of the WavPack DNS getting fooled. It is working exactly as intended staying pegged at 1.0 throughout, so -s1.0 makes an identical file, and -s0 makes the noise really audible. It’s just that full 1st-order isn’t steep enough.

I agree with shadowking here that samples like this don’t prove too much, especially since transform codecs have trouble with them too. Higher-order noise shaping would probably fix this, but another approach might simply be to detect the absurdity of the sample (the vast majority of the energy is above 14 kHz) and reject it or fall back to lossless.

I would even say that this sample poses a danger to delicate tweeters if played loudly enough, which is easy to do because you can’t hear how loud it is. To demonstrate that, I subtracted out the dither, transposed it down to the “audible” range (from 20 kHz to 7256 Hz), and remixed it back in (at the same level). This is what the sample would sound like to dogs!   :)

@bryant, can we assume that dither is used not only to mask quantization, but also for an artistic effect? Hissing and crackling are effects that I often hear in music. As comrade @danadam noted, in this case it seems 8-bit dither with noise-shaping of Shibata High profile was added. And there are more than a dozen other profiles (https://github.com/jniemann66/ReSampler/blob/master/ditherProfiles.md) that generate noise at HF range. I'm sad to think that hybrid mode will only handle basic dither (attached below) and choke on everything else.

(https://i1.imageban.ru/out/2024/03/27/d9b9fdaec7fa6c89d068fdfc5782d1cd.png)

but another approach might simply be to detect the absurdity of the sample (the vast majority of the energy is above 14 kHz) and reject it or fall back to lossless.

"Reject it" meaning reject the noise, i.e. low-pass filter the file, or reject the file entirely?

I don't know what are the intended goals for wavpack lossy, but my opinion on lossy in general is that low-pass should be standard procedure. We are already trading off some quality, so removing what is inaudible (or if you are young enough, what is not that important) seems like the reasonable thing to do. For that matter, for example, I don't understand why vorbis tries to preserve ultrasonics when q >= 6.

can we assume that dither is used not only to mask quantization, but also for an artistic effect? Hissing and crackling are effects that I often hear in music.

You don't need >= 14k content for that. At least for me, I can low-pass your example at 12k and I still hear the same hiss. Of course then it can't stay at 8-bits anymore.

And there are more than a dozen other profiles (https://github.com/jniemann66/ReSampler/blob/master/ditherProfiles.md) that generate noise at HF range. I'm sad to think that hybrid mode will only handle basic dither (attached below) and choke on everything else.

This needs clarification "... at 8 bits". I don't think there will be any problems with those noise shaping filters at 16-bits.

@bryant, can we assume that dither is used not only to mask quantization, but also for an artistic effect? Hissing and crackling are effects that I often hear in music. As comrade @danadam noted, in this case it seems 8-bit dither with noise-shaping of Shibata High profile was added. And there are more than a dozen other profiles (https://github.com/jniemann66/ReSampler/blob/master/ditherProfiles.md) that generate noise at HF range. I'm sad to think that hybrid mode will only handle basic dither (attached below) and choke on everything else.

WavPack lossy does not handle dither of any kind; it simply attempts to encode the entire waveform as closely as possible and makes no further distinctions. That fact that we have identified that noise as Shibata dither is irrelevant. This sample has a ton of ultrasonic noise and, unlike a psycho-acoustic codec, WavPack is not going to remove it just because you can’t hear it. Instead, it will encode it and attempt to hide its own quantization noise underneath the audio, which in this case is it is unable to do because currently its noise-shaping is not steep enough.

As for your other suggestion, I would certainly not assume that dither would (or should) be used for “artistic effect”. In this sample the audio was truncated to 8-bit at some point, and that was done using dither and noise-shaping to make the conversion artifacts as unobtrusive as possible (that’s what they’re for), and then it was converted back to 16-bit. Obviously there was some reason for this, but if they just wanted to add some hiss there would have been ways to do it without creating havoc with lossy encoders. When this was converted back to 16-bit most of that noise should have been filtered out.

Quote from: bryant on 2024-03-26 20:38:40

but another approach might simply be to detect the absurdity of the sample (the vast majority of the energy is above 14 kHz) and reject it or fall back to lossless.

"Reject it" meaning reject the noise, i.e. low-pass filter the file, or reject the file entirely?

I don't know what are the intended goals for wavpack lossy, but my opinion on lossy in general is that low-pass should be standard procedure. We are already trading off some quality, so removing what is inaudible (or if you are young enough, what is not that important) seems like the reasonable thing to do. For that matter, for example, I don't understand why vorbis tries to preserve ultrasonics when q >= 6.

I may have been a little rash when I said “reject it”, but I definitely was not referring to filtering out the noise despite it being inaudible (some, most, or all of it, depending on your age). WavPack lossy makes few psychoacoustic assumptions, and frequency is certainly not one of them. It attempts to preserve the waveform faithfully, so it can be useful for non-audio applications like electrophysiology data (https://iopscience.iop.org/article/10.1088/1741-2552/acf5a4).

But yes, lowpass filtering of audio would certainly be an appropriate thing to do to get better performance from WavPack lossy, or even reduce the sampling rate. For example, I use 32 kHz sampling rate when I record FM broadcast to WavPack as I do not consider the 19 kHz pilot tone to be part of the "artistic effect".   :)

In this case ,32 khz makes it worse as the noise has nowhere to go but down the spectrum.  In contrast, 48khz works better.

> In this case ,32 khz makes it worse as the noise has nowhere to go but down the spectrum.  In contrast, 48khz works better.

Do you mean, it subjectively sounds better at the same bitrate? (I don't think it *has* to always be worse in similar cases. All of the noise has to go to the audible range indeed, but the noise floor can be lower because there are more bits per sample available. It's probably very difficult to truly predict how it'll go in general.)

> When this was converted back to 16-bit most of that noise should have been filtered out.

Why/how? I don't think this is how it works. Converting an integer from less bits to more bits is lossless (perfectly reversible). Do you mean there is some extra step that you'd expect to always happen in tandem with that?

> In this case ,32 khz makes it worse as the noise has nowhere to go but down the spectrum.  In contrast, 48khz works better.

Do you mean, it subjectively sounds better at the same bitrate? (I don't think it *has* to always be worse in similar cases. All of the noise has to go to the audible range indeed, but the noise floor can be lower because there are more bits per sample available. It's probably very difficult to truly predict how it'll go in general.)

> When this was converted back to 16-bit most of that noise should have been filtered out.

Why/how? I don't think this is how it works. Converting an integer from less bits to more bits is lossless (perfectly reversible). Do you mean there is some extra step that you'd expect to always happen in tandem with that?

There are two different scenarios to consider. The first is that we want to preserve this pathological audio, and the other is we want to salvage it.

Since the vast majority of the energy in the sample is at frequencies that some people can hear and some can’t, this is going to sound very different to different people. But if the goal is to preserve that loud hiss, say for some nostalgia, then it’s sort of hit or miss as to what a lossy codec is going to do (as we’ve seen) because there’s all kind of ways that could fail, either in analysis or processing.

The recommendation is generally to not transcode from one lossy format to another (and converting to 8-bit PCM is a very lossy operation), so my advice would be to play it safe and accept the great lossless compression that you can get (because of the 8 bits). Keep in mind that the pathological amounts of hiss may very well create other distortions in your playback system, from resampling engines to DACs to transducers, but I assume that’s all acceptable and that any ABX testing you do is suspect.

On the other hand, we know what the artist intended this to sound like (from YouTube and Spotify) and it does not have pathological hiss. That was an artifact of converting to 8-bit PCM (for a game audio perhaps?) and so it seems reasonable to me to try to remove that to make everything more palatable for lossy encoders, and that’s very easy to do. The useful audio here goes up to about 14 kHz, so I used my ART program (https://github.com/dbry/audio-resampler) with a gentle 48-tap sinc lowpass at 15 kHz and got the attached file. You can see the lowpass profile here:

(https://www.wavpack.com/images/Lullaby-lowpass-compare.png)

That still has some audible hiss (like maybe from a cassette or FM recording), but should be an easy encode because it looks like real audio.

There also seems to be a misconception here. Resampling audio from 44.1 kHz to 32 kHz does not require the noise “to go somewhere else”. Proper downsampling involves an anti-aliasing lowpass filter that removes frequencies that are no longer valid at the new sampling rate (i.e., >= Fs/2), so when I use my tool again to convert this (using default settings) to 32 kHz it’s fine and the crazy hiss is gone and it should be easy to encode. If some other program is doing something else and making this worse to encode, it’s not being used as intended or buggy.

And I’m not suggesting that increasing the bitdepth of integer samples requires any filtering because it is, as you say, lossless. But in this particular case there is a lot of dither noise that is there only because of the reduced bitdepth, so it makes sense to remove it if you can do so without removing too much useful audio information.

And, by the way, if all this wasn't true then DSD wouldn't work because it's completely based on downsampling 1-bit audio and removing the dither noise.

Lame 3995o vbr -q1 cannot be better than any 320cbr. Helix is old, good yes but still mp3.

Just in case for less informed users among us: it's not -q1, but -Q1, a tweaked approach implemented by @halb27.

Actually, I agree with @maikmerten, who said: “Your LAME 3.995o encode (https://hydrogenaud.io/index.php/topic,123331.msg1041803.html#msg1041803) did overall a better job, certainly better than LAME 3.100 for this sample. However, as one can see in the spectrogram, it somewhat avoided most of the sbf21 trouble by effectively lowpassing the high frequency band [using transition band 17960 Hz - 18494 Hz] and thus getting rid of the excessive energy there, which might be the best tradeoff in this case”. Helix without -HF2 used an even lower 16536 Hz limit and also sounds fine (with enough hiss, but without metallic fluctuations and ultrasonic bloat).

Input.
(https://i1.imageban.ru/out/2024/03/26/6d3cdd377bf7781cf6c162d9e9a6e6a3.png)

Output. lame3995o -Q1
(https://i6.imageban.ru/out/2024/03/26/cbf2cee9b2bb39657dfaa77cab8c17fc.png)

Output. hmp3 -V150
(https://i5.imageban.ru/out/2024/03/26/d7e0780cc5fe56689ac4719397cdbb64.png)

@Kraeved with all due respect I have been on this forum for 2 decades, I know and used lame3995o.

"Lame 3995o vbr -Q1 cannot be better than any 320cbr"

@Kraeved with all due respect I have been on this forum for 2 decades, I know and used lame3995o.

Dear @shadowking, it seems my words were open to misconstruction. Speaking of less informed users, I didn't mean you personally, but those who read such in-depth forum threads without having our knowledge of codecs, after which they randomly apply the flags they encounter and then ask why they don't get the desired results. Since -q1 is different from -Q1, I felt it necessary to emphasize that. Also, it would be useful to know what upset you with the result of 3995o.

OK No hard feelings at at.

I have been running abx tests for the last few days for several hours total. I think I may have a solution or a partial one.
I even encoded some tracks to 8bit with dither and the effect was a bit similar to lullaby. Any way I don't know how that fits into
anything but anyhow - I discovered that at around 5 bit per sample or more is needed. Below its like FM radio  - too me not annoying at all but still..   So if one is into 8bit that is the way .  It also translates into 16bit robustness - around 6bps maybe less or more is needed for a lossywav like quality.  Back to codectest16,  I decided on the normal mode since that is the workhorse of WV.  Interestingly, to my ears @576k the modes seem to converge more or less like it don't matter if -x or -h -s etc..  I remember many years ago I read a post by dibrom on regards to MP3 -APS behavior .  He said its a quality 1st approach - reach bitrate first then try to bring it down if safe. So,  Going by that to my ears and test sample set if I take 576 and add some defensive mechanism like -x , smart mid-side stereo and -s , I got down to 500k .  Specifically;  -b500x4s1.  A workhorse setting  'normal' but with big safety net.  Then I guess for completion ; a 'high' setting of -b550x4s1 .  In bps its 5.67 to 6.24 I guess 6 on average.  Anyway now to 320-350k or -b4 ;  use -b4x4s.5 for an alternative. To my ears the difference is not annoying if audible at all in normal volume day to day listening. For middle bitrates I found -s.5 safe so far although you lose some of the advantage of not getting a full -s1 or even negative shaping when appropriate though how this actually translates in real life listening is a different matter. I think its a good balance anyway.  For high bitrate above 400,  abx results tell me a -s1 is the way or somewhere from 70-100% upward tilt ( -s.7 to -s1).  I am leaning on -s1 . 
Interestingly, On WV manual -s1 if the default for high sample rates > 48 and hi-res as the noise is 'pushed up into in audible range '.  So it seems to me the -j1 -s1 simple method is also good for very high bitrate 44-48khz- 16 bit.

Anyhow to make short of the long,  Two settings for different goals. Its really simple its almost ridiculous when I write it like:

350k
-b4x4 (-s optional)

500k
-b5.67x4s1  or round to -b6x4s1

In popular metrics
-b320x4    ~ compact portable
-b500x4s1 ~ archiving normal
-b550x4s1 ~ archiving xtreme

Now the space saved on 500k is still considerable IMO at least for non classical.  Lacuna coil down to 280mb from 541mb. 
For classical a very dynamic title ' Fauré  Requiem 235 vs 277 mb  or  434k vs 508k flac. Even here 18% would be considered very significant in lossless benchmarks between different codecs.