Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lossyWAV 1.1.0 Development Thread. (Read 185945 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lossyWAV 1.1.0 Development Thread.

Reply #175 –
Quote from: lvqcl on
I downloaded source code for 1.0.0b version.
Nick.C, can I ask you to add a new option? BTRlimit or something like this.
Then, in procedure process_this_codec_block insert one line
Code: [Select]
if min_fft_result.btr>BTRlimit then min_fft_result.btr:=BTRlimit;

just before calling remove_bits:

Code: [Select]
...
          if min_fft_result.sminbin>min_fft_result.savebin then
            fft_average:=fft_average+1
          else
            fft_minimum:=fft_minimum+1;
        end;
      end;

>>  if min_fft_result.btr>BTRlimit then min_fft_result.btr:=BTRlimit; << that line

    remove_bits;

    if (detailled_output=1) and (silent=0) then
      remove_bits_output
    else
      inc(current_codec_block);
...
I'd already re-introduced that as the static_maximum_bits_to_remove method I reintroduced at 1.0.1k.

However.... Thanks to Mardel's sample and my desire to see what was happening with it, I "fixed" the detailled output to show per-channel bits-to-remove and I think I have found a problem whereby some channels are having more bits-to-remove than I think they should. This will not necessarily be a quick fix. I would hope to post beta 1.0.1m tomorrow night.

lossyWAV 1.1.0 Development Thread.

Reply #176 –
Quote from: Nick.C on
However.... Thanks to Mardel's sample and my desire to see what was happening with it, I "fixed" the detailled output to show per-channel bits-to-remove and I think I have found a problem whereby some channels are having more bits-to-remove than I think they should. This will not necessarily be a quick fix. I would hope to post beta 1.0.1m tomorrow night.
I didn't find anything, although I had suspicions. However, I re-implemented the old max-inter-block-change in bits to remove (bits-to-remove can only increase by 1 bit per codec block). This wastes a few bits but should limit the change in noise level to 6dB every 11.6ms (for 44.1kHz audio). I would appreciate feedback to see if this has improved Mardel's sample at all at -q 0.

lossyWAV beta 1.0.1m attached to post #1 in this thread.

lossyWAV 1.1.0 Development Thread.

Reply #177 –
later today I will read the last pages of this thread, I am willing to test Mardel's sample at -q 0 V1.0.1l vs. -q 0  V1.0.1m, it shouldn't be too long/hard, unfortunatly I don't have V1.0.1l, I only have V1.0.1j & m, so if someone could repost V1.0.1l, I could do the job. Also if you have any sample with heavy problem at -q 0 to -q 2 like Mardel's sample, I am interested as long as it's not beyond my earing possibilities.

I also plan to do a quick transcodability test for my own use, I'll pass the Castanets sample thru lossywav -q 2.5 + nero aac VBR 96Kbps vs direct nero aac VBR 96Kbps & see if I can ear a difference, I test at 96Kbps because at 128Kbps it becomes hard to ABX (but still possible) & at 64Kbps with SBR I think it's too agressive if there would be a difference it would be destroyed anyway.

lossyWAV 1.1.0 Development Thread.

Reply #178 –
Quote from: sauvage78 on
later today I will read the last pages of this thread, I am willing to test Mardel's sample at -q 0 V1.0.1l vs. -q 0  V1.0.1m, it shouldn't be too long/hard, unfortunatly I don't have V1.0.1l, I only have V1.0.1j & m, so if someone could repost V1.0.1l, I could do the job. Also if you have any sample with heavy problem at -q 0 to -q 2 like Mardel's sample, I am interested as long as it's not beyond my earing possibilities.

I also plan to do a quick transcodability test for my own use, I'll pass the Castanets sample thru lossywav -q 2.5 + nero aac VBR 96Kbps vs direct nero aac VBR 96Kbps & see if I can ear a difference, I test at 96Kbps because at 128Kbps it becomes hard to ABX (but still possible) & at 64Kbps with SBR I think it's too agressive if there would be a difference it would be destroyed anyway.
Thanks for volunteering your listening time, it is much appreciated. The beta 1.0.1l that you are looking for never existed as the character 'l' is too similar to '1' and '|' in some fonts. Things have moved on a bit and I have made enough changes to warrant the release of a new beta version.

From memory (correct me if I'm wrong, halb27) eig, triangle_2_1644ds, furious and badvilbel would be good (i.e. problematic) samples to try.

lossyWAV 1.0.1n attached to post #1 in this thread.

lossyWAV 1.1.0 Development Thread.

Reply #179 –
sorry I was meaning V1.01k,

I started by my little transcoding test ... so far it's an ABX fiasco  , I couldn't tell the difference between a Direct nero AAC Q0.35 (96Kbps) Vs. a Lossywav -q2.5+Nero Q0.35 (96Kbps) transcoding ... I tried at Nero 64Kbps & I failed too, everything sounded terrible but I couldn't spot any regression due to lossywav q2.5 ... so I am currently testing a nero Q0.65 (256Kbps)+nero Q0.35 (96Kbps) transcoding Vs. a lossywav q2.5+nero Q0.35 (96Kbps) transcoding, just to see how bad is nero aac 256Kbps as a source compared lossywav q2.5 which I can't ABX. All this on the castanets sample.

lossyWAV 1.1.0 Development Thread.

Reply #180 –
Quote from: sauvage78 on
sorry I was meaning V1.01k,

I started by my little transcoding test ... so far it's an ABX fiasco  , I couldn't tell the difference between a Direct nero AAC Q0.35 (96Kbps) Vs. a Lossywav -q2.5+Nero Q0.35 (96Kbps) transcoding ... I tried at Nero 64Kbps & I failed too, everything sounded terrible but I couldn't spot any regression due to lossywav q2.5 ... so I am currently testing a nero Q0.65 (256Kbps)+nero Q0.35 (96Kbps) transcoding Vs. a lossywav q2.5+nero Q0.35 (96Kbps) transcoding, just to see how bad is nero aac 256Kbps as a source compared lossywav q2.5 which I can't ABX. All this on the castanets sample.
In terms of ABX'ing lossyWAV output, the most beneficial (to me) method would be to ABX the lossless original sample against the lossyWAV output rather than ABX processed samples from two versions of lossyWAV. I am very interested to find out if the quality of Mardel's sample when processed with 1.0.1n is as easy to ABX as it was with the lossyWAV version available when he introduced the sample.

lossyWAV 1.1.0 Development Thread.

Reply #181 –
Ok, I will test it soon.

If anyone is interested by the result of my personnal little transcoding test, lossywav -q 2.5 vs. Nero q0.65 as a source, it happened that the result was a success: lossywav -q 2.5 is a better source than Nero q0.65 for transcoding, the usual DCT artefact for the castanets sample (flat metallic attack) was slightly more pronounced with nero q0.65 as a source. In the end it is not surprising, but even if I can ABX it 9/12, I wouldn't tell the difference was incredible, you have to know exactly what to listen to, close your eyes & concentrates. So for me the interest of lossywav relies much more in its "splittability+no psychoacoustic" (CDImage.lossy.tak as archive) than in its "transcodability" alone. For me lossywav stands as a lossy codec by itself ... if I ever start using it when it will become stable, I think I will simply stop using Nero AAC & DCT codecs.

lossyWAV 1.1.0 Development Thread.

Reply #182 –
Ok, as you wanted me to ABX each lossywav version separatly vs. original, I first tested Lossywav V1.01n -q 1.0 Vs. Original:

foo_abx 1.3.3 report
foobar2000 v0.9.5.3
2008/05/26 15:36:25

File A: C:\Documents and Settings\Bureau\Test\Ginnungagap.lossyV1.01n-q1.wav
File B: C:\Documents and Settings\Bureau\Test\Ginnungagap.original.wav

15:36:25 : Test started.
15:36:44 : 01/01  50.0%
15:37:07 : 02/02  25.0%
15:37:28 : 03/03  12.5%
15:37:49 : 04/04  6.3%
15:38:14 : 05/05  3.1%
15:38:46 : 06/06  1.6%
15:40:01 : 07/07  0.8%
15:40:18 : 08/08  0.4%
15:41:24 : 09/09  0.2%
15:42:28 : 10/10  0.1%
15:42:57 : 11/11  0.0%
15:43:23 : 12/12  0.0%
15:43:28 : Test finished.

 ----------
Total: 12/12 (0.0%)

The artefact is still here, still very pronounced. Was easyly ABXable from the first try.
I didn't separatly re-ABX the original sample with a problem by Mardel vs. original as I think it is useless. (See the old log, it would be the same)

Instead I started ABXing the original sample with a problem by Mardel vs. Lossywav V1.01n -q 1.0, as I first wanted to do, in order to see if there was any progression/regression. I could ABX it too so easyly that I stopped after 4 try as I was 100% sure of myself.

foo_abx 1.3.3 report
foobar2000 v0.9.5.3
2008/05/26 15:46:19

File A: C:\Documents and Settings\Bureau\Test\Ginnungagap.lossyV1.01n-q1.wav
File B: C:\Documents and Settings\Bureau\Test\Ginnungagap.lossywithnoise.wav

15:46:19 : Test started.
15:46:41 : 01/01  50.0%
15:47:08 : 02/02  25.0%
15:47:40 : 03/03  12.5%
15:48:21 : 04/04  6.3%
15:48:26 : Test finished.

 ----------
Total: 4/4 (6.3%)

(The following conclusion is wrong see edit.)
The good news is that there is a progression, the bad news is that the artefact is still here & still severe.
I would describe the progression as less deep tearing, softer noise, shorter distortion duration.
The sound return to stability faster after the distortion which has less amplitude.
But this is still comparing rotten apples with rotten oranges, if you compare to the original, the artefact is still severe. I would say it's like a 0.5 quality increase in the old scale of V1.01f not much more than that.

Major Edit:
Bad news, I just realized that I tested -q 0 vs -q 1 in the 2nd ABX test (1st test is valid even if I tested a better setting than I should have) so the improvement I heard must be 100% normal. I must re-test  ... but even if the test is bad, it now almost means for certain that there is near to zero improvement because it can only be worst for V1.01n at -q 0 than at -q 1

Edit2: I re-did the test with the correct parameters, it was un-ABXable  , I cannot tell any progression/regression at all. I fear what you changed between V1.01f & V1.01n has no effect on this specific sample. Sorry ...

lossyWAV 1.1.0 Development Thread.

Reply #183 –
lvqcl got good results with Mardel's problem sample using a significantly higher bits-to-keep value of -m 5.333.
-m 5.333 is  bit of a hard bitrate penalty for the very low bitrate settings, but maybe a value of -m 4 brings a significant progress (we don''t need full transparency with -q 0 or -q 1, non-annoyance should be enough).

sauvage78, do you mind trying lossyWAV with the additional option of -m 4?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #184 –
ok I will try it to see if it helps.

Edit:

V1.01n -q0 -m 4 Vs. original

foo_abx 1.3.3 report
foobar2000 v0.9.5.3
2008/05/26 17:35:50

File A: C:\Documents and Settings\Bureau\Test\Ginnungagap.lossyV1.01n-q0-m4.wav
File B: C:\Documents and Settings\Bureau\Test\Ginnungagap.original.wav

17:35:50 : Test started.
17:36:13 : 01/01  50.0%
17:36:30 : 02/02  25.0%
17:36:42 : 03/03  12.5%
17:37:03 : 04/04  6.3%
17:37:20 : 05/05  3.1%
17:37:34 : 06/06  1.6%
17:38:05 : 07/07  0.8%
17:38:20 : 08/08  0.4%
17:38:25 : Test finished.

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

Conclusion 1:
Easy to ABX from original, always the same flaws more or less pronounced.

V1.01n -q0 -m 4 Vs. -q0

foo_abx 1.3.3 report
foobar2000 v0.9.5.3
2008/05/26 17:39:29

File A: C:\Documents and Settings\Bureau\Test\Ginnungagap.lossyV1.01n-q0.wav
File B: C:\Documents and Settings\Bureau\Test\Ginnungagap.lossyV1.01n-q0-m4.wav

17:39:29 : Test started.
17:41:02 : 01/01  50.0%
17:42:16 : 02/02  25.0%
17:43:38 : 03/03  12.5%
17:44:32 : 04/04  6.3%
17:44:43 : Test finished.

----------
Total: 4/4 (6.3%)

Conclusion 2:
There is a minor improvement but if I recall well the -q1 setting which I tested by mistake in my previous post sounded almost same or better (but not worst 100% sure), so if there is a big bitrate increase I am not sure it worth it.

for efficiency I dunno, so far I only tested lossywav as pure wav so I have no clue what ends in a bigger file, -q 0 -m 4 or -q 1 ... it be must tested further with & without -m 4 at comparable bitrate ... for non-annoyance as far as I tested use -q 2.5 on this killer sample.

lossyWAV 1.1.0 Development Thread.

Reply #185 –
I still think the main problem for that sample is that added noise changes between -36 and -42dBFS several times in a second. (at 1.1...1.7 s.)

Maybe program should look ahead and stores results of analysis of several frames after and before current? Then, some sort of filter (median?) can be introduced. So the problem of 'unstable' noise can be fixed.

lossyWAV 1.1.0 Development Thread.

Reply #186 –
Quote from: Nick.C on
I re-implemented the old max-inter-block-change in bits to remove (bits-to-remove can only increase by 1 bit per codec block). This wastes a few bits but should limit the change in noise level to 6dB every 11.6ms (for 44.1kHz audio). I would appreciate feedback to see if this has improved Mardel's sample at all at -q 0.

Of course it is OK to test this. I just remember last time this came up that 2Bdecided said something to the effect that gradualy changing the bits to removed wouldn't help, it even might have a chance of giving some kind of modulation effect, and inaudible noise should be inaudible anyway (and if it's not when it should, tune somewhere). O.t.h. that was only valid for the transparent settings, so who knows 
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.1.0 Development Thread.

Reply #187 –
Quote from: sauvage78 on
...
V1.01n -q0 -m 4 Vs. original
...
Easy to ABX from original, always the same flaws more or less pronounced.

Thanks for testing.
I didn't expect it to bring transparency (the bitrate penalty for -m 4 isn't so large), but I hoped it would make things less annoying. No need for a detailed comparison -q 0 -m 4 vs. -q 1 IMO. There should have been some progress IMO with -m 4 to justify further investigations.

In case no new ideas come up it looks like we can't seriously improve in the bitrate range of current -q 0 or -q 1, and --portable is a good solution for the lowest preset.

Quote from: Nick.C on
... From memory (correct me if I'm wrong, halb27) eig, triangle_2_1644ds, furious and badvilbel would be good (i.e. problematic) samples to try. ....

These are good samples to try, as is Bruhns, Living In The Future, and other tracks from my potential problem collection which can be downloaded from here for a while.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #188 –
Quote from: halb27 on
In case no new ideas come up it looks like we can't seriously improve in the bitrate range of current -q 0 or -q 1, and --portable is a good solution for the lowest preset.
I introduced the -H, --highskew <n> (0<=n<=36) parameter at beta 1.0.1n. This is analogous to the low-frequency skew which is built in to lossyWAV but acts above 3.45kHz rather than below. This in conjunction with -l, --limit may provide a solution for the Ginnungagap sample.

lossyWAV 1.1.0 Development Thread.

Reply #189 –
Quote from: GeSomeone on
Of course it is OK to test this. I just remember last time this came up that 2Bdecided said something to the effect that gradualy changing the bits to removed wouldn't help, it even might have a chance of giving some kind of modulation effect, and inaudible noise should be inaudible anyway (and if it's not when it should, tune somewhere). O.t.h. that was only valid for the transparent settings, so who knows 
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.

lossyWAV 1.1.0 Development Thread.

Reply #190 –
Quote from: 2Bdecided on
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:
Code: [Select]
  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).
Code: [Select]
  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:
Code: [Select]
|-------------|------------|------------|------------|------------|------------|
| 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.

lossyWAV 1.1.0 Development Thread.

Reply #191 –
Quote from: Nick.C on
...
Code: [Select]
|-------------|------------|------------|------------|------------|------------|
| 1.0.1o --LC | 670 kbit/s | 601 kbit/s | 527 kbit/s | 441 kbit/s | 336 kbit/s |
|-------------|------------|------------|------------|------------|------------|

What's the --LC option, Nick?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #192 –
Quote from: halb27 on
Quote from: Nick.C on
...
Code: [Select]
|-------------|------------|------------|------------|------------|------------|
| 1.0.1o --LC | 670 kbit/s | 601 kbit/s | 527 kbit/s | 441 kbit/s | 336 kbit/s |
|-------------|------------|------------|------------|------------|------------|
What's the --LC option, Nick?
--linkchannels (but it's a bit wide for the table).
 

lossyWAV 1.1.0 Development Thread.

Reply #193 –
Quote from: Nick.C on
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.

Yeah, we like to complain .  But seriously, I only would not like it if the bit rate at -q 5 would rise because something at -q 0 was fixed..

Quote
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.
[..]
This allows finer control by halving the width of the 3 highest spread-zones to approximately 2kHz each (except the highest one).

Although I don't understand what you are trying to accomplish, in general it is normal to take wider bands for higher freqs. To the ear 1 octave is a doubling of the frequency ( 2kHz - 4 kHz is the same (tonal) difference as 10 kHz - 20 kHz).
But maybe this has no relevance to lossyWav whatsoever
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.1.0 Development Thread.

Reply #194 –
I used 1.0.1o with my regular music test set.
For --portable bitrate is the same as with 1.0.1k (362 kbps), for --standard it's 449 kbps against 1.0.1k's 452 kbps, for --extreme bitrate comes down to 529 kbps (1.0.1.k: 534 kbps), and for --insane bitrate is 607 kbps (1.0.1k: 611 kbps).
So from --standard upwards, bitrate is a little bit lower than when using 1.0.1k.

Bitrate of -q 0 is 270 kbps (I didn't keep the 1.0.1k's bitrate).

I did a short listening test using -q 0 on Mardel's sample and to me it's fine. I'm not sensittive towards this problem however.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #195 –
Quote from: halb27 on
I used 1.0.1o with my regular music test set.
For --portable bitrate is the same as with 1.0.1k (362 kbps), for --standard it's 449 kbps against 1.0.1k's 452 kbps, for --extreme bitrate comes down to 529 kbps (1.0.1.k: 534 kbps), and for --insane bitrate is 607 kbps (1.0.1k: 611 kbps).
So from --standard upwards, bitrate is a little bit lower than when using 1.0.1k.

Bitrate of -q 0 is 270 kbps (I didn't keep the 1.0.1k's bitrate).

I did a short listening test using -q 0 on Mardel's sample and to me it's fine. I'm not sensittive towards this problem however.
Thanks for the listening time - it's always appreciated.

I've been working on simultaneous piped input and output within foobar2000. I have managed to convert a single file using this method!  However if I try to create a single album image from a number of tracks it crashes.... I'll work on this further as there must be a simple reason why it's working for a single file and not working for multiple files.

lossyWAV 1.1.0 Development Thread.

Reply #196 –
Quote from: GeSomeone on
Quote from: Nick.C on
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.
Yeah, we like to complain .  But seriously, I only would not like it if the bit rate at -q 5 would rise because something at -q 0 was fixed..
Quote
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.
[..]
This allows finer control by halving the width of the 3 highest spread-zones to approximately 2kHz each (except the highest one).
Although I don't understand what you are trying to accomplish, in general it is normal to take wider bands for higher freqs. To the ear 1 octave is a doubling of the frequency ( 2kHz - 4 kHz is the same (tonal) difference as 10 kHz - 20 kHz).
But maybe this has no relevance to lossyWav whatsoever
The increase in bitrate at --standard is due (at least in part) to the increase from 3.25 minimum-bits-to-keep to 3.50, also slightly from the tightening of the spreading-function.

The increase in the number of spread-zones still allows consecutive zones to have the same number of bins averaged, but it also allows for the possibility of averaging different numbers of bins in each "half" of the old zone (for those that were split).

lossyWAV 1.1.0 Development Thread.

Reply #197 –
Nick, halb27
Small issue, but I thought you might be interested in this (re. foobar setup batch file in LossyWAV wiki).
I posted in the other thread, but this seems to be the place now for all things lossyWAV.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV 1.1.0 Development Thread.

Reply #198 –
Quote from: carpman on
Nick, halb27
Small issue, but I thought you might be interested in this (re. foobar setup batch file in LossyWAV wiki).
I posted in the other thread, but this seems to be the place now for all things lossyWAV.

C.
Thanks for that - I saw it at the time, but my loss of code kind of focussed my attention elsewhere.... I'll amend the wiki.

lossyWAV 1.1.0 Development Thread.

Reply #199 –
I wondered why bitrate came down a bit with 1.0.1o as compared to 1.0.1k and played around with --shaping. The default shaping (--shaping q-value/10) has gone. With the corresponding --shaping bitrate goes up.
lame3995o -Q1.7 --lowpass 17