lossyWAV 1.3.0 Development Thread, Added noise WAV bitdepth reduction method. Options

[halb27]

1.2.3.e's average bitrate for my usual test set of various pop music:

-q S: 431 kbps
-q C: 395 kbps
-q P: 337 kbps
-q X: 293 kbps

Using -q X I could ABX eig and furious both 9/10. The hiss in eig is relatively obvious.
Using -Q P I could not ABX eig (the improvement from -q X is quite impressive), and ABXed furious 8/10. Don't care too much about artificial furious, especially as I'd call the result good.

This post has been edited by halb27: Mar 17 2011, 21:41

[Nick.C]

Thanks for the very prompt testing - these results seems to be a retrograde step from 1.2.3c (the last for which I could find your test results).

I will look at the differences in the noise shaping between these versions and revert.

I have decided to include a new parameter "--static" in the next beta to allow the user to increase the minimum-number-of-bits-to-keep as mentioned previously.

[edit] sp. [/edit]

This post has been edited by Nick.C: Mar 17 2011, 21:49

[halb27]

... these results seems to be a retrograde step from 1.2.3c ...

Well, when ABXing at different times my ABX results are not necessarily comparable. I guess my sensitvity varies. Moreover the exact test details aren't exactly the same (especially listening volume).
So I retested eig and ABXed it against the 1.2.3.c and 1.2.3.e extraportable results. And yes, the 1.2.3.c result is really better.

This post has been edited by halb27: Mar 17 2011, 22:53

[halb27]

I did the same test again this morning as with my last post, and I could ABX eig using 1.2.3.c -X with the same result as when using 1.2.3.e.
My sensitivity really changes. Not good, but it is like that. Probably also due to my age (61). It would be great if we could have more testers.
Sorry for the confusion.

This post has been edited by halb27: Mar 18 2011, 10:50

[Ljubo44]

I am thinking about how best to allow the user to tweak certain parameters to further reduce the number of bits removed. One which immediately springs to mind is to allow the user to increase the minimum-number-of-bits-to-keep (default=6), probably user selectable between 7 and 16. Will revert with another beta in due course.

lossyWAV beta 1.2.3e attached to post #1 in this thread.

Awesome thank you. Your thread is my homepage

[Nick.C]

lossyWAV beta 1.2.3f attached to post #1 in this thread.

[halb27]

I tested 1.2.3.f in my usual way.
Average bitrates are:

-q S: 432 kbps
-q C: 397 kbps
-q P: 340 kbps
-q X: 298 kbps

Using -q X I could not ABX eig. With furious I arrived at 8/10. For sec. 1.8...2.8 the added hiss makes the result sound a tiny bit brighter. It's only a tiny bit we really shouldn't care about with this artificial sample.
Using -q P my result with this spot was 6/10.

I also listened to some -q X encoded regular music and was totally happy with the result.

This post has been edited by halb27: Mar 29 2011, 08:55

[GeSomeone]

Thanks halb27 for your prompt test.
Did anybody test other sample rates than 44.1k? Just asking because Nick did not go final because of a suspicion there.

[Nick.C]

I've been working with higher sample rates - with somewhat mixed success.

The adaptive noise shaping method seems to be working well for sample rates up to and including 96kHz. Above that however, there are issues that I have not yet managed to get to the bottom of.

[GeSomeone]

The adaptive noise shaping method seems to be working well for sample rates up to and including 96kHz.

For all practical purposes that would do. Personally, if I wanted to save space on a 192kHz file, the first thing I would consider is resampling to 96kHz
I understand, of course, that you'd like to know what goes on at higher rates, if not, you could set 96kHz as the maximum sample rate for 1.3.0.

[Nick.C]

Knowing why is pretty fundamental - and working it out can cause some previously undetected problems to be discovered and rectified....

lossyWAV beta 1.2.3g attached to post #1 in this thread.

I believe that the adaptive noise shaping is working for all sample rates up to and including 384kHz (maximum tested so far....).

[botface]

I noticed that the Wiki looks badly out of date - especially regarding recent changes to quality settings - but I don't feel confident to update it

[Ljubo44]

lossyWAV_beta_1.2.3g is twice better than lossyWAV_beta_1.2.3e at 96kHz from 1235kb/s to 1244kb/s but twice closer to original. congrats!

[Nick.C]

That's one positive response, thanks! Anyone else care to chip in with some high-sample-rate observations?

I will get around to the wiki when v1.3.0 is (finally!) released (although I will need help, as usual.... ).

[halb27]

No high sample rate test from my side, just my usual one with the usual results (furiuos ABXable with -q X though quality is good, furious and eig fine with -q P).

Bitrates for my standard test set:

-q S: 436 kbps
-q C: 399 kbps
-q P: 341 kbps
-q X: 297 kbps

[Nick.C]

Thanks again for testing - it's much appreciated as always.

[Nick.C]

lossyWAV beta 1.2.3h attached to post #1 in this thread.

[Nick.C]

Thinking of reducing maximum clips-per-channel-per-codec-block to zero when adaptive shaping is active to reduce the possibility of the current method which allows a certain number of clips from "overloading" the noise-shaping filter(s).

[Nick.C]

Two technical questions:

1) the spreading algorithm in lossyWAV has always averaged the amplitude of adjacent FFT results rather than the power - is this likely to be the correct approach?

2) Should I correct the audio for DC offset prior to performing the FFT analyses on it (DC offset correction over number of samples in each FFT only, repeated per FFT)?

[edits] .... due to poor command of the English language.... [/edits]

This post has been edited by Nick.C: Apr 21 2011, 20:34

[Nick.C]

lossyWAV beta 1.2.3i attached to post #1 in this thread.

[Nick.C]

Full collection transcode resulted in 303kbit/s at -q X.

[2Bdecided]

Two technical questions:

1) the spreading algorithm in lossyWAV has always averaged the amplitude of adjacent FFT results rather than the power - is this likely to be the correct approach?

2) Should I correct the audio for DC offset prior to performing the FFT analyses on it (DC offset correction over number of samples in each FFT only, repeated per FFT)?

[edits] .... due to poor command of the English language.... [/edits]

1) probably not down the route to proper psychoacoustics you go...

2) you don't use the DC bin in the calculations, do you? if no, then no need to worry (IMO! I could be wrong). if yes, then don't.

Cheers,
David.

[Ljubo44]

lossyWAV beta 1.2.3h is better than lossyWAV beta 1.2.3i because lossyWAV beta 1.2.3i have stronger supression noise in audible range. In lossyWAV beta 1.2.3h the situation is reversed. But better is to be supression noise in inaudible range. I speaking only for high sample rate, 192kHz and 96kHz

[Nick.C]

I speaking only for high sample rate, 192kHz and 96kHz

Thanks for that - I'll have a look. I'm trying to optimise file-size as well as noise-shaping. It's disappointing to hear that beta 1.2.3i is retrograde compared to beta 1.2.3h.

David:

1) I think that I phrased my question badly. Should I be using power averaging?

2) The DC bin is not used in the calculations. Correcting DC offset seems to have got rid of the problem that has been plaguing the Furious sample. I can only guess that this is because of lower calculated amplitudes at the low frequency end of the spectrum. This alone makes me think that I need to correct before FFT. I'll try some other things that have occurred.

[Ljubo44]

picture says more than 1000 words

lossyWAV_beta_1.2.3h


lossyWAV_beta_1.2.3i


I using wavelab6 for audio compare between original and lossywav and gain for inverted difference +50db. All settings is [ lossywav - -q 10.0 --static 16 --silent --stdout ]
I still using lossywave for testing only. I hope this will help you