Quote from: halb27 on 09 November, 2007, 06:33:37 PMNothing changes with v0.4.3c and with v0.4.3d.Crashing here too. PIII 550
Nothing changes with v0.4.3c and with v0.4.3d.
I will try to revert to v0.4.1 with the functionality of v0.4.3 and attach.
Yeah, it works.Thank you.BTW: From my personal experience on performance optimization the most imprtant thing is to have a good and adequate software architecture. Low level optimization is important often in only isolated spots.Sure this needn't necessarily apply to lossyWav.
lossyWAV 0.4.2 has no issues with my laptop's AMD Mobile Sempron 3000+ (32-bit) CPU, except it crashes when the specified output folder doesn't exist.
... and close to optimal speed. ...
Quote from: Mitch 1 2 on 09 November, 2007, 11:43:04 PMlossyWAV 0.4.2 has no issues with my laptop's AMD Mobile Sempron 3000+ (32-bit) CPU, except it crashes when the specified output folder doesn't exist.This problem still hasn't been fixed.
I encoded part of my collection using v0.4.4 without any problem, and according to my listening experience so far everything is very fine.I used a variant of -2 which made me think more deeply afterwards about what's really important.I'd like to suggest a discussion on two points concerning default bahavior:1)I would welcome - as I said before - a general default cbs of 512 samples. This will make most lossless codecs behave more efficiently on one hand, and on the other hand I can't see a logical reason why not to use it. If it's about holding average bitrate up for defensive reason we should use a more direct approach targeting directly at overcoming potential weaknesses.2)With -2 I suggest to use an additional 128 sample FFT, to be precise I'd like to see a default behavior according to -fft 11101 -spf 11235-11236-11336-FFFFF-1234D.The 64 sample FFT yields only few bins in the low and lower mid frequency range, so it is welcome IMO to have another rather short FFT which improves significantly upon the situation in the important lower mid frequency range.So I think it's a meaningful addition to use a 128 sample FFT.Moreover it doesn't really hurt as lossyWav is very fast now, and the increase in average bitrate is very low.With -1 btw (not much in my focus) I suggest to use the full 5 analyses.What do you think?
As we're talking about default bahavior: what about -3?I see two targets for -3:a) -3 as a minor variant of -2, expected to be excellent under all circumstances as we expect it from -2, but with a detail behavior which is not as defensive as is -2. Your choice of using the same -spf values as that of -2 points in this direction. If we want to have it like this I suggest we increase the -skew value a bit.b) as a seriously less defensive alternative to -2 targeting at a larger average bitrate gap than with what we have at the moment. To be more precise: if -2 yields say ~440 kbps on average, -3 should yield ~400 kbps. I guess it's achievable while still getting excellent quality. May be an even larger gap makes sense when being aware that quality may be sacrificed on hopefully rare occasion.For b) the default setting should change quite a lot IMO.Having extremely good encoding speed (like with your doing just 1 FFT) as a target fits rather good into this framework.I personally don't have a favorite for a) or b).
Target b) for -3: OK, so we should think about the details.Identical -spf and -skew values for all of the three quality levels? I don't like the idea.From my test when finding useful values for -spf I know some values really hurt bitrate efficiency wise (most of all the bold 1 in '11124' for the 64 sample FFT of -1) but may be vital for being real defensive with respect to the critical band at the lower edge of the corresponding frequency range. So I think it's neceesary for -1 (and would be most welcome for -2 too but it's expensive and the more economic way of treating this within -2 may be by doing the additional 128 sample FFT).With -skew it's similar. -skew is important for diffentiating resulting bitrate between regular and problematic spots, but with a value >24 the improved defensiveness is getting more and more expensive. So I think a value of 24 is very appropriate for -2, but it should be significantly higher only for -1. For -3 it should be <24.Using very high values for -snr helps differentiating between regular and problematic spots too but with these values there's a rather high price to pay bitrate wise. So again high values of -snr should be used with -1 only IMO.So I strongly think -1, -2, and -3 should consist of different -fft, -spf, -skew, -snr, and -nts settings in such a way that the overkill defensiveness, standard defensiveness, reduced defensiveness are represented best.If you want to keep -1 and -2 clean of user options I suggest you do it for -3 as well, and instead create an experimental quality option -x which enables all the advanced options. advanced options = any option except for -1, -2, -3, -nts x (and -flac etc. in case these are ever needed - guess they won't).
I like the idea of the -x quality parameter (-0?) enabling the advanced options and also keeping -1, -2 & -3 "clean".On the -skew, -spf and -snr settings I am inclined to agree with you. The only difficult bit being agreeing what those settings will be.....
-1 = -fft 11111 -spf 11124-11125-11225-11225-11236 -cbs 512 -nts -3.0 -skew 30 -snr 24.-2 = -fft 11101 -spf 11235-11236-11336-FFFFF-1234D -cbs 512 -nts -1.5 -skew 24 -snr 18-3 = -fft 10001 -spf 11236-FFFFF-FFFFF-FFFFF-1246E -cbs 512 -nts -0.5 -skew 18 -snr 12.I don't care much about such details like whether -skew value for -3 should be rather 20 and -snr value 0 (my very personal preference but worth nothing).
The quality settings in the next revision will reflect those above (unless anyone else indicates a strong preference for something different). I've been playing with the -fft parameter again and -3 -fft 00100 -spf ....-23346-..... -skew 24 yields 403kbps on my problematic sample set with no immediately apparent artifacts. ....
As for your -3 approach (just 1 FFT, targeting a significantly lower bitrate than ~400 kbps for regular music ) I can try to help and do listening tests, especially with your setting. I wouldn't lower quality demand extremely however cause after all we will stay with pretty high bitrate, and with that I think we should have a distinction from what we can get with mp3 at moderate bitrate (though this is always a matter of taste).Sorry I won't be able to do it within this week as I'm leaving for my father in law's 90th birthday (got some trouble at the moment producing a photo based dvd movie, and neither my old nor the new dvd player (present for my father in law) are playing it fine).
... Have you checked whether the DVD is written as UDF or not? This may make a difference. ...
As for your new -3 setting I like the new one better as it's more demanding. Let's hear how it sounds.
Target b) for -3: OK, so we should think about the details.
I am wondering about the clipping reduction method - at the moment, if it finds 1 or more sample which clips after rounding then it reduces bits_to_remove by one and tries again, until bits_to_remove=0 then it just stores the original values. Is 0 permissible clipping samples a bit too harsh? At the time thatthe iterative clipping was introduced, I put in an "allowable" variable, implying that a number of clipping (but rounded) samples may be permitted.
I also tried -3 [..] which yielded 420kbps [..] Maybe 400kbps for "real music" should be the target rather than approaching that for my problem set. [/edit]