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: Question regarding Hi-Res FLAC to MP3 encoding (Read 9828 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Question regarding Hi-Res FLAC to MP3 encoding

When encoding Hi-Res audio files (in this case, they're 96kHz/24bit FLAC files) to MP3 via foobar2000 + LAME (+ SoX in case it's needed), which of the following procedures should I follow to correctly encode them?

1. Do resampling to 48kHz/44.1kHz with SoX and do bit depth reduction to 16bit (+ dither) and encode it to FLAC/WAV and then encode the resampled file to MP3

2. Convert the Hi-Res file directly to MP3 without touching resampling/bit depth settings and only adjust the LAME settings to set the VBR setting (in this case I'll just be using [-S --noreplaygain -V 0 - %d] and won't move anything else).

Will both provide an MP3 encode with the same quality? I'd like to go with option 2 due to sheer simplicity as I'll be encoding a lot of albums but I heard that Hi-Res files could introduce artifacts when they're not downsampled and bit depth reduced correctly.

P.S. I want to get rid of the Hi-Res files after encoding them to MP3 V2/V0 and I won't archive the source files or the resampled FLAC/WAV encodes.

I'd greatly appreciate your input and I look forward to reading all of your responses.

Re: Question regarding Hi-Res FLAC to MP3 encoding

Reply #1
3. Resample to 44.1/48 kHz, don't do bit reduction, don't create intermediate files.

Built-in resampler in LAME isn't great. But LAME accepts 24-bit input, so there's no reason to reduce bit depth to 16 (and add quantization/dither noise).

Re: Question regarding Hi-Res FLAC to MP3 encoding

Reply #2
3. Resample to 44.1/48 kHz, don't do bit reduction, don't create intermediate files.

Built-in resampler in LAME isn't great. But LAME accepts 24-bit input, so there's no reason to reduce bit depth to 16 (and add quantization/dither noise).


I have the exact same question so this answers it 99%.

1 - Does lame encode mp3s at both 44.1 and 48kHz so therefore it'll take either (but not higher than 48 kHz)?
2 - I can't remember where but I swear someone told me that Lame was optimized for cd input (44.1 at 16bit). In regards to this:
     2a - Is there any evidence/theory that Lame does a better job starting with 44.1?
     2b - Same as 2a except 16bit versus 24bit - or does it not matter because LAME truly encodes without bit depth. I've read that Lame mp3s really are encoded at 16bit but have but also have read that others swear it has no bit depth but software just "reads" that it is 16bit?
3 - Lastly, in regards to the SoX resampler...what settings are best to go from above 48kHz to 44.1 or 48kHz? Specifically:
phase response (0-50%? - seems default is 50% linear),
aliasing (on/off? - default seems to be off) and
passband (default seems to be 95%). Do any of these make a huge or noticeable difference...or are the defaults the best for most situations?

Thanks

Re: Question regarding Hi-Res FLAC to MP3 encoding

Reply #3
1) yes.  Mp3 maxes out at 48k.
2) in theory 44.1k is most used, I doubt it matters much though. Use whatever makes sense for you.
2b) Lame uses floating point, not integer precision. Everything is converted to that.
3) none make a huge difference. I would probably just use default.

Re: Question regarding Hi-Res FLAC to MP3 encoding

Reply #4
1) yes.  Mp3 maxes out at 48k.
2) in theory 44.1k is most used, I doubt it matters much though. Use whatever makes sense for you.
2b) Lame uses floating point, not integer precision. Everything is converted to that.
3) none make a huge difference. I would probably just use default.

Thanks for the reply.

In regards to 2b - floating point:
In short that means there is no "true" bit depth and therefore encoding from a from a 24bit or 16bit source (or 32bit or 8bit for that matter) doesn't make any difference?

Also in regards to question 1:
If starting with 48kHz material...don't bother down sampling to 44.1 before conversion to .mp3? But if starting with something greater than 48kHz, since you're already converting, might as well convert to 44.1? There really shouldn't be a difference from converting to >48 to 48 or 44.1? Will 44.1 make the file smaller than 48 do you know?

Re: Question regarding Hi-Res FLAC to MP3 encoding

Reply #5
The dynamic range of 32 bit floating point is so many times greater that any integer signal can fit. 8 bit audio sounds pretty bad no matter what you convert it too.

I recommend using whatever sampling rate makes the most sense for you. If you have no preference at all, just pick one.

Re: Question regarding Hi-Res FLAC to MP3 encoding

Reply #6
Quote
In short that means there is no "true" bit depth and therefore encoding from a from a 24bit or 16bit source (or 32bit or 8bit for that matter) doesn't make any difference?
Correct.

Quote
If starting with 48kHz material...don't bother down sampling to 44.1 before conversion to .mp3?
I leave it at 48kHz.  Although I wouldn't expect an audible difference I try to avoid any unnecessary resampling.

Quote
But if starting with something greater than 48kHz, since you're already converting, might as well convert to 44.1?
I'd probably just let LAME do whatever it wants to do by default.

Quote
There really shouldn't be a difference from converting to >48 to 48 or 44.1? Will 44.1 make the file smaller than 48 do you know?
I wouldn't expect any audible difference.   The file size is determined by the bitrate (kbps = kilobits per second) so if you know that there are 8 bits in a byte you can calculate file from the bitrate and playing time (plus some allowance for headers & metadata).

With VBR, there might be a slight (insignificant) difference between the 44.1kHz & 48kHz versions of the same file.