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:
lame --nohist --noreplaygain --preset cbr 80 mono.wav mono.mp3
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
lame --nohist --noreplaygain --preset cbr 160 stereo.wav stereo.mp3
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
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.
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.
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.
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 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 (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html) and here (http://lame.cvs.sourceforge.net/viewvc/lame/lame/libmp3lame/lame.c?view=log) 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.
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?
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.
Ha, nice work!
Patch in case anyone is curious:
http://sourceforge.net/mailarchive/forum.p...m_name=lame-dev (http://sourceforge.net/mailarchive/forum.php?thread_name=4F591289.4090606%40gmail.com&forum_name=lame-dev)
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.
What lowpass do you get for a 320 kbps mono file?
I was expecting that one
The default lowpass for a mono track above 160kbps is 20KHz, as expected.
Same for stereo freeformat above 320kbps.
This patch was never applied right? As far as I can see the bug is still there.