Yes.
The basic problem here is that lossyWAV's tuning is aiming for transparency. For argument's sake, let's imagine that in tuning, there will probably have been moments when things were well above transparency, and bits were being wasted, but no one really cared. The worst moments will be "just above" transparency.
If you force things into non-transparent territory, two things happen. Firstly, some moments will stay transparent because they have a high margin, while others will plunge into dramatically non transparent because they were on the edge already. Secondly, the various tweaks that are in there to gain transparency don't perform "linearly" in the range of non-transparent encoding; they are set up to keep the noise inaudible - they have no mechanism to make audible noise "least bad".
Please be aware that these are two separate mechanisms. If you can't hear something, you can't hear it. Simple as that. If you can hear something, figuring out how annoying it is is a whole different ball game.
So I guess (and it's only a guess) that the wildly fluctuating noise is exactly what lossyWAV should do to keep the noise inaudible. However, for settings where the noise does become audible, it'll be very annoying.
I emphasise this is all me guessing - I'm not trying to say "this is the way it is" because I don't know.
Cheers,
David.
Thanks for the insight David. I realise that -q 0 is pushing the envelope when bits-to-remove is concerned - but at the same time there are several user out there who "complain" () when I increase the bitrate at -q 0 with some revised setting or other.
I suffered a bit of a setback as the USB stick I was using to transport lossyWAV about failed and I had to revert to the source from beta 1.0.1e. The changes were mostly cosmetic or parametric and so no real trouble. In doing so, I have not yet re-enabled the "bits-to-remove increase of one per codec-block" code.
In re-modifying the code to bring it up to what 1.0.1n was (from memory and the change log) I had another thought about the spreading-function.
The spreading function string was: Frequency_Limits : Array [0..spread_zones+1] of Double = (20,1378.125,3445.3125,8268.75,12403.125,16000);
spreading_function_string : string[precalc_analyses*(spread_zones+2)-1]='22222-22222-22223-12223-12234-12345';
I have increased the number of spread-zones to 8 from 5 by making the inter-boundary frequency change constant (didn't have to move any boundaries, just interleaved 3 more). Frequency_Limits : Array [0..spread_zones+1] of Double = (20,1378.125,3445.3125,5512.5,8268.75,10335.9375,12403.125,14470.3125,16000);
spreading_function_string : string[precalc_analyses*(spread_zones+2)-1]='22222222-22222222-22222223-12222223-12222224-11222234';
This allows finer control by halving the width of the 3 highest spread-zones to approximately 2kHz each (except the highest one).
Bitrates for my 55 problem sample set are as follows:|-------------|------------|------------|------------|------------|------------|
| Version | --insane | --extreme | --standard | --portable | -q 0 |
|-------------|------------|------------|------------|------------|------------|
| 1.0.1n | 645 kbit/s | 571 kbit/s | 491 kbit/s | 410 kbit/s | 312 kbit/s |
|-------------|------------|------------|------------|------------|------------|
| 1.0.1o | 652 kbit/s | 580 kbit/s | 504 kbit/s | 421 kbit/s | 321 kbit/s |
|-------------|------------|------------|------------|------------|------------|
| 1.0.1o --LC | 670 kbit/s | 601 kbit/s | 527 kbit/s | 441 kbit/s | 336 kbit/s |
|-------------|------------|------------|------------|------------|------------|
lossyWAV beta 1.0.1o attached to post #1 in this thread.