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 lowpass: stereo vs. mono (Read 7185 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME lowpass: stereo vs. mono

I am encoding a mono file to mp3 with Lame and a bitrate of 80, and a stereo file with a bitrate of 160.
Since the bitrate per channel is the same in both cases, I'm curious why is the lowpass different?

Here are the command lines I use and the output I get:

Code: [Select]
lame --nohist --noreplaygain --preset cbr 80 mono.wav mono.mp3

Code: [Select]
LAME 3.98.4 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz
Encoding mono.wav to mono.mp3
Encoding as 44.1 kHz single-ch MPEG-1 Layer III (8.8x)  80 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  2298/2298  (100%)|    0:00/    0:00|    0:00/    0:00|   88.279x|    0:00
Writing LAME Tag...done


Code: [Select]
lame --nohist --noreplaygain --preset cbr 160 stereo.wav stereo.mp3

Code: [Select]
LAME 3.98.4 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 17249 Hz - 17782 Hz
Encoding stereo.wav to stereo.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (8.8x) 160 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  2298/2298  (100%)|    0:01/    0:01|    0:01/    0:01|   35.732x|    0:00
Writing LAME Tag...done


I get the same lowpass difference using different settings (forcing dual mono mode, using cbr without the preset switch, etc.).

Thanks

LAME lowpass: stereo vs. mono

Reply #1
That's certainly an error. With stereo files such a high lowpass is avoided even with CBR 256, and for stereo files lowpass frequency should be increased rather than decreased compared to the half bitrate mono setting because of the possibilities of joint stereo.
lame3995o -Q1.7 --lowpass 17


LAME lowpass: stereo vs. mono

Reply #3
I guess the whole CBR/ABR section of Lame can benefit form tidying it up a bit, and AFAIK robert is planning or already doing it.
lame3995o -Q1.7 --lowpass 17

LAME lowpass: stereo vs. mono

Reply #4
I agree with you, that is why I am posting this here, hoping a lame dev will either enlighten me or confirm this is a bug.


You are using a 2-year old version. Do not expect any feedback from developers who mostly care about 3.99.5 these days. Even though the bug is likely not fixed in the recent version, you need to show some respect to their efforts over past 2 years.

LAME lowpass: stereo vs. mono

Reply #5
I agree with you, that is why I am posting this here, hoping a lame dev will either enlighten me or confirm this is a bug.


You are using a 2-year old version. Do not expect any feedback from developers who mostly care about 3.99.5 these days. Even though the bug is likely not fixed in the recent version, you need to show some respect to their efforts over past 2 years.

I'm using the stable version that is in the official packages of my Linux distribution.
I checked here and here before posting this, to see if there was some changes in that area in the late versions.

But you are right, I should have double checked by running the latest version.
I manually compiled one and I get the same exact behaviour.

So I compiled another one with debug symbols, and by debugging the lame executable when encoding a mono file, I found where the bug is located.

The problem is fairly trivial, so I wrote a patch to fix it and sent it to the Lame dev mailing list, where it is currently waiting for review and approval.

LAME lowpass: stereo vs. mono

Reply #6
But you are right, I should have double checked by running the latest version.
I manually compiled one and I get the same exact behaviour.

So I compiled another one with debug symbols, and by debugging the lame executable when encoding a mono file, I found where the bug is located.

The problem is fairly trivial, so I wrote a patch to fix it and sent it to the Lame dev mailing list, where it is currently waiting for review and approval.


That's proactive! You patch essentially moves multiplification from one place to another and changes the factor from 1.5 to 2.
I'm guessing that a one-liner 1.5 -> 2.0. was not sufficient. Right?


LAME lowpass: stereo vs. mono

Reply #8
You patch essentially moves multiplification from one place to another and changes the factor from 1.5 to 2.

Nope, that is not what it does.

The original code was:
- calculating the optimal lowpass for the bitrate ignoring the number of channel, so for a 80kbps mono track, the lowpass would be 13.5KHz
- multiplying that lowpass by 1.5 if the track is mono, that gave us our incorrect 20KHz lowpass

With my patch, the initial lowpass calculation is done by taking into account the number of channels, so if the track is mono with a bitrate of 80, it chooses the index in the freq_map array as if the track was 160 stereo, in this case it is a 17.5KHz lowpass.
With that change a 80kbps mono encoding has the same lowpass as a 160kbps stereo one.

LAME lowpass: stereo vs. mono

Reply #9
What lowpass do you get for a 320 kbps mono file?

LAME lowpass: stereo vs. mono

Reply #10
I was expecting that one

The default lowpass for a mono track above 160kbps is 20KHz, as expected.
Same for stereo freeformat above 320kbps.

 

Re: LAME lowpass: stereo vs. mono

Reply #11
This patch was never applied right? As far as I can see the bug is still there.