lossyWAV Development, WAV bit reduction by 2BDecided Options

[halb27]

Looks like we have to be pretty resistant towards frustration (guess that's true for everybody working on lossy codecs):

Sorry, but using -spread 4 I just abxed keys_1644ds.wav 8/10 (in a very quick test cause I have to go to work now. Guess it's easy to abx it 10/10). The encoded result isn't bad but it sounds different - like volume is a bit lower at the beginning (though replaygain values are identical) especially in the lower frequency range. Based on a very quick test I'd say this is not the case without the spreading option and not the case with -spread 3 though with these settings bits_to_remove is higher.

Perhaps a small implementation error that has found it's way into the code cause -spread 4 shoud be more conservative than -spread 3 or no -spread at all - at least in case it's correct what lossywav say about -spread 4: 4 bins average from 3.7kHz to 16kHz.
This is a bit in contradiction however towards you talking about 'the 800Hz / 3.7kHz / 8kHz intermediate steps'. So are you doing a 5 bin averaging above 8 kHz as you wrote before? (I guess that is no problem but at the moment it is about finding out what might cause the problem with keys).
But maybe the problem is with the start as that's the place where it's rather easily audible.

This post has been edited by halb27: Oct 16 2007, 07:26

[Nick.C]

Sorry, but using -spread 4 I just abxed keys_1644ds.wav 8/10 (in a very quick test cause I have to go to work now. Guess it's easy to abx it 10/10). The encoded result isn't bad but it sounds different - like volume is a bit lower at the beginning (though replaygain values are identical) especially in the lower frequency range. Based on a very quick test I'd say this is not the case without the spreading option and not the case with -spread 3 though with these settings bits_to_remove is higher.

-spread 4 uses simple averaging, -spread 2 & 3 use square-mean-root (SMR). SMR is inherently more conservative, e.g. average[1,4,9]=4.67; SMR[1,4,9]=4.00.

I don't understand about -spread 4 being worse than default though, it should *only* remove more bits.

Perhaps a small implementation error that has found it's way into the code cause -spread 4 shoud be more conservative than -spread 3 or no -spread at all - at least in case it's correct what lossywav say about -spread 4: 4 bins average from 3.7kHz to 16kHz.

Always a possibility of a bug in the code .

This is a bit in contradiction however towards you talking about 'the 800Hz / 3.7kHz / 8kHz intermediate steps'. So are you doing a 5 bin averaging above 8 kHz as you wrote before? (I guess that is no problem but at the moment it is about finding out what might cause the problem with keys).
But maybe the problem is with the start as that's the place where it's rather easily audible.

Currently only 4 bins are averaged above 3.7kHz, however I am not ruling out re-introducing the 8kHz (move it out to 12kHz?) intermediate. I will dig deeper into keys and re-examine the code to try to spot bugs (they're there, I just haven't found them).

CODE

lossyWAV alpha v0.3.9 keys_1644ds.wav

-spread 0
Block    Time   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Tot.
====================================================================
    0    0.00s.  2  3  4  4  2  2  3  2  2  3  3  3  3  2  2  2  42
   16    0.37s.  2  2  3  5  3  3  2  2  2  3  3  3  4  3  3  2  45
   32    0.74s.  2  3  4  4  3  2  2  3  2  2  -  -  -  -  -  -  27
====================================================================
Average    : 2.7143 bits; [114/42; 5.16x; CBS=1024]

-spread 1
Block    Time   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Tot.
====================================================================
    0    0.00s.  2  3  4  3  2  2  2  2  2  3  3  3  2  2  1  1  37
   16    0.37s.  2  2  3  4  3  2  2  2  2  3  3  3  3  3  2  1  40
   32    0.74s.  2  3  4  4  3  1  2  2  2  2  -  -  -  -  -  -  25
====================================================================
Average    : 2.4286 bits; [102/42; 5.13x; CBS=1024]

-spread 2
Block    Time   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Tot.
====================================================================
    0    0.00s.  2  3  4  3  2  2  3  1  1  3  3  3  3  2  2  2  39
   16    0.37s.  2  2  3  4  3  3  2  2  2  3  3  3  3  3  3  2  43
   32    0.74s.  2  3  4  4  3  2  2  3  2  2  -  -  -  -  -  -  27
====================================================================
Average    : 2.5952 bits; [109/42; 5.11x; CBS=1024]

-spread 3
Block    Time   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Tot.
====================================================================
    0    0.00s.  2  3  4  3  2  2  2  1  1  3  3  3  2  2  1  1  35
   16    0.37s.  2  2  3  4  3  2  2  2  1  3  3  3  3  3  2  1  39
   32    0.74s.  2  3  4  4  3  1  1  2  2  2  -  -  -  -  -  -  24
====================================================================
Average    : 2.3333 bits; [98/42; 4.93x; CBS=1024]

-spread 4
Block    Time   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Tot.
====================================================================
    0    0.00s.  1  3  4  3  1  1  1  0  0  2  2  2  1  1  1  1  24
   16    0.37s.  2  2  2  4  3  2  1  2  1  3  1  2  3  3  2  1  34
   32    0.74s.  1  3  3  4  3  0  1  1  2  2  -  -  -  -  -  -  20
====================================================================
Average    : 1.8571 bits; [78/42; 5.36x; CBS=1024]

Well, the results are in and -spread 4 does not remove more bits for any codec_block than -spread 3 or 0

This post has been edited by Nick.C: Oct 16 2007, 08:17

[halb27]

I see. Strange. I will test the no -spread version more carefully this evening. Maybe my impression was wrong this morning - I was pretty much in a hurry.

This post has been edited by halb27: Oct 16 2007, 08:46

[2Bdecided]

Another thing I need advice with is licensing - portions of the code are (heavily modified) LGPL, so LGPL seems to be the way to go, however, I don't know exactly what I need to add to the .exe or license.txt file no enact it. As well as that, the method is David Robinson's implementation of an idea - all I have done is transcode and tweak a bit.

LGPL is fine by me. I don't know how you enact it or how legally binding it is - I'm sure Google can answer the first issue!

Cheers,
David.

[halb27]

I tested key_1644ds.wav again using -spread 4: I tried several times, also with different head/earphones, but couldn't abx it.

Sorry for the confusion. I have no idea what went on this morning. Apart from the not too bad abx result of 8/10 there was a pretty clear distinguishable difference in loundness this morning to me. Must have been imagination.

This post has been edited by halb27: Oct 16 2007, 19:08

[Nick.C]

I tested key_1644ds.wav again using -spread 4: I tried several times, also with different head/earphones, but couldn't abx it.

Sorry for the confusion. I have no idea what went on this morning. Apart from the not too bad abx result of 8/10 there was a pretty clear distinguishable difference in loundness this morning to me. Must have been imagination.

That's reassuring...... I have tweaked the -spread 4 method anyway. It's now

20Hz > 2 Bin > 800Hz > 3 Bin > 6kHz > 4 Bin > 13.5kHz > 5 Bin > 16kHz.

But, I'll add it as -spread 5.

Methods 2 and 3 are quite nice in terms of conservatism, but they are slower than 0, 1 & 4. Unless anyone says otherwise, they will be removed.

Thanks David - I'll start to compose the necessary text and run it past you before inclusion in the .exe and .zip files.

This post has been edited by Nick.C: Oct 16 2007, 22:36

[halb27]

Sounds good.
Just a remark as I see one of the corner frequencies is 6 kHz:
I remember the fact that we are most sensitive to noise in the 6 kHz region with sensitivity quickly dropping beyond. So maybe it's a good idea to use something like 7 kHz instead of 6.
Just an idea.

This post has been edited by halb27: Oct 17 2007, 09:19

[Nick.C]

Just a remark as I see one of the corner frequencies is 6 kHz:
I remember the fact that we are most sensitive to noise in the 6 kHz region with sensitivity quickly dropping beyond. So maybe it's a good idea to use something like 7 kHz instead of 6.

Will do.

[halb27]

Maybe you want to look it up in the Wikipedia as 'Audio noise measurement'.
I just did for brushing up my memory. Judging from this article it may be advantegous evne to go a bit beyond 7 Khz with the corner frequency as at the sensitivity top around 6 kHz sensitivity is still pretty flat.

[Nick.C]

I've tweaked the intermediate frequencies again:

20Hz > 2 Bin > 1.38kHz > 3 Bin > 3.45kHz > 3 Bin > 8.27kHz > 4 Bin > 13.8kHz > 5 Bin > 16.5kHz.

Other than 20Hz these frequencies relate to integer bins for a 64 sample FFT at 44.1kHz. Superseded.

-spread 0 and 1 are the only options, 1 being equivalent to tweaked 4 from alpha v0.3.9

CODE

lossyWAV alpha v0.3.10 : WAV file bit depth reduction method by 2Bdecided.
Transcoded to Delphi by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      noise_threshold_shift=n (-15.0<=n<=0.0, default -1.5dB)
              (reduces overall bits to remove, -1 bit = -6.0206dB)
-o <folder>   destination folder for the output file
-force        forcibly over-write output file if it exists.

Advanced Options:

-spread <n>   select spreading method : 0 or 1; default=0
              0 = fft bin averaging : 3 or 4 bins, (less agressive than orig.);
              1 = fft bin averaging : 2 bins from 20Hz to 1.38kHz; 3 bins from
                  1.38kHz to 8.27kHz; 4 bins from 8.27kHz to 13.8kHz; 5 Bins
                  from 13.8kHz to 16.5kHz.
-skew <n>     skew results of fft analyses by n dB (0.0<=n<=12.0, default=0.0)
              with a (sin-1) shaping over the frequency range 20Hz to 3.7kHz.
              (artificially decrease low frequency bins to take into account
              higher SNR requirements at low frequencies)

-dither       dither output using triangular dither; default=off
-noclip       clipping prevention amplitude reduction; default=off

-quiet        significantly reduce screen output
-nowarn       suppress lossyWAV warnings
-detail       enable detailled output mode
-below        set process priority to below normal.
-low          set process priority to low.

Special thanks:

Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.

This post has been edited by Nick.C: Oct 18 2007, 22:01

[halb27]

Wonderful. Though all these new things are pure heuristics I think they are good at keeping things defensive, and in the end we want the perceptive quality of lossless at a probality of close to 1 while keeping bitrate significantly below that of lossless.

I will try out -spread 1 this evening.

As David Bryant addressed the potential clipping issue, just another thought about a simple clipping prevention scheme:
When clipping occurs due to bit depth reduction: reduce the number of bits to remove until no clipping occurs.
No quality issue, no pre-scanning of the entire track, no serious negative impact on bitrate (in case it's correct what I guess: clipping usually occurs on rare occasion).

This post has been edited by halb27: Oct 17 2007, 14:03

[Nick.C]

As David Bryant addressed the potential clipping issue, just another thought about a simple clipping prevention scheme:
When clipping occurs due to bit depth reduction: reduce the number of bits to remove until no clipping occurs.
No quality issue, no pre-scanning of the entire track, no serious negative impact on bitrate (in case it's correct what I guess: clipping usually occurs on rare occasion).

I like the idea, although, when a value rounds to 32768 I currently reduce it to (int(32767/(2^bits_to_remove))*(2^bits_to_remove). I'll have a look and revert.

[2Bdecided]

When clipping occurs due to bit depth reduction: reduce the number of bits to remove until no clipping occurs.

It isn't always useful. If you have a track which is constantly near clipping (most modern pop music) lossyFLAC should make huge gains (throw away many bits), but if it has to back off the bit reduction to prevent clipping, it'll throw away a few or none.

If you have a track which is well away from clipping, it doesn't matter anyway. So this approach only works well when you have a track which is quite close to clipping.

Cheers,
David.

[halb27]

Sure with modern compressed music near or at the clipping level it may be that this approach isn't good cause bits_to_remove may get very low often. But did you try? IMO it's not necessary so resp. not necessarily typical behavior with such music.

I'd welcome to give it a try. Bitrate will go up on average with modern music I'm sure, but who knows may be the extent to which it does is negligible.

Thinking of other kind of music not highly compressed clipping may occur too in cases via the bit depth reduction. In these cases this simple approach would be valuable I think.

Anyway as we certainly don't want to have the user differentiate too much: everything depends on the average behavior with music published the loudness war way.

This post has been edited by halb27: Oct 17 2007, 19:25

[Nick.C]

On the licensing front I've been in touch with the copyright holder of TPMAT036 and he is happy that lossyWAV is released under the LGPL.

@Halb27: Are you happy to release your wavIO unit under the LGPL?

On the clipping front: If a sample clips, the old method just set it to 32767 / -32768 accordingly. This was a minimalist response to those few samples which exceed the upper or lower bound on rounding / dithering.

With no dither, a simple amplitude reduction to 31.5/32 of the original value should stop clipping on rounding (32768 > (32767 shr bits_to_remove) shl bits_to_remove.

I will implement a -noclip 2 (existing -noclip goes to -noclip 1) parameter which will try the iterative approach mentioned previously.

Nick.

[edit] Question: should I reduce bits_to_remove if *any* sample clips, or only if adjacent samples clip? Also, how many samples need to clip before bits_to_remove is reduced? [/edit]

This post has been edited by Nick.C: Oct 17 2007, 21:15

[halb27]

@Halb27: Are you happy to release your wavIO unit under the LGPL?

Yes, I am. But please feel free to think and behave as if you are the one who developped lossyWav.exe in its current form. In fact you did 99.9% of the job so we shouldn't make things so complicated. No need also to mention me at all in the lossyWav message text. If you want to do any changes to wavIO, feel free to do it (but please send me the modified version), and if you want me to do some modifications or extensions, let me know and I'lll do it.

As for the threshold for the number of samples clipping before the bit depth reduction is modified to prevent clipping I have no idea. I did think to do it immediately in case it happens but I am also afraid that bitrate will go up too much. But I also have no idea whether it really does in an unacceptable way.
Maybe a special -noclipexp option with a parameter 0...1024 for the number of clipping samples which are ignored before the clipping prevention method is started can help us find out.
Luckily no listening test is needed to answer the question how low we can go with the parameter value and still find the 'bitrate bloat' acceptable.

Adjacent clipping samples are more of concern than scattered clipping samples but for a first result I think we shouldn't make it so complicated.

Sorry I wasn't able to test the current lossyWav version this evening. I had a lot of trouble with my system (shouldn't have installed new software today).

This post has been edited by halb27: Oct 17 2007, 23:12

[Nick.C]

@Halb27: Are you happy to release your wavIO unit under the LGPL?

Yes, I am. But please feel free to think and behave as if you are the one who developped lossyWav.exe in its current form. In fact you did 99.9% of the job so we shouldn't make things so complicated. No need also to mention me at all in the lossyWav message text. If you want to do any changes to wavIO, feel free to do it (but please send me the modified version), and if you want me to do some modifications or extensions, let me know and I'lll do it.

Thanks very much - however, you were there, so you will be mentioned.

As for the threshold for the number of samples clipping before the bit depth reduction is modified to prevent clipping I have no idea. I did think to do it immediately in case it happens but I am also afraid that bitrate will go up too much. But I also have no idea whether it really does in an unacceptable way.

I have attached alpha v0.3.11 which has "if any samples clip, reduce bits_to_remove and repeat" implemented. Not too bad an effect on the sample set.

Maybe a special -noclipexp option with a parameter 0...1024 for the number of clipping samples which are ignored before the clipping prevention method is started can help us find out.

Maybe - but that would be samples per codec_block.....

Luckily no listening test is needed to answer the question how low we can go with the parameter value and still find the 'bitrate bloat' acceptable.

Adjacent clipping samples are more of concern than scattered clipping samples but for a first result I think we shouldn't make it so complicated.

Probably in the next day or so though.....

Sorry I wasn't able to test the current lossyWav version this evening. I had a lot of trouble with my system (shouldn't have installed new software today).

Nothing serious, I hope!

Nick.

[edit]attachment removed, superseded.[/edit]

This post has been edited by Nick.C: Oct 19 2007, 14:00

[halb27]

I have attached alpha v0.3.11 which has "if any samples clip, reduce bits_to_remove and repeat" implemented. Not too bad an effect on the sample set.

Wonderful, and a very promising result.

Maybe a special -noclipexp option with a parameter 0...1024 for the number of clipping samples which are ignored before the clipping prevention method is started can help us find out.

Maybe - but that would be samples per codec_block.....

Sure. But if your results with the current version turns out to have a wide scope with clipping-critical material maybe this isn't necessary at all. Qualitywise this would be the perfect solution.

This post has been edited by halb27: Oct 18 2007, 09:34

[Nick.C]

I have attached alpha v0.3.11 which has "if any samples clip, reduce bits_to_remove and repeat" implemented. Not too bad an effect on the sample set.

Wonderful, and a very promising result.

Maybe a special -noclipexp option with a parameter 0...1024 for the number of clipping samples which are ignored before the clipping prevention method is started can help us find out.

Maybe - but that would be samples per codec_block.....

Sure. But if your results with the current version turns out to have a wide scope with clipping-critical material maybe this isn't necessary at all. Qualitywise this would be the perfect solution.

I've been developing the clipping prevention method further - it's now faster. Also, the minimum value of each fft analysis is being determined for use in determining bits_to_remove - should some thought also be given to the difference between the maximum value of each fft analysis to the minimum? This difference is to some extent a signal to noise ratio as removing bits adds noise. If the difference should be taken into consideration, what should be the reasonable minimum difference? I'll start playing with it and try 12dB initially - we'll see what happens......

[halb27]

As far as I understand the lossyWav method I can't see a meaning in the difference. But this doesn't say much. Maybe 2Bdecided can bring some light into it.

[Nick.C]

As far as I understand the lossyWav method I can't see a meaning in the difference. But this doesn't say much. Maybe 2Bdecided can bring some light into it.

Maximum was the wrong choice, I'm now trying comparing average spread result to minimum spread result and if the difference is less than 15dB then new_minimum = average - 15dB.

The bits_to_remove average comes down a bit so it *should *(?) improve the quality of the output.

As no one has spoken up, I will remove -spread 0 and the only spreading function will be the most recent -spread 1 (previously -spread 4).

[Josef Pohm]

In the hereafter you can see removed bits table evaluated on my SetF, for LossyWAV 0.3.8-9-10-11, all presets, frame sizes 512 - 1024 - 2048 - 4096.
As we already know, recent versions are removing less bits than previous ones.

CODE

------- -------------------- -------------------- -------------------- -------------------- --------------------
|      |       0.3.8        |       0.3.9        |       0.3.10       |       0.3.11       |  0.3.11 vs. 0.3.8  |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
|      |   1  |   2  |   3  |   1  |   2  |   3  |   1  |   2  |   3  |   1  |   2  |   3  |   1  |   2  |   3  |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
| 512  | 4,69 | 5,58 | 5,80 | 4,67 | 5,50 | 5,73 | 4,38 | 5,18 | 5,41 | 4,04 | 4,80 | 5,03 | -,65 | -,78 | -,77 |
| 1024 | 4,46 | 5,21 | 5,37 | 4,44 | 5,14 | 5,31 | 4,16 | 4,84 | 5,00 | 3,77 | 4,42 | 4,58 | -,69 | -,79 | -,79 |
| 2048 | 4,12 | 4,95 | 5,11 | 4,10 | 4,89 | 5,06 | 3,83 | 4,59 | 4,75 | 3,39 | 4,11 | 4,27 | -,73 | -,84 | -,84 |
| 4096 | 3,81 | 4,63 | 4,79 | 3,79 | 4,57 | 4,74 | 3,53 | 4,28 | 4,45 | 3,05 | 3,75 | 3,91 | -,76 | -,88 | -,88 |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------

In next table, you can see TAK 1.0.2e08 -p3m bitrates for LossyWAV files produced by 0.3.8 and 0.3.11.

CODE

------- ----------------- ----------------- -----------------
|      |  TAK on 0.3.8   |  TAK on 0.3.11  | 0.3.11 vs 0.3.8 |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----
|      |  1  |  2  |  3  |  1  |  2  |  3  |  1  |  2  |  3  |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----
| 512  | 499 | 430 | 413 | 552 | 490 | 472 | +53 | +60 | +59 |
| 1024 | 501 | 443 | 431 | 557 | 504 | 491 | +56 | +61 | +60 |
| 2048 | 519 | 453 | 441 | 578 | 520 | 507 | +59 | +67 | +66 |
| 4096 | 539 | 473 | 461 | 602 | 545 | 532 | +63 | +72 | +71 |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----

As you may see, on average we have 13% bigger files. I am aware that in this phase LossyWAV development is heading for some less aggressive settings and I'm confident sound quality improvements may be worth the loss in compression efficiency. Nevertheless in my opinion, as we are approaching bitrates which are not so attractive when compared to pure lossless (862kbps, for TAK 1.0.2e08 -p3m on my SetF, lossless) I would keep some more aggressive settings as a preset.

[halb27]

As we wanted to have -2 very safe, -1 very safe with a rather large safety margin, and as guruboolez abxed a sample with the not-so-cautious approach IMO the current dvelopment is appropriate for -1 and -2.

But maybe -3 details should be more such that focus is kept on saving bits, more than on very safe quality.

BTW do you mind trying the new clipping prevention method of 3.11 on your set and compare it to the pure 3.11 result without clipping prevention?

This post has been edited by halb27: Oct 18 2007, 18:39

[Josef Pohm]

As we wanted to have -2 very safe, -1 very safe with a rather large safety margin, and as guruboolez abxed a sample with the not-so-cautious approach IMO the current dvelopment is appropriate for -1 and -2.
But maybe -3 details should be more such that focus is kept on saving bits, more than on very safe quality.

I definitely agree. If it was up to me I would go for "<level -3> best we can do in the 384-448kbps range (generally transparent except for very rare problem samples)";

BTW do you mind trying the new clipping prevention method of 3.11 on your set and compare it to the pure 3.11 result without clipping prevention?

Bits removed table.

CODE

------- -------------------- -------------------- --------------------
|      |   0.3.11 -noclip   |       0.3.11       | noclip vs default  |
|       ------ ------ ------ ------ ------ ------ ------ ------ ------
|      |   1  |   2  |   3  |   1  |   2  |   3  |   1  |   2  |   3  |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------
|  512 | 4,11 | 4,89 | 5,12 | 4,04 | 4,80 | 5,03 | 0,07 | 0,09 | 0,09 |
| 1024 | 3,89 | 4,56 | 4,72 | 3,77 | 4,42 | 4,58 | 0,12 | 0,14 | 0,14 |
| 2048 | 3,57 | 4,31 | 4,48 | 3,39 | 4,11 | 4,27 | 0,18 | 0,20 | 0,21 |
| 4096 | 3,29 | 4,02 | 4,19 | 3,05 | 3,75 | 3,91 | 0,24 | 0,27 | 0,28 |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------

Tak 1.02e08 -p3m table.

CODE

------- ----------------- ----------------- -----------------
|      |   TAK -noclip   |   TAK default   | noclip vs def   |
|       ----- ----- ----- ----- ----- ----- ----- ----- -----
|      |  1  |  2  |  3  |  1  |  2  |  3  |  1  |  2  |  3  |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----
|  512 | 543 | 481 | 462 | 552 | 490 | 472 | - 9 | - 9 | -10 |
| 1024 | 544 | 490 | 477 | 557 | 504 | 491 | -13 | -14 | -14 |
| 2048 | 560 | 500 | 487 | 578 | 520 | 507 | -18 | -20 | -20 |
| 4096 | 579 | 519 | 506 | 602 | 545 | 532 | -23 | -26 | -26 |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----

[Nick.C]

Thanks for the testing Josef, as Halb27 said, it was agreed some time ago that the -2 quality level would be a "very good" default option, with -1 as overkill and -3 as compact. Once the settings for -2 are determined and set, then work can start on -1 and -3.

Personally, I will probably use -3 as I too want to keep the bitrate down, but I am being lead by my more golden-eared colleagues with respect to level -2.

I will release alpha v0.3.12 tonight with a new parameter "-snr" (as in signal to noise, with signal being average of the spread results and noise being the added noise due to bit reduction) which will allow input from 0dB to 48dB. I've tentatively set the default to 12dB as it doesn't affect the bitrate too much.

As an aside, never forget that you can always over-ride the noise_threshold_shift (-nts) default of -1.5 for quality level 2 and set it to a more aggressive value.

In ways I would like to see the default noise_threshold_shift set to zero, but only if the spreading, anti-clipping and signal-to-noise functions work as I hope they will to reduce artifacts to a minimum.

Thanks again for the input!

Nick.

[edit] posts at the same time...... Could you post a list of samples in your set and I will re-examine settings for -3. Initially, -3 was only going to have 2 FFT analyses (64 and 1024 samples) but from using -2 a lot I feel that maybe -3 should also include the 256 sample FFT analysis but have different noise_threshold_shift and signal_to_noise settings. In alpha v0.3.11, the "check-for-clipping-and-recursively-reduce-bits_to_remove-until-no-clipping" mechanism is on by default (an oversight on my part, I didn't put a parameter in place to switch it off). I'll change "-noclip" from overall amplitude reduction (31.49/32 for no dither) to select this bits_to_remove-reduction method. [/edit]

This post has been edited by Nick.C: Oct 18 2007, 20:10