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.

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.

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.

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.

QUOTE (2Bdecided @ Oct 19 2007, 10:54)

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;

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.

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.......

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.......

.... 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?

.. 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).

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.

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%.

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.

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.

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.

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.

QUOTE (halb27 @ Oct 22 2007, 12:36)

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.