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: lame 3.96.1 and -q0 (Read 8753 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame 3.96.1 and -q0

Hi All

First post so forgive me if it's too noobie. I've frequented these forums for the past few months ever since I started using Lame to encode my music to my Irivier. At the time I read the recommended version and setting thread and decided on 3.96.1 due to speed reasons. I also chose to use -v0 and -q0 (preset extreme) settings just to be safe. After some extensive form reading I've found that -q0 pushes down the mask threshold (or some other technical term) too far on 3.96.1 and shouldn't be used (although, even after searching the forum I still can't find out exactly what this does to the quality). So two questions 1) Is this really audible at such extreme quality settings? and 2) Why on earth is there no warning about this on the recommended compile thread (or at least a fix)?

Thanks in advance

lame 3.96.1 and -q0

Reply #1 –
A bug was found and fixed in the lame 3.97 alphas with q 0 and q 1 switches. it affected (at least) versions up to 3.96.  (in gabriel's words.  Don't ask me what the bug itself did, but some people heard the difference, IIRC)

lame 3.96.1 and -q0

Reply #2 –
Severe background ringing is audible with -q0 switch and 3.96.1. It's audible with specific samples (the one I uploaded is not online anymore).
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

lame 3.96.1 and -q0

Reply #3 –
Try this sample with --preset 128 and --preset 128 -q0 (3.96.1); the -q0 one very distorted to my ears.
Less distorted but still anoying:
http://guruboolez.free.fr/ENSEMBLE/E07_MOD...G_windoctet.ofr
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

lame 3.96.1 and -q0

Reply #4 –
I believe -q0 in 3.96 drove the psymodel masking thresholds way down -- so much that quantization artifacts became apparent because few frames could actually stay below masking thresholds the way they were set. I'm guessing here, but it was probably a bug in the preset code that adjusts the thresholds, because the four floating point numbers passed to LAME API are actually all stored as 4-bit numbers in the same integer, so the set/get code uses bit shifts to change/retrieve these (I wonder why Naoki did it that way originally?).

Per Takehiro, ATH code for short blocks was broken as well.

lame 3.96.1 and -q0

Reply #5 –
Thanks for the quick replies. I'll test out those samples shortly. Still there should at least be a warning on the recomended compiles thread.

lame 3.96.1 and -q0

Reply #6 –
Quote
I'm guessing here

Right, this is plain guess here....

There was a specific code that was enabled at -q0, and I only found it during the 3.97 alpha stage, searching for a strange behavior of -q0.

lame 3.96.1 and -q0

Reply #7 –
Quote
Quote
I'm guessing here

Right, this is plain guess here....

There was a specific code that was enabled at -q0, and I only found it during the 3.97 alpha stage, searching for a strange behavior of -q0.
[a href="index.php?act=findpost&pid=316962"][{POST_SNAPBACK}][/a]


Gabriel! I would be thankful if you clear a confusion that is running in my mind since i started using lame.

In lame 3.96.1 q switches were affected, which were solved in lame alphas.
so now, will decreasing q (from 3->0) value increase efficient coding from now on?
will it affect quality? (i don't mind if there is no perceivable difference below -q3 but i want to know that at least it doesn't decrese)

and ESPECIALLY -h SWITCH
will it be bound to -q3 or -q2?
and if -q2, will -q3 still remain default for presets(or rather -V0 to -V3)?

and is it still preferable to use -h over default (-q3)?

Thanks in advance

lame 3.96.1 and -q0

Reply #8 –
I think that you can now safely change the q value to a lower one.
Not sure if it is really worth it, however.

lame 3.96.1 and -q0

Reply #9 –
Quote
Quote
I'm guessing here

Right, this is plain guess here....

There was a specific code that was enabled at -q0, and I only found it during the 3.97 alpha stage, searching for a strange behavior of -q0.
[a href="index.php?act=findpost&pid=316962"][{POST_SNAPBACK}][/a]

You mean best_huffman_divide() in the inner loop? But it can't make things worse, can it -- only slower? -- From what I understood, best_huffman_divide() and best_scalefac_store() aren't supposed to introduce any additional noise to the quantization, just cut the number of bits -- and I verified that calling calc_noise() on a granule before and after best_huffman_divide() produces identical results... (This was not the case for best_scalefac_store(), but I'm assuming calc_noise() doesn't take scalefac compression into account.)

Or was it something else?

lame 3.96.1 and -q0

Reply #10 –
@Pa3PyX
No, it was something different, it was patch 1.120 of quantize_qvt.c Gaby was talking about.

lame 3.96.1 and -q0

Reply #11 –
Quote
@Pa3PyX
No, it was something different, it was patch 1.120 of quantize_qvt.c Gaby was talking about.
[a href="index.php?act=findpost&pid=317038"][{POST_SNAPBACK}][/a]

Ah.

So basically masking thresholds for short blocks were off by 30 dB. And I recall that the presets for -q0 themselves were crazy too -- like -36 dB bass, -30 dB alto, -30 dB treble -- or were they just printed that way? [Edit: In fact, this must be why they were printed that way.]

But I can see how this would screw things up -- by default (ns-bass=ns-alto=ns-treble=0), short block maskings are off (relative to long blocks), but not by 30 dB (in reality, approximately by 4.5-6 dB in bass, about the same in alto, and approximately by 1-1.5 dB in treble). So looks like someone had the right idea, but they went for an overkill...