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 1.2.0 Development Thread (Read 313892 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.2.0 Development Thread

Reply #525 –
The noise_threshold_shift_average and noise_threshold_shift_minimum values are the same quality level dependent values as are used in the rest of the (previous to bit-removal) processing.

Actually, I've had a thought.... (dangerous, I know).

This approach could be taken with *every* single analysis to determine the resultant noise allowable bits to remove rather than just using the correction data analysis for the codec-block-length single analysis per channel as used in beta 1.1.4k.

I'll work out how best to implement and see what happens....

lossyWAV 1.2.0 Development Thread

Reply #526 –
I see. So you have something different in mind than I assumed. --postanalyze is an extra procedure not directly related to the classical lossyWAV approach targeting at a quality adequate for the quality level chosen in the very same sense the usual procedure does.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #527 –
Nothing has changed except for the possible modification of the calculated bits-to-remove value for a particular codec-block channel when the noise level of the analysed correction data is compared to the spreading function result (amended by quality dependent shifts) of the source audio.

The post-analysis is (optionally) carried out after the existing bit-removal process - after which the processed result is written to the output file.

[edit] I tried the immediate check to see whether the noise associated with the correction data for the calculated bits-to-remove value for each and every analysis FFT is consistent with the calculated bits-to-remove value and it is (well, almost - my 55 sample set at --zero is 134 bytes bigger when modifications are made based on noise modified bits-to-remove). [/edit]

lossyWAV 1.2.0 Development Thread

Reply #528 –
Hmmm.... It appears that the post-analyse parameter in its present incarnation simply duplicates (nearly) the inclusion of analyses using an FFT the same length as the codec-block.

Will ponder again, but I think that at the moment simply reversing the inclusion order for additional analyses will allow the inclusion of codec-block length FFTs more easily. (currently 2=64,1024; 3=64,128,1024; 4=64,128,256,1024; 5=64,128,256,512,1024 - would be changed to: 2=64,1024; 3=64,512,1024; 4=64,256,512,1024; 5=64,128,256,512,1024).

lossyWAV 1.2.0 Development Thread

Reply #529 –
I've come to an end for thinking about those ideas originating from encoding more efficiently 15 kHz lowpassed music.
For --portable I'm using --limit 15000 -s 0.1 now which yields 362 kbps for my test set.
I like the idea that this is a (for me) universally good setting which also deals well with lowpassed music.
From listeneing tests I'm totally happy with the quality.

I don't care about the lost noise control in the 15...16 kHz region, and if it were only for this I'd even go a bit lower with the 15 kHz limit.
I care more about the side effect this has because controlling noise in the x ... 16 kHz region has the defensive side effect of less bits-to-remove as a general tendency compared to not doing so, which makes the entire process more defensive (noise is lowered in the entire frequency range) even if it would not really be necessary in the x ... 16 kHz range.
With --portable we have a little but not a huge safety margin from the transparency border IMO, so to me using --limit 15000 is appropriate.

The procedure is more interesting with higher quality levels.
Using --standard --limit 14500 -s 0.2 I arrive at 435 kbps which is significantly lower than pure --standard, and lowering the -s value has its part in reducing bitrate - to a larger extent than when not using --limit.
That's why I also lowered -s with the --portable quality.
--extreme --limit 14000 -s 0.3 takes 501 kbps.
--insane --limit 13500 -s 0.4 takes 574 kbps.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #530 –
Thanks for these thoughts - decreasing the --shaping below q/10 will always save resultant bitrate to some extent.

I am intrigued by your use of the --limit parameter but remain convinced (at the moment) that the default should remain at 16kHz per David's method as "published".

lossyWAV 1.2.0 Development Thread

Reply #531 –
The idea behind --limit <=15000 is like this:
Let's first assume that we are at --standard quality.
--limit 14500 makes sure that there is no audible noise in the range up to 14.5 kHz according to 2Bdecided's basic principle.
A high value of bits-to-remove means that there's pretty much energy all up to 14.5 kHz. With pretty high energy near 14.5 kHz I consider noise in the 14.5 ... 16 kHz range is masked enough. Considering further our low sensitivity in this very high frequency range.  On the other hand a low value of bits-to-remove means a good S/N ratio at whatever frequency.
To me this is sufficiently plausible to do it like this especially as at the --standard quality level we can assume that we have a pretty large safety margin towards the transparency border.
At the --portable quality level things aren't that clear as we are in the range of heuristics below 2Bdecided's basic principle. But we aren't at the very start of lossyWAV experience. --portable seems to have some small safety margin. That's why I decided for me to use a little bit of a more aggressive setting in line with these ideas.
My motivation for these things comes also from the fact that this way I don't have to care about reencoding rather strongly lowpassed mp3 tracks after having modified them.

So things just come together, and I like the results I listened to.

May be you can look at it like this: Noise analysis has always been restricted to 16 kHz for good reason (at least as a default). What I'm doing right now is put the question on the 16 kHz. Why 16 kHz? In the end it's an arbitrary choice (though it's clear that it should be at very high frequency). I just prefer 15 kHz at the --portable quality level, and even less for the higher ones.

The -s setting isn't necessarily touched by these considerations. I just found that the -s bitrate penalty is higher with a lower --limit. And allowing for not directly controlled noise in the 14.5 .... 16 kHz area is in line with reducing the overall noise shift towards higher frequencies. But it's not a necessary conclusion.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #532 –
Sounds like a well thought out approach. I'll try some transcoding and see what the results sound like....

btw, I have made more progress with [JAZ]'s request to split the code up into functional chunks - the main program only contains the main loop itself, all functions and procedures have been farmed out into supporting units.

[edit] Tried some transcoding - My Mike Oldfield collection: 383 tracks, 34h18m: --portable --postanalyse --limit 13750 --shaping 0.15 results in 373kbps. [/edit]

[edit2] In foobar2000, add "-S- -P=32768" to the FLAC element of the lossyWAV command line in the converter to remove the seek-table and reduce padding to 32kiB. [/edit2]

[edit3] Same 383 tracks, --portable --limit 14000 --shaping 0.10 results in 365kbps. Sounds fine at relatively quiet nocturnal listening levels.[/edit3]

[edit4] Changed size of padding - 20kiB was too small for adding tags and Replay Gain tags. [/edit4]

lossyWAV 1.2.0 Development Thread

Reply #533 –
What's the bitrate when not using --limit?

You have encoded a lot of Mike Oldfield's tracks. I would prefer a bit if you could use a certain mix of various kind of pop music (while staying within the same genre which I also do with my test set). In return I am convinced that it needn't be that many tracks to encode which makes things a lot easier. I have always used an identical test set of just 12 tracks of very varying pop music, starting with The Beatles and ending with tracks which were actual at the time (2 or 3 years ago) I set up the test set. My bitrate results were always pretty close to what came out from your many album tests as well as the results of other members, though just 12 tracks is certainly a rather low number which can be improved (I'm just lazy).
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #534 –
My MO collection is always the one I will turn to for checking if I like the quality of the output. I am working on a vanilla --portable transcode of it at the moment.

I will post some details of my 10 album test set tomorrow.

lossyWAV 1.2.0 Development Thread

Reply #535 –
As it's about quality: preferred and well-known tracks are among the best candidates for a test of course.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #536 –
Vanilla --portable on the 383 tracks comes in at 392kbps. 365kbps for --portable --limit 14000 --shaping 0.10 seems quite a good reduction by comparison. I'll probably do a full transcode tomorrow and see what the results are for my 760hours, 10826 tracks, 880kbps collection which comes in at 378kbps at --portable.

So, if 392kbps goes to 365kbps for my MO collection then 378kbps may go to around 351 to 353kbps for my whole collection with these revised settings.

lossyWAV 1.2.0 Development Thread

Reply #537 –
--portable --limit 14000 -s 0.1 takes 347 kbps for my test set.

I am glad we're on the same train.
Of course it's disputable where exactly to put the limit.
Maybe it's more appropriate to have the same --limit value with all the quality levels, and maybe we can allow for a lower --limit value than 15000 for --portable, just as you are trying right now.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #538 –
I did some ABXing with --portable --limit 14000 --shaping 0.1.
I couldn't ABX a problem, but with Rickie Lee Jones' 'Under The Boardwalk', range 2:25.2 ... 2:28.1, I got at 6/7 which turned into 7/10 (I really hate results like this). So there's a bit of a supicion left.
When using --portable --limiit 14500 --shaping 0.1 I was lost with ABXing this spot from the very start.
--portable --limiit 14500 --shaping 0.1 takes 254 kbps for my test set.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #539 –
I would probably use 21/64*44100 = 14470(.3125) as the cutoff - it's a nice round number of bins.

[edit] sp. [/edit]

[edit2] Cancelled the --portable --limit 14000 --shaping 0.10 transcode in favour of --portable --limit 14470 --shaping 0.10. Should be ready in about 4h30m. [/edit2]

[edit3] Currently 287h38m, 355kbps resultant (FLAC -5 -S- -P=40960) bitrate; 1 file per album. [/edit3]

lossyWAV 1.2.0 Development Thread

Reply #540 –
Quote from: Nick.C on
I would probably use 21/64*44100 = 14470(.3125) as the cutoff - it's a nice round number of bins. ...

Wonderful.
From experience so far this seems to be a reasonable value.
--portable --limit 14470 --shaping 0.1 takes 354 kbps for my test set as was the case with --limit 14500 (sorry for writing 254 kbps in my last post).

It would be great if we could get some feedback from listening tests of interested members helping to bring lossyWAV forward.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #541 –
My 760hr collection results in 357kbps at --portable --limit 14470 --shaping 0.10. Quite a nice reduction from the 378kbps for vanilla --portable. I am encouraged by your ABX testing and similarly would appreciate it very much if other user with gifted hearing could devote some of their time to testing this particular setting.

lossyWAV 1.2.0 Development Thread

Reply #542 –
Quote from: Nick.C on
My 760hr collection results in 357kbps at --portable --limit 14470 --shaping 0.10. Quite a nice reduction from the 378kbps for vanilla --portable. I am encouraged by your ABX testing and similarly would appreciate it very much if other user with gifted hearing could devote some of their time to testing this particular setting.

I've had a go using the suggested settings.
I have been using LossyWav 1.1.4a up to now and often use it with -q 2.5 -s 0.5 -a 4 --sortspread. By way of explanation I actually find -q 2.5 transparent but I add the "extras" to give me peace of mind in case whatever I'm encoding happens to contain a difficult case.


I happened to have  Bob Marley album to convert so I used my usual settings in v1.1.4a and got an average bitrate of 353. Using 1.1.4k with --limit 11470 -s 0.1 and FLAC -b 512-5 -S- -P=40960 I got an average of 334. I realise that doesn't tell you anything useful about the relative bitrates. However on listening I can't hear any difference at all. I should qualify that by pointing out that I do not have "gifted hearing" - I can't hear as high as 14470 and I'm not good at ABXing. But assuming any noticeable difference would be in the background noise level, I certainly wasn't able to spot a change.

Hope that helps

lossyWAV 1.2.0 Development Thread

Reply #543 –
Thanks for your efforts - the result is encouraging.

On another topic, I am interested to gather opinion on the --sortspread parameter - is anyone using it?

lossyWAV 1.2.0 Development Thread

Reply #544 –
I haven't used --sortspread. I didn't understand the background and was happy without it. So I had no motivation to try it.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #545 –
Quote from: Nick.C on
Thanks for your efforts - the result is encouraging.

On another topic, I am interested to gather opinion on the --sortspread parameter - is anyone using it?

I use it but only because it's there and the rationale behind it made sense to me. I wouldn't miss it if you decide it's superfluous

lossyWAV 1.2.0 Development Thread

Reply #546 –
Has anyone found that -s 0.1 is better than -s 0 with these settings (--limit 14470) ?

edit: corrected limit
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.2.0 Development Thread

Reply #547 –
Quote from: GeSomeone on
Has anyone found that -s 0.1 is better than -s 0 with these settings (--limit 11470) ?

To avoid any confusion, that was a typo on my earlier entry. It should read --limit 14470. I'll edit my original post if the system will allow it

edit - unfortunately I can't change my original post - \edit

 

lossyWAV 1.2.0 Development Thread

Reply #548 –
Just wanted to see how much below -P i can go and still get decent quality. My general impression is Q1.5 (320k) is the limit and quality is not bad even on more difficult tracks. For non-fussy people maybe Q1. Quality <=1 can be a disaster as the noise can fluctuate like static.

The 'serioustrouble' sample is a good one. abxable until Q1.5 - but quality is still good at that level.

Another interesting sample:

http://www.hydrogenaudio.org/forums/index....showtopic=74486


I could abx upto Q1.5 easily (Q0~1 is a disaster) . At Q2 i needed more concentration but i believe there is a hiss in the right channel but quality is very good (abx 7/8). Maybe i'll try -P later when things are more quite.

In contrast i tried the wv lossy mode:

250k -hhx  - hiss . Quality is not bad
300k -hhx  -hiss more subtle 7/8
320k - hhx - even more subtle i failed at 5/8

lossyWAV 1.2.0 Development Thread

Reply #549 –
Thanks for your efforts, encouraging results. (If you have the time / inclination) how is the sample processed with the latest beta using the --sortspread parameter?