That did amount to a not-at-all-bad 13 kB per ekstra second.

• @Wombat's "Exact Rice" build. At -8 it saved 0.02 percent over the Xiph build. That did amount to a not-at-all-bad 13 kB per ekstra second. 
  
• -8 -A "subdivide_tukey(4)", beefing that one up. About the same as the Exact Rice build, both in time and size (loses narrowly to it due to the classical music). I did not do that setting with the Exact Rice.
• -8r7, -8pr7 in the Xiph build and the "Exact Rice" build: surprisingly little. Especially surprising especially on the heavier corpus where that fine partitioning is often used - but not so much saved from it. Hardly any difference at classical music. Overall only 3 kB/s saved at -8 (Xiph), and much less at -8p and at Exact Rice.
  
• Any synergies between Exact Rice and -p? No. Even less than previous line.  Exact Rice's -8p is slow. 
• Heavier flaccid: 40 percent more time than the one above, did improve but very little.  --mode peakset --blocksize-list 2304,4608 --analysis-comp 5 --output-comp 8r7  --queue 32 --tweak 32 --merge 0
  
• Lighter flaccid: just a little bit faster than the gasc above, and not far worse, was --mode chunk --blocksize-list 2304,4608 --tweak 0 --merge 0 --analysis-comp 8 --output-comp 8r7
  
  

Quote from: Raven1 on 2025-05-11 05:52:02

[Thanks! Any opinion on noise shaping?

Some years back i played around with noise shaping and found the shibata shapes indeed sounding very pleasant to my ears when amplified. There must be some samples in the upload section.
I checked many years on many recordings if it is worth to apply but all the music i seem to listen never needs full 16 bits leave alone needing it noise shaped.
For the sake of doing at least something to lower the possibility of perceived noise i now use the sloped dither inside SoX with dither -S -a.

You only need one $replace
...

$replace($replace($replace(Just a little bit more louder than before,a,z),e,w)o,x)

• WavPack Hybrid is slower and takes more space than FLAC. The lossy part is obviously larger than a pure lossy codec (about twice the size at 320 kbps than my ~160 kbps Vorbis files).
• LossyWAV suffers from the same issue, whether you encode it with FLAC or WavPack (or TAK).
• Correction files are supposed to live in the same directory as the lossy files, which makes it very inconvenient to copy an entire lossy collection to a DAP (say, my iPhone). I could write a BASH script (and I just might) to move lossy files and correction files to twin directory structures. That way I could just drag and drop the lossy directory structure to my iPhone. But I also would need to run that script in reverse to join lossy and correction files back together.
• lossyWAV has a bigger problem of its own: the way it works is that you end up with two WAV files, that you encode with FLAC or whatever. So there's the time spent by lossyWAV to treat the original WAV, then the time spent on losslessly encoding TWO files instead of one. Then, when you want to losslessly transcode those, you need to decode both lossless files (so, twice the time), then use lossyWAV to merge the resulting two files (more time spent), and then finally transcode the reconstructed file to whatever you like. It's very slow, and very storage intensive (3 WAV files in total before you can transcode the 3rd file).