so if we mix, first we have something like this :

-q 00.0 = -nasty
-q 02.5 = -portable
-q 05.0 = -archive or -default
-q 07.5 = -overkill
-q 10.0 = -paranoid

it's not my ideal, but as I am not alone to use the codec ... it's better than nothing & I can live with it
& now if we kill -nasty & -paranoid, but agree that -paranoid is a better word than -overkill, we have.

-q 02.5 = -portable
-q 05.0 = -archive or -default
-q 07.5 = -paranoid

I like it like this.

Edit:
As -portable & -archive describe the use rather than the quality (unlike -nasty, -overkill & -paranoid)
maybe it would be better to use 3 words that all describe the final use, so:

-q 02.5 = -portable
-q 05.0 = -archive or -default
-q 07.5 = -transcoding

is possible too & even more self-speaking for noobs.

That's how I do it for the moment. My batchfile exists of three settings to test. Q9 for near-lossless archives, Q6 for playable flac images and Q3 for DAP. I mentioned earlier that imho the eleven step scale is too wide. Let alone the numerous steps in between. 5.5678 or 0.1234 To hear the differences quickly I take these bigger steps.
There's also the various combo's in shaping, detail, lowpass. A half-deaf noob would be going mad.

For -paranoid (or -riskless) I use flac. And yes, maybe shaping and such should be an embedded part of the presets. so an inexperienced user won't have to bother about these settings. Like -e -r -b 4096 in flac; just -best or -fast.

Combining some previous suggestions posted here, these are the presets I'd like to see:


Of course, the presets would be mutually-exclusive with the "--q" advanced setting.

I wonder if -archive is a good term afterall as it really depends on what people intend to do with their "archive", personnaly I would keep -archive out of the game & keep it for lossless. Some people use lossy for archive because it's transparent to them, some people use lossless for archive as it is perfection to them. There is no consensus on it. So, I slowly tend toward:

-q 2.5 = -portable
-q 5.0 = -default
-q 7.5 = -transcoding

you could as well use -q 5 or -q7.5 for archival purpose as there is no evidence that transcoding -q 7.5 to lossy for DAP would be more transparent than transcoding -q 5.0 to lossy for DAP even if -q 7.5 is less agressive on paper.

So the main problem is whether the naming should address the application (like 'portable', 'archive', 'transcoding') or the quality.

Targeting at the application has its problems as we see in the discussion. I for instance wouldn't like -q 5 to be associated with archiving (archiving in the sense of a substitute for a lossless archive). I also don't like a specific 'transcoding' quality as I'd expect even from -q 2.5 that it should be transcodable to, say mp3, without really sacrifying quality.
These things are all a matter of taste and personal context, and as we see, an application oriented naming scheme leads to these subjective ambiguities.

So I think we're better off with the quality targeting approach, but here it's harder to find names.
My suggestion in clear but rather bad sounding words:

-goodEnough (for -q 2.5)
-transparent (for -q 5)
-safetyMargin (for -q 7.5)

or in short word form:

-fine (for -q 2.5)
-transparent (for -q 5)
-overkill (for -q 7.5)

with 'overkill' back as a rough equivalent to 'safetyMargin'. The added emotionality of 'overkill' isn't bad in this context IMO. It conflicts less with 'transparent' than a 'safetyMargin'. With this quality scale I wouldn't mind using 'overkill' though 'overkill' for -q 7.5 has the disadvantage that -q 5 already is expected to be overkill for most of us.

IMO this describes well what the quality settings are about.

Sure -transparent is a claim (after all we're in a world of lossy codecs), but IMO not a bad one. In case -transparent should be found not to be transparent on a sample it is a challenge to change the -transparent internals in order to reestablish transparency.

I think:

-medium (2.5)
-normal (5)
-insanity / crazy (7+)


This way things are simple and we are down to 3 real world scenarios - modest needs, normal or don't want to be bothered knowing.. then Q5 caters for the clueless while keeping true to the goals of lossywav real transparent sound at a much reduced bitrate compared to lossless. 'Insanity' gives a real hint to people that we are in overkill bitwaste territory but nonetheless it is there as an 'end to all' setting and can be considered a true replacement for lossless coding. -Medium attempts to compromise between quality and size while protectign the user from unfavourable situation where noise will be audiable and annoying - in other words -medium is probably enough for 98 % + cases but we don't want to risk ugly situations by going too low like Q0.




I like it . Its quite clean and concise.

What happened to this thread?

Can I "me too" give my opinion

-low = -q 1
-medium = -q 2.5
-normal = -q 5 (default)
-high = -q 7.5
-insane = -q 10

OK?
The doc should not give any quality expectation for the different -q values, instead the documentation of presets should tell the corresponding -q option.

It really seems to be boiling back down to an equivalent of -1, -2 and -3 per the original development....

How about:

-P, --portable = -q 2.5;
-N, --normal = -q 5.0 (default);
-E, --excessive = -q 7.5?

you could as well still use word describing targeted use & include quality expectation as a clue in the help:

-q 2.5 = -portable (good enough)
-q 5.0 = -default (transparent)
-q 7.5 = -transcoding (safety margin)

quote jido:
-low = -q 1

... ??? sorry but it starts at -q 0, you'd rather not give your opinion if you don't use the codec unless it's a typo indeed just teasing I already made the same typo

lossyWAV beta 1.0.1i attached to post #1 in this thread.

Probably too late, but

medium/portable
standard
extreme
insane

has a good tradition on these boards!

Cheers,
David.

Never too late for you, Sir! Give me 5 mins....

No Nick - calm down!

I wasn't demanding all of these - just suggesting "standard" as a posh way of saying "normal" - it sounds fractionally grander.

I like "transcoding" anyway - it makes sense. When I get chance, I'm going to run some transcoding tests on lossyWAV and see which values are really worth it - so far, we're just guessing!

Given my usual speed of getting around to things, if anyone else wants to try, please jump in!

Cheers,
David.

insane being 100% lossless would be a statement. :-)

Cheers,
SG

I'd like to see another option name changed: --lowpass.
With --lowpass everybody not intimate to the lossyWAV details has the impression that the signal is lowpassed whereas it's lossyWAV's major advantage that there's nothing in the signal path changed at all - for the sake of significantly reducing the bitrate just a little bit of quantization noise is added and controlled so that it's inaudible in the sense the quality settings tell.

The --lowpass parameter addresses the frequency limits of the FFT analyses, so a name like --FFTlimit is more appropriate.

LOL! I don't think anyone who suggested that could take the flames...

Cheers,
David.

I feel like this as well, and I really like your naming schemes 'medium'/'standard'/'extreme'.

I would prefer --hflimit or --upperlimit or something like that - --FFTlimit is a bit ambiguous....

I agree. I'd suggest "analysislimit" but it's longer to type!

Did you leave "lower limit" internally within the code, or is it gone? Not that I need it - just curious.

EDIT:

Maybe just -limit with the explanation "frequencies higher than this are not analysed"

... and maybe extended help "lossyWAV adds white noise based on analysis of the signals _below_ this frequency; if signals above this frequency are at an even lower level, they they can be swamped by the added noise. This is usually inaudible, but the behaviour can be changed by specifying a higher -limit. For many audio signals, there is little content at very high frequencies, and forcing lossyWAV to keep the noise lower than the content at these frequencies can increase the bitrate dramatically"

or something!

Cheers,
David.

<deep breath>
Agreed.
Does --transcoding not imply some sort of internal transcoding process rather than the-output-is-considered-to-be-good-enough-for-transcoding?

So, in the spirit of keeping to tradition :

--insane = -q 10;
--extreme = -q 7.5;
--standard = -q 5.0;
--portable = -q 2.5.

-A, --analysislimit or -U, --upperlimit?

It's gone - I could relatively easily re-instate it (20<=n<=1378.125) --lowerlimit.

I would avoid a word that can be associated as a synonym for 'lowpass'.
My first thought was 'analysislimit' like 2Bdecided suggested, but for the sake of shortness I changed it to FFTlimit. 'analysislimit' is more precise of course, so why not use it.

see my edited post above (I can't keep up!)

I like it - though I'd prefer 'medium' as all the other names refer to quality and not application. But it's not really important.



--limit is ok IMO though --analysislimit is clearer.

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

-l, --limit <n> it is then. And I'll add something akin to your added text to the --longhelp.

So you want the --portable quality to be equivalent to what is now -q 2.5 --lowpass 17000?

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

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.

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.

I checked it now, it seems that about what I would have liked to talk was repaired already, so void. Sorry.

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.

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.

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.

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.

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]

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.

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

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....

Excellent news SG!

[edit] I processed my (now) 55 problem sample set (Mardel's sample and udial added) and the results are as follows: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).

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.


If this is really so there's nothing to fear.

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

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

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.

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

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.

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 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.

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.

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).

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.