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: curious about lowpass filters used by LAME (Read 9776 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

curious about lowpass filters used by LAME

I just have a few questions about how LAME works that I was curious about.

In the Hydrogenaudio Wiki here, there's a table showing lowpass filters applicable to various command-line switches.
I'm just curious why it is a frequency band rather than a fixed frequency value. When I think of a lowpass filter, I think of values below a fixed cutoff value being allowed to pass, and values above the fixed cutoff being filtered out. How does it work when the cutoff is a band rather than a fixed value?

And where do these frequency bands come from? I mean, why have these pairs of values in particular been chosen as the endpoints of each range?

Then, I was also wondering about the lowpass filter used by LAME by default. This varies depending on the target bitrate/quality. I had a look at the LAME source code (which is over my head), but in lame.c I found what appears to be a table mapping default lowpass filters to target bitrates:
Code: [Select]
    const band_pass_t freq_map[] = {
        {8, 2000},
        {16, 3700},
        {24, 3900},
        {32, 5500},
        {40, 7000},
        {48, 7500},
        {56, 10000},
        {64, 11000},
        {80, 13500},
        {96, 15100},
        {112, 15600},
        {128, 17000},
        {160, 17500},
        {192, 18600},
        {224, 19400},
        {256, 19700},
        {320, 20500}
    };


Again, I'm just curious how/why these frequencies in particular were chosen for each target bitrate.

Thanks.

curious about lowpass filters used by LAME

Reply #1
I guess these values are based on a trade-off between added noise, artifacts ... and bandwidth.

If you have some easily compressible signal then you should be able to raise the lowpass frequency even at low bitrates.
"I hear it when I see it."

curious about lowpass filters used by LAME

Reply #2
I'm just curious why it is a frequency band rather than a fixed frequency value. When I think of a lowpass filter, I think of values below a fixed cutoff value being allowed to pass, and values above the fixed cutoff being filtered out. How does it work when the cutoff is a band rather than a fixed value?
The 100% perfect cut-off you're imagining implies a filter with a long time-domain response that "rings". If that cut off point is in the audible range (as some of these frequencies are), you can hear the ringing. Literally, it sounds like a bell ringing along with the music at the chosen frequency.

If you soften the filter, so all the sounds below A are preserved, all the frequencies above B are removed, and there's a gradual transition between A and B, then the ringing is reduced. The bigger the gap (wider the transition band) between frequency A and frequency B, the less ringing you have.

Quote
And where do these frequency bands come from? I mean, why have these pairs of values in particular been chosen as the endpoints of each range?
The bandwidth vs artefacts trade off is highly subjective: some people prefer wider bandwidth with more artefacts, some people prefer fewer artefacts with narrower bandwidth. At least some of these values come from listening tests which tried to judge the best compromise for most listeners. Many years ago there was a listening test on a now extinct audio forum which found 19.5kHz was a reasonable cut off for very high quality audio. mp3 is a little tricky because it's expensive (in terms of bitrate) to keep frequencies above 16kHz.

No mp3 encoders preserve all frequencies all the time at moderate bitrates on all samples without introducing audible artefacts at lower (more important) frequencies. It's just not possible.

Counter-intuitively, for people with excellent high frequency hearing, it's better to remove all the frequencies above e.g. 16kHz, than to preserver the higher frequencies some of the time if that dynamic keep/dump decision process is flawed (i.e. you can hear the switching). Lame generally doesn't make that mistake (if/when it keeps high frequencies selectively, it selects the moments pretty well so that the switching is inaudible - i.e. it only selectively removes them when they're well and truly inaudible). In contrast, some old encoders are really bad at this.

Cheers,
David.

curious about lowpass filters used by LAME

Reply #3
Quote
I'm just curious why it is a frequency band rather than a fixed frequency value. When I think of a lowpass filter, I think of values below a fixed cutoff value being allowed to pass...
The MP3 encoder works by analyzing the relative energy in different frequency bands to determine what's audible, and what's masked and can be thrown-away.  So, I think the low-pass filtering is related to ignoring the highest bands.

Quote
I had a look at the LAME source code (which is over my head),
I've never looked at the source code, but Inside The MP3 CODEC might be a better place to start.

curious about lowpass filters used by LAME

Reply #4
Quote
I'm just curious why it is a frequency band rather than a fixed frequency value. When I think of a lowpass filter, I think of values below a fixed cutoff value being allowed to pass...
The MP3 encoder works by analyzing the relative energy in different frequency bands to determine what's audible, and what's masked and can be thrown-away.  So, I think the low-pass filtering is related to ignoring the highest bands.
No, it's separate. The low pass filter is a simple static low pass filter. The decision to encode (or not) frequency bands based on masking and the absolute threshold of hearing is separate.

Look at a decoded mp3 as a spectrogram and you can usually see both in operation (depending on bitrate, encoder settings, etc).

Cheers,
David.