Hi folks,

Knowing that there rarely is any content above 16kHz in up to 128kbit/s mp3s, the use of 44kHz sampling frequency seems questionable. 32kHz gives you 16kHz per channel, which is often enough.

But how much bits does it free up when using 32kHz instead of 44.1? Basing on simple calculations, at least in case of a WAV, it should be roughly 1/3, but that is hard to beleive in case of mp3, beacause a 32kHz mp3 would then be approaching the quality of a 16kHz lowpassed 160kbps 44kHz one, wouldn't it?

Still, the majority of 128kbps and even 112kbps mp3s are encoded with 44kHz. Why is that? Sure it takes time to downsample when encoding, but still...

A, once again, confused newbie,
Immo

I always wondered about that as well

About downsampling a 16kHz-band-limited signal from 44.1kHz to 32kHz:

In PCM yes, you would gain roughly 1/3, but in the frequency domain this downsampling just removes the zeroes from the upper MDCT coefficients.

This overhead for storing near-zero values should be very small, in all lossy audio formats. In theory, you would gain almost nothing.

[Edit]Downsampling, however, may be useful in very low bitrates, to accelerate the encoding process a bit. We'll also spare a few bits, due to limitations of mp3 (blocks will represent a longer duration, which is usually better for lower bitrates). [/Edit]

Thanks for the explanation,

OK, so it's not much use in 128kbps. But is it better or worse?

When encoding 128kbps mp3s in CoolEdit, the max. bandwidth preset increases by about 100-200Hz from ~15.8kHz to 16.0kHz, when changing the setting from 44 to 32kHz, so the gained bits seem to amount high enough to raise the lowpass by at least 100Hz... not that it would be easily heard, though...

Immo

so if i got it right NumLOCK say that downsampling to 32khz for 128kbit stuff is just fine if u use --lowpass 16 already?
Does it free up some stuff for better encoding of lower freq? or is it just better cause of the LAME encoding process?

For me i cant hear anything over 15.4-16khz so 32khz is all i need or? I already use --lowpass 16 -Y so adding --resample 32 is better or just leave stuff at 44khz?

Mp3 has a design flaw preventing efficient encoding of the highest sfb. For 44.1 and 48kHz, this sfb starts around 16kHz.
For 32kHz, this sfb starts lower, reducing the range of frequencies that could be encoded in an efficient way.

ah oki thx, that means leave stuff at 44khz than.

Well.. it's perfectly possible that fhg is well-tuned for 32kHz. I just don't know. The lowpass being raised is probably not a sign of more available bits - because, as Gabriel just said, in 32kHz mode the high-end of the spectrum is encoded less efficiently in the file format.

The best test would be to use 44kHz (LAME is better tuned for that), until some artifact pop up. Then, switch to 32kHz (and/or CoolEdit's encoder) and see if it gets reduced...


Well, if mp3 weren't limited (sfb21 - just mentioned by Gabriel) and LAME were equally tuned for 32 and 44.1, then you would get a slight advantage when switching to 32kHz.

You might still get a tiny advantage with 32kHz FhG, but the best would be to try it.
Probably, you'll have the best quality keeping 44kHz and your lowpass, or switching to FhG.


Normally, yes.

Almost forgot: the -Y switch is useless when you already lowpass @ 16kHz in 44.1kHz mode.

However, one might want to try -Y in 32kHz mode.. try it, it might be a good bet, who knows

If you use 32 Khz @ 128kbps you'll avoid artifacts but the sound will become poorer.
And maybe some artifacts are preferable than a lower sampling frequency (in particular if you will burn the mp3s onto an Audio CD).

To increase the quality without downsampling the audio, with Cool Edit Pro you could disable the lowpass used by the mp3 encoder (setting it to 22050 Hz) and use the lowpass function of Cool Edit (the quality will be higher than the lowpass used by the mp3 encoder).

Using of 32 kHz will increase the size in ms of MDCT blocks, and thus it will increase pre-echo. Frequency resolution will be increased (width of one sfb in Hz will be smaller) - but problem with encoding of the last scalefactor band in MP3 might completely cancel out benefits done with increased frequency resolution - maybe someone can make detailed measurement.

For example, 1152 samples for 44.1 kHz = 26 ms
for 32 kHz = 36 ms

By the way, latest QuickTime 6.1 defaults 32 kHz sampling rate at 128 Kb/s for MPEG-4 AAC (thank God you can select 44.1 kHz), which was the first thing that I noticed while testing it. I don't think that is smart at all (although AAC has TNS tool which can compensate the increase in time domain frame length), but probably somebody at Apple thinks otherwise

For AAC this higher frequency resolution at lower bitrates is quite noticable in my opinion. As mentioned before, PsyTEL's -radio preset benefits very much from resampling at 32 kHz, also -internet. The higher resolution results in fewer flanging artifacts with high frequency sounds at the sides of the stereo image (hi-hats etc.). I did not notice any worse pre-echo artifacts with resampling in my tests, but this could also be due to the samples I used.



So there's really a new Windows version of QT 6.1 available now?



This makes me think of the cutoff frequencies that c't stated in their last test for the professional FhG AAC codec. For 128 kbps it was 15 kHz, so maybe FhG also resamples at 32 kHz on default in their own Pro codec, and Dolby has only copied this setting for their consumer version in QuickTime 6.1?

If the cut-off was 15 kHz than it is certainly FhG's AAC fastenc - it has very low cut-off (even 14.5 kHz at 128 kbps (ultra)"fast" mode).

Dolby consumer (at least the version I have, but I don't think it is changed) uses 44.1 kHz and 16 kHz cut-off at 128 kbps - so only QT 6.1 is defaulting 32 khz at 128 kbps (16 khz cut-off , i.e. - no cut off)

While the usage of 32 kHz is certainly necessary below certain number of bits per compressed sample (for MP3 this is ~1.1 bits per sample, for AAC it is ~0.8 bits per sample) at higher bit rates it is less productive (like @128 kbps)



Yes, it is available.


Back to MP3,

Considering short window length in MP3, as well as lack of tools like TNS - combined with the last scalefactor band problem - usage of 32 kHz at 128 Kb/s would only reduce audio quality IMHO.

In theory, if there was no sfb21 problem - some signals would benefit from the increased frequency resolution. But, unfortunately, I think that last scalefactor band issue would cancel all benefits - even without coming to the pre-echo issue.

@32 kHz there is no sfb21 problem with mp3. Considering the larger block length in time, I would use it at bitrates of 96 and below only.

Then FhG would use a very special interpretation of "ultra fast", because this codec needed 7:48 min. for encoding a 4:06 min. test file at 128 kbps on a Pentium III/800 Mhz, while the others (MP3, mp3PRO etc.) only needed between 0:18 and 0:52 min. Maybe both FhG codecs use this low cutoff then, and I thought you would have one to compare, but obviously this is not the case. Furthermore c't did not tell how they found out these values, probably by looking at the graphs in Sound Forge 6. And of course they didn't tell if the encoded files were resampled.



OK, then this seems to be an "exclusive" feature of the new version...