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 fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0) (Read 8976 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #25 –
Can you elaborate a bit on "Not working: CBR -q > 3"? Starting with q4, LAME by default disables the noise shaping amplification, so there's nothing to fix there.

The noise_shaping_stop appears to be completely unused in LAME, at least I couldn't find a single place where the value would be used. I think that's a variable that could just be deleted entirely.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #26 –
Creates 0 byte output file :

G:\>lame-cbr -q2 ravel.wav
LAME 3.101 (beta 3, Jun 24 2024) 64bits (https://lame.sourceforge.io)
CPU features: SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding Ravel.wav to Ravel.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
     0/952    ( 0%)|    0:00/    0:00|    0:00/    0:00|   0.0000x|    0:00
00:24--------------------------------------------------------------------------
   kbps      %     %
    0.0

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #27 –
Hmmm... 0 bytes doesn't sound right, but at least the compression ratio is stellar.

For me, john's compile seems to work quite right (on Linux, with Wine):

Code: [Select]
wine lame.exe -q2 rave.wav 
LAME 3.101 (beta 3, Jun 24 2024) 64bits (https://lame.sourceforge.io)
CPU features: SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding rave.wav to rave.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
  1043/1043  (100%)|    0:00/    0:00|    0:00/    0:00|   64.108x|    0:00
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  128.0        0.5  99.5        87.6   7.2   5.2
Writing LAME Tag...done
ReplayGain: -7.6dB

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #28 –
Also seems to be fine here:
Code: [Select]
Microsoft Windows [Version 10.0.22631.3737]
(c) Microsoft Corporation. All rights reserved.

F:\Testdir>lame -q 2 01.wav
LAME 3.101 (beta 3, Jun 24 2024) 64bits (https://lame.sourceforge.io)
CPU features: SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding 01.wav to 01.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=2
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  9211/9211  (100%)|    0:03/    0:03|    0:03/    0:03|   67.912x|    0:00
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  128.0       42.3  57.7        92.5   4.3   3.2
Writing LAME Tag...done
ReplayGain: -1.4dB

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #29 –
Quote from: maikmerten on
Another weird thing I noticed: With VBR, q0, q1, q2, q3 and q4 appear to be the same speed. That's not quite what I expected.

In VBR, the encoder does not do the same steps than with CBR, and it is documented that q 0 to q 4 generate the same output.  Possibly, enabling --vbr-old might have a different effect on the -q setting.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #30 –
I reinstalled lame from source using maikmerten's modifications to cfg->noise_shaping_amp and cfg->noise_shaping_stop and the difference is huge, here's the same sample encoded with the same settings after the patch so you can compare to the original qval0. I can get the most out of the MP3 format now. With qval 0 fixed, I think these are the best settings to get the best quality possible output file.

Code: [Select]
lame -b320 --cbr -m s -q 0 --resample 44.1 input.wav output.mp3
If the source is mono, -m s must be ommited.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #31 –
Even though LAME resampler is not bad, the "best quality possible" would also mean using the best resampler possible, so the use of the LAME resampler sort of contradicts the premise.

Also, it is not proven that simple stereo is needed to have higher quality. LAME joint stereo (automatic switch of joint and simple) has always been one of the strong points of LAME.
As such, if you don't show a reason to use -m s in LAME as opposed to it's default mode ( -m j), it won't be considered "best quality possible" either here at hydrogenaudio.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #32 –
The resampler thing is true, one needs to get his source to 44.1kHz before encoding with lame not to use lame's encoder, but on the other hand, I don't know if I just discovered another bug but -m s and using the default joint stereo at 320kbps gives me the exact same result, i imported them to audacity and both have two peaks over 0db at the same exact place and both peak at the same value, then I separated each stereo channel of both modes, and they peak the same, left side of joint stereo peaks at the same value of left side stereo and the same for the right side. But this isn't the case for 128kbps, the red transients look different and the true peak of each file is different, and I repeated the same process to all the bitrates above it, and all get different resultant files except for 320kbps, so is it a hidden setting or a bug?

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #33 –
Looking at peaks is not sufficient to determine the audio is the same. LAME certainly encodes stereo in a different mode when selecting "-m s":

Code: [Select]
lame -b320 --cbr -m s -q 0 --resample 44.1 rave.wav
-------------------------------------------------------------------------------
   kbps        LR  %     long switch short %
  320.0      100.0        86.6   7.8   5.6

Code: [Select]
lame -b320 --cbr -q 0 --resample 44.1 rave.wav rave-j.mp3
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  320.0       75.7  24.3        85.1   8.7   6.1

Specifying "-m s" is very likely not a good idea and might result in worse quality. Let the encoder do the decision. Joint stereo is not detrimental to quality, it's just generally more efficient.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #34 –
@Molledix Just for curiosity: Why you are not using a lower sampling rate?

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #35 –
Quote from: Klymins on
@Molledix Just for curiosity: Why you are not using a lower sampling rate?

How low sample rate would you suggest while still retaining good quality?

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #36 –
Quote from: synclagz on
Quote from: Klymins on
@Molledix Just for curiosity: Why you are not using a lower sampling rate?

How low sample rate would you suggest while still retaining good quality?

I suggest 11025Hz for this bitrate. It can give higher quality even from your perspective, and the bandwidth of this MP3 was already almost equal to 5512.5Hz.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #37 –
Quote from: Klymins on
@Molledix Just for curiosity: Why you are not using a lower sampling rate?
I don't intent to use that low bitrate, I only used it to easily discern the difference between the different qvalues, and the sample rate was just to ensure playback compatibility.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #38 –
Quote from: Klymins on
I suggest 11025Hz for this bitrate. It can give higher quality even from your perspective, and the bandwidth of this MP3 was already almost equal to 5512.5Hz.

I can't tell if this guy is a very good troll or he needs to see a doctor soon.
gold plated toslink fan

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #39 –
Quote from: [JAZ] on
Even though LAME resampler is not bad, the "best quality possible" would also mean using the best resampler possible, so the use of the LAME resampler sort of contradicts the premise.

Also, it is not proven that simple stereo is needed to have higher quality. LAME joint stereo (automatic switch of joint and simple) has always been one of the strong points of LAME.
As such, if you don't show a reason to use -m s in LAME as opposed to it's default mode ( -m j), it won't be considered "best quality possible" either here at hydrogenaudio.
Simple stereo is for more fidelity in the stereo separation, 320kbps with the patched q 0 is enough to keep up with the two separate independent channels without artifacts.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #40 –
Quote from: Molledix on
Quote from: Klymins on
@Molledix Just for curiosity: Why you are not using a lower sampling rate?
I don't intent to use that low bitrate, I only used it to easily discern the difference between the different qvalues, and the sample rate was just to ensure playback compatibility.

Thanks.

Quote from: Markuza97 on
Quote from: Klymins on
I suggest 11025Hz for this bitrate. It can give higher quality even from your perspective, and the bandwidth of this MP3 was already almost equal to 5512.5Hz.

I can't tell if this guy is a very good troll or he needs to see a doctor soon.

Can you compare a 44100Hz 32kbps stereo with an 11025Hz 32kbps stereo? Please be honest: Which one is better?

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #41 –
Quote from: Molledix on
Simple stereo is for more fidelity in the stereo separation, 320kbps with the patched q 0 is enough to keep up with the two separate independent channels without artifacts.
It is not. It has been demonstrated time and again that Simple Stereo is inferior to Joint Stereo. The argument for Simple Stereo is an audiofool myth.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #42 –
Quote from: Klymins link=msg=1047025 Can you compare a 44100Hz 32kbps stereo with an 11025Hz 32kbps stereo? Please be honest: Which one is better? [/quote
etter?

Why you can't /won't use higher bitrate?

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #43 –
Quote from: synclagz on
Quote from: Klymins link=msg=1047025 Can you compare a 44100Hz 32kbps stereo with an 11025Hz 32kbps stereo? Please be honest: Which one is better? [/quote
etter?

Why you can't /won't use higher bitrate?

I'm trying to say that lower sampling rates can be better at lower bitrates, I'm not saying I can't / won't use higher bitrate.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #44 –
Expanding my tinkering to ABR, I think that noise_shaping_amp also can be detrimental to ABR. The difference, IMO, is not as pronounced, though.

Enclosed is another trivial patch, this time covering CBR *and* ABR.

I also attach two test cases:

a) moby-original.wav, moby-abr32-q0-nopatch.wav and moby-abr32-q0-patch.wav

This is output from Google's text-to-speech engine, 24 kHz, mono. This is my original use-case (embedding speech into web pages, with MP3 as "works everywhere" fallback) why I went looking into MP3 encoding again.

Code: [Select]
lame --resample 24000 --lowpass 12000 --abr 32 -q0 moby-original.wav moby-q0.mp3
lame --decode moby-q0.mp3

(This particular section of Moby Dick being presented by Star Trek: First Contact)

b) rave-abr96-q0-nopatch.wav and rave-abr96-q0-patch.wav (OP's original sample)

Code: [Select]
lame --resample 44100 --lowpass 16000 --abr 96 -q 0 rave.wav rave-abr96-q0.mp3
lame --decode rave-abr96-q0.mp3


I'd be very interested to hear if people prefer the "nopatch" or "patch" version.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #46 –
Thanks again, john, for quickly providing an experimental build!

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #47 –
Quote from: john33 on
Quote from: Molledix on
Simple stereo is for more fidelity in the stereo separation, 320kbps with the patched q 0 is enough to keep up with the two separate independent channels without artifacts.
It is not. It has been demonstrated time and again that Simple Stereo is inferior to Joint Stereo. The argument for Simple Stereo is an audiofool myth.
Should I use -m f then?
-m <mode>       (j)oint, (s)imple, (f)orce, (d)ual-mono, (m)ono (l)eft (r)ight
                    default is (j)
                    joint  = Uses the best possible of MS and LR stereo
                    simple = force LR stereo on all frames
                    force  = force MS stereo on all frames.
If MS stereo is always equal or better to stereo, there would be no harm in the resulting quality after encoding using it for the whole song.

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #48 –
Quote from: Molledix on
Should I use -m f then?

No, just leave -m alone. The encoder will automatically choose a stereo encoding mode best suited.

MS-stereo is most efficient *most* of the time, but not *all* of the time. The encoder will compare the cost of MS-stereo *and* LR-stereo, then pick what's most efficient.
 

Re: LAME fastest encoding(-q 9) gives better quality than the slowest encoding(-q 0)

Reply #49 –
So, The patched -q3 with noise amp=0 should be same as -q4 (also noise amp=0) in normal versions if i m correct ?