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.1.0 Development Thread. (Read 195836 times) previous topic - next topic
0 Members and 5 Guests are viewing this topic.

lossyWAV 1.1.0 Development Thread.

Reply #125
see my edited post above (I can't keep up!)
-l, --limit <n> it is then. And I'll add something akin to your added text to the --longhelp.

lossyWAV 1.1.0 Development Thread.

Reply #126
It would be necessary to add an lowpass limit for portable preset.

So you want the --portable quality to be equivalent to what is now -q 2.5 --lowpass 17000?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #127
lossyWAV beta 1.0.1j attached to post #1 in this thread.

lossyWAV 1.1.0 Development Thread.

Reply #128

It would be necessary to add an lowpass limit for portable preset.

So you want the --portable quality to be equivalent to what is now -q 2.5 --lowpass 17000?
Maybe. We have to vote for the number of a limit. I think the preset not simply sets the quality, but makes fine-tuning too.
Wavpack -hh or TAK -pMax
OggVorbis aoTuVb6.03 -q 4

lossyWAV 1.1.0 Development Thread.

Reply #129
... I think the preset not simply sets the quality, but makes fine-tuning too.

I think fine-tuning should be applied to the still available -q quality levels.
So if a --limit aka former --lowpass value of say 17000 is considered useful for -portable, we should use it not primarily with -portable but with -q 2.5 (and probably for every -q value or perhaps for every -q setting below a certain -q value).
Because of the mapping of -portable to -q 2.5 fine tuning is automatically applied to -portable this way.

As you suggested to use an explicit  --limit aka former --lowpass value with -portable, it would be nice to hear your suggestion.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #130
I checked it now, it seems that about what I would have liked to talk was repaired already, so void. Sorry.
Wavpack -hh or TAK -pMax
OggVorbis aoTuVb6.03 -q 4

lossyWAV 1.1.0 Development Thread.

Reply #131
You could tie the default -limit value into the -q scale, but people might want to change it far more dramatically because they can't hear above a certain frequency (so no point keeping it noise free) or because they can hear above a certain frequency.

In the latter case, it's really unlikely they can hear lossyWAV noise up there. The threshold of hearing slopes upwards quite steeply up there (though it's age dependent) and masking spreads upwards too - both act to make low level high frequency noise inaudible, even if there's nothing up there to hide it.

So whatever the q scale, 14-18k ish is about right - it would be mad to make it change further automatically.

Cheers,
David.

lossyWAV 1.1.0 Development Thread.

Reply #132
Here it is a test for those that like to call -q 0 "ugly" "horrible" and the likes.

Here you have a .flac (1' 32'' , a snippet of a song of mine, so no problems with copyrighs), which encodes to 292kbps (flac -5 -b 512) from 948 (flac -8) and which i haven't been able to ABX at the -q 0 setting.

And yes, i've ABX'd easily the problem sample posted here earlier at this same setting.

http://psycle.free.fr/josepma/gameplay-snip.flac (10.4MB)


EDIT:

What i want to point out is that while problem samples are problem samples, the route that should *not* be followed is "up the bitrate/constraints until problem samples are ok". This problem sample could actually be pointing to a flaw, rather than a lower limit, and could be as been suggested, that the fluctuation in bits change could be the root of the cause.
Also, looking at the sample itself, it also produces clipped-like samples (reducing that much the precision, that a sinusoidal signal is converted to a straight line), so there is where the eyes should be looking, rather than to up the internal settings.

lossyWAV 1.1.0 Development Thread.

Reply #133
Nick, there's a problem with --insane: it's identical to --extreme.

What do you think about using --shaping for --extreme and --insane, or, more precisely, for a -q setting above a treshold? If you like to listen to the correction file you'll hear the added noise is so much lower and often inaudible when only listening to the noise.
Moreover other than with the low quality settings the bitrate penalty of noise shaping isn't large, especially when keeping away a bit from --shaping 1.0.
My suggestion: For -q >= 6: use --shaping 0.4+(q-value - 6)/10.

@ [JAZ]: You're right: -q 0 usually isn't so bad as it looks like after the discussion of Mardel's problem sample.
But I also think we should start a bit higher for the lowest preset and leave the lower bitrate usage to the older -q scheme.
There may be something specific with Mardel's sample that can be fixed, but among my problem samples there are several ones (with definitely no clipping) that are also easily abxable with -q 0. Though I agree they are problem samples, and most of the time the situation is more favorable with -q 0. So it's ok IMO to have -q 0, but for a robust quality which I guess is asked for by many users of a codec like lossyWAV, -q 0 and also -q 1 are a bit low.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #134
Here it is a test for those that like to call -q 0 "ugly" "horrible" and the likes.

Here you have a .flac (1' 32'' , a snippet of a song of mine, so no problems with copyrighs), which encodes to 292kbps (flac -5 -b 512) from 948 (flac -8) and which i haven't been able to ABX at the -q 0 setting.

And yes, i've ABX'd easily the problem sample posted here earlier at this same setting.

http://psycle.free.fr/josepma/gameplay-snip.flac (10.4MB)

EDIT:

What i want to point out is that while problem samples are problem samples, the route that should *not* be followed is "up the bitrate/constraints until problem samples are ok". This problem sample could actually be pointing to a flaw, rather than a lower limit, and could be as been suggested, that the fluctuation in bits change could be the root of the cause.
Also, looking at the sample itself, it also produces clipped-like samples (reducing that much the precision, that a sinusoidal signal is converted to a straight line), so there is where the eyes should be looking, rather than to up the internal settings.
You're right, of course - I'm falling into the same trap as before when I kept trying to make -3 transparent.... I'll have another look at the mechanics and see if anything springs to mind regarding this issue.

Nick, there's a problem with --insane: it's identical to --extreme.

What do you think about using --shaping for --extreme and --insane, or, more precisely, for a -q setting above a treshold? If you like to listen to the correction file you'll hear the added noise is so much lower and often inaudible when only listening to the noise.
Moreover other than with the low quality settings the bitrate penalty of noise shaping isn't large, especially when keeping away a bit from --shaping 1.0.
My suggestion: For -q >= 6: use --shaping 0.4+(q-value - 6)/10.
Mea culpa - I copied the parameter code from --extreme to --insane and forgot to change the 7.5 to 10.0.

I like the idea of some quality related shaping. Say:

quality_shaping_factor : array[0..quality_presets] = (0,0,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1.0);

as an example?

I'll carry out some comparisons and post the bitrates....

[edit] I immediately thought back to when I was using:

maximum_bits_to_remove:=(bitspersample - minimum_bits_to_keep -1);

and realised that this static method was removed when the dynamic maximum_bits_to_remove was introduced, i.e.:

maximum_bits_to_remove_channel[channel]:=(log2(max(1,RMS of all samples in channel))-quality_minimum_bits-to_keep);

I've reinstated the static method in series with the dynamic method and it stops the 11 bits removed for Mardel's sample.... [/edit]

lossyWAV 1.1.0 Development Thread.

Reply #135
...
quality_shaping_factor : array[0..quality_presets] = (0,0,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1.0);
...

When playing around with shaping my personal conclusion was: do it only with high quality settings as otherwise the bitrate increase is too severe. I'm also a bit afraid that with moderate quality settings and a very moderate noise shift unmasked hiss may concentrate in the 6...11 kHz zone where our ears are still pretty sensitive to hiss.
I'd welcome to do it only from a certain -q setting above like from -q 6.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #136
I'm also a bit afraid that with moderate quality settings and a very moderate noise shift unmasked hiss may concentrate in the 6...11 kHz zone

That's odd because the filter (at least at 1.0) doesn't amplify anything below 13 kHz. 11 kHz is still rejected by about 5 dB.

In other news, I've finished implementing & testing new filter code for adaptive noise shaping. This could be one building block for improving lossyWAV or WavPack's lossy-only mode. (Note: It doesn't include a psychoacoustic model. This would be another building block.)

Cheers,
SG

lossyWAV 1.1.0 Development Thread.

Reply #137
...
quality_shaping_factor : array[0..quality_presets] = (0,0,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1.0);
...
When playing around with shaping my personal conclusion was: do it only with high quality settings as otherwise the bitrate increase is too severe. I'm also a bit afraid that with moderate quality settings and a very moderate noise shift unmasked hiss may concentrate in the 6...11 kHz zone where our ears are still pretty sensitive to hiss.
I'd welcome to do it only from a certain -q setting above like from -q 6.
From my discussion with SG, it would seem that the effect moves the noise to the same frequency range no matter how big the factor is (0 to 1, obviously none for 0.0 ). Think of the factor a bit like the interpolation factor between in this case pure white noise and shaped noise. 0.5 would then be 50% of each....

I'm also a bit afraid that with moderate quality settings and a very moderate noise shift unmasked hiss may concentrate in the 6...11 kHz zone

That's odd because the filter (at least at 1.0) doesn't amplify anything below 13 kHz. 11 kHz is still rejected by about 5 dB.

In other news, I've finished implementing & testing new filter code for adaptive noise shaping. This could be one building block for improving lossyWAV or WavPack's lossy-only mode. (Note: It doesn't include a psychoacoustic model. This would be another building block.)

Cheers,
SG
Excellent news SG!

[edit] I processed my (now) 55 problem sample set (Mardel's sample and udial added) and the results are as follows:
Code: [Select]
|-------------|-------------|-------------|-------------|-------------|-------------|
|  -s factor  |    -q 0     | --portable  | --standard  | --extreme   |  --insane   |
|-------------|-------------|-------------|-------------|-------------|-------------|
|     0.00    |312.11 kbit/s|406.03 kbit/s|485.17 kbit/s|565.05 kbit/s|640.03 kbit/s|
|-------------|-------------|-------------|-------------|-------------|-------------|
|     0.25    |322.66 kbit/s|410.41 kbit/s|487.22 kbit/s|565.80 kbit/s|640.24 kbit/s|
|-------------|-------------|-------------|-------------|-------------|-------------|
|     0.50    |338.95 kbit/s|418.19 kbit/s|491.29 kbit/s|567.58 kbit/s|640.81 kbit/s|
|-------------|-------------|-------------|-------------|-------------|-------------|
|     0.75    |354.77 kbit/s|429.28 kbit/s|498.20 kbit/s|571.04 kbit/s|642.13 kbit/s|
|-------------|-------------|-------------|-------------|-------------|-------------|
|     1.00    |374.46 kbit/s|444.93 kbit/s|508.96 kbit/s|577.15 kbit/s|644.75 kbit/s|
|-------------|-------------|-------------|-------------|-------------|-------------|
Based on these results I would like to propose that shaping_factor:= quality_level/10 for 1.0.1k for testing (will be able to be overridden with -s 0 or --shaping 0).

lossyWAV 1.1.0 Development Thread.

Reply #138
I'm also a bit afraid that with moderate quality settings and a very moderate noise shift unmasked hiss may concentrate in the 6...11 kHz zone
That's odd because the filter (at least at 1.0) doesn't amplify anything below 13 kHz. 11 kHz is still rejected by about 5 dB.
Thanks for your correction. So there's nothing to fear. clarification.
Oh, I've overseen your '(at least at 1.0)'. That's what I'm a bit afraid of: the lower --shaping factors.

... Think of the factor a bit like the interpolation factor between in this case pure white noise and shaped noise. 0.5 would then be 50% of each....
If this is really so there's nothing to fear.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #139
How about some preset for -q 0, such as "MP3 replacement"?

lossyWAV 1.1.0 Development Thread.

Reply #140
lossyWAV beta 1.0.1k attached to post #1 in this thread.

lossyWAV 1.1.0 Development Thread.

Reply #141
How about some preset for -q 0, such as "MP3 replacement"?

mp3 replacement may be the motivation for the one or other user but it's a very personal decision to prefer lossyWAV -q 0 over, say, Lame 3.98b8 --abr 280. Not everybody would agree with such a preference.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #142
Oh, I've overseen your '(at least at 1.0)'. That's what I'm a bit afraid of: the lower --shaping factors.


Here's what happens at --shaping 1.0


This is the filter at --shaping 0.6


At 0.0 it'll be a flat line (0 dB). So, it's like what Nick said + some smoothing.

HTH,
SG

lossyWAV 1.1.0 Development Thread.

Reply #143
Not everybody would agree with such a preference.

Ok. Newer mind  I meant that once there is a preset for -q 2.5/5/7.5/10, it is logical that also should be a preset for -q 0.

p.S. sbmewb.

lossyWAV 1.1.0 Development Thread.

Reply #144
... Here's what happens at --shaping 1.0 ...
... This is the filter at --shaping 0.6 ....
So, it's like what Nick said ...

OK, thank you. So we should only expect a quality increase from noise shaping.
Nick's kind of doing it brings up bitrate only to a small degree, so this is expected to be another progress.

... I meant that once there is a preset for -q 2.5/5/7.5/10, it is logical that also should be a preset for -q 0. ...

I only adressed the name 'mp3 replacement' which IMO isn't a lucky choice. As we have 2 settings above standard there is some logic in having two settings below it.

What is the general opinion towards this?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.1.0 Development Thread.

Reply #145

... I meant that once there is a preset for -q 2.5/5/7.5/10, it is logical that also should be a preset for -q 0. ...

I only adressed the name 'mp3 replacement' which IMO isn't a lucky choice. As we have 2 settings above standard there is some logic in having two settings below it.

What is the general opinion towards this?

I've lost touch a little. Am I right in thinking:
10 is pretty much the old -1
7.5 is pretty much the old -2
5 is pretty much the old -3

and 2.5 is a new setting that is lower than any setting since LossyWAV moved away from the olden days when life was simple?

If that's approximately the case, I wouldn't go any lower than 2.5, especially since transparency is pretty much guaranteed with MP3 at lower bitrates, why would you choose a "mp3 replacement" (or whatever term you like) when LossyWAV, at sub 2.5 bitrates, is not as safe as MP3? Surely, no one is going to use much less than level 2 as a transcode setting either; as I would have thought you want to guarantee transparency for your transcode source.

But then I don't understand the LossyWAV as DAP audio file. MP3 et al are too competitive aren't they?

EDIT: Though I guess for the sake of symmetry a setting between 2.5 and 5 would work.

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

lossyWAV 1.1.0 Development Thread.

Reply #146
Your are kind off right. I still think lossywav can take on and beat Lame 320k at similar bitrates simply due to the mp3 native defect.

lossyWAV 1.1.0 Development Thread.

Reply #147
Quote
Joint frequency encoding

Joint frequency encoding is an encoding technique used in audio data compression to reduce the data rate.

The idea is to merge a given frequency range of multiple sound channels together so that the resulting encoding will preserve the sound information of that range not as a bundle of separate channels but as one homogenous data stream. This will naturally destroy the original channel separation for good, as the information cannot be accurately reconstructed, but this process will greatly lessen the amount of required storage space. It should be noted that only some forms of joint stereo use the joint frequency encoding technique, such as intensity stereo coding.

lossyWAV 1.1.0 Development Thread.

Reply #148
Quote
Joint frequency encodingJoint frequency encoding is an encoding technique used in audio data compression to reduce the data rate.

The idea is to merge a given frequency range of multiple sound channels together so that the resulting encoding will preserve the sound information of that range not as a bundle of separate channels but as one homogenous data stream. This will naturally destroy the original channel separation for good, as the information cannot be accurately reconstructed, but this process will greatly lessen the amount of required storage space. It should be noted that only some forms of joint stereo use the joint frequency encoding technique, such as intensity stereo coding.
Does not happen in the lossless codecs that lossyWAV is aimed at therefore it makes no sense to use it in lossyWAV. All lossyWAV does is round lower significant bits to zero (now with added noise shaping).

lossyWAV 1.1.0 Development Thread.

Reply #149
Your are kind off right. I still think lossywav can take on and beat Lame 320k at similar bitrates simply due to the mp3 native defect.

In bitrate/quality perhaps, but not in filesize. Average filesize of my testset Q1 lossyflacs is almost twice the size of my mp3 V1, let alone V4. DAP users won't like that.