Hi,

I've searched the forum over the but haven't found an answer. LAME accepts 24-bit input, but does it also natively accept 32-bit floating-point? The reason I ask is, on occasions when I use Foobar's diskwriter with DSPs enabled, e.g. to resample 48kHz DVD PCM to 44.1kHz, I'm concerned that the digital transforms prior to encoding may cause samples to shoot over 0dB, and would hope that with LAME such >0dB samples would be seen as being >0dB rather than being seen as at 0dB (and result in unnecessary clipping). Since LAME processes in 32-bit fp, I'd be surprised if it didn't also accept fp input "as is", but it's always good to find out about things.

Also, years ago I found via experiment that musicmatch JB, or perhaps its FhG encoder, converted 24 and 32-bit files to 16-bit before encoding. (Of course, not to imply that LAME devs are in the same league as MMJB's amateurs!)

TIA.

Sorry to bump, and the o.p. was probably long-winded, just to ask again if Lame accepts piped f.p. input natively. The reason for my asking being that when Lame is placed at the end of a DSP chain in Foobar, I want to know if Lame will be aware of floating-point stuff over 0dB (possibly caused by the DSPs) before encoding.

Last year when encoding the Led Zep DVD's PCM (and setting the SSRC plugin to resample 48kHz -> 44.1kHz), I set the Volume DSP to -3dB to try to avoid the problem of any clipping introduced in the resampling, but it would be better to know if this "workaround" is not necessary in the first place.

Thanks.

How about you try it?

either lame doesn't support 32bits on encode, or mp3 decoding software (mad, mpadec) doesn't support that on decode, i forget...


later

Pls re-read my question - if I had wanted to know if lame.exe can read 32-bit waves, I would try it myself and not waste everyone's time by posting. Can you distinguish between clipping introduced during DSP operations and clipping from Lame's transforms?

In Foobar 0.83, Lame's "highest BPS mode supported" in the Diskwriter is preset at 24-bit - does this mean that 32-bit f.p. input is rounded to 24-bit integer before being sent to Lame, and thus any stuff already over 0dB is lost instead of encoded?

That I know of, you actually are feeding a "wave" file to lame, when you encode through foobar. I also recall reading that LAME did support 32 bit streams. LAME is floating point, anyways, so the data should be scaled fine. I think it would be anyways, if it were rounded to 24 bits first, but whatever.

The key difference between 32-bit f.p. and 24-bit integer is that, in the f.p., stuff can exist over 0dB, which is useful for not losing information when stacking DSPs (one of Foobar's many strengths). E.g., in my example, I'm resampling before encoding, and don't want to use Lame's own resampler.

I've been at ha.org since Nov 2001 and I'm surprised I haven't seen my question before. Anyway the reason I resample 48kHz PCM to 44.1kHz for MP3 is that, at least back when Lame 3.96 was new, my 48kHz --aps files were consistently a lot bigger.

Well, cheers.

I would have to check, but I do not remember the input signal to be clipped, so full input range should be kept.
However, you are mentionning something else: 32bits fp would have an higher dynamic range than 24bits fp. I do not remember 24 and 32 bits fp to be handled differently in Lame (but this is only from memory).

Now, could anyone explain why 32 bits fp could go over 0dB and not 24bits fp? Both dynamic ranges should be similar, in my opinion, the only difference beeing the precision.

Thanks for weighing in; I'd suspected Lame (unlike musicmatch) wouldn't mishandle this kind of thing. But as I was taught in the army, when in doubt always confirm and never assume! Being an arts rather than science fellow, I don't have the necessary technical background, so there's always the chance that I'm completely off.

To answer your question, what I said earlier was that 24-bit integer (rather than f.p.) data can't cope with such scenarios without clipping; it didn't occur to me that the "24" in diskwriter could still refer to f.p. data, as the few 24-bit .WAVs I've come across are always integer (but that may just be a limitation of Microsoft's format / AIFF).

Best regards.

I just noticed today that in foobar2000 0.83's (i dunno about 0.9x as i'm on Win98) default Lame encoding presets in Diskwriter, the
"Pass floating point data (some lossy encoders only)"
box is not ticked.
I presume this means floating-point data is passed to Lame as 24-bit integer, which also implies that any clipping resulting from DSPs earlier in the encoding chain would be piped to Lame as well? I wonder why Fb2k doesn't enable the floating-point feature by default?

lame.exe doesn't support 32-bit fp PCM data.

lame_enc.dll supports direct feeding of 32bit floating point values, in the same range as 16bit short (-32768 to 32767). It works just fine, and encoding a -120dB sine works as expected (but had to use 320 CBR to make it sound acceptable, tho). I have no clue about commandline LAME.

If you enable the Advanced Limiter DSP any clipping will be just about inaudible, unless it's severe and continuous. The SSRC resampler doesn't cause much (if any?) clipping at all on it's own from what I've seen.