Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lossyWAV Development (Read 559168 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lossyWAV Development

Reply #325
Thank you, Josef.
So with your test set the new clipping prevention scheme doesn't have a seriously bad influence on the bitrate.
I'll try and find some clipping-prone samples and test it too.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #326
I would like to remove the "-skew" parameter, as I believe that the new spreading function takes care of low frequencies by averaging fewer bins, i.e. giving more weight to the lowest FFT analysis results at low frequencies.

Please state any interest in retaining this parameter......

One thing to remember (and it's important) is that lossyWAV does not have a target bitrate in mind, only a quality level specified by the input parameters.

Also, due to the relatively small increase in total filesize on my sample set of the new -noclip (by bits_to_remove reduction) I would like feedback as to whether it should be on by default rather than have to be selected.

lossyWAV alpha v0.3.12 attached: Superseded.

In this version, the upper limits of the spreading function have been reduced to 12.4kHz and 15.8kHz respectively.

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Code: [Select]
lossyWAV alpha v0.3.12 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      noise_threshold_shift=n (-15.0dB <= n <= 0.0dB, default -1.5dB)
              (reduces overall bits to remove, -1 bit = -6.0206dB)
-snr <n>      set minimum average signal to added noise ratio;
              (0.0dB <= n <= 48.0dB, default = 12.0dB)
-o <folder>   destination folder for the output file
-noclip       clipping prevention amplitude reduction; default=off
-force        forcibly over-write output file if it exists.

Advanced Options:

-skew <n>     skew fft analysis results by n dB
              (0.0db <= n <= 12.0db, default = 0.0dB) with a (sin-1) shaping in
              the frequency range 20Hz to 3.45kHz. (decrease low frequency bins
              to take into account higher SNR requirements at low frequencies)
-dither       dither output using triangular dither; default=off

System / Output options:

-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.
[/size]

Have fun now!
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #327
I finished my listening test with my usual samples using v0.3.11 -spread 1.
Everything is fine.
This time it was furious with which I had a similar effect to the one I described last time for keys: sometimes I believed that the original is a subtle bit lower in tonality than the lossyWaved version. I arrived at 6/7 and finished at 7/10 so this can't be judged as being abxed. Anyway a bit strange, especially as it's a déja vu.

It would be great if someone could try furious and keys_1644ds.

Thank you, Nick, for the new version. Will test FLAC bitrate with lossyWav -noclip option and without as soon I have found a set of clipping-prone samples.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #328
Personally, I will probably use -3 as I too want to keep the bitrate down, but I am being lead by my more golden-eared colleagues with respect to level -2.
Apart from the fantastic dedication of halb27, I think your main problem Nick is that you're not getting input from anyone - Golden eared or otherwise. (Consider the number of people who were involved trying to make lame 3.90.3 transparent!)

I wish I had time to help with the skew vs variable-spreading choice from a theoretical standpoint. Without a fleet of golden ears you're stabbing in the dark.

If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does. Never the less, given that it works at lower frequencies, that's good enough for me! I suspect that there are two possible approaches that could both work: variable-spreading, and fixed-spreading with frequency skew. Maybe the best is a combination of both. But again, if you have something that works, go for it. Just be aware that you don't have an army of golden Ears backing you up.

Cheers,
David.

lossyWAV Development

Reply #329
If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does.
I take it from that you think that the 5 bin spreading between 12.4kHz and 15.8kHz has in some way reduced the quality of the output. The simple way round that would be to revert to 4 bin averaging in this frequency band as well.
Never the less, given that it works at lower frequencies, that's good enough for me! I suspect that there are two possible approaches that could both work: variable-spreading, and fixed-spreading with frequency skew. Maybe the best is a combination of both.
Taking on board what you said here, I have revised the skewing function and increased the upper skew limit to 48dB (too high, overkill, like the -snr maximum) and set a default -skew of 12dB (again like -snr, the user can actively switch it off by -skew 0). This coupled with the 2/3/4/5 bin weighting seems to give good reduction while maintaining higher bitrate on known problem samples. I am considering changing the default -nts values, but need feedback.

lossyWAV alpha v0.3.13 attached. Superseded.

clipping prevention default, use -clipping to disable;
12dB skew default, use -skew 0 to disable;
12dB average signal to added noise default, use -snr 0 to disable;

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Code: [Select]
lossyWAV alpha v0.3.13 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      set noise_threshold_shift to n dB (-15dB<=n<=0dB, default=-1.5dB)
              (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, default = 12dB)
-o <folder>   destination folder for the output file
-clipping     disable clipping prevention by iteration; default=off
-force        forcibly over-write output file if it exists.

Advanced Options:

-skew <n>     skew fft analysis results by n dB (0db<=n<=48db, default=12dB)
              in the frequency range 20Hz to 3.45kHz
-dither       dither output using triangular dither; default=off

System / Output options:

-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.
[/size]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #330
Apart from the fantastic dedication of halb27, I think your main problem Nick is that you're not getting input from anyone - Golden eared or otherwise. (Consider the number of people who were involved trying to make lame 3.90.3 transparent!)

So true, unfortunately.
Luckily we're not exactly in the same situation as the Lame devs.
Starting from your very first MATLAB version quality was already very high, and as long as variations are done in a defensive way lossyWav development isn't very dangerous qualitywise.
IMO taking it all in all the variants brought into lossyWav have a high probability of making progress towards ensuring quality even in difficult situations.
So IMO lossyWav can be used already for practical purposes.

Hopefully guruboolez will have time and test with the current version especially the problem he could abx.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #331
did you guys dropped "lossyFLAC" and adopted "lossyWAV" ?

lossyWAV Development

Reply #332
did you guys dropped "lossyFLAC" and adopted "lossyWAV" ?
Yes, simply because the pre-processing method is not limited to the FLAC codec. I believe that it works well with TAK and WavPack as well. Also, in the "old school" programming world, naming had to be done within 8 characters......

I'll release v0.3.14 tonight - I am dabbling in FPU assembly and have made one notable speedup already (changed Magnitude function, which calculates the magnitude of a complex number, to assembler). Having trouble picking double real values out of an array of complex numbers though.......
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #333
Comparison of 0.3.13 and 0.3.11 on my SetF.

Bits to remove table.
Code: [Select]
------- -------------------- -------------------- --------------------
|      |       0.3.13       |       0.3.11       |      13 vs 11      |
|       ------ ------ ------ ------ ------ ------ ------ ------ ------
|      |   1  |   2  |   3  |   1  |   2  |   3  |   1  |   2  |   3  |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------
|  512 | 5,13 | 5,64 | 5,85 | 4,04 | 4,80 | 5,03 | 1,09 | 0,84 | 0,82 |
| 1024 | 4,88 | 5,25 | 5,40 | 3,77 | 4,42 | 4,58 | 1,11 | 0,83 | 0,82 |
| 2048 | 4,48 | 4,93 | 5,09 | 3,39 | 4,11 | 4,27 | 1,09 | 0,82 | 0,82 |
| 4096 | 4,11 | 4,55 | 4,70 | 3,05 | 3,75 | 3,91 | 1,06 | 0,80 | 0,79 |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------

TAK 1.0.2e08 -p3m bitrate table (lossless 862kbps).
Code: [Select]
------- ----------------- ----------------- -----------------
|      |  TAK on 0.3.13  |  TAK on 0.3.11  |    13 vs 11     |
|       ----- ----- ----- ----- ----- ----- ----- ----- -----
|      |  1  |  2  |  3  |  1  |  2  |  3  |  1  |  2  |  3  |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----
|  512 | 465 | 426 | 411 | 552 | 490 | 472 | -87 | -64 | -61 |
| 1024 | 470 | 441 | 430 | 557 | 504 | 491 | -87 | -63 | -61 |
| 2048 | 492 | 457 | 445 | 578 | 520 | 507 | -86 | -63 | -62 |
| 4096 | 517 | 482 | 471 | 602 | 545 | 532 | -85 | -63 | -61 |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----

lossyWAV Development

Reply #334
I'll release v0.3.14 tonight - I am dabbling in FPU assembly and have made one notable speedup already (changed Magnitude function, which calculates the magnitude of a complex number, to assembler). Having trouble picking double real values out of an array of complex numbers though.......


Regarding performance: How about using floats with single precision?

Cheers!
SG

lossyWAV Development

Reply #335
If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does.
I take it from that you think that the 5 bin spreading between 12.4kHz and 15.8kHz has in some way reduced the quality of the output.
No, not the current version - I thought halb27 had ABXed a previous version with wider spreading? Sorry if I was mistaken, or if that's the one he retracted.

Cheers,
David.

lossyWAV Development

Reply #336
.... I thought halb27 had ABXed a previous version with wider spreading? Sorry if I was mistaken, or if that's the one he retracted.

In the end I could'nt abx a problem with any of the recent versions.

There is a small suspicion that someone else may really abx a problem with keys_1644ds and/or furious. I did beleive I can hear a subtle difference here, and my abx results were such that the listenenig results of other members are highly welcome.


@Nick: Looking at Josef's results: What makes 0.3.13 bring down the bitrate so significantly compared to 0.3.11?
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #337
.. I think your main problem Nick is that you're not getting input from anyone ...
David.

It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section 
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV Development

Reply #338

.. I think your main problem Nick is that you're not getting input from anyone ...
David.

It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section 


if you guys could upload The "eig" sample with lossyWAV (provided with the lossless sample) I could try to ABX it. But I doubt I would since I did not with OGG at -q6. For what I have seen it would take a combination of a couple with golden years plus killer lossy codecs samples (gurubolez included..LOL).


lossyWAV Development

Reply #340
.. I think your main problem Nick is that you're not getting input from anyone ...
David.
It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section 
I can't upload in the FLAC forum.....
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #341
@Nick: Looking at Josef's results: What makes 0.3.13 bring down the bitrate so significantly compared to 0.3.11?
There was a bug - there was no 5 bin averaging between 12.4kHz and 15.8kHz, the program was using 4 bin averaging.

@Sebastian: I tried that at an early stage but the output didn't match that of Mathcad, so I didn't pursue it. I may revert to single if I have no luck with 80x87 assembly language....
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #342
I searched my collection looking for clipping samples. Which turned out to be not easy.

Tracks which I know have strong distortions in them didn't have them due to clipping. And when I found clipping it usually was so isolated that it wasn't worth while trying. CDs with the typical loudness-war style kind of compression and clipping didn't have the clipping level very close to the 100% CD level.

In the end I found a CD wonderfully suited for worst-case testing: Francoise Hardy: Le temps des Souvenirs. Not the kind of music I expected to be clipping-prone. But it seems to be terribly remastered in this respect.
I took 16 tracks from this 2 CD album (everything from my productive collection plus everything I could perfectly re-rip from the 1st CD). I added 15 other tracks of various kind which made at least a slight impression that bitrate might go up with the iterative clipping prevention method.

I encoded these 31 tracks using lossyWav 0.3.13 with and without the -clipping option (no other option).

All the tracks: Average bitrate with -clipping:      419 kbps.
All the Tracks: Average bitrate without -clipping:  467 kbps.

A closer look:

Francoise Hardy tracks: Average bitrate with -clipping:      441 kbps.
Francoise Hardy tracks: Average bitrate without -clipping:  551 kbps.

Non-Francoise Hardy tracks: Average bitrate with -clipping:      401 kbps.
Non-Francoise Hardy tracks: Average bitrate without -clipping:  402 kbps.

So with tracks loundness-war style and clipping at or very close to the peak level sure this clipping prevention scheme increases bitrate significantly.
On the other hand at least judging from my collection (and I looked at quite a lot of CDs published in recent years) it doesn't happen very often that bitrate bloat requirements are fulfilled.

In order to take everything into account a more elaborated clipping prevention method could be like this:
Encode with the iterative clipping prevention strategy. When doing so, compute the average bits removed also for the variant of pretending the clipping prevention strategy is not used (can easily be done in parallel - no extra encoding necessary). If in the end it turns out the percentage of the difference between the two strategies is too high, reencoding can occur with a scale factor for preventing clipping.
From all we know so far reencoding is rarely necessary, and in these strong clipping cases it's easy to accept the theoretical quality impact of scaling.

The threshold for reencoding can vary with quality level, for instance like this:
-1: no reencoding with scaling no matter what bits to remove difference
-2: reencoding with scaling in case bits to remove difference is greater than 10%.
-3: reencoding with scaling in case bits to remove difference is greater than 5%.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #343
I listened to my usual sample set with v0.3.13 (no option).
Everything is fine.
Amazing for this rather low bitrate on average with usual samples.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #344
I listened to my usual sample set with v0.3.13 (no option).
Everything is fine.
Amazing for this rather low bitrate on average with usual samples.
  I'm *really* glad that the new spreading function / skew combination is working [good shout, David!]! Also, keeping the bitrate down is nearly as important.

Is there any appetite for correction files? I have been toying with the idea of this option but it's not worth doing if there is no "market".

lossyWAV alpha v0.3.14 attached: - superseded.

No parameter changes, just faster.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #345
lossyWAV alpha v0.3.15 attached. Superseded.

Code speeded up again.

Changes made to quality level -3 to make it slightly more aggressive : codec_block_size changed from 1024 samples to 512; -nts default changed from -1 to -0.5.

I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please.

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
Code: [Select]
lossyWAV alpha v0.3.15 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      set noise_threshold_shift to n dB (-15dB<=n<=0dB, default=-1.5dB)
              (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, default=12dB)
-skew <n>     skew fft analysis results by n dB (0db<=n<=48db, default=12dB)
              in the frequency range 20Hz to 3.45kHz
-o <folder>   destination folder for the output file
-clipping     disable clipping prevention by iteration; default=off
-force        forcibly over-write output file if it exists; default=off

Advanced / System Options:

-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.
[/size]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #346
...I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please. ...

I welcome the approach of putting more details into -1, -2, -3, as well as a more pronounced differentiation security-/and bitrate wise for -1 and -3, with -2 being the standard as ever with a good but not exaggerated security margin.

But what is the advantage of a blocksize of 2048 for -1?

Indepent of the block size question for -1 I personally would like to see a new approach with spreading_length=1 for low frequencies and short ffts cause in this case the current approach averages over more than 1 critical band.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #347
...I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please. ...
I welcome the approach of putting more details into -1, -2, -3, as well as a more pronounced differentiation security-/and bitrate wise for -1 and -3, with -2 being the standard as ever with a good but not exaggerated security margin.

But what is the advantage of a blocksize of 2048 for -1?

Indepent of the block size question for -1 I personally would like to see a new approach with spreading_length=1 for low frequencies and short ffts cause in this case the current approach averages over more than 1 critical band.
A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.

At present for my 52 sample set WAV: 121.53MB; FLAC: 68.20MB, 791.9kbps; -1: 42.97MB 499.0kbps(106.1% -2); -2: 40.49MB, 470.2kbps; -3: 37.68MB, 437.5kbps (93.1% -2). A quick test of "-1 -snr 24" gave 44.67MB, 518.7kbps (110.3% -2).

I will have a look at spreading_function_length with respect to Critical Bandwidth and post.

[edit] See attached Excel sheet. I will have a think as to how best to implement this, without reverting to my abortive previous attempt at Bark averaging. [/edit]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #348
A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.

I understand well that you want to be conservative qualitywise with -1, and a blocksize of 2048 certainly will reduce bits to remove, but from my naive understanding I cannot see a promising impact of a 2048 sized block on quality. The -snr approach or an increased value of -nts or -skew are more promising to me.

My personal feelings however go strongly in the direction that for FFT lengths <= 256 the spreading length is two long in case the width of critical bands are worth taking into account.
Sure there must be compromise, and IMO the current results are very good. But in favor of conservatism for -1 a shorter spreading length at least for a FFT length of 64 and low frequency is welcome IMO (spreading_length=1 in this case), and in case the influence on bits removed remains acceptable even for a FFT length of 128 and maybe 256 spreading length should be tried to get lower than they are now, and if possible not only for the low frequency end.
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #349
A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.
I understand well that you want to be conservative qualitywise with -1, and a blocksize of 2048 certainly will reduce bits to remove, but from my naive understanding I cannot see a promising impact of a 2048 sized block on quality. The -snr approach or an increased value of -nts or -skew are more promising to me.
I agree, a -snr / -skew combination will probably be a better solution. I am running a matrix calculation of -snr 0 to 30 step 3, -skew 0 to 30 step 3 to see what happens with bitrate for my sample set.
My personal feelings however go strongly in the direction that for FFT lengths <= 256 the spreading length is two long in case the width of critical bands are worth taking into account.
Sure there must be compromise, and IMO the current results are very good. But in favor of conservatism for -1 a shorter spreading length at least for a FFT length of 64 and low frequency is welcome IMO (spreading_length=1 in this case), and in case the influence on bits removed remains acceptable even for a FFT length of 128 and maybe 256 spreading length should be tried to get lower than they are now, and if possible not only for the low frequency end.
I am currently looking at what impact a spreading_function_length of 1 would have and how to implement it. It could be as simple as if FFT_length<256 then spreading_function_length=1. if 256 or 512 then 1,2,3,4. if 1024 or above then 2,3,4,5.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)