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

lossyWAV 1.3.0 Development Thread

Reply #225 –
I did a listening test with 1.2.2.z using -q -2.5 --altpreset --adaptive 96 as I did with my last listening test last year. This setting produces an average bitrate of 283 kbps on my test set of various popular music.

I tested those samples that didn't come out totally fine with my last listening test.
For regular music this was 'Köln Concert', 'Sweet Old World', 'Ta douleur', 'Tout le monde'.
I tried really hard, but couldn't ABX any difference to the original (nor do I have any suspicion that's something's not right).
As for the problem samples the situation isn't quite as perfect (as was expected). 'herding calls' was fine to me, furious was - as always - the clearest thing to be ABXed due to the hiss which makes furious sound 'brighter'. This time however I could only spot the problem at sec. 0 ... 0.8. eig is certainly ABXable though I only got at 7/10. Quite interesting that lossyWAV can have problems with temporal resolution too.

Anyway the issues with furious and eig are hardly perceptible and not annoying to me. Moreover these samples can't be exactly called music (as is the case with many problem samples). So I think lossyWav 1.2.2.z -q -2.5 --altpreset --adaptive 96 is an excellent setting for portable listening.

I also tried lossyWav 1.2.2.z -q 0 --altpreset --adaptive 96 on furious and eig and couldn't ABX deviations from the original. This setting yields an average bitrate of 323 kbps on my standard test set.

I also wanted to try the subparameters <warp_lambda> and <persistance> of the adaptive option but it looks as if they are not available any more. Not too bad though because with earlier experiments I didn't get very encouraging results. I did encounter ABXable differences but for some samples <warp_lambda>=0 and <persistance>=0.5 was best among the parameters I tested, while on other samples <warp_lambda>=0.6 and <persistance>=0 was best.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #226 –
Today I gave lossyWavANS a try and tested it with furious on my pc with alessandro MS-2 headphones. For comparison I also tested furious again using lossyWav 1.2.2.z -q 0 --altpreset --adaptive 96. Today I got at 7/7 and finished 8/10. The difference is subtle to me though. Yesterday I tested with my notebook attached to an electrostic headphone which usually is the more sensitive device. Not true for furious obviously (or maybe I am more sensitive today having tested furious several times now within two days).
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #227 –
Hi! How can I get lossyWAV to work with WMA Lossless. What is the command line for foobar2000

lossyWAV 1.3.0 Development Thread

Reply #228 –
See post #1. Sorry - typing faster than the speed of thought never gets the right answer - there was a conversion somewhere, I'll try to dredge it up....

You could try to convert initially to lossy FLAC or Tak or Wavpack and then transcode (losslessly of course) to WMALSL using information from this thread. You will also have to check that you have the relevant WM encoder pack installed as well.
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.3.0 Development Thread

Reply #229 –
I just want to say that I am impressed by LossyWAV. I am trying out "-q -2 -t -A 128" and for the size (around 300 kbps) it sounds so good. Full frequency range and so far I hear NO noise. I will do an ABX some time. Keep it up!

lossyWAV 1.3.0 Development Thread

Reply #230 –
Nick.C:
Your "-q -2 -t -A 128" sounds really, really good even when I use my Beyerdynamic DT880 Pro. What command line would you use to make the files even smaller where I can accept a little noise to put on my HTC to play outside in noisy environments? I tried to change from -2 to -0 but the bitrate increased. Any suggestion? Regards

lossyWAV 1.3.0 Development Thread

Reply #231 –
You could try something in the range -q -4 to -q -2. Using -t (--altpreset) changes the lower quality limit to -4 (although this is the same as -q 0 in the default scale with the exception of the upper frequency limit used for analysis purposes) and also changes the upper frequency limit for analysis purposes to 15159Hz.

[edit] You could also lower the upper frequency limit used for calculation purposes by using the --limit (-l) parameter with a selected frequency in the range 10000 to 20000Hz. The default is 16000Hz and 15159Hz is used for the --altpreset scale. This is, however, likely to add more noise. [/edit]
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.3.0 Development Thread

Reply #232 –
As for Nick's suggestion I can add that -q -4 -t still is very very good from my experience with a former version of lossyWAV (and lossyWAV seems to have improved since then).
I once experimented with lower values of --limit and found --limit 14500 (resp. --limit 14470 as Nick's optimizied suggestion) still to be very good.
So I think you'll be totally content with -t -q -4 --limit 14470 or similar especially if you are willing to allow for a tiny bit of noise on rare occasion. If you should consider to allow even for a higher amount of very high frequency noise (not necessarily audible) you can consider to go even lower with --limit. Things become significantly critical only if you go lower than --limit 13500.
It's questionable however whether it's worth while. You won't get a significantly lower bitrate than when using say -q -2.5 -t which is more solid. A matter of taste.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #233 –
Modern audio codecs have come so far and become so good, that I have stopped looking for a better overall quality/bitrate ratio than AAC. I also see people being amazed, how good lossyWAV has become at portable bitrates. I don't doubt this and respect the achievement. But what's the purpose of lowering lossyWAV's point of general transparency even further? AAC, for example, is already there, has a much more advanced toolbox at its disposal, and is nearly perfect at ~200 kbit/s VBR, with very few exceptions. Between AAC and lossless I rather miss a codec for which no ABXable samples are known in the 300-400 kbit/s range.

Wouldn't achieving 0.000% risk of artifacts be a much nicer goal than further lowering the point of general transparency? The new ANS and psy-models seems to be working nicely at achieving the latter, but I'm afraid the added complexity might increase the absolute risk of failure for extreme samples.

Have I just missed, that there already is a preset with no known problem samples? If not, is any improvement planned in that area or are ANS and psy-model tuning going to get the most attention in the near future?

lossyWAV 1.3.0 Development Thread

Reply #234 –
My understanding, and I may be wrong, but nothing > -2.5 (i.e. portable has been ABX'd). I'd like to know the answer to this also. Certainly --standard (-q 5) so far is 100% transparent.

C.

ps. I kind of agree with you googlebot, I'm not entirely sure of the purpose of lossyWAV going into the non-transparent territory < 300 kbps when transform codecs do such a good job there. But then it's interesting to see how far it can be pushed, I guess.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV 1.3.0 Development Thread

Reply #235 –
I also see the main purpose with lossyWAV to get transparent results with a probability which is extremely close to 1. Nick managed to achieve this more or less from the very start - at a bitrate of roughly 500 kbps on average. A nice bitrate reduction already compared to plain lossless. With his restless efforts we can achieve the same quality level now at a bitrate which is not far beyond 300 kbps using for instance -q 0 -t -A (or a bit more defensive setting for the cautious one).

BTW: I just saw I forgot the -A parameter in my last post (#233). I can't edit it any more.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #236 –
I think if use -t and quality is equal or greater than -q 5

it can consider to use --limit 16000 replace --limit 15159 in default

because for most of people , 16k is safe in mental efforts in MP3 and doesn't increase too much bits

if -t is stable , it can replace old -q setting in default

sorry , my English is poor
 

lossyWAV 1.3.0 Development Thread

Reply #237 –
Quote from: carpman on
....,  but nothing > -2.5 (i.e. portable has been ABX'd).
Nothing greater than -q 2.5, I believe.

Quote from: carpman on
I'm not entirely sure of the purpose of lossyWAV going into the non-transparent territory < 300 kbps when transform codecs do such a good job there. But then it's interesting to see how far it can be pushed, I guess.
To me, the further down the quality scale that the apparent transparency point exists, the better - no?

Quote from: halb27 on
With his restless efforts we can achieve the same quality level now at a bitrate which is not far beyond 300 kbps using for instance -q 0 -t -A (or a bit more defensive setting for the cautious one).
Totally sprung - I just can't stop tweaking the code.... 

Quote from: misuzu on
I think if use -t and quality is equal or greater than -q 5

it can consider to use --limit 16000 replace --limit 15159 in default

because for most of people , 16k is safe in mental efforts in MP3 and doesn't increase too much bits

if -t is stable , it can replace old -q setting in default
I would rather leave the --altpreset system alone - you can always modify the default upper frequency limit for calculations in --altpreset by adding "-l 16000" on the command line. It should be restated that the frequency defined by --limit is for the calculation which finds the lowest part of the signal. It does not affect where the added noise due to rounding goes - that is defined by whether (or not) the user selects shaping (fixed shaped noise), adaptive shaping (behind the signal, sort of....) or does not select shaping at all (full spectrum noise).

[edit] I forgot to add - there are users who have expressed unhappiness previously when the resultant bitrate at the lowest quality settings increased during development - my desire to drive the apparent transparency point down the quality scale is mainly prompted by the wishes of these users. [/edit]
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.3.0 Development Thread

Reply #239 –
Quote from: carpman on
My understanding, and I may be wrong, but nothing > -2.5 (i.e. portable has been ABX'd). I'd like to know the answer to this also. Certainly --standard (-q 5) so far is 100% transparent.

Yes, I think you're right. However, I've never seen any large scale listening test results, just ABX results from a handful (or less) of people. Has a large-enough scale test ever been done to establish statistically meaningful results?

I also agree with Googlebot that there doesn't seem much point trying to compete at typical lossy bit rates. But it does at least give people another choice

lossyWAV 1.3.0 Development Thread

Reply #240 –
Unfortunately, there have been no large scale listening tests performed with lossyWAV. There have been, and still are, those who have volunteered their ears and time to test processed output at various stages in the development process - for which I am very grateful - the results have shaped the development of lossyWAV.

There may not be much point, to some, in trying to lower bitrates for "acceptable" output - on the other hand output at higher bitrates should have even more clearance between the signal and the added noise. The drive to lower bitrates, as has been said, gives people choice.

[edit] Sp. [/edit]
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.3.0 Development Thread

Reply #241 –
Finding out how far "down the quality scale [...] the apparent transparency point" is, seems very worthwhile IMO.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV 1.3.0 Development Thread

Reply #242 –
Nick, now that you're at 1.2.2z RC1 so that 1.3.0 is ahead of us: what about cleaning up the option scenery which has evolved during the development process?

My ideas on this as a whole (partially we talked about it already):

a) with the explicit exclusion of the --limit strategy it would be good IMO to have only the --altpreset quality scheme and forget about the older one.
    The --altpreset scheme allows for a good audio quality when varying q in steps of 2.5 as you always did for the named presets.
    Also bitrate scales well for a step size of 2.5 with the --altpreset scheme.
    q should be allowed to be in the range -2.5 to 10 (or maybe -5 instead of -2.5, but -2.5 as a lower limit is more in line with the lossyWAV target properties IMO).

b) analysis limit default should be the usual 16 kHz for q in the range q>=2.5, q<7.5.
    --limit should default to 15159 for q<2.5.
    --limit default should be 17 kHz or a little bit lower for q>=7.5.
    --limit should remain an explicit parameter to override the defaults.

c) Adaptive noise shaping should be defaulted as it showed to be useful and doesn't break things.
    However there should be a switch to turn it off.
    So this is the opposite to today's behavior where it has to be explicitly switched on.
    As for the -A value I have no idea what is most appropriate. Today it defaults to 64 if I see this correctly.
    I used a value of 96, but that was only because you suggested this some day for trying out. Encoding speed using -A 96 is fine to me.
    My feeling (from very few experiments) is that resulting quality doesn't depend much on the -A value.
    So the FIR quality parameter should go IMO (with the -A option as adaptive noise shaping should be defaulted) and should be appropriately set internally.

d) There should be named quality parameters which correspond to a -q stepsize of 2.5 used according to the default behavior as described by a) to c).
    Names can be similar to:
    - insane (equivalent to -q 10)
    - extreme (equivalent to -q 7.5)
    - standard (equivalent to -q 5)
    - economic (equivalent to -q 2.5)
    - portable (equivalent to -q 0)
    - superportable (equivalent to -q -2.5).
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #243 –
Can someone help me with my Foobar parameters for Lossywav?

Please Ignore, I cracked it

lossyWAV 1.3.0 Development Thread

Reply #244 –
@Botface - glad that you identified the issue....

@halb27 - I am thinking of stretching the -4 to 10 scale to -5 to 10. The only issues with --economic and --superportable are the associated letter for the short version as -E and -S are already used by --extreme and --insane.

I would also be looking for suggestions for for the new lowest quality setting as -Z, --zero could do with being changed.

I will post my initial proposals for the change to the --altpreset scale. I will not remove the existing preset scale but will introduce a --classic parameter to allow users to consciously select the old one.
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.3.0 Development Thread

Reply #245 –
Just my £0.02 but I think negative quality settings look a bit silly. I'd much rather see 0 to10. But I accept that might result in the typical final bitrates not being smooth steps - and I like the idea of q5 being the "standard" or "assumed transparent" setting with roughly equal more and less conservative settings either side of it. Having said that I don't feel particularly strongly about it if you feel there's good reason to go -5 to 10

lossyWAV 1.3.0 Development Thread

Reply #246 –
Another way to approach this would be to squeeze the portion of the quality scale currently between -5 and 5 into the 0 to 5 range. This would do away with negative quality values altogether but would have the side effect of bringing all of the quality presets lower than 5 closer together. I'll have a think on this too. Thanks for your tuppence worth.
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.3.0 Development Thread

Reply #247 –
Just a thought, but where minus numbers might be useful is where the scale cannot guarantee transparency.
If say --portable at -q 2.5 is transparent, but -q 2 is potentially not, then have --portable at 0 (or perhaps better 1) and < -q 2.5 at -1 onwards etc ..

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

lossyWAV 1.3.0 Development Thread

Reply #248 –
Hmmmm.... I really quite like that suggestion. If this were to be developed then I would map the current -q 2.5 to -q 0, stretching 2.5 to 5 over 0 to 5 and moving -2.5 to 2.5 into -5 to 0.
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.3.0 Development Thread

Reply #249 –
The only thing I'd throw in (and I'm almost ambivalent about this) is what about not having 0 (zero).
e.g.  -2, -1, 1, 2, 3 ... (forget the numbers, but you see what I mean).
The reason I'm suggesting this, is if -x = potentially not transparent and +x = guaranteed transparency (with increasing safety margins*), what does 0 mean?

C.

EDIT *
PC = TAK + LossyWAV  ::  Portable = Opus (130)