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

lossyWAV 1.3.0 Development Thread

Reply #250 –
Zero = the apparent transparency point? i.e. q>0, transparency expected; q<0, transparency not expected.
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 #251 –
Yeah, that makes sense, especially since you're dealing with a point at the border of perceived transparency. So zero would be like the fulcrum.

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

lossyWAV 1.3.0 Development Thread

Reply #252 –
Quote from: carpman on
... and +x = guaranteed transparency (with increasing safety margins*) ...
has me a bit nervous - "guaranteed" is a very strong word in this context. I would prefer to use "expected"
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 #253 –
Quote from: Nick.C on
"guaranteed" is a very strong word in this context. I would prefer to use "expected"

Sensible. Do you think "guaranteed" can be used for --standard though? Since "expected" is also a relevant term for say LAME at -v 2. What it seems you are saying is "expected (even for problem samples)". And that kind of language would differentiate lossyWAV from many lossy transform codecs.

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

lossyWAV 1.3.0 Development Thread

Reply #254 –
As for the named quality levels:

What about using three-letter-abbreviations like:

-INS
-XTR
-STD
-ECO
-PBL
-SPB ?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #255 –
Quote from: halb27 on
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

Or maybe switch to 15159 for q<3.5 to smooth the bit rates as there was/is a (small) jump in the bit rates >2.5 where --impulse became default.
Anyway, all this might look different if the -q scale will be re-stretched and/or more defaults change.
Quote from: Nick.C on
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.

Would that mean 3 sets of -q setting? normal, --altpreset, --classic ? I'm all for compatibility and I use the --alt-preset in 1.2.0 exclusively but I think if you give us a few hints of how the 1.3.0 -q scale relates to the 1.2.0 one we can figure out how to adjust our settings accordingly. I'm just thinking about maintainability in the future, so it's up to you.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.3.0 Development Thread

Reply #256 –
lossyWAV beta 1.2.3a RC2 attached to post #1 in this thread.

New default parameters introduced.

--limit as follows for default -q -5 to -q 10: 15159,  15332,  15504,  15676,  15848,  16021,  16107,  16193,  16279,  16365,  16451,  16538,  16624,  16710,  16796,  16882;

Approximate quality setting conversion as follows (in terms of resultant bitrate for my 10 album test set):
Code: [Select]
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|
|  default  |-5.00|-4.00|-3.00|-2.00|-1.00| 0.00| 1.00| 2.00| 3.00| 4.00| 5.00| 6.00| 7.00| 8.00| 9.00|10.00|
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|
|--altpreset|-2.52|-1.35|-0.24| 0.83| 1.95| 2.88| 3.80| 4.41| 4.90| 5.41| 5.93| 7.00| 8.08| 9.16|10.00|10.00|
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|
| --classic | 0.40| 0.86| 1.29| 1.75| 2.29| 2.89| 3.75| 4.27| 4.63| 5.01| 5.42| 6.25| 7.09| 7.95| 8.81| 9.68|
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|

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 #257 –
Need input:
1) Should the existing --altpreset preset system be removed now that the new default system exists?
2) Is the existing fixed noise shaping system required given that[blockquote]a) the new adaptive noise shaping seems to be working well;
b) the existing method only really works for 44.1kHz and 48kHz.[/blockquote]3) Should the default quality system automatically enable adaptive noise shaping?
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 #258 –
To me the new default quality system including --limit defaults is very reasonable. Saying so I assume that the internal details of the new quality system are very similar to the internal details of the corresponding --altpreset setting - corresponding with respect to comparable bitrate. With this in mind the --altpreset scheme should be removed IMO. If it were me I wouldn't keep the classic scheme either. But it all depends on the internal parameters of the new default scheme not departing much from what we have with the --altpreset and current default scheme. Having just one quality scheme makes things a lot clearer.

The new quality system is defensive with respect to the quality systems used so far. If someone using current quality system with say -q 5 switches to the new system he will get a quality which will be equal or better.

I wasn't aware of sample frequency limitations of adaptive noise shaping. As for this I'd prefer a noise shaping parameter with 'adaptive' (default for 44.1 or 48 kHz), 'fixed', 'none' as possible values.

lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #259 –
Sorry, my lack of clarity.....

The fixed noise shaping method is only optimized for 44.1kHz and 48kHz (by the available coefficients).

[edit]
The adaptive noise shaping method copes with all permitted sample-rates (tested up to 192kHz so far).

With some more support for removing --altpreset (and, for that matter --classic) it will happen.

Seriously considering removing the fixed noise shaping method.
[/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 #260 –
I'd be very happy with only one quality scheme (i.e. getting rid of --altpreset and --classic).
As far as noise shaping, I think on or off is good (so +1 for getting rid of 'fixed').

The simpler the better IMO.

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

lossyWAV 1.3.0 Development Thread

Reply #261 –
Btw, have you experimented with 'pleasantness' of different kinds of noise besides hiding it as intelligently as possible?

For a lot of music, especially classical, a faint, mellow noise floor can sound much more pleasing than total silence in between. If I could trade-in bitrate for something like that, I would seriously consider it. But there are such and such noises, some annoy, some bed you gently.

lossyWAV 1.3.0 Development Thread

Reply #262 –
Thanks, Nick, for clarification that noise shaping limitations are with fixed noise shaping.

So for me: I'd give away fixed noise shaping (as well as --altpreset and --classic - under the assumption that internal details don't differ considerably from these with comparable bitrate).
The default quality system should automatically use adapitive noise shaping as a default IMO.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.3.0 Development Thread

Reply #263 –
I agree with halb27 (and others) about dropping  --altpreset and --classic. But I still think negative quality levels look a bit silly, even though I understand the rationale here.

In day-to-day English a quality level of zero is equivalent to having no quality at all. You'd expect anything with no quality to be pretty bad. Having a quality attribute that is even less than no quality is a bit nebulous to say the least but if such a thing could exist it must absolutely dire. I don't think that's the impression we want to create. What's more we know that this isn't the case with LossyWav so to me it doesn't make sense. However, as I've said before I don't feel strongly about it and if that's what others want I'm happy.

lossyWAV 1.3.0 Development Thread

Reply #264 –
Quote from: botface on
...In day-to-day English a quality level of zero is equivalent to having no quality at all. ... Having a quality attribute that is even less than no quality is a bit nebulous to say the least ...


If it were me we could also give away -q levels and concentrate on named presets.
The new default scheme is a nontrivial change from the old schemes in terms of the meaning of the q levels. So to me it wouldn't be a bad thing to go on one step and switch to only named presets as a final solution.
Moreover the quality meaning of -q differences below a certain threshold is pretty uncertain anyway.

So in the end I think the clearest thing would be to have just named quality presets. Quality expectation should be clear from the name.
Once this final step would be made it would finish reasoning about the -q level scheme which has already undergone some history. With the maturity lossyWAV has reached I think it is appropriate to stop changing parameter systems right now.
And using just named presets would be a great step in this direction.

lame3995o -Q1.7 --lowpass 17
 

lossyWAV 1.3.0 Development Thread

Reply #265 –
Quote from: halb27 on
If it were me we could also give away -q levels and concentrate on named presets.
The new default scheme is a nontrivial change from the old schemes in terms of the meaning of the q levels. So to me it wouldn't be a bad thing to go on one step and switch to only named presets as a final solution.

Not my opinion.
To me the named presets are meaningless, with names that suggest a specific use, which will not be the case for everyone. Also they're rather coarse (big steps in bit rate).
Having at least one working quality scale is a good thing, but I will leave it to others to discuss about the value range (<0 or >0).

I agree that the redefining of the Q scale will confuse the users that have not been following this thread. So the difference, between the scale in 1.2.0 and the new one, should be documented somewhere (maybe even in the longhelp).
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.3.0 Development Thread

Reply #266 –
Quote from: GeSomeone on
To me the named presets are meaningless, with names that suggest a specific use, which will not be the case for everyone. Also they're rather coarse (big steps in bit rate).
Having at least one working quality scale is a good thing [...]

I agree.

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

lossyWAV 1.3.0 Development Thread

Reply #267 –
Quote from: botface on
I agree with halb27 (and others) about dropping  --altpreset and --classic. But I still think negative quality levels look a bit silly, even though I understand the rationale here.

In day-to-day English a quality level of zero is equivalent to having no quality at all. You'd expect anything with no quality to be pretty bad. Having a quality attribute that is even less than no quality is a bit nebulous to say the least but if such a thing could exist it must absolutely dire. I don't think that's the impression we want to create. What's more we know that this isn't the case with LossyWav so to me it doesn't make sense. However, as I've said before I don't feel strongly about it and if that's what others want I'm happy.


Regarding negative quality levels they could be made accessible only with additional special option, like --enable-advanced-options or --testing

lossyWAV 1.3.0 Development Thread

Reply #268 –
What do you think. Which is the best possible command line for LossyWav.exe for 24bit / 96kHz wav conversion. I have used so far:
lossywav - -I --adaptive --silent --stdout          .. I get flac 8 after and getting about 950 kbps .. but I think it would be around 1300kbps in flac without much loss

lossyWAV 1.3.0 Development Thread

Reply #269 –
What you used is the best possible - there is no higher quality setting, unless you wanted to add additional FFT analyses using --analyses <n> (3<=n<=5), or use the --underlap parameter to increase the number of FFT analyses carried out at each FFT length, --underlap <n> (n=4 or 8).
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 #270 –
lossyWAV beta 1.2.3b RC3 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.3.0 Development Thread

Reply #271 –
I have encoded some HDCD tracks with quality 10, 9, 8, 7 and 6 and Foobar says they are HDCD still. How can this work when LossyWAV removes the lowest unused bits if I understand it correctly. Regards.

Edit: I notice when I play the files in Foobar the volume suddenly jumps up to normal after a few seconds indicating that it probably can't see any more HDCD info after a second or so.

lossyWAV 1.3.0 Development Thread

Reply #272 –
Quote from: punkrockdude on
I have encoded some HDCD tracks with quality 10, 9, 8, 7 and 6 and Foobar says they are HDCD still. How can this work when LossyWAV removes the lowest unused bits if I understand it correctly. Regards.

Edit: I notice when I play the files in Foobar the volume suddenly jumps up to normal after a few seconds indicating that it probably can't see any more HDCD info after a second or so.

I believe that what you are experiencing is something that I described here. The problem is that because the beginning of the track is silence (or nearly so), LossyWAV is not removing any bits, so the HDCD signal is available. Once the music starts, bits are removed and the HDCD signal is lost and the decoder switches off the HDCD decoding. There might be very quiet passages later that might re-activate it. I have seen this with WavPack lossy encoding and real hardware HDCD decoders (but I think the foobar decoder will not do that).

The solution is not obvious. One might be that LossyWAV could have an option to destroy the HDCD signal if it is detected during a passage with no removed bits (just flipping one bit in the trigger sequence would do it, and there are only 10 per second, IIRC). Or someone could create a stand-alone program to destroy it for whole tracks before processing.

On the decoder plugin side, it might make sense to have the processor make a decision about the HDCD status of a track at the beginning and not allow it to change, but that's not ideal either (but would at least prevent switching off in the middle).

edit: spelling

lossyWAV 1.3.0 Development Thread

Reply #273 –
Maybe what it should do is detect the hdcd header and tell the user that the file has to be decoded by an hdcd bitstream first before feeding it to lossywav.

Then, a command line option could be added to skip this error and forcefully destroy the hdcd bitstream.

Not sure how much time this is worth.

lossyWAV 1.3.0 Development Thread

Reply #274 –
.... or when transcoding using foobar2000, the HDCD decoder plugin should be active when there is a chance of HDCD content being involved. I believe that it is the user's responsibility to ensure that the bitstream going into lossyWAV, or any codec / dsp for that matter, is going to be interpreted correctly.

I had a look at taking notice of HDCD content some time ago but it depends on calls to a Microsoft API and is therefore platform dependent (and also closed source on the part of the HDCD decoder....). Therefore I abandoned it.
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)