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: LAME input bitdepth (Read 2592 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME input bitdepth

When creating a LAME encoder preset, foobar2000 sets the maximum input bit depth to 24. At least that's where it's set after switching the encoder from MP3 to Custom.
I'm sure I've tested it in the past, and 24 bit was the maximum for LAME, but maybe I was dreaming because when creating a new preset recently, I accidentally set the maximum input depth to 32 and it worked.

Hence this post to ask.... is there a reason foobar2000 sets 24 bit for LAME instead of 32?

Thanks.

Re: LAME input bitdepth

Reply #1 –
Floating point input support seems to have been added to LAME in version 3.99. I assume the change wasn't noticed by the right people.

Re: LAME input bitdepth

Reply #2 –
Ahhhh..... thanks.

Re: LAME input bitdepth

Reply #3 –
But LAME clips its input signal anyway, so there's almost no difference between 24 and 32.

Re: LAME input bitdepth

Reply #4 –
That could be construed as disappointing. Thanks for the info. I hadn't checked it.

I did just check ffmpeg though, and it appears not to clip when encoding as MP3, so I guess I'll use it instead, at least when I'm not confident about the input level.

For anyone stumbling onto this thread, the foobar2000/ffmpeg command line equivalent of a VBR -V2 encode for LAME would be:

-i - -ignore_length true -c:a libmp3lame -q:a 2 %d

And for a 128k, CBR MP3 with the equivalent of LAME's -q2 quality setting (the default is -q3):

-i - -ignore_length true -c:a libmp3lame -b:a 128k -compression_level 2 %d

Re: LAME input bitdepth

Reply #5 –
But will you be getting gapless files that way? I wasn't aware that ffmpeg could even encode any lossy formats gaplessly.

Re: LAME input bitdepth

Reply #6 –
A good question. I have no idea. Not that I really need it, because I don't encode CDs with tracks that run together very often, and if I do I tend to make my own fades/gaps because my audio player spends it's life in random mode. I'll try to confirm if ffmpeg does save gapless info or not though and I'll report back.

Re: LAME input bitdepth

Reply #7 –
It's looking good unless I'm making bad assumptions or don't properly understand the gapless concept. Anything in particular I should be checking?

I converted a flac file to MP3 with both ffmpeg and LAME and foobar2000 reported the same number of samples and duration as the source for both. Mp3Tag shows both MP3s as having an MP3_ACCURATE_LENGTH field.

I looked at the Mp3s with MediaInfo in debug mode, which was fairly pointless because I didn't understand much of what I saw, but I'd hazard a guess LAME writes an extended Xing header (I remember reading about it somewhere, sometime) whereas ffmpeg writes a standard Xing header, so there's no information regarding the encoder version or settings written, but if that's correct would LAME be using that for extra gapless info that ffmpeg doesn't write?

I'll have to investigate more over the next few days..... try to understand where any gapless info is saved etc, but I encoded to the following lossy formats with ffmpeg:
ac3, eac3, m4a, mp2, mp3, ogg, and opus
and foobar2000 reported the same number of samples as the source for mp3 and ogg, and the same number plus 1 for opus, but that happened when I used the opus encoder too so that's probably just opus being special.
For ac3, eac3, m4a, and mp2 there appears to be a lack of gaplessness, based on the sample count foobar2000 displayed.

I probably should look at he various ffmpeg command line options again later, to make sure there's not something I missed but should be using.

Re: LAME input bitdepth

Reply #8 –
Ah, it lets LAME do its own thing there. Good. I don't think it does any such special treatment for MP4/AAC, however, but you're welcome to try.

Regarding Opus, remember that Opus is a 48 kHz format, so it's upsampling to that rate from whatever you supply, and if it's returning exactly what you requested, then it's also downsampling on decode. The Opus tools are supposed to include a rounding choice that makes this match the input somehow, but maybe it still has possible rounding errors? Or maybe FFmpeg doesn't take this into account?

Re: LAME input bitdepth

Reply #9 –
I never use Opus myself. Only if I include it when testing as I did earlier, yet almost every time I do I discover it's special in another way. I had no idea it doesn't support 44.1 kHz. I understand it probably doesn't matter, and it'd probably be nice if 44.1kHz somehow just went away, but still.... that was a surprise.

I encoded with Opus again for a look, and this time the number of samples reported by foobar2000 was way different to the source, which makes perfect sense. I assume the same thing happened earlier and when I checked it, foobar2000 was displaying something like this:
Duration 4:49.133 (12 750 757 samples)
And I would have blocked out everything except "757" while switching between the encodes in a playlist, and it was probably bad luck the last three numbers for the Opus sample count were only off by one because then I got to be stupid. I assume that's what happened but I can't check as I deleted the samples and I can't remember which track i used as the source.

I don't normally use ffmpeg's AAC encoder so I'm not fussed there, although I did notice the ffmpeg MP3 had 1D3v2.4 tags whereas the LAME MP3 had 1D3v2.3 tags (which is the tag version I have foobar2000 configured to write), so I probably should investigate that phenomenon.