Re: [MP3 ENCODER] default high pass filtering
Segher Boessenkool wrote: On some signals, however, highpass filters can do bad things as well. For example, after processing this file http://www.geocities.com/SiliconValley/Bit/5683/test1c.zip with a 5 Hz highpass filter, the peak amplitude increased to about 52000, resulting in lots of clipped samples. True. But you should always adjust the volume to less than 100% before encoding, because the clipping happens anyway. Can be worse with a low cut filter, though. Yes, low frequency "ringing" caused by the highpass filter can do bad things on some signals (such as this test). Anyway, what filter is it? How sharp etc. I used MiXViews (a sound editor) on Linux, elliptical filter with these parameters: passband cutoff: 6 Hz stopband cutoff: 4 Hz passband ripple: 0.1 dB stopband attenuation: 90 dB (note: I converted the signal to float format before filtering). Btw. most mp3 encoders seem to have problems with the 4 short noises at the beginning of the file (pre-echo is cleanly audible). -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Segher Boessenkool wrote: Perhaps someone could find a wav wich produces this disturbing high frequency echos while encoding with lame due to low frequency signals. This could be bassNN_N.wav from SQAM (at low bitrates). about anything from "Grotus" as well (_very_ fat bass) On some signals, however, highpass filters can do bad things as well. For example, after processing this file http://www.geocities.com/SiliconValley/Bit/5683/test1c.zip with a 5 Hz highpass filter, the peak amplitude increased to about 52000, resulting in lots of clipped samples. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Does anyone know how a high pass filter is usually implemented? The convolution approach (like the low pass filter) seems like it would be expensive and require a lot of extra internal buffering: a 10Hz signal takes 4410 samples to represent one period. To get good frequency resolution (so you can tell the difference between the 10Hz signal and a 20Hz signal, for example) I would guess your window size would have to be at least twice that, or 8820 samples? Mark I have 3 ideas, but I'm not sure if they'd even work, let alone how to code them if they did... 1- Try simulating the behaviour of ideal capacitors/resistors/op-amps/etc. Maybe a highpass filter could be "built" out of computer code put just before the resampling function. (Or is *that* what the "convolution approach" is? Oops.) 2- Resample the input file to something ridiculously low like 40Hz, subtract this from the original WAV. (Although that would probably require the above method anyway.) 3- Remove the lowest frequency band(s) from the FFT data Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
On Wed, 10 May 2000, Naoki Shibata wrote: 2- Resample the input file to something ridiculously low like 40Hz, subtract this from the original WAV. (Although that would probably require the above method anyway.) Assume that the original sampling frequency is f. Downsampling to sampling frequency f/n (n is integer) is easy, since this is done by picking up every nth sample. Ooh, ouch - this leads to heavy aliasing. Don't do that! Before any resampling to lower frequencies, you have to do filtering to that frequency's half. Upsampling this data to frequency f requires filter with large order, but since almost all input sample is zero, this process requires only small computational power. Sehr Wus, - Matthias -- "Fire! Fire!!! FIRE! cat?" (from Pleasantville) - -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
I have 3 ideas, but I'm not sure if they'd even work, let alone how to code them if they did... 1- Try simulating the behaviour of ideal capacitors/resistors/op-amps/etc. Maybe a highpass filter could be "built" out of computer code put just before the resampling function. (Or is *that* what the "convolution approach" is? Oops.) 2- Resample the input file to something ridiculously low like 40Hz, subtract this from the original WAV. (Although that would probably require the above method anyway.) 3- Remove the lowest frequency band(s) from the FFT data The resampler uses a low pass filter, so I guess it'd just be a case of modifying the code to reshape the filter. I don't know how many points you need to do a 16Hz filter though Scott Manley (aka Szyzyg) /-- _@/ Mail -\ ___ _ _ __ __ _ | Armagh Observatory | / __| __ ___| |_| |_ | \/ |__ _ _ _ | |___ _ _ | Armagh | \__ \/ _/ _ \ _| _| | |\/| / _` | ' \| / -_) || | | Northern Ireland | |___/\__\___/\__|\__| |_| |_\__,_|_||_|_\___|\_, | | BT61 9DG. | http://star.arm.ac.uk/~spm/welcome.html |__/ \=/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
_very_ few. Every mdct sample is about 38 Hz wide, so you wouldn't even cut away the first (or zeroeth, whatever) sample. There is no such thing as 'zeroeth' ! Remember the "when does the millenium start" problem ? :-) Hey, C and Perl both start arrays with index 0. I trust them more than I trust historians. The reason ISO recommends highpass filtering is to cut away the DC portions, which mp3 can't directly represents (it is a combination of the 0'th and 575'th sample. The 575'th normally gets set to zero, especially if you're lowpass filtering). You get DC in a long block, if the sound contains some components 19 Hz. DC leads to high-frequency echoes. (Some kind of phantom image of the true sound at lower freqs). Hmm , can you explain why this happens ? Okay, here comes: - If you take the formulae for encoding and decoding 1 mdct block, and combine them, it gives the original output + a half bandwidth modulated mirror image. _If_ quantization would be perfect, overlapping blocks would cancel this. (The mdct is a tdac transform (time domain alias cancellation)). But of course, quantization is _not_ perfect. This is a general problem, not only DC related. - mdct works on the odd frequencies; this makes the problem worse for DC. - If your frame is DC shifted, you typically get huge samples at mdct index 0. Because the maximum sample value (after quant) is 8191+15, you end up with the rest of that subband quantized not nearly good enough. The 0'th subband is indices 0..3, i.e. 0..153 Hz (at 44.1 kHz samplerate). I guess you can here 153 Hz... - scalefactor allocation uses mean error, so if 1..3 can be reasonably represented, the fact that 0 can't doesn't mean that much to the iteration loops. Doesn't seem logical to me, but I'm no mp3/mdct expert. david balazic It's just some math observations. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Shawn 2- Resample the input file to something ridiculously low like 40Hz, subtract this from the original WAV. (Although that would probably require the above method anyway.) Assume that the original sampling frequency is f. Downsampling to sampling frequency f/n (n is integer) is easy, since this is done by picking up every nth sample. Upsampling this data to frequency f requires filter with large order, but since almost all input sample is zero, this process requires only small computational power. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Segher Boessenkool wrote: _very_ few. Every mdct sample is about 38 Hz wide, so you wouldn't even cut away the first (or zeroeth, whatever) sample. There is no such thing as 'zeroeth' ! Remember the "when does the millenium start" problem ? :-) The reason ISO recommends highpass filtering is to cut away the DC portions, which mp3 can't directly represents (it is a combination of the 0'th and 575'th sample. The 575'th normally gets set to zero, especially if you're lowpass filtering). You get DC in a long block, if the sound contains some components 19 Hz. DC leads to high-frequency echoes. (Some kind of phantom image of the true sound at lower freqs). Hmm , can you explain why this happens ? Doesn't seem logical to me, but I'm no mp3/mdct expert. Dag dag, Segher david balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Shawn Riley wrote: Does anyone know how a high pass filter is usually implemented? The convolution approach (like the low pass filter) seems like it would be expensive and require a lot of extra internal buffering: a 10Hz signal takes 4410 samples to represent one period. To get good frequency resolution (so you can tell the difference between the 10Hz signal and a 20Hz signal, for example) I would guess your window size would have to be at least twice that, or 8820 samples? Mark I have 3 ideas, but I'm not sure if they'd even work, let alone how to code them if they did... 1- Try simulating the behaviour of ideal capacitors/resistors/op-amps/etc. Maybe a highpass filter could be "built" out of computer code put just before the resampling function. (Or is *that* what the "convolution approach" is? Oops.) 2- Resample the input file to something ridiculously low like 40Hz, subtract this from the original WAV. (Although that would probably require the above method anyway.) 3- Remove the lowest frequency band(s) from the FFT data I don't think that 3 would be good, since it would affect a rather large range of frequencies ( the lowest band is for 38 Hz, as someone recently mentioned, I think at least freq to 50 Hz would be affected ) david balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Hi Has everyone tested the results of such a highpass filter ? Has anyone time to prefilter a wave (with mathlab, scilab, or something else), send it through lame and rate the results with and without prefiltering ? Perhaps someone could find a wav wich produces this disturbing high frequency echos while encoding with lame due to low frequency signals. This could be tested with listening test and -this time- perhaps with a spectral analysis - if it's possible to make the distorsions in the high frequency band visible. If there are results that validate the importance of this filter we can discuss how to implement it (using a iir or fir filter routine ...) and if it's worth the expense, but discussing it like this is IMHO a waste of time ... sorry ! A+ Christian -- Christian Schepke Tel.: +49 (0)231 39 88 99 3 Lehrstuhl fuer Kommunikationstechnik Universitaet Dortmund [EMAIL PROTECTED] Dortmund, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Perhaps someone could find a wav wich produces this disturbing high frequency echos while encoding with lame due to low frequency signals. This could be bassNN_N.wav from SQAM (at low bitrates). about anything from "Grotus" as well (_very_ fat bass) Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
While I preety much agree with the rest of the post, I must comment on this one basis. On Tue, 9 May 2000, Gabriel Bouvigne wrote: [snip] why a 14Hz high pass filter and not a 20Hz one: because the lowest tone produced by a true musical instrument is 16Hz (it's from organ). [snip] And the fastest math calculateable by a true computer (the human type, i.e. the orignal use of the word computer) is X operations per second, so lets limit these new fangled silicon computers to X operations per second. :) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] default high pass filtering
Hello I would vote for a default 14Hz high pass filter, removable with the -k option. Why an high pass filter: *theorical minimum audible freq for humans is 20Hz (also very discutable) *most soundcards are unable to reproduce less than 20Hz frequencies *most speakers are unable to reproduce less than 19Hz freq *most (if not all) headphones are unable to reproduce such low freq (even if their specs tell they are) *ISO doc recommends an high pass filter At 5 Hz, IIRC. *even if it's a small part of the spectrum, it's still a few bits usable for other more critical parts. _very_ few. Every mdct sample is about 38 Hz wide, so you wouldn't even cut away the first (or zeroeth, whatever) sample. The reason ISO recommends highpass filtering is to cut away the DC portions, which mp3 can't directly represents (it is a combination of the 0'th and 575'th sample. The 575'th normally gets set to zero, especially if you're lowpass filtering). You get DC in a long block, if the sound contains some components 19 Hz. DC leads to high-frequency echoes. (Some kind of phantom image of the true sound at lower freqs). Dag dag, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
