lossyWAV Development
Reply #170 – 2007-09-21 13:19:30
Perhaps we should split this thread somehow in one that contains bug reports and announcements of versions (which I'm not interested in) and a technical one where strategies and techniques are discussed. Skewing now follows a (sin-1) shape rather than (1-cos), now 9dB rather than 6dB; Forgive my ignorance but what exactly is "skewing"? Is there a relation to noise shaping? What's the current state strategy on selecting the 'wasted_bits' count / noise shaping filters (if any) ? Cheers! SG The original thread is still running in the FLAC forum - maybe technical discussion should move to that? Skewing in this instance artificially lowers the fft bin values, in this case at the lower end of the fft results. As applied in the code, at the low_frequency_bin the dB reduction is by the full amplitude of the selected reduction amount. At the high_frequency_bin there is no reduction at all. The shape of the dB reduction curve is a scaled (1-sin[value]) curve where value is 0 at the lfb (or lower) and pi/2 at the hfb (or higher). For a 32 sample fft_length, lfb=2, hfb=11:Bin Freq. 1-sin dB reduction 00 0 -1.000 -9.031 01 1378 -1.000 -9.031 02 2756 -1.000 -9.031 03 4134 -0.826 -7.463 04 5513 -0.658 -5.942 05 6891 -0.500 -4.515 06 8269 -0.357 -3.226 07 9647 -0.234 -2.113 08 11025 -0.134 -1.210 09 12403 -0.060 -0.545 10 13781 -0.015 -0.137 11 15159 0.000 0.000 12 16538 0.000 0.000 From the discussions previously, maybe the zero-point in this reduction should be the nearest bin to 3.5kHz, and maybe the amplitude of the skew should be more extreme. The bits_to_remove value for each codec block is the threshold_index corresponding to the dB of the lowest (CONV'd) bin in any of the analyses carried out on that codec block. The threshold index is determined by calculating the dithered bit reduction noise dB for each bit_to_remove for each fft length.