spreading_function_string         : string[29]='22223-22224-12235-12246-12357';
  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-12,-8,-4,0,4,8,12,16);
  quality_signal_to_noise_ratio     : array[0..Quality_Presets] of Integer = (30,27,24,21,20,19,18,17);
  quality_clips_per_channel         : array[0..Quality_Presets] of Integer = (0,0,0,1,2,3,3,3);

I encoded my regular sample set (which is a bit typical of what at least I encode usually) with 0.9.4 -3 and got an average bitrate of 417 kbps.
As the new -3 roughly corresponds to the old -2 this is a good result IMO.
I also see sense in shifting the meaning of the quality levels a bit in favor of the top quality edge.

....I'll process the other integer settings for comparison.

I know that nobody is soliciting opinions but in case anybody's interested .....

I think it's absolutely right to concentrate on getting the original concept implemented for an initial release and adding noise shaping and anything else in a subsequent release. I also think that giving preference to the higher quality settings is a good idea, but then I am more interested in quality than file sizes. For what it's worth I think LossyWAV is now looking like a much more professional, mature product.

I have converted a number of files using 0.9.4. They were a mixture of 16/44.1 and 24/48. All were sourced from vinyl. Not being very comfortable with the command line I used IFLCDrop, which only has "1" as the highest quality option available. Using "1" the 16/44.1 files ended up with bit rates ranging from 505kbps to 525kbps. The 24/48 files had a range of 535kbps to 555kbps - as an aside, I guess this gives credence to the argument that using 24 bits for vinyl is overkill as LossyWAV obviously doesn't think most of the extra bits are storing anything worth keeping. To me these are ideal bit rates as they nicely fill the gap between existing lossy and lossless.

I am in the process of arching my vinyl collection and while I will continue to use lossless for records that are very important to me, I will definetly use LossyWAV for those that are just "nice to have" (especially if someone comes up with a nice friendly GUI front end).

If there is any interest in developing LossyWAV for use ith higher bit depths/sample rates I'd be very happy to help with testing - bearing in mind that I'm not very technical, just a music lover - as I'd like to be able contribute in some way

  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-12,-8,-4,0,4,8,12,16);
  quality_signal_to_noise_ratio     : array[0..Quality_Presets] of Integer = (30,27,24,21,20,19,18,17);

  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-24,-16,-8,0,4,8,12,16);
  quality_signal_to_noise_ratio     : array[0..Quality_Presets] of Integer = (39,33,27,21,20,19,18,17);

I prefer the old settings, at least as far as -nts is concerned.
Because of the reduced efficiency of the lossless codec due to the small blocksize it happens rather often  with non-complex or quiet music when targeting at a lossyFLAC average bitrate of just 380 kbps, that a totally lossless codec yields a lower bitrate than lossyFLAC (that's why I used lossless wavPack instead of lossyFLAC to encode many tracks from my collection which contain classical music or music with few instruments). The higher we choose the bitrate the more often does this happen.
2Bdecided's basic priciple is fulfilled with -nts 0, so for an additional security -nts -4/-8/-12 should be sufficient IMO even for the most cautious people.

I also like the 16 kHz limit for doing the bits-to-remove calculations. Going lower would reduce the risk that bits-to-remove is 0 for the only reason that there's no (or only low volume) HF content around 16 kHz. But it increases the risk of not taking audible HF noise into account. When going higher it's the other way around.
IMO the best compromise is very much what you are doing right now.

From just careful listening (especially to the problem samples): is -8/-9/-10 acceptable with respect to the still high quality everybody may expect from a >=270 kbps encoding?

I prefer the old settings, at least as far as -nts is concerned.
Because of the reduced efficiency of the lossless codec due to the small blocksize it happens rather often  with non-complex or quiet music when targeting at a lossyFLAC average bitrate of just 380 kbps, that a totally lossless codec yields a lower bitrate than lossyFLAC.

Taking into account what botface was saying about the higher quality presets, I've had (yet) another think about the basis for the presets. If the -nts and -snr values were changed from:

Code: [Select]

  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-12,-8,-4,0,4,8,12,16);
  quality_signal_to_noise_ratio     : array[0..Quality_Presets] of Integer = (30,27,24,21,20,19,18,17);

to

Code: [Select]

  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-24,-16,-8,0,4,8,12,16);
  quality_signal_to_noise_ratio     : array[0..Quality_Presets] of Integer = (39,33,27,21,20,19,18,17);

Then the resultant bitrates (for my 53 problem sample set) would change from:

-0.0: 610kbps; -0.5: 589kbps; -1.0: 566kbps; -1.5: 543kbps; -2.0: 520kbps; -2.5: 496kbps; -3.0: 472kbps;

to

-0.0: 717kbps; -0.5: 686kbps; -1.0: 651kbps; -1.5: 611kbps; -2.0: 555kbps; -2.5: 519kbps; -3.0: 472kbps;

with the remaining presets:

-3.5: 451kbps; -4.0: 431kbps; -4.5: 412kbps; -5.0: 395kbps; -5.5: 379kbps; -6.0: 364kbps; -6.5: 350kbps; -7.0: 338kbps

staying the same.
[edit] Oh, I forgot to say: there's an undocumented parameter, currently called -lowpass (the name should maybe be changed - suggestions please) which changes the upper limit of the frequency range used in the spreading-function / minimum value / average value calculations. Permitted values are in the range 13.5kHz to 20.05kHz. [/edit]

If the -nts and -snr values were changed from:

Code: [Select]

  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-12,-8,-4,0,4,8,12,16);

to

Code: [Select]

  quality_noise_threshold_shifts    : array[0..Quality_Presets] of Integer = (-24,-16,-8,0,4,8,12,16);

From just careful listening (especially to the problem samples): is -8/-9/-10 acceptable with respect to the still high quality everybody may expect from a >=270 kbps encoding?

Quote from: halb27 on 2008-04-20 21:23:05

I prefer the old settings, at least as far as -nts is concerned.
Because of the reduced efficiency of the lossless codec due to the small blocksize it happens rather often  with non-complex or quiet music when targeting at a lossyFLAC average bitrate of just 380 kbps, that a totally lossless codec yields a lower bitrate than lossyFLAC.

Do you think it would be worth checking for this automatically?

If found you could increase the blocksize specified to the lossless encoder when encoding the lossyWAV output (e.g. 1024, 2048 etc), and if that didn't help you could just keep the lossless version?

The latter would be really easy if you were transcoding from FLAC (or whatever) lossless anyway (if the lossyWAV program can find the files). Otherwise, I can't see any way of doing the checking other than encoding the file to lossless to see how big it comes out - which is going to double or triple the time spent on lossless encoding! Thoughts?

Cheers,
David.

Quote from: halb27 on 2008-04-20 22:28:13

From just careful listening (especially to the problem samples): is -8/-9/-10 acceptable with respect to the still high quality everybody may expect from a >=270 kbps encoding?

I managed to listen to my 53 problem sample set at -10 and -9 today - definitely too much hiss at -10 (only for certain samples, however) and it is still noticable (and annoying, although I'm deliberately listening out for it) at -9. I will try to listen to -8 tomorrow.

@Botface: I don't really know which samples / tracks will be best for evaluation purposes - although I would guess that as Gurubooleez has a library of 150 instrumental samples, instrumental will be useful - I think harpsichord is a difficult type to retain transparency for.

@GeSomeone: I'm going to stick with -12..16 (step 4) for the -nts values. The change from integer to float for the quality preset selection has made use selection of intermediate points much simpler rather than manual -snr and -nts selections.

There was a time when I thought for a more refined quality setting -nts is what should be used, and as a primary quality setting -1/-2/-3 is what we should have.

But now that we have arrived at these many primary quality settings I think this is the better way to go, but in this case we should concentrate on the primary quality setting and hide details like -nts from the user in the final version (or devide them clearly apart into the advanced options).

From just bitrate/expected quality I like your -0 to -7 settings of 0.9.4 very much (or maybe an aditional -8 in case that's useful).
It's a clear thing (especially when ommitting the a and b appendix which IMO should go into the advanced options as well [as something like -analyses n]).
IMO the default quality should be -3 (in 0.9.4 scale) and we should clearly state that -0 and -1 are useful only as an extremely high quality lossy substitution for a lossless encoding.

lossyWAV
lossyWAV -help

lossyWAV -longhelp

It's really amazing to see lossyWAV get to where it's at now, and thanks to everyone helping out with this, from the original idea to just the "fans".  I really like where it's come to by this point, and thanks to Nick especially of course, and for almost always knowing which "whims" were good to explore, and which ones to hold off on.  Without that wisdom, we would still be back before v0.50  =)

I agree with the advanced settings in the help, and it might be a good thing even to leave the advanced stuff complete out of the normal help which comes up with, for instance:

Code: [Select]

lossyWAV
lossyWAV -help

and go with something like LAME, and have a

Code: [Select]

lossyWAV -longhelp

for the advnaced stuff, that way only one line is needed to mention that there's more help if you use that variable, but it's not crucial that the information is seen for "normal" and "safe" use of lossyWAV.

It also would be nice to get some graphics gurus in here, to do up a right proper logo for this.  Perhaps some submissions from the likes of deviant art or the like?  I've never used those types of sites much, but there should be a few things out there that would support that kind of thing.

As long as the executable has a resource section (yours do already, for version info) then you can use one of several resource editors to import a new .ico into the executable, and they should automatically create and icon group resource too.

Here's two of my favs, both are free:
http://www.wilsonc.demon.co.uk/d10resourceeditor.htm
http://www.angusj.com/resourcehacker/

They are both useful because each of them have their own querks.  I recommend using XN whenever you can though.  Also usefull is LordPE or PEiD, for rebuilding your executables.  That also cuts down on the file size slightly.