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 573684 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lossyWAV Development

Reply #950 –
I see what' you're saying, and I think what you did was either switch around the wording or the numbers you used.  I think you switched around the wording, because it would make sense that the WavGained version would be compressed more easily, since the original least significant bits are removed and get re-quantized into a new least significant bit - thereby having less most significant bits actually being used and FLAC being able to compress it more efficiently.

The problem with doing this is two fold, in my opinion:
1 - with WavGain, you're losing least significant bits that might not necessarily be insignificant.
2 - WavGain doesn't have a correction file.  there's no way to ever get a 1:1 copy of the original again.  If you're using normal FLAC, and the ReplayGain built into it, you can still enjoy the benefits of the volume equalization, and still be able to generate a 1:1 copy of the original source file at any time.  And if ReplayGain code ever becomes more transparent in audio quality.  Or if there is every a more accurate ReplayGain algorithm designed, you can enjoy the benefits of that by re-running ReplayGain over your libraries.

Also I noticed that the WavGained source file was slightly larger after lossWAV+FLAC.  I wonder if someone else knows why that might have been.  My initial thought was that lossyWAV thought the quantization noise introduced by WavGain was a slightly quieter noise-floor than in the original?

lossyWAV Development

Reply #951 –
Quote from: jesseg on
I see what' you're saying, and I think what you did was either switch around the wording or the numbers you used.  I think you switched around the wording, because it would make sense that the WavGained version would be compressed more easily, since the original least significant bits are removed and get re-quantized into a new least significant bit - thereby having less most significant bits actually being used and FLAC being able to compress it more efficiently.

The edit was simply that in the original I said the "lossy.FLAC is 69% smaller than the FLAC" when what I'd meant was that its size was 69% of the FLAC. Instead I kept the "smaller" and made it 31%. That's all the edit was.

Quote from: jesseg on
Also I noticed that the WavGained source file was slightly larger after lossWAV+FLAC.

Yeah, I thought that was strange. 

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV Development

Reply #952 –
I've been testing beta v0.8.5 using the -shaping <n> parameter (0 to 1 in 0.05 steps) to process my 53 problem sample set and here are the results:
Code: [Select]
|---------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
| Shaping |    -1     |    -2     |    -3     |    -4     |    -5     |    -6     |    -7     |
|---------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
|  0.000  | 543.5kbps | 494.6kbps | 433.9kbps | 408.2kbps | 385.6kbps | 365.4kbps | 348.1kbps |
|  0.050  | 543.7kbps | 495.0kbps | 434.5kbps | 408.9kbps | 386.5kbps | 366.7kbps | 349.7kbps |
|  0.100  | 543.9kbps | 495.3kbps | 435.0kbps | 409.6kbps | 387.3kbps | 367.6kbps | 350.9kbps |
|  0.150  | 544.2kbps | 495.7kbps | 435.6kbps | 410.4kbps | 388.3kbps | 368.8kbps | 352.2kbps |
|  0.200  | 544.4kbps | 496.2kbps | 436.3kbps | 411.3kbps | 389.3kbps | 370.1kbps | 353.7kbps |
|  0.250  | 544.8kbps | 496.8kbps | 437.2kbps | 412.3kbps | 390.6kbps | 371.6kbps | 355.5kbps |
|  0.300  | 545.2kbps | 497.4kbps | 438.2kbps | 413.5kbps | 392.1kbps | 373.4kbps | 357.6kbps |
|  0.350  | 545.7kbps | 498.1kbps | 439.2kbps | 414.8kbps | 393.6kbps | 375.2kbps | 359.8kbps |
|  0.400  | 546.2kbps | 498.9kbps | 440.4kbps | 416.2kbps | 395.4kbps | 377.3kbps | 362.2kbps |
|  0.450  | 546.7kbps | 499.8kbps | 441.7kbps | 417.8kbps | 397.3kbps | 379.6kbps | 364.8kbps |
|  0.500  | 547.5kbps | 500.9kbps | 443.3kbps | 419.7kbps | 399.5kbps | 382.4kbps | 368.3kbps |
|  0.550  | 548.2kbps | 502.0kbps | 444.9kbps | 421.5kbps | 401.7kbps | 385.0kbps | 371.3kbps |
|  0.600  | 549.1kbps | 503.3kbps | 446.6kbps | 423.5kbps | 403.9kbps | 387.4kbps | 374.1kbps |
|  0.650  | 550.1kbps | 504.7kbps | 448.6kbps | 425.7kbps | 406.2kbps | 389.9kbps | 376.7kbps |
|  0.700  | 551.1kbps | 506.2kbps | 450.7kbps | 428.0kbps | 408.7kbps | 392.3kbps | 379.0kbps |
|  0.750  | 552.3kbps | 507.8kbps | 452.9kbps | 430.4kbps | 411.3kbps | 395.0kbps | 381.6kbps |
|  0.800  | 553.5kbps | 509.6kbps | 455.2kbps | 432.9kbps | 413.9kbps | 397.8kbps | 384.6kbps |
|  0.850  | 554.9kbps | 511.4kbps | 457.7kbps | 435.6kbps | 416.7kbps | 400.7kbps | 387.7kbps |
|  0.900  | 556.5kbps | 513.5kbps | 460.4kbps | 438.6kbps | 419.9kbps | 404.1kbps | 391.3kbps |
|  0.950  | 558.2kbps | 515.8kbps | 463.4kbps | 442.0kbps | 423.5kbps | 407.8kbps | 395.2kbps |
|  1.000  | 560.1kbps | 518.3kbps | 466.8kbps | 445.8kbps | 427.5kbps | 411.9kbps | 399.2kbps |
|---------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
It is interesting that adding shaping has less of an effect at the higher bitrate end of the quality spectrum than at the lower end.

Please disregard the -newspread parameter as added to beta v0.8.4, it had a bug in it which, when rectified, produces the same results as the existing method (although that in itself was a bit of a surprise....). However, the means by which it arrives at the result is likely to be quicker once optimised in IA-32/x87, so I'll replace the existing code in due course.
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 #953 –
lossyWAV beta v0.8.5 attached to post #1 in this thread.
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 #955 –
All of this brings up 2 questions:
1.  How is the quality of -7 -shaping 1.000 compared to -4 -shaping 0 at similar bitrate (or to -5 -shaping 0.5, etc)? 
2.  How can we use shaping to get at lower bitrates than -7 -shaping 0?  Are tweaking snr and such necessary, or will there be a -8 or -9 added in the future, or something else?
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

lossyWAV Development

Reply #956 –
Quote from: The Sheep of DEATH on
1.  How is the quality of -7 -shaping 1.000 compared to -4 -shaping 0 at similar bitrate (or to -5 -shaping 0.5, etc)?

That's a good question.

Quote from: The Sheep of DEATH on
2.  How can we use shaping to get at lower bitrates than -7 -shaping 0?

The answer is much simpler than its implementation: Adaptive noise shaping driven by a good psychoacoustic model.

The increased bitrate with activated shaping (currently) is due to the quantization noise that is added in a spectral area where there usually is no music. This leads to a worse prediction gain. The method I was sketching in one of the first posts does the opposite. It adds quantization noise "under" the signal exploiting the masking effect. This approach won't decrease the predictability too much since the spectral shape of the signal is preserved.

Cheers,
SG

lossyWAV Development

Reply #957 –
1. Strange results (at least to a non-technical person)

I've been running a few tests with WavGain & lossyWAV, taking into account what jesseg and 2Bdecided have said.

I had thought that "1.wav" encoded via FLAC Drop then decoded to WAV would give me "1.lossy.wav" (i.e. the result of the lossyWAV processor. (for why I was doing this -- see 2 below)

But when I encoded 1.lossy.wav (without any other processing) back to FLAC using foobar and latest flac.exe (1.2.1) at -5, the file was much larger (522kbps) than the FLAC Dropped 1.lossy.flac (475kbps). 

Can someone explain why?

Additionally, I copied the 1.lossy.wav" and WavGained it and then encoded that to FLAC using foobar and flac.exe (1.2.1) and the file was much, much larger (628kbps). I'm assuming this is to do with WavGain undoing some of the work done by lossyWAV?

2. Request for help:

I was trying to get foobar to convert to lossy.wav (rather than direct to lossy.flac) but kept getting a can't flush file error.

Code: [Select]
Error flushing file (Object not found) : file://C:\Documents and Settings\[...my edit...]\test1.lossy.wav


I'd set it up as per wiki. The only difference was the batch file, which I edited to leave out the FLAC encoding (though I didn't really know what I was doing  ).

Code: [Select]
@echo off
D:\lossywav\lossyWAV %1 %3 %4 %5 %6 %7 %8 %9 -below -nowarn -quiet


Can someone tell me where I've gone wrong.

Thanks

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV Development

Reply #958 –
Quote from: carpman on
But when I encoded 1.lossy.wav (without any other processing) back to FLAC using foobar and latest flac.exe (1.2.1) at -5, the file was much larger (522kbps) than the FLAC Dropped 1.lossy.flac (475kbps).

Can someone explain why?
Because you're not using the -b 512 option in your FLAC.exe command to force FLAC to use a 512 sample block size for compression.  That's my best guess.


Quote from: carpman on
Additionally, I copied the 1.lossy.wav" and WavGained it and then encoded that to FLAC using foobar and flac.exe (1.2.1) and the file was much, much larger (628kbps). I'm assuming this is to do with WavGain undoing some of the work done by lossyWAV?
Yes.  When it re-quantizes the sample values, I'm pretty sure it doesn't care at all about creating new LSB all the way to the bit-floor.  If it did, it would be compromising it's own quality.


Quote from: carpman on
Code: [Select]
@echo off
D:\lossywav\lossyWAV %1 %3 %4 %5 %6 %7 %8 %9 -below -nowarn -quiet


Can someone tell me where I've gone wrong.
When you use a full path, you have to use the full filename, like so:
Code: [Select]
D:\lossywav\lossyWAV.exe %1 %3 %4 %5 %6 %7 %8 %9 -below -nowarn -quiet


[edit]
but now after looking at the error, i'm not sure that's the problem either.
[/edit]

lossyWAV Development

Reply #959 –
Quote from: 2Bdecided on
Patent:
http://patft.uspto.gov/netacgi/nph-Parser?...RS=PN/5,204,677

Post:
http://www.hydrogenaudio.org/forums/index....st&p=512342

I haven't reviewed it properly.

carpman, yes ReplayGain before encoding is a nice efficiency boost. Only apply negative gains. Put it within lossyWAV itself to avoid (extra) dithering.

Cheers,
David.
I'll need to read up on ReplayGain to see how I would implement it in lossyWAV. However, I can't seen any simple way of linking tracks together to albums so I think that the lossyWAV ReplayGain implementation would only calculate / use track gain (which if you processed a whole album as one file [as i do] would in effect be album gain).

I've been optimising the code again and the FFT unit is now about 95% IA-32/x87 and is a little bit faster / smaller.

Awaiting feedback on -shaping : how does it sound? Is it worth the extra bitrate? Does anyone have any ideas for alternate filters?

Quote from: jesseg on
Quote from: carpman on
Additionally, I copied the 1.lossy.wav" and WavGained it and then encoded that to FLAC using foobar and flac.exe (1.2.1) and the file was much, much larger (628kbps). I'm assuming this is to do with WavGain undoing some of the work done by lossyWAV?
Yes.  When it re-quantizes the sample values, I'm pretty sure it doesn't care at all about creating new LSB all the way to the bit-floor.  If it did, it would be compromising it's own quality.
It certainly will - WavGaining a lossy.wav file will almost certainly destroy all the carefully zeroed lsb's....
Quote from: jesseg on
Quote from: carpman on
Code: [Select]
@echo off
D:\lossywav\lossyWAV %1 %3 %4 %5 %6 %7 %8 %9 -below -nowarn -quiet
Can someone tell me where I've gone wrong.
When you use a full path, you have to use the full filename, like so:
Code: [Select]
D:\lossywav\lossyWAV.exe %1 %3 %4 %5 %6 %7 %8 %9 -below -nowarn -quiet


[edit]
but now after looking at the error, i'm not sure that's the problem either.
[/edit]
I think that the problem is that %1 (%s from foobar) = "temp"+32 (or so) random hex characters+".wav" and %d is the expected output filename. If you don't rename %1 to %2 (%d from foobar) then foobar will not find the file named by %d and will give you this error.... So, I think adding:
Code: [Select]
ren %~n1.lossy.wav %2
inserted as the last line might fix your problem.
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 #960 –
You can't run lossyWAV and then WaveGain, as Nick has explained.

Nick, what you need is to run WaveGain, grab the album gain value, and then use that to scale the data within lossyWAV in floating point or the 24-bit domain, but still only outputting 16-bits. I would heretically suggest not using dither at the output, but people can if they want. I put an option into the MATLAB version "always dither LSB" to ensure that even if you didn't remove any bits, the output was still dithered - that's the correct way of applying a gain change, but I would disable it by default.

There was some code or script that allowed you to run WaveGain, grab the scaling value, and use it when encoding with lame. It was in this thread but the links have died...
http://www.hydrogenaudio.org/forums/index....0637&st=150
...you need something like that to pass the value to lossyWAV - I don't think you should try to integrate ReplayGain itself into lossyWAV because just having track mode available is kind of useless.

Cheers,
David.

lossyWAV Development

Reply #961 –
Quote from: 2Bdecided on
Nick, what you need is to run WaveGain, grab the album gain value, and then use that to scale the data within lossyWAV in floating point or the 24-bit domain, but still only outputting 16-bits.

I would absolutely love to see this functionally added to lossyWAV!  I envision it being an input option just like the --scale option in lame.

Depending on how this is implemented within the lossyWAV code, would it be possible to undue the gain processing with the correction file?  That would be totally awesome!

All my flacs already have replaygain value tags.  So that could be another source of the gain value for lossyWAV.  I suppose that functionality would be part of the flac to lossyWAV to flac script i.e. lFLCDrop.

lossyWAV Development

Reply #962 –
Yep, I can for sure add track ReplayGain to the flac commands, and ability to turn that on/off in the custom section.  I don't see why ReplayGain should be implemented with lossyWAV any other way than in the final codec used, unless the final codec doesn't support it.  (and then, should you even be using it, if you like ReplayGain?)

I don't really see a way to have a correction file to undo the WavGain "distortion" without it being a huge file after lossless compression.  As it is now, lossyFLAC + lwcdfFLAC is still smaller than a plain FLAC, especially using lossyWAV -1 preset.

lossyWAV Development

Reply #963 –
Quote from: spies on
Quote from: 2Bdecided on
Nick, what you need is to run WaveGain, grab the album gain value, and then use that to scale the data within lossyWAV in floating point or the 24-bit domain, but still only outputting 16-bits.
I would absolutely love to see this functionally added to lossyWAV!  I envision it being an input option just like the --scale option in lame.

Depending on how this is implemented within the lossyWAV code, would it be possible to undue the gain processing with the correction file?  That would be totally awesome!

All my flacs already have replaygain value tags.  So that could be another source of the gain value for lossyWAV.  I suppose that functionality would be part of the flac to lossyWAV to flac script i.e. lFLCDrop.
Your wish is my command....

-scale <n> parameter implemented which takes a value in the range 0 to 1 and scales the input WAV data by that amount. -scale is compatible with -correction and -merge will combine both files to re-create the lossless master.

*WARNING* filesizes may get large.... when I had a test with -scale 0.5 -correction using my 53 problem sample set, I got a combined filesize for 53 lossy.flac and 53 lwcdf.flac files of 93.1MB, compared to 69.3MB for the 53 lossless originals. Interestingly, the lwcdf.flac file is not too bad to listen to...

lossyWAV beta v0.8.6 attached to post #1 in this thread.
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 #964 –
Quote from: Nick.C on
Your wish is my command....

-scale <n> parameter implemented which takes a value in the range 0 to 1 and scales the input WAV data by that amount. -scale is compatible with -correction and -merge will combine both files to re-create the lossless master.

*WARNING* filesizes may get large.... when I had a test with -scale 0.5 -correction using my 53 problem sample set, I got a combined filesize for 53 lossy.flac and 53 lwcdf.flac files of 93.1MB, compared to 69.3MB for the 53 lossless originals. Interestingly, the lwcdf.flac file is not too bad to listen to...

lossyWAV beta v0.8.6 attached to post #1 in this thread.

Wow Nick, that was fast, thanks!  Can't wait to try it out when I get home.

Quick question though, when using the -scale option are you dithering at the output?  I think I would prefer it not to be dithered or at least make it an option of the -scale command as suggested by David.

I would not be surprised to find that the change from 69.3MB to 93.1MB would be caused by scaling and dither, but would be quite surprised if it was caused by just scaling alone.  I wonder what the result would be with ReplayGain scale values as opposed to using a scale factor of 0.5 for your test suite.

lossyWAV Development

Reply #965 –
Thanks to everyone for their answers and patience - on the WavGain issue. That's cleared up some confusion on my part.

@ Nick, thanks, haven't had time yet, but I'll give that a go  " -- ren %~n1.lossy.wav %2"

While lossyWAV is on the Replay Gain issue:

I use replay gain on a track by track basis. I tried jesseg's suggestion of using FLAC's internal replay gain, the problem I had was that I needed to switch on replay gain processing in Foobar for it to have the desired effect. Foobar automatically adjusted all my (non-tagged-replay-gained) files which are less or greater than 89dB (because I set them that way).

It's very possible I'm missing something obvious here, but just not obvious to me.

What I would like from lossyWAV is either:
a) a way to set the value at the lossy.wav stage (i.e. 1.2 dB below 89dB - as is possible with WavGain) --- and it looks like Nick may have already achieved this, or
b) be able to manually alter the replay gain value in FLAC's vorbis comments? (is this already possible?)

Slighly OT (not LossyWAV specific):
Is it possible to scan all the files in my collection with foobar and then manually adjust the track replay gain value to 0.0000, so these files aren't affected by the gain processing? If I do this then I will be able to use the FLAC Tag replay gain method and keep the lossy.flacs at their original volume and thus get the most out of lossyWAV.  ---- I think that makes sense.

Thanks
C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV Development

Reply #966 –
Quote from: spies on
Wow Nick, that was fast, thanks!  Can't wait to try it out when I get home.

Quick question though, when using the -scale option are you dithering at the output?  I think I would prefer it not to be dithered or at least make it an option of the -scale command as suggested by David.

I would not be surprised to find that the change from 69.3MB to 93.1MB would be caused by scaling and dither, but would be quite surprised if it was caused by just scaling alone.  I wonder what the result would be with ReplayGain scale values as opposed to using a scale factor of 0.5 for your test suite.
No dithering is employed at all (yet) in lossyWAV. All WAV data related calculations (apart from the final difference for correction values) are performed using 64-bit real values, the only rounding used is for bit-reduction. Using -7 -shaping 1.0 -scale 0.5, the lossy & lwcdf files totalled 98.5MB - it's almost not worth useing correction at all, merely keep a lossless FLAC copy and transcode to lossy.FLAC for an additional lossy copy.
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 #967 –
If the correction file is just the difference between the original, and the scaled lossy version, then it'll be huge. You shouldn't do it that way. If you think about it (or even if you don't!), you are storing the entire data twice, since the correction file is also a scaled lossy version!

What you should try is this:

First, you must store the scale somewhere. Don't lose it. It's vital. ("keep foreign metadata" in correction file?)

Then...

lossy = original * scale + quantisation noise

correction = original - (lossy / scale)

merged = (lossy / scale) + correction
            = (lossy / scale) + original - (lossy / scale)
            = original!

It's more complicated, and you're going to have to check there are no differential rounding errors (i.e. lossy/scale gives the same result each time, whatever that happens to be), but it's far more efficient. You won't double the file size this way.



I think you need to separate "ReplayGain applied to make lossyWAV more efficient", and "ReplayGain applied for whatever people use ReplayGain for" (!). I'm not sure. It depends how people use it.

I would use the AlbumGain (negative ones only) with lossyWAV. If people are already using ReplayGain anyway, I would pass through all the ReplayGain data (with appropriate adjustment, because the original is now quieter) to include in the final FLAC. If people aren't using ReplayGain normally, then there's nothing to pass through - just apply the negative album gains and leave it at that.

Cheers,
David.

lossyWAV Development

Reply #968 –
I've just realised that in my haste to implement -scale, I have omitted to correctly scale codec_blocks which are not having any bits removed whatsoever. Big problem.

I am working on implementing David's recent scale-then-only-store-the-scaled-difference method and will post v0.8.7 asap.

!!Please do not use -scale in beta v0.8.6!!
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 #969 –
Quote from: 2Bdecided on
If the correction file is just the difference between the original, and the scaled lossy version, then it'll be huge. You shouldn't do it that way. If you think about it (or even if you don't!), you are storing the entire data twice, since the correction file is also a scaled lossy version!

What you should try is this:

First, you must store the scale somewhere. Don't lose it. It's vital. ("keep foreign metadata" in correction file?)

Then...

lossy = original * scale + quantisation noise

correction = original - (lossy / scale)

merged = (lossy / scale) + correction
            = (lossy / scale) + original - (lossy / scale)
            = original!

It's more complicated, and you're going to have to check there are no differential rounding errors (i.e. lossy/scale gives the same result each time, whatever that happens to be), but it's far more efficient. You won't double the file size this way.
Ouch my poor head..... I'm getting *close* to the right answer as you detailed above - however I need to get to grips with x87 rounding (again)......
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 #970 –
lossyWAV beta v0.8.7 attached to post #1 in this thread.
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 #971 –
I've been focussing on speed-ups and have been working on the FFT unit in particular. I tripped over a method of calculating a real FFT of length 2N using a complex FFT of length N. As the FFT in use in lossyWAV is complex, it seems attractive to use this method. However, I am having trouble "untangling" the results to form the result of the real analysis from the complex analysis. I'll keep working on it as I think it will speed up the processing by about 25% overall.
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 #972 –
I've finally managed to crack the problem I was having in implementing the 2N real FFT in an N Complex fft speedup - the improvement is between 20% and 25%.

I have however found a problem with the correction / merge / scale combination for 24 bit files - this will be investigated and beta v0.8.8 will be posted.

I played about with an 8 bit WAV file and I am going to remove 8 bit processing as removing any bits from an 8 bit WAV will most probably produce foul results.....
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 #973 –
lossyWAV beta v0.8.8 attached to post #1 in this thread.
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 #974 –
In my own tests, lossyWAV 0.8.8 is significantly faster than version 0.8.7.

Would it make sense to drop all of the extra FFT analysis options (-Xa/b/c), in favour of an "-exhaustive" (or "-e") parameter, which would perform analysis passes using all suitable FFT sizes?
lossyFLAC (lossyWAV -q 0; FLAC -b 512 -e)