Skip to main content

Topic: LAME's resampling leaves something to be desired (Read 4964 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • eamon123
  • [*]
LAME's resampling leaves something to be desired
http://shibatch.sourceforge.net/ is a good resampler. It beats lame in quality every time. Here is an example:

Yes I retested Baba O'Reilly and it sounded noticibly better with ssrc.

I did

FLAC 88.2 > lame.exe -S --noreplaygain -b 32 --lowpass 10 --resample 24 - %d
VS
FLAC 88.2 > WAV > ssrc.exe --rate 24000 --bits 16 > lame.exe -S --noreplaygain -b 32 --lowpass 10 - %d

in ABX and got 14/16 (0.2% prob of guessing). I was hearing a whole different type of artifact that I have either never heard before or just never listened for before. I was 5/2 up when I started listening to the bass drum and it just sounded fuller, warmer and louder in ssrc. It was then that I noticed that there was a shrill artifact at about 9 kHz at the same time as the drum beat in question. It was obvious in both files, but louder in the LAME version. Up until now the bass drum "masked" it, "masking" is seriously like an aural illusion, that bass drum sounded fine before I heard the shrill in one and then I heard it in the other, I was dumbfounded! After that I just listened for that beep and the louder one was LAME. LAME should really look into their resampler, a lot of people are downsamping high res FLACs these days!

I feel like I did the first time I discovered that I had a blind spot on my retina that I could "discover" at will with carefully engineered designs and some ordinated displacement of said designs. Discovering the nature of my aural blind spots first hand I can only describe myself as feeling enlightened!

Maybe that shrill noise is due to a crappy lpf in LAME?

https://rapidshare.com/files/1612342437/ssrc.vs.lame.zip





ssrc is foss, maybe the LAME devs would like to copy some of it's code?

  • eamon123
  • [*]
LAME's resampling leaves something to be desired
Reply #1

  • pdq
  • [*][*][*][*][*]
LAME's resampling leaves something to be desired
Reply #2
Since the differences seem to be localized to frequencies very close to fs/2, and since this is followed by perceptual encoding, isn't it possible that what you are seeing is not necessarily due to differences in the quality of resampling?

IOW, something innocuous like the steepness of the cutoff could allow or not allow frequencies that cause encoding problems to be present, and this causes artifacts in one that are not present or significantly reduced in the other.

What I am saying is that the perceptual encoding step could completely invalidate a comparison of the quality of resampling (though I don't see any other way to test the resampling algorithm in lame).

  • eamon123
  • [*]
LAME's resampling leaves something to be desired
Reply #3
I'm using that as a particularly glaring example that I can show on the screen. If you listen to the two files, you can find extra artifacts in the LAME resampled file throughout. Do your own tests even. To quote someone else on the reason as to why this is the case:

Quote
What makes this probably worse than usual is that the kind of noise artefacts produced by bad digital filters can easily mislead lossy psycho-acoustically modelled encoders to allocate spectral buckets to these artefacts rather than "real" content.


Quote
something innocuous like the steepness of the cutoff

The only difference is the resampling algorithm so it must be something about the resampling process  that is sub-standard.

Quote
Not all low pass filters are created equally, especially when the order of a "perfect" filter exceeds a few thousand, as few resamplers will bother with that.

To be sure you're not suffering from resampler implementation bias, you should do manual resampling with SSRC in "high quality" mode using the standalone tool written by SHIBATA Naoki.

Outside of proprietary closed-source resamplers, I'd assume anything less than Shibata's is broken. 44.1->48/32/24 resampling requires a relatively complex filter to do it "perfectly". (One of the reasons why 44.1KHz was chosen even though more "harmonic" values were known or even proposed at the time was precisely to make this kind of resampling "hard" for consumers.) The resampling ratio is a beast, in any event: 160:147 (for 44.1->48). EEs/DSP jocks will immediately understand the high order filter needed to do this job perfectly.


They both have the same cutoff, I specified --lowpass 10 which has a default range of 15%. The input wav from ssrc was cut off well above 11.5 kHz so after the lpf the cutoff in both is exactly the same.
  • Last Edit: 16 October, 2012, 09:53:16 PM by eamon123

  • saratoga
  • [*][*][*][*][*]
LAME's resampling leaves something to be desired
Reply #4
Does this still happen if you don't specify a lowpass filter in lame?

  • AndyH-ha
  • [*][*][*][*][*]
LAME's resampling leaves something to be desired
Reply #5
I looked at this once upon a time with simple test signals. The reconstructed wav files matched the originals well when there was no LAME resampling. Lame resamled signals showed a quite visible amount of aliasing, of the sort shown at
http://src.infinitewave.ca/
by some of the less able resamplers.

  • eamon123
  • [*]
LAME's resampling leaves something to be desired
Reply #6
I looked at this once upon a time with simple test signals. The reconstructed wav files matched the originals well when there was no LAME resampling. Lame resamled signals showed a quite visible amount of aliasing, of the sort shown at
http://src.infinitewave.ca/
by some of the less able resamplers.



Here are some tests done with this sweep tone http://www.audiocheck.net/download.php?fil..._-3dBFS_30s.wav at the following settings:

WAV > ssrc_hp.exe --rate 44100 --bits 16 --dither 0 > lame.exe -S --noreplaygain -b 320 - %d
Vs.
WAV > lame.exe -S --noreplaygain -b 320 --resample 44.1 - %d


IDEAL WAVEFORM

SSRC -> LAME WAVEFORM

LAME WAVEFORM

These waveform pictures speak for themselves.



IDEAL SPECTRAL

SSRC -> LAME SPECTRAL

LAME SPECTRAL

Note the scale on the left.
  • Last Edit: 17 October, 2012, 05:34:41 AM by eamon123

  • Destroid
  • [*][*][*][*][*]
LAME's resampling leaves something to be desired
Reply #7
Spectrogram aside (which is notable), I also preferred down-sampling using FB2K's SSRC prior to encoding low-bitrate MP3's (80kbps stereo and 48kbps mono).

My own ABX is not very conclusive either, so call it paranoia  . Yet, I think it is possible to locate where LAME's internal re-sampling falls short in certain lower bit-rate areas.

OP: My advice is: instead of directly shoveling the (assumed) WAV directly to LAME at bitrates lower than 96kbps, just continue to use SSRC pre-processing function inside FB2K like you have been doing. I see no harm in that. Is it overkill? Maybe... or not?
"Something bothering you, Mister Spock?"

  • mjb2006
  • [*][*][*][*][*]
Re: LAME's resampling leaves something to be desired
Reply #8
I was just doing my own tests with LAME -V 9.999 and some tonal electronic music. I found that LAME's internal resampler does indeed seem to be producing much worse results than using a high quality resampler prior to encoding.

Just running the original WAV through LAME -V 9.999, you can see in Audition's spectrograms and frequency analysis graphs that for each of the music's natural harmonics above f/4 (2 kHz) there's a "ghost" tone right below it—e.g., the music's tone at 2794 Hz has a 2762 Hz artifact paired with it, and it's at nearly the same amplitude. This is, of course, quite audible and sounds terrible.

Since LAME is resampling to 8 kHz, I tried converting the original WAV to the same rate in Audition, with quality 100%, pre/post-filter enabled. (src.infinitewave.ca's graphs suggest this should be artifact-free and comparable to SoX and SSRC High-Precision.) After feeding this through LAME, the result was quite a bit better: no artifact tones, at least. Pre-echo is another issue.

Also, if I enabled triangular dither during the resample, it helped LAME preserve more of the higher frequencies, sometimes audibly on the transients, and with no adverse affect on quality for this particular piece of music, but I wouldn't assume that would always be the case.
  • Last Edit: 13 July, 2016, 12:28:54 AM by mjb2006

  • mjb2006
  • [*][*][*][*][*]
Re: LAME's resampling leaves something to be desired
Reply #9
I posted to lame-dev about it just now.

Here's a 4-frame animation to illustrate my previous post:

(apologies for breaking your screen width, but it should get better after version 1.1 beta 2 of the forum software is released)



  • Last Edit: 13 July, 2016, 02:29:09 AM by mjb2006

  • kode54
  • [*][*][*][*][*]
  • Administrator
Re: LAME's resampling leaves something to be desired
Reply #10
Can I mention something else about LAME that I think should be fixed? I should probably post this to a new topic, while I'm at it.

The last time I looked at the LAME source, it appeared that the start and end of file padding that is done to make the length equal an even number of packets, appears to be done with pure silence, rather than a linear predictor. This may hamper gaplessness for some problem tracks, depending on where the start or end of the track lie, relative to a zero crossing.

  • mjb2006
  • [*][*][*][*][*]
Re: LAME's resampling leaves something to be desired
Reply #11
Yes, separate topic, though it has been mentioned before and has turned out to be an issue for virtually no one. The usual method of encoding separate tracks, storing the encoder delay and padding info in each file, and relying on players to trim it from the decoder's output has been sufficient for most cases; the assumption of silence adjacent to each track almost never audibly affects the output. The edge cases can be handled (only when using those same players) by encoding the whole album to one MP3 and then splitting it with a cue sheet and pcutmp3. There is also the old method of splitting (as done by any other splitter or LAME's --nogap option), but this, too, required special player support to keep from resetting the decoder between files and to play the last frame or two of the last file; I think only RockBox ever attempted it, and LAME's implementation is still buggy, tag-wise.
  • Last Edit: 13 July, 2016, 03:49:16 AM by mjb2006