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 308095 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.2.0 Development Thread

Reply #550 –
Quote from: shadowking on
Just wanted to see how much below -P i can go and still get decent quality.  ...

Thanks a lot for testing. Confirms so far that with --portable quality there seems to be a small safety margin.
Did you use plain -q x? Or did you give --limit 14470 a try?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #551 –
Quote from: halb27 on
Quote from: shadowking on
Just wanted to see how much below -P i can go and still get decent quality.  ...

Thanks a lot for testing. Confirms so far that with --portable quality there seems to be a small safety margin.
Did you use plain -q x? Or did you give --limit 14470 a try?


Plain -q x with -s0 using v1.1 encoder.

lossyWAV 1.2.0 Development Thread

Reply #552 –
Quote from: shadowking on
Plain -q x with -s0 using v1.1 encoder.

You mean before 1.1.1 ? That was over a year ago. Not that there was anything obviously wrong with that version but Nick has been been busy trying to improve.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.2.0 Development Thread

Reply #553 –
Ok. Updated to the latest encoder.

My sample is improved. Q0 sounds less static and Q1.5 is about transparent.

Serioustrouble is still serious trouble with Q0~1, quality is not bad at Q1.5 but noise is still fluctuating like static. Q2 was trasparent 5/8. Bitrate is amazing >600 k vs 780k original even for Q0. Q5 is 739 , Q2 645

In contrast i also compared wavpack quality / bitrate (ABR):

200k -hhx5: heavy hiss. poor quality but better than Q0~1 LW (no static) - 201k avg

256k -hhx5: moderate hiss 7/8 - 265k

300k -hhx5: failed to abx 3/8 - 309k


When going for the more 'common' bitrate , less than perfect but still very good quality say 256 ~ 320 k , ABR / CBR seems more efficient and safer..
Doing the same with VBR as in lossywav may at times give inferior quality with still very high close to lossless bitrate. Bitrate saving from Q2.5 >> Q2 isn't much . Q1.5 is a candidate but bitrate with 1.1.4 is higher around 350k. So perhaps going lower than -P isn't so attractive.

lossyWAV 1.2.0 Development Thread

Reply #554 –
Yes, I think we have to accept that it takes -P or at least -q 2.0 to get at what we expect from lossyWAV: perfect quality in a practical sense.
Bitrate of critical spots in critical tracks is high usually - it's a feature. Average bitrate of an entire collection should be pretty attractive for a non-transform codec (though you may get a better one with wavPack lossy according to personal demands).
The current approach of lowering bitrate is to use --limit 14470.
Do you mind trying your samples with this option? Most interesting is the quality of -P, but the results of -q 2.0 or -q 1.5 are very welcome too.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #555 –
Quote from: halb27 on
The current approach of lowering bitrate is to use --limit 14470.

was to be (can't edit any more):
The current approach of lowering bitrate is to use --limit 14470 -s 0.1.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #556 –
Seems like a grand idea to reduce size.
I tested [--portable --limit 14470 -s 0.1] and it sounds transparent to that of [--portable] on a few albums that I tried.
One album had a 15kbps difference and dropped the size down by about 5mb. The others are still being worked on. : /

I will continue doing some testing with different [-s] values.

Has anyone tried -s 0.2 or -s 0.3?

lossyWAV 1.2.0 Development Thread

Reply #557 –
--portable has a default --shaping value of 0.25 - reducing this will reduce resultant bitrate.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #558 –
oh ok then I will test from 0-0.1 -haha
But sure enough it does reduce a good amount for that quality.
If this sounds transparent for the majority will this replace --portable? Or Would be an approximate?

lossyWAV 1.2.0 Development Thread

Reply #559 –
couldn't edit my previous post but I tried the same setting with -s 0.08, faint hisses every now and then.
The second time I re-sampled to 32khz and which reduced the file size even further and the hisses aren't as apparent. (someone may want to confirm it, may just be placebo.)
354kbps=299kbps and the quality was an improvement compared to trying to lower the shaping to 0.080.

"Re-sampling appears to reduce the hissing..." -hope this helps out.

A Yoko Ishida album I had was 140mb before resample, after became 118mb.

lossyWAV 1.2.0 Development Thread

Reply #560 –
Based on the latest tests, that indicate that -s 0.1 is an acceptable value at -q 2.5 (--portable), I came up with this suggestion. Lower the the automatic value of -s a bit quicker accross the board.

for example like this: -s=Q*0.12-0.2 . It should only be decided what the minimum should be, 0.0 or maybe 0.1 .
This gives -q 2.5 -s 0.1 ; -q 5 -s 0.4 ; -q 10 -s 1

And along the --limit way of thinking, maybe some (bin) steps would make sense:
-q 3    --limit 14470 (would be better to derive from sample rate)
-q 4    --limit 15159
-q 5    --limit 15848

Not sure if it would make sense to go above or below these.

The idea would be to incorporate these mechanisms into the defaults.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.2.0 Development Thread

Reply #561 –
I second that, using modified --limit / -s values as defaults for the various -q levels.

I am happy with -P --limit 14470 -s 0.1, so this is my favorite -P combination.
Using a -s value of 0.12*q - 0.2 would be fine to me though I personally would prefer a mechanism targeting at somewhat smaller -s values for the higher quality levels, something like s value = 0.008 * q^2 +0.02 * q (q=5 -> s=0.3, q=7.5 -> s=0.6, q=10 -> s=1).
As for --limit I'd prefer to have a constant --limit of 14470 no matter what quality level.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #562 –
Quote from: halb27 on
As for --limit I'd prefer to have a constant --limit of 14470 no matter what quality level.

We should make sure however that lossyWav is usable for other sample rates than 44100. This value might not be optimal for 48000Hz (or higher). BTW --limit 15000 could be exactly right for 48000Hz files.
Those considerations might make it too complex maybe?
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.2.0 Development Thread

Reply #563 –
OK, I had only 44.1 kHz sample frequency in mind.
From 'clean' bin considerations maybe another limit is more attractive for other sample frequencies. Can't judge on this.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #564 –
I will work on a --altpreset parameter to change the automatic shaping and limit values in line with the proposal.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #565 –
Thanks a lot, Nick.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #566 –
Quote from: Nick.C on
I will work on a --altpreset parameter to change the automatic shaping and limit values in line with the proposal.

Thanks for considering this. Do you think it is too soon to amend the normal -q? For testing the manual --limit is OK.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.2.0 Development Thread

Reply #567 –
lossyWAV beta 1.1.4m attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #569 –
The postanalyse parameter effectively duplicated the effect of adding an analysis to the process of the same FFT length as the codec-block. I have reversed the order that the additional analyses are added so that the codec-block length FFT analysis is added first - so in effect -a 3 replaces --postanalyse.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #570 –
ok, good to know it isn't really gone as it seemed to be a useful feature.  I admit i don't understand much of lossywav technicalities but the more analyses the better quality, right?

lossyWAV 1.2.0 Development Thread

Reply #571 –
nice... so does the --altpreset has the new shaping and limit adjustments... 
will try out things lower than --portable... it does go after -portable right?
iLike 

lossyWAV 1.2.0 Development Thread

Reply #572 –
I just tried 1.1.4m on a CD that I originally ripped yesterday. Using --altpreset brought the overall size down from 144MB to 136MB with no discernable difference in noise levels or any other undesirables. Nice work Nick, thanks

lossyWAV 1.2.0 Development Thread

Reply #573 –
Good to hear that recent modifications are as yet well received.

Bugfix: lossyWAV beta 1.1.4n attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #574 –
Thank you, Nick.
lame3995o -Q1.7 --lowpass 17