We've got visitors until Monday, but I'll try to get some of my 10 album test set results out tonight / tomorrow.

Take your time, don't hurry.

I did some listening tests using v0.9.7b -impulse -spf 22222-22223-22224-12235-12246-12357.
At -q 0 I could abx the difference against v0.9.7 with eig, but I wouldn't call it a significant improvement.
At -q 1 I couldn't, quality is high in both cases.

Bitrate for my regular track set goes up from 427 kbps to 442 kbps at -q 5 which I agree is way too high and could only be justified by a remarkable quality improvement.

I tested those samples from my last listening test which weren't totally correct.
I used v0.9.7 -q 3 -impulse.
Everything was fine to me with the exception of triangle-2_1644ds, though my abxing wasn't very good (7/10). Comparing this with v0.9.7b -q 3 -impulse -spf 22222-22223-22224-12235-12246-12357 I found that the encoding is identical to that of v0.9.7 -q 3 -impulse.

Judging from the results available so far I do think -impulse has a favorable effect. But it's fine the way you do it with v0.9.7, and the 22222 approach isn't efficient just as you said (I was just curious).
Guess I'll do some more listening tests tomorrow in order to confirm the positive effect of -impulse (hoping that everything will be alright now at -q 5 or even -q 4).

If there's spaces in a static path in a batch file, it's easy enough to deal with by wrapping double-quotes around the path\executable parth of the command. Such as:

But to handle that with a variable as a path, it's a bit more complicated but fine once you know how to do left() and right() type functions with variables.

As a nice side effect of "massaging" the variables that way, you can handle also any other chars in the path, as well as in other variables such as those you might use for tagging. Unicode for the tagging is mainly what I would think it's most useful for.

I have previously used spaces in the path-to-exe-files in the batch file, surrounded by double quotes as you mentioned - I just don't from preference as I keep the batch file in the same directory as the two exe files, but if there are spaces in the path to the batch file itself there seems to be a problem between foobar2000 and cmd.exe.

You could have look at Speek's batchencoder at Speek's Frontends
It's one of his fabulous front ends, and it works great for me.

I've computed the bitrates [kbps] for my full length regular track set using various settings:

           v0.96         v0.97      v0.9.7 -impulse      v0.9.7b -impulse -spf 22222-....
-q 0       263           272               290                             297
-q 1       281           288               304                             313
-q 2       305           311               325                             334
-q 3       335           339               351                             363
-q 4       372           375               385                             399
-q 5       417           418               427                             442
-q 6       447           448               456                             471
-q 7       477           477               485                             500

I've done the same thing with my short length problem tracks set but it's not worth while giving it here: it's more or less the same relations, just at a higher bitrate level.
I hoped bitrate would increase more with the problems than with the regular music as I was used to this behavior at the time we had a stronger skewing at the low frequency edge.

I did a lot of listening tests in order to arrive at conclusions what IMO should be the way to go.
From the consequences (not the history of my tests):

a) At the low bitrate edge we shouldn't use the 32 sample FFTs IMO.
I listened to furious, eig, and castanets, comparing the results of v0.9.7b -q 0 -impulse -spf 22222-.... with those of v0.9.7 -q 1, as well as v0.9.7b -q 1 -impulse -spf 22222-.... with those of v0.9.7 -q 2.
As the result IMO it's better to use the next quality level instead of using -impulse -spf 22222-..... with both requirung roughly the same bitrate. The quality result was pretty clear for furious, there was no real difference for castanets, and just eig -q 0 -impulse -spf 22222-..... was is a tiny bit better to me than -q 1, and when doing the same comparison with quality levels advanced by 1 the preference for the 32 FFT is gone for eig too.
So using -impulse -spf 22222-.... is advantegous in rare cases whereas using the next quality level without the 32 sample FFTs brings a more general improvement.
Mooreover you've arrived at very good quality, Nick, way below 300 kbps, and if we used the 32 sample FFTs we would be at ~300 kbps which I guess isn't too attractive for the low bitrate users.

b) This morning with fresh ears I listened to all my potentially problematic samples again using v0.9.7 -q 4 -impulse. Now I could hear problems again with badvilbel (9/10), castanets (7/10), triangle (7/10).
Trying v0.9.7b -q 4 -impulse -spf 22222-.... made badvilbel and castanets non-abxable to me. With triangle I found out none of the 2 variants used with the 32 samples FFT produced a different file than the one when the 32 samples FFT isn't used at all.
I did the same thing with -q 5 instead of -q 4. Now badvilbel and castanets are okay to me using just -impulse (no -spf 22222-...). With triangle it's the same thing however as with -q 4: 7/10.
So the triangle problem can't be tackled by the 32 sample FFT, some other problems can but it looks like it's necessary to use a 22222 spreading.

As for the new -snr values when looking at the bitrate table they seem not to have a vital effect from -q 5 upwards.
Can you please further increase the -snr values from -q 5 up (maybe starting with a more gentle increase already at -q 3 or -q 4), Nick? I wonder if the problems can be tackled by this. When looking at this as an alternative to the 32 sample FFT accepting say half of the bitrate increase of the 32 sample FFts there's room for a very serious increase of the -snr value.

I too love his frontends particularly Multi frontend that I use all the time. I've been trying to get Batchenc to work with LossyWAV but I've obviously got something wrong. I wonder if you can help

I have batchenc and LossyWAV in the same directory and the output directory in Batchenc set to the same as the input directory but when I run it Batchenc places the output files in its own directory (IE the one that contains Batchenc and LossyWAV). The only way I can get it to put the output files where I want them is to use the -o parameter in LossyWAV. Can you help me with that?

Thanks

How do you envisage the -snr values changing? At v0.9.7 the quality related presets are:



Firstly, I propose that the 32 sample FFT spreading function will be 22222 rather than 22223 as if it is used at all, it should be at its most(?) effective.

Secondly, I propose that -snr be (18,19,20,21,22,25,28,31,34,37,40).

Bitrates for 53 problem sample:

This makes sense to me.



If this yields the bitrate of 0.9.8 in your table this is reasonable for me too. The details depend on what we will do with the 32 samples FFT, cause I think we can't add several defensive methods or make the existing ones more defensive without sacrificing too much bitrate while lettng -q 5 be the setting with -nts 0.

At the moment I'd like to play around a bit trying to bring the triangle issue (though it's a subtle one) down with -q 4 or at least -q 5, and I'd like to try this first with a higher -snr value.
For this purpose it would be kind if you could also make the -snr option temporarily available for the user, Nick.

Yes, those quality preset parameters refer to v0.9.8 and correspond to the achieved bitrates.

lossyWAV beta v0.9.8 attached to post #1 in this thread. (-nts and -snr parameters temorarily re-enabled).

Thank you for v0.9.8, Nick.

The bitrate table for my full length regular track set up to -q 7:

-q 0   272 kbps
-q 1   289 kbps
-q 2   311 kbps
-q 3   340 kbps
-q 4   376 kbps
-q 5   422 kbps
-q 6   454 kbps
-q 7   486 kbps

So from -q 5 up the increased -snr do have a better effect compared to the values of 0.9.7.
Up to -q 4 however the effect is more or less negligible.

If we do want to have the 32 samples FFT when using the higher quality settings (and I think we should - hopefully we've got rid of the perception of a changed pitch by this, and maybe a 64 samples FFT was really too long as the short FFT at least with very high quality demands in mind). Even if a 32 sample FFT isn't necessary for very high quality it's one more weapon in the set of additional defensive tools).
The question is at what quality level to start with the 32 samples FFT. I think we definitely should have it with our default -nts 0 setting of -q 5. -q 5 -impulse takes an average bitrate of 446 kbps with my regular test set. So for the quality settings lower than -q 5 we have to redefine parameters a bit in order to get a roughly equally spaced quality and bitrate scale.

I've played around a lot with the parameters, and listened to especially the low bitrate settings.
What I've found, Nick, doesn't correspond totally with your idea of having all the quality parameter increase when going from one quality level to the next. Technically however I think there isn't any problem: The various quality parameters are defined for the integer quality levels. For a non-integer quality level you can take the quality parameters of the next lower integer quality level with the exception of -nts for which you can do a linear interpolation. As a rough description. For more details see below.

My suggestion for the quality parameters of integer quality levels:

-q 0: v0.9.8 -q 0 (average bitrate for my full length regular track set: 272 kbps).

For the next quality level IMO the best quality increase per kbps is by increasing -snr significantly. I've listened to -q 1 with various -snr setting, and going directly to -snr 22 brings an astonishing good quality to eig and furious which otherwise do suffer a bit from these low bitrate settings (though other than with these samples quality is remarkably high).

-q 1: v0.9.8 -q 1 -snr 22 (average bitrate for my full length regular track set: 307 kbps).

Once at -snr 22 increasing -snr further isn't so important. What should be more in focus is decreasing the -nts value significantly from the rather high value of -q 1's
-nts 16:

-q 2: v0.9.8 -q 2 -snr 22 -nts 9 (average bitrate for my full length regular track set: 337 kbps).

For -q 3 -nts should get lower one more time, but as we've arrived already at a modest -nts value I think we should use -impulse with -q 3 (if not we can lower -nts a bit more):

-q 3: v0.9.8 -q 3 -snr 22 -nts 6 -impulse (average bitrate for my full length regular track set: 382 kbps).

-q 4 should lower the -nts value one more time:

-q 4: v0.9.8 -q 4 -nts 3 -impulse (average bitrate for my full length regular track set: 409 kbps).

-q 5: v0.9.8 -q 5 -impulse (average bitrate for my full length regular track set: 446 kbps).

-q 6: v0.9.8 -q 6 -impulse (average bitrate for my full length regular track set: 479 kbps).

and so on.

Thus -nts goes smoothly from 9 (-q 2) to 6 (-q 3) to 3 (-q 4) to 0 (-q 5).

I've tried triangle with this setting of -q 4, and I can't abx it.
I've also looked at the effect -snr has for triangle. Unfortunately -snr doesn't have an influence on bits-to-remove (only with extreme values for -snr), just as is the case with -impulse. A lower -nts value is the only thing that helps.

This is my suggestion.
Compared to what we have right now IMO this means an improved quality for -q 1 and -q 2 while having bitrate still pretty low. As for -q 3+ we have an improved quality for the high end demand though at the cost of a higher bitrate. Moreover I think there is more 'meaning' in the quality steps up to -q 5.

A remark on the continuous quality scale as only the basic approach as I think of it is described above.
For the -q 0...1 range I think there should be linear interpolation (or any other continuous variation) with -snr as well as -nts.
With the -impulse parameter we can't have a smooth transition, and starting -impulse with -q 3.0 necessarily makes a larger jump in bitrate when going from -q 2 to -q 3 (more dramatically when going from -q 2.9 to -q 3.0).
Looking at the quality level analogy of Vorbis it's a bit similar to the situation where Vorbis starts using a different stereo handling at certain quality levels.

Where can one go about finding this version? Googling uber brute force upx leads to nothing but this thread.

I had that too. But if it isn't a problem to use the -o parameter do so. The only thing is you have to change (fill in) the output directory name in the command line.
My command line for testing with lossyWav is "lossywav.exe <infile> -q 3 -force -o E:\iPOD". I admit it's more convenient when the programm uses <<output directory same as input directory >>. I'll experiment with that

[edit] A normal command line can be "FOR %%X IN ("*".WAV) DO LOSSYWAV "%%X" -q 3", without the outer quotes of course. [/edit]

Thanks for responding. My command line is pretty much like yours. While it's not that much hassle having to specify the output directory I often find myself wanting to convert several albums at once, each one being in a separate input directory and wanting to keep them separate. I assumed I was doing something wrong because Multi Frontend, which is from the same developer and which I also use, will quite happily deal with a bunch of files from several different directories and put them back in the directories they originated from. Shame it can't handle LossyWAV .

I am fond of those gadgets, batchfiles and front ends too. This afternoon I wrote myself a little batchfile that preserves the long filenames. For recursive actions I use the program 'sweep' together with it. It works and you can PM me if you're interested.

I've implemented these changes into beta v0.9.8b and the bitrates for my 53 problem sample set are as follows:Looking at the rate of change of bitrate, I might be tempted to increase the -nts on -3 slightly to "smooth out" a peak in the rate of change of bitrate, however these bitrates look fairly interesting....

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

Thank you, Nick.

It would be very nice if we could get some more listening feedback no matter at which quality scale.

http://upxshell.sourceforge.net/

and yeah, I guess it's actually "Ultra Brute", but really "Uber" is just as meaningless. Anyways, that's the app.

It's not important, but I suggest a minor defensive change of -snr 22 to -snr 23.5 for -q 2 to -q 4.

My first motivation was a mere optical one:
With this the average bitrate for my regular tracks test set is 272 - 307 - 344 - 388 - 413 - 446 for -q 0 ... -q 5, which IMO is a tiny bit more equally spaced especially when going from -q 2 to -q 3 than 272 - 307 - 337 - 382 - 409 - 446.
Moreover we have a smooth -snr transition 22 - 23.5 - 25.

But I also think it's a good thing to have especially -q 2 more defensive while hardly sacrificing bitrate.
Sure between -q 1 and -q 2 -snr should vary as well as -nts. I think this makes an in-between quality level like -q 1.5 more attractive too.

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

Thank you, Nick.

I'm half tempted to change (18,22,23.5,23.5,23.5,25,28,31,34,37,40) to (18,22,22.75,23.5,24.25,25,28,31,34,37,40) as it appeals more to my linear tendencies....

This makes sense to me too.

Comparing the two:

It was clear that the bitrate difference between -q 2 and -q 3 would increase, but it's more or less negligible.

Looking at the rate of change of bitrate, I'm more inclined to leave -snr preset values as per v0.9.8c as it gives a more even spread of bitrate.

Practically speaking I prefer the way it's done with 0.9.8c a little bit too.

I've re-visited the -spf function for higher frequencies at longer FFT lengths.

was: spreading_function_string : string[precalc_analyses*(spread_zones+2)-1]='22222-22223-22224-12235-12246-12357';
now: spreading_function_string : string[precalc_analyses*(spread_zones+2)-1]='22222-22223-22224-12234-12245-12356';

this gives the following for my 53 problem sample set:

10 Album Test Set:

Attached is a detailed analysis of bitrate vs quality preset for each sample in my 53 problem sample set.

As always I'm more interested in the bitrate increase for regular music (or in the relation bitrate increase of regular vs. problem tracks with a warm welcome to settings where bitrate increase is higher for the problem tracks).
Anyway, in this case it looks like difference is next to nothing in either case. This slightly more defensive setting is more or less for free.

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

Thank you, Nick.
As you tidied up the code a bit: does that mean it is necessary to do another listening test? Or were it just very minor changes?

Other than that I don't know how the community feels about it, but I'd welcome to go final now.
It doesn't look that we'll have essential changes any more, and it also looks as if there isn't a real need for changes, covering now the bitrate range from ~270 kbps up to 500+ kbps in a useful way.

No further changes to the mechanics of the method, only slight speed-up changes.

My only area of concern is with the -help and -longhelp (more the -longhelp) with respect to level of detail required to allow the user to make informed decisions....

The changes to the -spf parameters will not necessitate any more listening tests, I think the circa 1kbps increase in bitrate across the range of quality presets can only improve quality.

If no dissenting voices are forthcoming with respect to quality issues or required modifications to the help pages, v1.0.0 will be released on 12th May 2008 at 20:31 (precisely..... ).

I can't wait to see that as certified news on the front page. Awesome.

What about a logo? If the icon I made is used in the v1.0 binaries, then the logo could probably be delayed indefinitely, at least until there is a website/sf.net page for lossyWAV.

Some players (fb2k, WV winamp plugin) can use correction files for WavPack to play .WV+.WVC files losslessly. It seems no player can use *.lwcdf.XYZ with *.lossy.XYZ (say, .lossy.flac and .lwcdf.flac). It is of no importance for me, but...

Great.
I've hesitated for so long reencoding my entire collection, but I'll do it with v1.0.0.
Guess I'll say goodbye to lossless archiving, will use a unique final VHQ lossyFLAC version instead for all the tracks in my collection, and will never touch them again.
(Life will be easier then as I hate having to manually overwrite the automatically generated replay gain values for quite a series of tracks after reencoding).

I've probably transcoded that portion (about 60%) of my collection which I have ripped to FLAC on my server about 15 to 20 times as lossyWAV has been in development....

I'll still be keeping the FLAC though.... (!)

"My only area of concern is with the -help and -longhelp (more the -longhelp) with respect to level of detail required to allow the user to make informed decisions....

The changes to the -spf parameters will not necessitate any more listening tests, I think the circa 1kbps increase in bitrate across the range of quality presets can only improve quality.

If no dissenting voices are forthcoming with respect to quality issues or required modifications to the help pages, v1.0.0 will be released on 12th May 2008 at 20:31 (precisely..... )."
[/quote]

Great news and well done everybody who's been involved especially Nick.C & halb27 of course.

I think you're right that the help/longhelp need to be good and, well, helpful. Also the wiki needs to be up to date and accurate.

I'm sure that people will want to rip to lossy.wav or even straight to lossy.flac, lossy.wv or whatever, but I guess that's something for others to pick up on once it's gone live.

Once again, well done. It's a great achievement

I was thinking about this area.
As a result I suggest we don't use the kind of advanced options we had so far.
We have arrived at these very differentiating -q levels (already too many levels for some users), and with this I don't see any sense in using even the most basic advanced option -nts. Why not just use a corresponding -q level? With -snr it's the same thing. We have a pretty defensive -snr setting with each quality level, but on the other hand not a lot of bitrate can be saved when going less defensive. IMO it's pretty balanced. Keeping away -nts and -snr from the user has the advantage that there's no need for describing which I guess is a difficult job.
The only useful option for the user IMO is the -clips options though I agree it's pretty personal and not really important either. In case we address the clipping as a user option I suggest we just use something like -noclips which makes sure that no clipping occurs (as done with the high -q levels). This can easily be described. IMO it can be one of the standard options.

I could always change the -q 0 to 10 to -q 0 to 1.0 with a default of 0.5.... Actually, the more I think about that, the more I like it - and it's different from lame, ogg vorbis, flac, etc.

I like this idea (and also halb27's re. keeping options simple)

By the way, looking forward to world lossyWAV day on 12th May. How does one celebrate this? By listening to 24 hours of music?

C.

Hmmm, I'm afraid using something like -q 1.0 is emotionally assciated with 'full (100%) quality', -q 0.6 is pretty much below in quality (though in reality it's overkill quality), and -q 0.15 is pretty bad (though in reality it's excellent). The problem is the association with a percentage quality scale.
But maybe it's just me who looks at it this way. In a sense we have this problem also with the -q 0 ... 10 scale, but because of the lacking association with a percentage scale the problem is less severe IMO.
BTW your suggestion is similar to the Nero AAC quality scale - however I don't see a problem in having a similar scale as another encoder as long as the emotional quality associations are corresponding, at least in the mid quality scale range.

I take your point - 0.0 to 1.0 does indeed have an immediate association with 0% to 100%. I'll leave the -q scale as is.

Please do . Can I ask for a progress bar (or percentage) and an option to create a log file ? I can't catch/save that informative 'average'line. When processing my disc images it's nice to see the progress counting up and down and up again, but I haven't a clue where it's going to. Anyway, many thanks for the program.

A progress bar in what sense and to what purpose? I suppose I could append a line to a log file with a "-l <filepath\filename>" type parameter but what would you want it to contain? When running from the command line there is a progress output of sorts which doesn't include the %age complete, rather amount of data processed (duration of WAV file processed) and number of bits removed so far.

A bit more detail as to what you would want to see would be nice.

Everybody has its own way of how to practically do the encoding. If you give foobar2000 a try as a GUI for encoding you get a nice progress bar (and a good GUI). You just have to configure lossyWAV once for foobar2000 usage which isn't hard if you have a batch file for doing the lossyFLAC stuff (or whatever way you use lossyWAV).

I was asked for where to download the samples I usually try as potential problem samples for lossyWAV.

I've uploaded them for a limited time on my webspace. They can be downloaded from here.

Most of the samples don't show up problems (to me) even at a low quality setting like -q 1.5.
Even those samples that aren't perfect have an excellent quality to me even at -q 1.5.
I can abx however few of the samples at a mid quality level like -q 4.
With the triangle sample I don't know really how to think about it. In a strict sense I can't abx it because my results are too poor. Sometimes I can't hear a problem at all (at -q 4). But there are times when I can repeatedly get results like 4/4 before I start producing more and more errors.

It would be nice to learn about other people's experience.

I agree with that, but a percentage figure counting up while processing (like flac does) is more informative than counting up and down and up again to 256 MB (..).
Foobar won't work on my old and slower pc. And is rather overkill just to use it for just the information
Well, forget about the progression bar; it's still a great program. And mareo and the batchfiles do their tasks finely.

A progress %age would be more convenient to me while working with dos-screen-output and batchfiles than the up- and downcounting to just 256 MB. When processing a disc image of say 771 MB, it's useless to see the up and downcounting not knowing where it ends. The percentage like flac does is fine.
And while processing I see an 'average' line with info that I would like to save. I'm a list and reports man. Especially in the testperiods it's nice to see what lossywav did with my files. I know most people us xp and foobar, but I'm with win98 on a slower and older computer, which is sufficient for playing my music and surfing.