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.

-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.
Always a possibility of a bug in the code .
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).



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

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.

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.

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.

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.

Will do.

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.

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.

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).

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.

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.

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.

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]

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).

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

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 - but that would be samples per codec_block.....

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

Nothing serious, I hope!

Nick.

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

Wonderful, and a very promising result.
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......

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).

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.



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



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.

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?

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)";

Bits removed table.

Tak 1.02e08 -p3m table.

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]

Thank you, Josef.
So with your test set the new clipping prevention scheme doesn't have a seriously bad influence on the bitrate.
I'll try and find some clipping-prone samples and test it too.

I would like to remove the "-skew" parameter, as I believe that the new spreading function takes care of low frequencies by averaging fewer bins, i.e. giving more weight to the lowest FFT analysis results at low frequencies.

Please state any interest in retaining this parameter......

One thing to remember (and it's important) is that lossyWAV does not have a target bitrate in mind, only a quality level specified by the input parameters.

Also, due to the relatively small increase in total filesize on my sample set of the new -noclip (by bits_to_remove reduction) I would like feedback as to whether it should be on by default rather than have to be selected.

lossyWAV alpha v0.3.12 attached: Superseded.

In this version, the upper limits of the spreading function have been reduced to 12.4kHz and 15.8kHz respectively.

CODE

lossyWAV alpha v0.3.12 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation 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.0dB <= n <= 0.0dB, default -1.5dB)
              (reduces overall bits to remove, -1 bit = -6.0206dB)
-snr <n>      set minimum average signal to added noise ratio;
              (0.0dB <= n <= 48.0dB, default = 12.0dB)
-o <folder>   destination folder for the output file
-noclip       clipping prevention amplitude reduction; default=off
-force        forcibly over-write output file if it exists.

Advanced Options:

-skew <n>     skew fft analysis results by n dB
              (0.0db <= n <= 12.0db, default = 0.0dB) with a (sin-1) shaping in
              the frequency range 20Hz to 3.45kHz. (decrease low frequency bins
              to take into account higher SNR requirements at low frequencies)
-dither       dither output using triangular dither; default=off

System / Output options:

-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:

Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis.
Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.

Have fun now!

I finished my listening test with my usual samples using v0.3.11 -spread 1.
Everything is fine.
This time it was furious with which I had a similar effect to the one I described last time for keys: sometimes I believed that the original is a subtle bit lower in tonality than the lossyWaved version. I arrived at 6/7 and finished at 7/10 so this can't be judged as being abxed. Anyway a bit strange, especially as it's a déja vu.

It would be great if someone could try furious and keys_1644ds.

Thank you, Nick, for the new version. Will test FLAC bitrate with lossyWav -noclip option and without as soon I have found a set of clipping-prone samples.

Apart from the fantastic dedication of halb27, I think your main problem Nick is that you're not getting input from anyone - Golden eared or otherwise. (Consider the number of people who were involved trying to make lame 3.90.3 transparent!)

I wish I had time to help with the skew vs variable-spreading choice from a theoretical standpoint. Without a fleet of golden ears you're stabbing in the dark.

If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does. Never the less, given that it works at lower frequencies, that's good enough for me! I suspect that there are two possible approaches that could both work: variable-spreading, and fixed-spreading with frequency skew. Maybe the best is a combination of both. But again, if you have something that works, go for it. Just be aware that you don't have an army of golden Ears backing you up.

Cheers,
David.

I take it from that you think that the 5 bin spreading between 12.4kHz and 15.8kHz has in some way reduced the quality of the output. The simple way round that would be to revert to 4 bin averaging in this frequency band as well.
Taking on board what you said here, I have revised the skewing function and increased the upper skew limit to 48dB (too high, overkill, like the -snr maximum) and set a default -skew of 12dB (again like -snr, the user can actively switch it off by -skew 0). This coupled with the 2/3/4/5 bin weighting seems to give good reduction while maintaining higher bitrate on known problem samples. I am considering changing the default -nts values, but need feedback.

lossyWAV alpha v0.3.13 attached. Superseded.

clipping prevention default, use -clipping to disable;
12dB skew default, use -skew 0 to disable;
12dB average signal to added noise default, use -snr 0 to disable;

CODE

lossyWAV alpha v0.3.13 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation 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>      set noise_threshold_shift to n dB (-15dB<=n<=0dB, default=-1.5dB)
              (reduces overall bits to remove by 1 bit for every 6.0206dB)
-snr <n>      set minimum average signal to added noise ratio to n dB;
              (0dB <= n <= 48dB, default = 12dB)
-o <folder>   destination folder for the output file
-clipping     disable clipping prevention by iteration; default=off
-force        forcibly over-write output file if it exists.

Advanced Options:

-skew <n>     skew fft analysis results by n dB (0db<=n<=48db, default=12dB)
              in the frequency range 20Hz to 3.45kHz
-dither       dither output using triangular dither; default=off

System / Output options:

-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:

Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis.
Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.

So true, unfortunately.
Luckily we're not exactly in the same situation as the Lame devs.
Starting from your very first MATLAB version quality was already very high, and as long as variations are done in a defensive way lossyWav development isn't very dangerous qualitywise.
IMO taking it all in all the variants brought into lossyWav have a high probability of making progress towards ensuring quality even in difficult situations.
So IMO lossyWav can be used already for practical purposes.

Hopefully guruboolez will have time and test with the current version especially the problem he could abx.

did you guys dropped "lossyFLAC" and adopted "lossyWAV" ?

Yes, simply because the pre-processing method is not limited to the FLAC codec. I believe that it works well with TAK and WavPack as well. Also, in the "old school" programming world, naming had to be done within 8 characters......

I'll release v0.3.14 tonight - I am dabbling in FPU assembly and have made one notable speedup already (changed Magnitude function, which calculates the magnitude of a complex number, to assembler). Having trouble picking double real values out of an array of complex numbers though.......

Comparison of 0.3.13 and 0.3.11 on my SetF.

Bits to remove table.

TAK 1.0.2e08 -p3m bitrate table (lossless 862kbps).

Regarding performance: How about using floats with single precision?

Cheers!
SG

No, not the current version - I thought halb27 had ABXed a previous version with wider spreading? Sorry if I was mistaken, or if that's the one he retracted.

Cheers,
David.

In the end I could'nt abx a problem with any of the recent versions.

There is a small suspicion that someone else may really abx a problem with keys_1644ds and/or furious. I did beleive I can hear a subtle difference here, and my abx results were such that the listenenig results of other members are highly welcome.


@Nick: Looking at Josef's results: What makes 0.3.13 bring down the bitrate so significantly compared to 0.3.11?

It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section

if you guys could upload The "eig" sample with lossyWAV (provided with the lossless sample) I could try to ABX it. But I doubt I would since I did not with OGG at -q6. For what I have seen it would take a combination of a couple with golden years plus killer lossy codecs samples (gurubolez included..LOL).

File space is restricted here.
I provide the sample for a limited time on my webspace:
zip version of eig.original.flac and eig.lossy.flac.

eig.lossy.flac is encoded with 0.3.13 (no special options).

I can't upload in the FLAC forum.....

There was a bug - there was no 5 bin averaging between 12.4kHz and 15.8kHz, the program was using 4 bin averaging.

@Sebastian: I tried that at an early stage but the output didn't match that of Mathcad, so I didn't pursue it. I may revert to single if I have no luck with 80x87 assembly language....

I searched my collection looking for clipping samples. Which turned out to be not easy.

Tracks which I know have strong distortions in them didn't have them due to clipping. And when I found clipping it usually was so isolated that it wasn't worth while trying. CDs with the typical loudness-war style kind of compression and clipping didn't have the clipping level very close to the 100% CD level.

In the end I found a CD wonderfully suited for worst-case testing: Francoise Hardy: Le temps des Souvenirs. Not the kind of music I expected to be clipping-prone. But it seems to be terribly remastered in this respect.
I took 16 tracks from this 2 CD album (everything from my productive collection plus everything I could perfectly re-rip from the 1st CD). I added 15 other tracks of various kind which made at least a slight impression that bitrate might go up with the iterative clipping prevention method.

I encoded these 31 tracks using lossyWav 0.3.13 with and without the -clipping option (no other option).

All the tracks: Average bitrate with -clipping: 419 kbps.
All the Tracks: Average bitrate without -clipping: 467 kbps.

A closer look:

Francoise Hardy tracks: Average bitrate with -clipping: 441 kbps.
Francoise Hardy tracks: Average bitrate without -clipping: 551 kbps.

Non-Francoise Hardy tracks: Average bitrate with -clipping: 401 kbps.
Non-Francoise Hardy tracks: Average bitrate without -clipping: 402 kbps.

So with tracks loundness-war style and clipping at or very close to the peak level sure this clipping prevention scheme increases bitrate significantly.
On the other hand at least judging from my collection (and I looked at quite a lot of CDs published in recent years) it doesn't happen very often that bitrate bloat requirements are fulfilled.

In order to take everything into account a more elaborated clipping prevention method could be like this:
Encode with the iterative clipping prevention strategy. When doing so, compute the average bits removed also for the variant of pretending the clipping prevention strategy is not used (can easily be done in parallel - no extra encoding necessary). If in the end it turns out the percentage of the difference between the two strategies is too high, reencoding can occur with a scale factor for preventing clipping.
From all we know so far reencoding is rarely necessary, and in these strong clipping cases it's easy to accept the theoretical quality impact of scaling.

The threshold for reencoding can vary with quality level, for instance like this:
-1: no reencoding with scaling no matter what bits to remove difference
-2: reencoding with scaling in case bits to remove difference is greater than 10%.
-3: reencoding with scaling in case bits to remove difference is greater than 5%.

I listened to my usual sample set with v0.3.13 (no option).
Everything is fine.
Amazing for this rather low bitrate on average with usual samples.

I'm *really* glad that the new spreading function / skew combination is working [good shout, David!]! Also, keeping the bitrate down is nearly as important.

Is there any appetite for correction files? I have been toying with the idea of this option but it's not worth doing if there is no "market".

lossyWAV alpha v0.3.14 attached: - superseded.

No parameter changes, just faster.

lossyWAV alpha v0.3.15 attached. Superseded.

Code speeded up again.

Changes made to quality level -3 to make it slightly more aggressive : codec_block_size changed from 1024 samples to 512; -nts default changed from -1 to -0.5.

I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please.

CODE

lossyWAV alpha v0.3.15 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation 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>      set noise_threshold_shift to n dB (-15dB<=n<=0dB, default=-1.5dB)
              (reduces overall bits to remove by 1 bit for every 6.0206dB)
-snr <n>      set minimum average signal to added noise ratio to n dB;
              (0dB<=n<=48dB, default=12dB)
-skew <n>     skew fft analysis results by n dB (0db<=n<=48db, default=12dB)
              in the frequency range 20Hz to 3.45kHz
-o <folder>   destination folder for the output file
-clipping     disable clipping prevention by iteration; default=off
-force        forcibly over-write output file if it exists; default=off

Advanced / System Options:

-dither       dither output using triangular dither; 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:

Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis.
Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.

I welcome the approach of putting more details into -1, -2, -3, as well as a more pronounced differentiation security-/and bitrate wise for -1 and -3, with -2 being the standard as ever with a good but not exaggerated security margin.

But what is the advantage of a blocksize of 2048 for -1?

Indepent of the block size question for -1 I personally would like to see a new approach with spreading_length=1 for low frequencies and short ffts cause in this case the current approach averages over more than 1 critical band.

A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.

At present for my 52 sample set WAV: 121.53MB; FLAC: 68.20MB, 791.9kbps; -1: 42.97MB 499.0kbps(106.1% -2); -2: 40.49MB, 470.2kbps; -3: 37.68MB, 437.5kbps (93.1% -2). A quick test of "-1 -snr 24" gave 44.67MB, 518.7kbps (110.3% -2).

I will have a look at spreading_function_length with respect to Critical Bandwidth and post.

[edit] See attached Excel sheet. I will have a think as to how best to implement this, without reverting to my abortive previous attempt at Bark averaging. [/edit]

I understand well that you want to be conservative qualitywise with -1, and a blocksize of 2048 certainly will reduce bits to remove, but from my naive understanding I cannot see a promising impact of a 2048 sized block on quality. The -snr approach or an increased value of -nts or -skew are more promising to me.

My personal feelings however go strongly in the direction that for FFT lengths <= 256 the spreading length is two long in case the width of critical bands are worth taking into account.
Sure there must be compromise, and IMO the current results are very good. But in favor of conservatism for -1 a shorter spreading length at least for a FFT length of 64 and low frequency is welcome IMO (spreading_length=1 in this case), and in case the influence on bits removed remains acceptable even for a FFT length of 128 and maybe 256 spreading length should be tried to get lower than they are now, and if possible not only for the low frequency end.

I agree, a -snr / -skew combination will probably be a better solution. I am running a matrix calculation of -snr 0 to 30 step 3, -skew 0 to 30 step 3 to see what happens with bitrate for my sample set.I am currently looking at what impact a spreading_function_length of 1 would have and how to implement it. It could be as simple as if FFT_length<256 then spreading_function_length=1. if 256 or 512 then 1,2,3,4. if 1024 or above then 2,3,4,5.