best mp3 preset and settings for 128 kbps CBR Options

[Rio]

you can try FhG ACM for your 128 CBR

[m3gab0y]

As I understand it, v2 downsamples the audio to half its sample rate, then replaces the lost frequencies with a simulation. That would mean in this case downsampling to 48 kHz, then replacing everything that was lost above 24 kHz with simulated audio.

Correct. That's the idea of dual-rate Spectral Band Replication (SBR).

What audio above 24 kHz is it simulating???

Nothing. There is nothing above 21 kHz. I think the idea here was to avoid the core-coder (AAC-LC) downsampling but still use the bandwidth extension functionality of SBR (which starts at ~17 kHz and ends at 21 kHz here).

Not a bad idea in principle, except that with 256 kb available you can simply encode to AAC-LC with 20 kHz bandwidth or so (i.e. no need for bandwidth extension).

Chris

And you can take into account that there's absolutely nothing above 16 KHz in this stream (except some almost inaudible noice), because it's a radiostation and the lowpass filters take care of everything above 16 KHz.

you can try FhG ACM for your 128 CBR

I've tried it, but my software doesn't like ACM codecs and I can't tweak any settings, except bitrate, sample rate, and channel mode (mono/stereo)
With it's default settings for 128 kbps 44 KHz Stereo, Lame 3.93.1 outperforms it.
Also, for me, Lame 3.98.4 is a bit rough on the high frequencies, and in my opinion, 3.93.1 sounds a little better.
I've also tested LC-AAC, HE-AAC and OGG/Vorbis. They all sound one idea better than mp3 encoder, but I've expected more
Judging by my ears,OGG/Vorbis is the best, followed closely by LC-AAC. HE-AAC produces weird artifacts in the high frequencies at 128 kbps.

So far, the quality is acceptable, but I'm considering alternative streams

Any more suggestions for a way to tweak the settings, or use different mp3 coders are welcome

[Rio]

well, lame 3.93.1 is a favorite over newer versions in the case of 128 CBR. to suit fm streaming, you could lowpass it at 16khz or downsample it to 32khz. don't forget -h

[m3gab0y]

well, lame 3.93.1 is a favorite over newer versions in the case of 128 CBR. to suit fm streaming, you could lowpass it at 16khz or downsample it to 32khz. don't forget -h

Downsampling to 32 KHz messes up the quality badly.
I use the quality=0 switch (0 being the best, 10 the worse), adding a -h switch in combination with this may cause problems. Correct me if I'm wrong.
As I mentioned in my first post, I use highpass and lowpass filters at the studio. The audio transfer to the encoder (and the transmitter) is digital and lossless (SPDIF interface). Would specifying a lowpass filter in the encoding parameters inprove the quality?

[2Bdecided]

HE-AAC produces weird artifacts in the high frequencies at 128 kbps.

Have you tried standard AAC at 128kbps?

Cheers,
David.

[2Bdecided]

I use equivalent equipment, and the level is normalized, the tracks probably filtered (lowpass + highpass) before going into the compressor, limiter, clipper and, finally, the transmitter and the encoder.

Do you mean you're transmitting on FM as well as encoding for the net?

If so, I don't think it's a great idea to send the same audio to both. Most obviously, a clipper that's taking account of FM pre-emphasis is sub-optimal for digital - and that's even if you accept the use of a clipper. Most people encoding for the web don't feel the need to maximise levels in the same way as they do for FM, and many adopt an entirely different "sound" from a separate processing chain.

Plenty of stations here in the UK still use fairly aggressive processing for their net streams, but then keep the final audio peaking at -1dB, -3dB or even -6dB FS. This isn't a mistake: they just don't like the sound that 0dB FS compressed audio can make when it goes through some common sound cards, and some versions windows mixer / sound card drivers. Not to mention the inevitable clipping due to lossy encoding (which is usually irrelevant after all that processing).

Cheers,
David.

This post has been edited by 2Bdecided: Jun 10 2011, 11:35

[DonP]

And you can take into account that there's absolutely nothing above 16 KHz in this stream (except some almost inaudible noice), because it's a radiostation and the lowpass filters take care of everything above 16 KHz.

No need to lowpass the internet stream to 16 khz just because it's an FM station.

[pdq]

I use the quality=0 switch (0 being the best, 10 the worse), adding a -h switch in combination with this may cause problems. Correct me if I'm wrong.

I seem to recall that the -q 0 switch was buggy in early versions of lame, or am I wrong?

[m3gab0y]

HE-AAC produces weird artifacts in the high frequencies at 128 kbps.

Have you tried standard AAC at 128kbps?

Cheers,
David.

Yes. It sounds one idea better on the hights

I use equivalent equipment, and the level is normalized, the tracks probably filtered (lowpass + highpass) before going into the compressor, limiter, clipper and, finally, the transmitter and the encoder.

Do you mean you're transmitting on FM as well as encoding for the net?

If so, I don't think it's a great idea to send the same audio to both. Most obviously, a clipper that's taking account of FM pre-emphasis is sub-optimal for digital - and that's even if you accept the use of a clipper. Most people encoding for the web don't feel the need to maximise levels in the same way as they do for FM, and many adopt an entirely different "sound" from a separate processing chain.

Plenty of stations here in the UK still use fairly aggressive processing for their net streams, but then keep the final audio peaking at -1dB, -3dB or even -6dB FS. This isn't a mistake: they just don't like the sound that 0dB FS compressed audio can make when it goes through some common sound cards, and some versions windows mixer / sound card drivers. Not to mention the inevitable clipping due to lossy encoding (which is usually irrelevant after all that processing).

Cheers,
David.

There's a seperate processing chain for the FM output and the net stream. The FM is 100% modulation at all times, while streaming is -2dbFS for mp3, -4dbFS for AAC+ at all times. There is NO pre-emphasis sent to the encoder, and therefore no pre-emphasis clippers involved there. This happens on the transmitter site, where it's supposed to

p.s. here is what the station sounds like on the net at 128 kbps mp3 CBR.

And you can take into account that there's absolutely nothing above 16 KHz in this stream (except some almost inaudible noice), because it's a radiostation and the lowpass filters take care of everything above 16 KHz.

No need to lowpass the internet stream to 16 khz just because it's an FM station.

At this moment, due to the setup, I can't remove the lowpass filter. This will happen in the near future. So, at the moment, I'm limited to 16 KHz lowpass.

I use the quality=0 switch (0 being the best, 10 the worse), adding a -h switch in combination with this may cause problems. Correct me if I'm wrong.

I seem to recall that the -q 0 switch was buggy in early versions of lame, or am I wrong?

Someone told me to use -q 3 instead of 0, I have to try it.

This post has been edited by m3gab0y: Jun 10 2011, 14:15

[db1989]

-h simply maps to a given -q value (unsure which), so the only 'problem' it might create is a conflict between that and your specified -q0 (depending on which takes priority).

[Rio]

well -h is equivalent to -q0, but if you go with -q0, no need to add -h

[db1989]

-q0, in CBR? Last I knew, it was equal to -q3 and previously -q2, or vice-versa.

[pdq]

For years there has been all of this confusion about -h and -q and what each does in which version and with what kind of file. Best advice is to go with the default. which has always worked well, and avoid these switches entirely.

[mixminus1]

-h has always mapped to -q 2 since at least 3.90.3 (verified in the documentation).

@pdq: Yes, -q 0 could actually *increase* artifacts in some versions of LAME when used with CBR encoding.

Edit: I was referring to pdq's earlier post re: -q 0, but I think it should be clear by now that, yes, the -q/-h switches should just be left alone.

This post has been edited by mixminus1: Jun 10 2011, 15:30

[m3gab0y]

-h has always mapped to -q 2 since at least 3.90.3 (verified in the documentation).

@pdq: Yes, -q 0 could actually *increase* artifacts in some versions of LAME when used with CBR encoding.

Edit: I was referring to pdq's earlier post re: -q 0, but I think it should be clear by now that, yes, the -q/-h switches should just be left alone.

I will set q to 2 and check the results.

p.s. I use preset=12 and I have absolutely no idea what kind of pre-defined settings are set in there (I couldn't find any accurate info for this specific preset number). In the encoder quality setting is not specified by default, nor preset.

This post has been edited by m3gab0y: Jun 10 2011, 16:20

[pdq]

I will set q to 2 and check the results.

No, the recommendatioin was to not set it at all.

p.s. I use preset=12 and I have absolutely no idea what kind of pre-defined settings are set in there (I couldn't find any accurate info for this specific preset number). In the encoder quality setting is not specified by default, nor preset.

What front end are you using? preset=12 is not a lame switch, as far as I know.

[m3gab0y]

What front end are you using? preset=12 is not a lame switch, as far as I know.

As I mentioned in the beggining:

I currently use edcast with Lame 3.93.1 using preset=12 and quality=0 and I'm getting decent results.

[pdq]

You need to check your edcast documentation then to see what lame switches that corresponds to. quality=0 may have nothing to do with the -q switch.

[mixminus1]

*Now* I remember what this was about: "preset=12" is an edcast/Icecast setting in the .ini that is sent to the lame_enc.dll to invoke standard CBR encoding, as opposed to a VBR preset.

I was actually able to dig up an email from years ago regarding that, and here are all the Ed/Icecast presets and what they map to in the .dll:

CODE

LQP_NORMAL_QUALITY = 0,
LQP_LOW_QUALITY = 1,
LQP_HIGH_QUALITY = 2,
LQP_VOICE_QUALITY = 3,
LQP_R3MIX = 4,
LQP_VERYHIGH_QUALITY = 5,
LQP_STANDARD = 6,
LQP_FAST_STANDARD = 7,
LQP_EXTREME = 8,
LQP_FAST_EXTREME = 9,
LQP_INSANE = 10,
LQP_ABR = 11,
LQP_CBR = 12

I have no idea what the "normal/low/high/voice" of 0-3 map to, and that fact that good ol' "r3mix" is in there gives you an idea of how old those presets are, but preset 12 does/did give better results than preset 0 at the same bitrate.

Also, IIRC ( ) the "quality=" switch didn't map directly to LAME's -q switch, i.e. it invoked the -q switch, and lower numbers were higher quality, like LAME, but I don't think it was a 1:1 relationship - I never saw any actual documentation on that, though.

In any event, "preset=12" does give the best quality CBR encoding in Ed/Icecast, and the "quality=" parameter is something of a wildcard, although it should be at least set to 3 because I think the default was 5, and that did make at least a bit of an improvement with CBR.

[Rio]

oh my, i meant -h equals -q2