What do you get for your test set resampled to 32kHz, processed with -2?Does 32k resampling followed by ReplayGain (only negative values applied) help even more?It makes sense to have a -3 along the lines you're proposing, but I suspect the above will be dramatically more efficient, and still artefact-free (though with a 16k LPF and, with RG, loud tracks becoming quieter).Cheers,David.

Quote from: halb27 on 12 November, 2007, 09:13:11 AMTarget b) for -3: OK, so we should think about the details.Just following you dialog here.. This seems the right basic choice, there has to be a benefit for offering a (little) bit of quality. IMO that means a significant lower bit rate for -3 (compared with -2).(Would -skew of -12 -18 -24 (for -3 -2 -1) be too agressive?)Quote from: Nick.C on 12 November, 2007, 05:25:21 PMI am wondering about the clipping reduction method - at the moment, if it finds 1 or more sample which clips after rounding then it reduces bits_to_remove by one and tries again, until bits_to_remove=0 then it just stores the original values. Is 0 permissible clipping samples a bit too harsh? At the time thatthe iterative clipping was introduced, I put in an "allowable" variable, implying that a number of clipping (but rounded) samples may be permitted.I suppose you mean consecutive samples of the maximum (or minimum) value? To me in this case 0, 1 or 2 would make sense, only already badly clipping music would be affected by other values.And yes, the dither function is obsolete as you no longer opt to lower the amplitude.Quote from: Nick.C on 12 November, 2007, 06:22:41 PMI also tried -3 [..] which yielded 420kbps [..] [edit]Maybe 400kbps for "real music" should be the target rather than approaching that for my problem set. [/edit]The problem with this is that from the offset this method aims for constant quality (I like that BTW) so the bit rate will vary. I found for example that music that already compresses well (lossless) like in the 600's will not get half the bit rates with the help of lossyWav but rather still around 420.

Target b) for -3: OK, so we should think about the details.

I am wondering about the clipping reduction method - at the moment, if it finds 1 or more sample which clips after rounding then it reduces bits_to_remove by one and tries again, until bits_to_remove=0 then it just stores the original values. Is 0 permissible clipping samples a bit too harsh? At the time thatthe iterative clipping was introduced, I put in an "allowable" variable, implying that a number of clipping (but rounded) samples may be permitted.

I also tried -3 [..] which yielded 420kbps [..] [edit]Maybe 400kbps for "real music" should be the target rather than approaching that for my problem set. [/edit]

lossyWAV alpha v0.4.5 : WAV file bit depth reduction method by 2Bdecided.Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.orgUsage : lossyWAV <input wav file> <options>Example : lossyWAV musicfile.wavQuality Options:-1 extreme quality [5xFFT] (-cbs 512 -nts -3.0 -skew 30 -snr 24 -spf 11124-11125-11225-11225-11236 -fft 11111)-2 default quality [4xFFT] (-cbs 512 -nts -1.5 -skew 24 -snr 18 -spf 11235-11236-11336-12348-1234D -fft 11101)-3 compact quality [3xFFT] (-cbs 512 -nts -0.5 -skew 24 -snr 18 -spf 22236-22237-22347-22358-2234E -fft 01010)-o <folder> destination folder for the output file-force forcibly over-write output file if it exists; default=offAdvanced / System Options:-nts <n> set noise_threshold_shift to n dB (-18dB<=n<=0dB) (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)-skew <n> skew fft analysis results by n dB (0db<=n<=48db) in the frequency range 20Hz to 3.45kHz-cbs <n> set codec block size to n samples (512<=n<=4608, n mod 32=0)-fft <5xbin> select fft lengths to use in analysis, using binary switching, from 64, 128, 256, 512 & 1024 samples, e.g. 01001 = 128,1024-overlap enable conservative fft overlap method; default=off-spf <5x5hex> manually input the 5 spreading functions as 5 x 5 characters; These correspond to FFTs of 64, 128, 256, 512 & 1024 samples; e.g. 44444-44444-44444-44444-44444 (Characters must be one of 1 to 9 and A to F (zero excluded).-clipping disable clipping prevention by iteration; default=off-allowable select allowable number of clipping samples per codec block before iterative clipping reduction; (0<=n<=64, default=0).-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.

Code: [Select]-allowable select allowable number of clipping samples per codec block before iterative clipping reduction; (0<=n<=64, default=0).

-allowable select allowable number of clipping samples per codec block before iterative clipping reduction; (0<=n<=64, default=0).

%lossyWAV Warning% : Codec_block_size forced to 512 bytes.%lossyWAV Warning% : Allowable clipping samples set to 1 per codec block.%lossyWAV Warning% : Process priority set to low.temp-6605F1A4E1877D7AA8BA0D93BF92EA95.wav;5.2624;67932;12909;8.92x%lossyWAV Warning% : 9 sample(s) clipped to maximum +ve amplitude.%lossyWAV Warning% : Codec_block_size forced to 512 bytes.%lossyWAV Warning% : Process priority set to low.temp-6605F1A4E1877D7AA8BA0D93BF92EA95.wav;5.2606;67909;12909;9.01x%lossyWAV Warning% : 23 bits not removed due to clipping.

Quote from: Nick.C on 13 November, 2007, 04:25:40 PM[code]-allowable select allowable number of clipping samples per codec block before iterative clipping reduction; (0<=n<=64, default=0).[/codeI tried with/without -allowable 1 on a track that hits full scale.Doesn't make a lot of difference here.BTW shouldn't the logging say 512 samples

[code]-allowable select allowable number of clipping samples per codec block before iterative clipping reduction; (0<=n<=64, default=0).[/code

So after about 8 hours of opcode hexing, and batch file scripting... lFLCDrop is born. See attached.

lossyWAV alpha v0.4.6 : WAV file bit depth reduction method by 2Bdecided.Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.orgUsage : lossyWAV <input wav file> <options>Example : lossyWAV musicfile.wavQuality Options:-1 extreme quality [5xFFT] (-cbs 512 -nts -3.0 -skew 30 -snr 24 -spf 11124-11125-11225-11225-11236 -fft 11111)-2 default quality [4xFFT] (-cbs 512 -nts -1.5 -skew 24 -snr 18 -spf 11235-11236-11336-12348-1234D -fft 11101)-3 compact quality [2xFFT] (-cbs 512 -nts -0.5 -skew 24 -snr 18 -spf 22236-22237-22347-22358-2234E -fft 01010)-o <folder> destination folder for the output file-force forcibly over-write output file if it exists; default=offAdvanced / System Options:-nts <n> set noise_threshold_shift to n dB (-18dB<=n<=+6.0dB) (-ve values reduces bits to remove, +ve value increase)-snr <n> set minimum average signal to added noise ratio to n dB; (0dB<=n<=48dB) Increasing value reduces bits to remove.-skew <n> skew fft analysis results by n dB (0db<=n<=48db) in the frequency range 20Hz to 3.45kHz-cbs <n> set codec block size to n samples (512<=n<=4608, n mod 32=0)-fft <5xbin> select fft lengths to use in analysis, using binary switching, from 64, 128, 256, 512 & 1024 samples, e.g. 01001 = 128,1024-overlap enable conservative fft overlap method; default=off-spf <5x5hex> manually input the 5 spreading functions as 5 x 5 characters; These correspond to FFTs of 64, 128, 256, 512 & 1024 samples; e.g. 44444-44444-44444-44444-44444 (Characters must be one of 1 to 9 and A to F (zero excluded).-clipping disable clipping prevention by iteration; default=off-allowable select allowable number of clipping samples per codec block before iterative clipping reduction; (0<=n<=64, default=0).-window select windowing function n (0<=n<=6, default=0); 0=Hanning 1=Bartlett-Hann; 2=Blackman; 3=Nuttall; 4=Blackman-Harris; 5=Blackman-Nuttall; 6=Flat-Top.-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.

Thanks to everyone for bettering LossyWAV!! I don't know exactly what is happening here, but when I try to run version 0.4.6 it just outputs a wav header and no data. I attached a screenshot of the commandline, and it appears that LossyWAV doesn't even try to render any audio for me. I'm running an Intel Celeron processor @ 2.4ghz (the P4 based style) and I'm wondering if something SSE-wise just isn't meshing with my processor. If anybody has any answers they will be greatly appreciated, but I'm gonna for now hope that newer versions will work again for me.Thanks!-808

[edit]There's a bug in the -detail parameter which seems to prematurely end the process. I'll amend and include in the the next revision.[/edit]

I tried 0.4.7 on my regular/problem test set and got the following average bitrates:-1: 512/585 kbps for my regular/problem sample set-2: 430/539 kbps for my regular/problem sample set-3: 388/481 kbps for my regular/problem sample set-3 -nts 6 -skew 36 -snr 21: 338/468 kbps for my regular/problem sample set.To me these are a very attractive bitrate variations for the various quality levels, and the average bitrate differences between regular and problems samples show at least in a statistical sense that lossyWav can differentiate well what to do according to the different situations.Your new -3 candidate looks extremely attractive judging from the statistics, Nick.Statistics however doesn't really tell about quality, so I tried -3 -nts 6 -skew 36 -snr 21 on my problem samples as well as on some tracks of regular music.Surprise was the only issue I found was with badvilbel at ~sec. 19.0 where I could abx the added hiss 8/10. This added hiss is so negligible to me that it is well within the excellent quality I'd like to see with -3.I have never thought before that lossyWav is that good at an average bitrate of ~340 kbps with regular music.Great work, Nick.So this is the way to go for -3 IMO as long as we don't get bad news. Maybe even for -2 in an adapted and more cautious way.

I couldn't resist and try your new -3 proposal this morning, Nick.The statistics says 343/473 kbps on average for my regular/problem set which is very close to the 338/468 kbps of the current -3 setting.I also tried the 'hiss spot' of badvilbel, and I can't abx the difference.Looking more closesly at the new setting it is a bit of what I have in mind with -2: let the short FFT do the main decision job for the high frequencies (the short FFT is good at that), and let the long FFT do the main decision job on the low frequencies (the short FFT isn't good at that).Sorry for having been pretty negative about the new -3 setting. Guess I was a bit upset cause I've done a lot of listening effort with the current -3 setting. But I think this wasn't useless when switching to the new setting. The major principle is the same, and it is a little bit more defensive. Sure I'll try the new setting with my usual problem samples tonight. To me this is sufficient and I won't go through part of my regular collection again.What's more relevant IMO: why is this -nts x setting, with x>0 to a rather high degree so good? Can we trust it so much to use a positive -nts also for the higher quality settings?A high -skew value is a good thing for differentiating good and bad spots (with respect to 'number of bits to remove') in the music. But -skew is effective only at rather low frequencies. Together with a high -skew value -snr also does a good job differentiating. But because of this interconnection I'm afraid -snr is effective also only in the low to lower medium frequency range below ~3 kHz.If this is correct using a positive -nts value leaves the high frequency range under reduced noise control.However from what we experienced so far this doesn't seem to have a practical negative impact.Maybe dropping the same amount of LSBs in an entire block usually gives a noise floor with frequencies below 3 kHz which is caught well by the skew/snr machinery even with a rather high positive -nts value?Or maybe maybe the ATH curve is relevant here which gives reduced sensitivity to the 3+ kHz range for low level signals?In either case it would be very welcome if younger members could contribute listening. If for instance everything's fine in the high frequency range to my old ears this doesn't say a lot.

-------------------------------------------------------------------------Qual. String Rem.Bits kb/s -------------------------------------------------------------------------0,2 | 4096 -15,0 44,4 43 1111211112111121111211112 11111 | 0,3797 | 830 |0,4 | 2048 -12,0 40,8 38 1111211113111131111311123 11111 | 1,1347 | 770 |0,6 | 2048 -9,0 37,2 34 1112311123112231122311224 11111 | 2,2097 | 678 |0,8 | 1024 -6,0 33,6 29 1112311124112241122411235 11111 | 3,3363 | 593 |1,0 | 512 -3,0 30,0 24 1112411125112251122511236 11111 | 4,3924 | 523 |1,4 | 512 -2,4 27,6 22 111351113611236112381124D 11111 | 4,7898 | 491 |1,6 | 512 -2,1 26,4 20 112351123611336113481134D 11101 | 5,2201 | 458 |2,0 | 512 -1,5 24,0 18 112351123611336123481234D 11101 | 5,4594 | 440 |2,4 | 512 1,5 28,8 19 112361123711347123581234E 11010 | 5,9919 | 401 |2,7 | 512 3,8 32,4 20 122361223712347123581234E 01010 | 6,4358 | 370 |3,0 | 512 6,0 36,0 21 222362223722347223582234E 01010 | 6,9055 | 337 |3,4 | 512 6,0 21,6 13 7778A7778A7788A7789B7788E 01010 | 7,6182 | 295 |3,8 | 512 6,0 7,2 4 CCCDDCCCDDCCDDDCCDDECCDDF 00100 | 8,1760 | 269 |-------------------------------------------------------------------------

.... apply some morphing between them ...

Well, while we are talking about defaults settings... in these days I've been working, just for the fun of it, on a very simple algorhythm....

Your -2 proposal yields 420/543 kbps on average for my regular/problem samples, and this is not a lot better in comparison to the 430/539 kbps on average of the current -2 setting.....With -1 it's 523/601 kbps for regular/problematic tracks, and this too isn't a real progress from the 512/585 kbps for the current -1 setting......

-2 -skew 36 -snr 24 -fft 10011 -spf 22235-22236-22347-12359-1236C -nts 2which yields 395/551 kbps for my regular/problematic tracks.-1 -skew 40 -snr 21 -fft 11011 -spf 22224-22225-11235-11246-12358 -nts -1which yields 452/576 kbps for my regular/problematic set.