Skip to main content
Topic: 24bit/96khz FLAC audio to MP3 320k (Read 1446 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #1
I would advise finding a VBR preset that makes you comfortable, as b320 will merely be wasting bits most of the time.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #2
The LAME defaults are optimized for the best sound with most audio sources.    Some "killer samples" are difficult to compress transparently but it's related to the nature of the sound, not because the original is high resolution.

At higher bitrates, MOST recordings should be transparent in an proper blind ABX Test.    A couple of ABX tests should ease your mind...    Even if you can hear a difference between the high resolution original and the MP3, you'll discover that it's not easy to hear the difference.    (Sometimes there is an "obvious" difference in a non-blind listening test... ;)  )

Quote
I'm using b320 (the highest quality preset).
This is largely theoretical.    It's only "best" if you can hear a difference.     No matter what the setting MP3 it's lossy compression and all of the samples are changed.    The only meaningful way to measure quality by listening.   If you can't hear the difference between 192kbps and 320kbps, or if you can't hear the difference between the high resolution original and 192kbps,  we can't say 320 is "better."


Re: 24bit/96khz FLAC audio to MP3 320k

Reply #3
I'm using b320 (the highest quality preset).
320 kbps CBR is an overkill. Go V0 (~256 kbps VBR) - not only guys above, but even HydrogenAudio wiki says it's better option.

Do I need to tweak any setting when the source is Hi-Res audio?
In LAME? Apart from changing that bitrate, no.
But before feeding the audio to the LAME? I think yes. Not only sample rate is higher than LAME's maximum, but you should reduce the bit depth, too. LAME's internal resampler is known for having poor quality. SoX has perfect resampler and built-in dithering. When you feed the audio to LAME, there are some tweaks you can apply to all your audio, not only Hi-Res.

This is technically correct command line that will retain the most quality from your audio. LAME settings from the second line are applicable to all audio, either CD or Hi-Res.
Code: [Select]
sox input.wav -b 16 resampled.wav rate 44100 dither
lame -m j --clipdetect -h -V 0 resampled.wav output.mp3

Explaination:
I think that SoX line is self-explanatory. However, BE CAREFUL OF CLIPPING. If you get clipping warning, write gain -1 before rate effect. If audio still clips, reduce gain even more till you get no warnings.
LAME line needs more explanation.
-m j forces joint stereo (L/R or M/S, which is more efficient in particular MP3 frame).
--clipdetect does accurate clipping check. If audio clips, write --scale 0.99 (or --gain -0.5 if you have LAME 3.100) and reduce the scale (or gain) till audio doesn't clip.
-h means highest quality MP3 encoding.
-V 0 = ~256 kbps VBR.

Happy listening! ;)
sox -e float -b 32 -V4 -D gain -3 rate -v 48000 norm -1
opusenc --bitrate 128

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #4
Code: [Select]
sox input.wav -b 16 resampled.wav rate 44100 dither
lame -m j --clipdetect -h -V 0 resampled.wav output.mp3

So, the intermediate audio is 16-bit? What's the point?
Also IIRC -m j and -h are default settings and can be omitted.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #5
I don't know how does LAME handle bit depth. If we feed it with 24-bit audio, there are three options:
  • LAME will make all the calculations directly on 24-bit input - desired option. In this case: yes, we don't have to go 16-bit.
  • LAME will simply truncate to 16-bit and do calculations on truncated integers - worst case scenario that pre-dithering prevents.
  • LAME will truncate to 16-bit and dither - safe option.
If I don't know how does LAME handle 24-bit audio, choosing safe option (16-bit, dither) is better.
Besides, what's the point in feeding MP3 encoder with 24-bit audio, if artifacts caused by MP3 encoding are waaaaay louder than 16-bit dither noise? Not to mention that 16-bit itself is enough for everything we can hear...
sox -e float -b 32 -V4 -D gain -3 rate -v 48000 norm -1
opusenc --bitrate 128

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #6
Also IIRC -m j and -h are default settings and can be omitted.
Correct me if I'm wrong, but lame --longhelp doesn't say anything about these options being default... It's better though to set these options explicitly than not to set and worry that encoder might choose different defaults.
sox -e float -b 32 -V4 -D gain -3 rate -v 48000 norm -1
opusenc --bitrate 128

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #7
I don't know how does LAME handle bit depth. If we feed it with 24-bit audio, there are three options:
  • LAME will make all the calculations directly on 24-bit input - desired option. In this case: yes, we don't have to go 16-bit.
  • LAME will simply truncate to 16-bit and do calculations on truncated integers - worst case scenario that pre-dithering prevents.
  • LAME will truncate to 16-bit and dither - safe option.
If I don't know how does LAME handle 24-bit audio, choosing safe option (16-bit, dither) is better.
Besides, what's the point in feeding MP3 encoder with 24-bit audio, if artifacts caused by MP3 encoding are waaaaay louder than 16-bit dither noise? Not to mention that 16-bit itself is enough for everything we can hear...
LAME immediately converts to 32 bit float and uses that for all calculations.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #8
LAME immediately converts to 32 bit float and uses that for all calculations.
Could you prove that?
sox -e float -b 32 -V4 -D gain -3 rate -v 48000 norm -1
opusenc --bitrate 128


Re: 24bit/96khz FLAC audio to MP3 320k

Reply #10
I don't know how does LAME handle bit depth. If we feed it with 24-bit audio, there are three options:
  • LAME will make all the calculations directly on 24-bit input - desired option. In this case: yes, we don't have to go 16-bit.
  • LAME will simply truncate to 16-bit and do calculations on truncated integers - worst case scenario that pre-dithering prevents.
  • LAME will truncate to 16-bit and dither - safe option.

None of those are how real encoders work.  Math is done on floating point values except for on very simple hardware devices without real CPUs, and those tend to produce poor quality. 

If I don't know how does LAME handle 24-bit audio, choosing safe option (16-bit, dither) is better.

With respect to codecs, if you don't know, the best option is always to let the encoder figure it out.  Trying to second guess the encoder is hard when you know what is going on, but if you don't even know that, it is hopeless.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #11
LAME frontend accepts float format but it gets clipped. Though it's weird as quick look at the sources does suggest it deals with floats internally.
Using SoX to resample but keeping output bit depth at 24 bits leaves the material as clean as possible for lame. Also doing resampling in another process than the encoding allows multi-core processors encode faster as the two processes happen in different cores.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #12
That's probably because integer audio values are between +- 1, so floats are clamped to that range as well.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #13
Oh, this is really hard to understand for me. Thank you for the details. How about simply encoding it, then apply replaygain in foobar? Would it be any different from --clipdetect outputs?

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #14
Could you prove that?
You could verify for yourself that Lame will encode in excess of 24-bit dynamic range in CBR 320 if you feed it a suitably quiet input, and also that joint-stereo and -q 3 is used.

I confirm that Lame CLI encoder will clip floating point input. The only program I know of that will encode unclamped samples is Reaper DAW prior to version 5.50. It used lame_enc.dll beEncodeChunkFloatS16NI. Current version uses libmp3lame.dll and clips again too.

The above procedure with command-line seems like too much manual effort towards (largely insignificant) clipping avoidance. Most front-ends won't show the console output of --clipdetect or any error. I'd scan the source files with ReplayGain first. If the album peak is over 0.9, especially on more than one track, add -1 dB gain during encoding with DSP, and you shall avoid most, except theoretically the highest frequency, less audible clippings.

A more thorough method that still avoids dealing with the command-line: Resample the album with SoX in Foobar to a temporary file(s), I'd choose a disk image (generate multi-track files), scan that file with ReplayGain, and note the peak. Now encode the album, and add negative gain to bring the peak below -0.5 db or 0.94.

Quote
How about simply encoding it, then apply replaygain in foobar?
That wouldn't avoid clipping potentially created during resampling with SoX, because the encoder doesn't accept samples over full scale. Other encoders (Vorbis, Opus, FhG AAC, QAAC) don't have this limitation.

I don't think the issue with clipping is significant on audio that isn't distorted already. At high bitrate, I find a margin of 0.5 db to be sufficient.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #15
....Also IIRC -m j and -h are default settings and can be omitted.

Just to be clear, This statement only applies to VBR encoding. Because even though the default is -q3, when using VBR, q values from 0 to 4 are mapped to 0. -h would be 2 which would also be mapped.

But when using CBR the q values do have different effects. Again, default is -q3. -h is just -q2, which is a good high quality/performance trade off. But using -q0 should be the best quality with the slowest encoder performance, even if the difference in quality is negligible.

Code: [Select]
Noise shaping & psycho acoustic algorithms:
    -q <arg>        <arg> = 0...9.  Default  -q 3
                    -q 0:  Highest quality, very slow
                    -q 9:  Poor quality, but fast
    -h              Same as -q 2.
    -f              Same as -q 7.   Fast, ok quality

http://wiki.hydrogenaud.io/index.php?title=LAME_-q_switch


Re: 24bit/96khz FLAC audio to MP3 320k

Reply #17
You'd think that smaller q values should be better. But all they seem to do in current Lame, is make the encoding much slower, and pad the stream with unused bytes of ancillary data. A regular track with no silence at CBR 320: 1 kbps ancillary data in default mode, 7 kbps with -q 2, 11 kbps with -q 0.

-q 3 used to be the same as -q 2 ("high") back when presets were the recommended mode. Then the q was remapped when a new q 0 was added. I'm surprised that -h wasn't changed. The default looks to be high enough.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #18
Hi, is it true Lame downscales the source using internal resampler even if it's 24/44.1?
I think it's not true as it should process up to 32/48 but not quite sure about that.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #19
Lame does not truncate the bit depth prior to encoding. It has internal range of more than 200 dB. On the plus side I tried +60 dBFS in Reaper 5.17 without obvious saturation. You can test this by applying a fadeout to a sound clip, then amplifying it after decoding again. However, music rarely gets quiet enough to make use of the extra bit depth above 16 bits. There will be loss of accuracy from encoding, as usual, 20..40 db below the most quiet sound. The encoder (in CBR) permits you generous leeway with choosing recoding level, with option to normalize afterwards.

The internal resampler is used if input samplerate is non-standard, greater than 48 kHz or a very low bitrate is requested.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #20
Could you prove that?

The type for holding a sample interally is of type sample_t, defined in machine.h:
https://github.com/rhishi/lame/blob/master/libmp3lame/machine.h#L135
https://github.com/rhishi/lame/blob/master/libmp3lame/machine.h#L159-L160

Code: [Select]
135 typedef float FLOAT;
...
159 /* sample_t must be floating point, at least 32 bits */
160 typedef FLOAT sample_t;

The term "float" referes to a 32-bit single-precision floating point number as defined in IEEE 754, called binary32

This variable type is used throughout the LAME encoder, a good example is obviously lame_encode_mp3_frame() in encoder.c:
https://github.com/rhishi/lame/blob/master/libmp3lame/encoder.c#L305 (and the following lines).

The source code contains relatively nice markings and explanations in comments, especially right in front of the function definition.

Further meta information is available in encoder.h. The function siganture definition of lame_encode_mp3_frame() illustrates the use of sample_t:
https://github.com/rhishi/lame/blob/master/libmp3lame/encoder.h#L152-L154

Code: [Select]
152 int     lame_encode_mp3_frame(lame_internal_flags * gfc,
153                               sample_t const *inbuf_l,
154                               sample_t const *inbuf_r, unsigned char *mp3buf, int mp3buf_size);

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #21
Another of my favorite aspects of LAME is that it pads the start and end of the track to even frame sizes using silence, not extrapolation like Vorbis and Opus do.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #22
I made a horrible mistake clipping in Reaper with Utility/volume, because I had a different one in the old install. There is no clipping in latest version of Reaper when saving to MP3. Vorbis and Opus do clip, however. They seem to follow a safe practice of clamping the range just in case.

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #23
Vorbis and Opus do clip, however. They seem to follow a safe practice of clamping the range just in case.
Do you mean they clip only in Reaper? Because usually they don't clip. I encoded file in 32 bit floating point with peak +10 dBFS to vorbis and opus using fb2k and peak is saved.

 

Re: 24bit/96khz FLAC audio to MP3 320k

Reply #24
Yes, only in Reaper. When clipping in the MP3 codec was brought up a few years ago, the developer of Reaper was concerned that the encoder might behave incorrectly if given unlimited input. He used floating point format, but applied a limit to the range. Perhaps similar concerns are a reason why other software clip or fall back to fixed-point format.

 
SimplePortal 1.0.0 RC1 © 2008-2018