I hear what's being said, but my ears / listening environment are not up to finalising the settings by myself.
The current (unreleased alpha v0.3.6) command line parameter list is as follows:
lossyWAV alpha v0.3.6 : WAV file bit depth reduction method by 2Bdecided.
Transcoded to Delphi by Nick.C & Halb27 from a script, www.hydrogenaudio.org
Usage: lossyWAV <input wav file> <options>
Options:
-1, -2 or -3 quality level (1:overkill, 2:default, 3:compact)
-o <folder> destination folder for the output file
-force forcibly over-write output file if it exists.
-cbs <n> analysis codec_block_size (512<=n<=4608, default=576 samples)
(should match codec block size used in target compression codec)
-nts <n> noise_threshold_shift=n (-15.0<=n<=0.0, default -1.5dB)
(reduces overall bits to remove)
-spread select variable spreading functions.(incompatible with -weight)
-weight select weighted spreading functions.(incompatible with -spread)
(weighted average of fft bins during convolution of fft results
weighted towards lower frequency fft bins, 5/8:3/8)
-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 <n> dither selection, 0<=n<=2, default=0
(0=no dither; 1=rectangular dither; 2=triangular dither)
-clipping <n> clipping prevention selection, 0<=n<=1, default=0. 0=none;
1=fixed clipping prevention amplitude reduction, taking into
account dither amplitude (if any).
-overlap <n> fft_overlap = fft_length/n (2<=n<=8, default=2)
(increases number of fft analyses per codec block)
-quiet significantly reduce screen output
-nowarn suppress lossyWAV warnings
-detail enable detailled output mode
-info display WAV file information
-below set process priority to below normal.
-low set process priority to low.
Options not yet implemented:
-bitdepth <n> forced output bitdepth (16 or 24)
-flac optimizations for use with FLAC
-wv optimizations for use with wavPack
-tak optimizations for use with TAK
[/size]
However, I think that it may be beneficial to reduce this to
lossyWAV alpha v0.3.6 : WAV file bit depth reduction method by 2Bdecided.
Transcoded to Delphi by Nick.C & Halb27 from a script, www.hydrogenaudio.org
Usage: lossyWAV <input wav file> <options>
Options:
-1, -2 or -3 Classic 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)
-o <folder> destination folder for the output file
-force forcibly over-write output file if it exists.
-dither dither output using triangular dither, default=off
-clipping <n> clipping prevention selection, 0<=n<=1, default=0. 0=none;
1=fixed clipping prevention amplitude reduction, taking into
account dither amplitude (if any).
-quiet significantly reduce screen output
-nowarn suppress lossyWAV warnings
-below set process priority to below normal.
-low set process priority to low.
[/size]and tweak the parameters implicit in -1,-2 & -3. Possibly implement additional test settings to see whether a listener prefers -2 or -20? Codec block size needs to be stated for each quality setting or the user will not know how to optimally compress the output.
As an aside, I used v0.3.5 to compress 30GB of FLAC files at quality -2 and got 15.2GB out - average bitrate approx 420kbps.
As there are no real process developments (other than code optimisation) in v0.3.6, I will defer release until a way forward is agreed on internal quality settings development.
Nick.
... -spread, replaces -vsfl. An experimental take on spreading. ...
Sorry, but I'm not sure whether it's a promising procedure to try out different weights in building the average of 3 or 4 bins. My feeling is that in the overall view that's not significant variation and may produce better results in one case and worse in other ones.
I'm still a bit worried about David Bryants comment on the spreading function: that the critical bands have a different width, with corner frequencies according to Bark of 0, 100, 200, 300, 400, 510, 630, 770, 920, 1080, 1270, 1480, 1720, 2000, 2320, 2700, 3150, 3700, 4400, 5300, 6400, 7700, 9500, 12000, 15500 Hz.
So to me it's plausible to vary the number of bins over which to build the average not only according to the fft_length as you did already with the previous -vfsl option, but also on the frequency range the corresponding bin belongs to. Taking it into account roughly may be sufficient (for instance averaging over 2 bins in the range up to 1720 Hz, 3 bins in the range up to 3700 Hz and over 4 bins otherwise).
[/size]
The most recent experimental take on spreading (in the original thread) uses simple 3 bin average at short FFT lengths (2 to 64 samples) and shifts gradually to max of adjacent bins and current bin (a simple attempt at masking) at long FFT lengths (1024 to 32768 samples). If anyone has any algorithmic ideas with regard to spreading, then please let me know. Bear in mind that the default quality settings have always used 4 bin averaging (-2 & -3) and 3 bin averaging (-1).