lossywav1.3.0.exe input.wav -o outputdir --correction --quality portable --adaptive OFFresult: 9x speedlossywav1.1.0c.exe input.wav -o outputdir --correction --portableresult: 33x speed
lossless flac: 854 kbit/s--portable lossywav flac: 376 kbit/s (-56%)
thank you Northpack. This increases speed to 9x, but still isn't close to the 33x I had with 1.1.0c
I always thought that there is unsuitable real-world wave input for lossyWAV (i.e. an input which won't result in significantly higher compression when prepocessed with lossyWAV). I just came across an example which seems to defy that rule.
I always thought that there is NO unsuitable real-world wave input for lossyWAV
If you want it fast, I suppose you should stay with 1.1.0c
Make sure that lossyWAV uses fftw library (libfftw3-3.dll).
lossywav1.1.0c.exe input.wav -o outputdir --correction --portable33x speedlossywav1.3.0.exe input.wav -o outputdir --correction --quality portable 5x speed --> with libfftw3-3.dll: 7x speedlossywav1.3.0.exe input.wav -o outputdir --correction --quality portable --adaptive OFF9x speed --> with libfftw3-3.dll: 17x speed
Regarding processing speed, there are 3 things to note: [...]
Regarding content where processing using lossyWAV and compression using FLAC results in a larger file-size - this is not a new discovery - content was found quite early in the original development of lossyWAV where there was no advantage gained.
No surprise here. It's known that there are some kind of signals which FLAC itself compresses very efficiently (i.e. solo piano music).
which type of content is that?
i get -48% for a 43min 16bit 48kHz .wav with wma lossless...
with little or no content at one or more points in the calculation range (20Hz to c.16kHz) will result in less bits removed.
I believe that your recent change from v1.1.0c to v1.3.0 explains the "sudden jump between 0.2% and 11%" as the quality presets were amended during the development of v1.3.0.
This is not a lowpass - this is an outcome of the frequency range in which lossyWAV searches for the lowest frequency bin result.
What conclusions can non-experts users such as myself can draw from all this? Do we have to (or should we?) create a spectogram each time before processing audio with lossyWAV to see (A) if lossyWAV preparation will lead to a noteworthy file size reduction and (B) if we need to use a non-default value for the --limit parameter ?
Problematic samples in lossyWAV tend to manifest themselves as samples that the process does not manage to remove many bits from - these generally have dips in the frequency range inside the calculation range where the lowest frequency response is determined.
Thinking of reducing maximum clips-per-channel-per-codec-block to zero when adaptive shaping is active to reduce the possibility of the current method which allows a certain number of clips from "overloading" the noise-shaping filter(s).