--alt-preset should use --scale 1

[tangent]

Most of the --alt-preset settings include a --scale setting which varies depending on the bitrate selected with --alt-preset. I recommend overriding this by adding "--scale 1" at the end of commandline you are using, e.g. "--alt-preset 128 --scale 1". Without that --scale 1, "--alt-preset 128" defaults to a --scale of 0.93

Why override the --scale? Either you normalize your wav before you encode or you don't. If you don't, then assuming you are ripping off DVD which tend to be low volume, you don't have to worry about clipping anyway. If you do normalize before encoding, then I assume you are already normalizing to a sensible maximum (e.g 93% if you intend to use --alt-preset 128). Scaling another time by 0.93 is probably something you don't want to do.

Personally, I prefer not to mess with the wav before encoding. I use mp3gain (http://www.geocities.com/mp3gain) to find the optimal gain for the mp3 which provides the maximum volume which doesn't cause clipping. This global gain is written into the frame headers of the mp3 and is then applied by the mp3 decoder during playback.

[ohliuv]

@tangent: is all of the above valid also when using graphedit with InterVideo audio decoder to extract .wav?

[zulu]

hey tangent,
good idea to continue discussing this topic here on doom9's site ;)

i agree that first normalizing in azid and then downscaling in lame is a bad idea.

until now, for me this was the way to go:

first,
decoding in azid using -C normal -L -3db -g xxx.
as u can see i use dynamic range compression and set the gain to xxx
where xxx is the maximum gain determined in a previous pass.

second,
mp3 encoding in lame using --alt-preset xxx --scale 1.

now my question:

what gain to use in azid to prevent clipping with lame.
is there a way to find the optimal/highest possible gain which doesn't introduce clipping?

or...

...what about this way:

1. azid -C normal -L -3db (without -g gain increase)

2. lame --alt-preset xxx --scale 1

3. mp3gain

is normalizing in mp3gain (step3) equal to increasing the gain in azid (step 1), but prevents clipping?

confused...:confused:

[tangent]

Originally posted by ohliuv
@tangent: is all of the above valid also when using graphedit with InterVideo audio decoder to extract .wav?

Yup. I believe you're just using InterVideo rather than Azid to decode to .wav

[tangent]

If you want to scale your wav (either with lame's --scale or Azid's -g) before encoding with lame, there is no way to find the "optimal/highest possible gain which doesn't introduce clipping". Simply because you do not know how the sample will be decoded. The values defaulted in the --alt-presets are just estimates. If you want to avoid LAME's --scale and only use Azid's -g, then you have to calculate a new -g value to use. For example, if you're using --alt-preset 128, the recommended --scale is 0.93, which translates to -1.26dB, so subtract 1.26dB from whatever gain value Azid recommends to you from the first past.

If you use mp3gain instead, this is what happens. You leave everything alone without normalizing or scaling before encoding. After encoding, mp3gain will decode the mp3 and determine what is the maximum peak level. Mp3gain will then determine the optimum noclip gain, and then write this value to the headers of all the frames in the mp3. This will tell the decoders playing back the mp3 to decode using this gain when decoding. The limitation of this method is that (until replaygain is fully implemented), the frame headers can only modify the gain in 1.5dB steps. This is usually good enough for all purposes though.

Using mp3gain and Azid's -g are two different methods. I think you can see that mp3gain's method is superior because you don't have to guess at the gain value, and that the gain change process is as lossless as you can get.

[zulu]

i read the mp3gain docs and consider to modify the way i transcode ac3 to mp3, now.

i want to create a batch file with the following steps, but there are still a few questions:

1. azid -C normal -L -3db

you recommend to leave everything alone without normalizing or scaling before lame encoding. does this also count for dynamic range compression (-C normal), or does it only concern the gain (-g) switch?

2. lame --alt-preset xxx --scale 1

3. mp3gain --???

what switches do you use for mp3gain?


do you have to correct/add something?


btw.: i can't remember to read about the clipping issue in doom9's docs, does nobody here care about it?

thanks in advance

[DarkAvenger]

Some people will never learn it.:rolleyes:

Use BeSweet or HeadAC3he and you have no problems whatsoever!!! In HeadAC3he you can set the normalizing to eg. 98% and no clipping will occur and you have a perfect *lossless* normalized file in the end.

About that --alt preset stuff, matter says it works with HeadAC3he with the hacked DLL, though I have not really tried it.
Or decode to a 24bit int 98% normalized WAV with HeadAC3he and then use lame.exe and you will still have a better sounding file in the end than with tangent's method.

You can still use mp3gain on the normalized (by BeSweet or HeadAC3he) file...

there is no way to find the "optimal/highest possible gain which doesn't introduce clipping"

Someone really didn't understand how our programs work..., so this statement is ########.

[tangent]

Originally posted by zulu
1. azid -C normal -L -3db
2. lame --alt-preset xxx --scale 1
3. mp3gain --???

This looks fine.
I don't use the mp3gain.exe directly, but the GUI. Load up the GUI, select your mp3, click on "Radio Analysis". After the analysis is done, go to the "Modify Gain" menu and select "Apply Max Noclip Gain".

[tangent]

Originally posted by DarkAvenger
Some people will never learn it.:rolleyes:

Use BeSweet or HeadAC3he and you have no problems whatsoever!!! In HeadAC3he you can set the normalizing to eg. 98% and no clipping will occur and you have a perfect *lossless* normalized file in the end.

About that --alt preset stuff, matter says it works with HeadAC3he with the hacked DLL, though I have not really tried it.
Or decode to a 24bit int 98% normalized WAV with HeadAC3he and then use lame.exe and you will still have a better sounding file in the end than with tangent's method.

You can still use mp3gain on the normalized (by BeSweet or HeadAC3he) file...

Someone really didn't understand how our programs work..., so this statement is ########.

I think you don't understand the problem with LAME encoder clippings. At lower bitrates with more quantisation errors and missing frequency coefficients, reconstruction of the waveform during decoding will often cause clipping to occur. The clipping can be so bad that you need to scale to 85% to prevent clipping at the low bitrates. The --alt-presets have been thoroughly tested and have defaulted --scale values for different bitrates. Let me point you to the sourcecode where the recommended values are defined:


const dm_abr_presets_t abr_switch_map [] = {
// kbps Z X lowpass safejoint nsmsfix ns-bass scale
{ 80, 1, 1, 13500, 0, 0 , -3, 0.85 }, // 80
{ 96, 1, 1, 15300, 0, 0 , -4, 0.85 }, // 96
{ 112, 1, 1, 16000, 0, 0 , -5, 0.87 }, // 112
{ 128, 1, 1, 17500, 0, 0 , -6, 0.93 }, // 128
{ 160, 1, 1, 18000, 0, 0 , -4, 0.95 }, // 160
{ 192, 1, 1, 19500, 1, 1.7 , -2, 0.97 }, // 192
{ 224, 1, 1, 20000, 1, 1.25, 0, 0.98 }, // 224
{ 256, 0, 3, 20500, 1, 0 , 0, 1.00 }, // 256
{ 320, 0, 3, 21000, 1, 0 , 0, 1.00 } // 320
};


As you can see 98% is not sufficient for most of the commonly used bitrates. The other problem is that clipping is pretty much random. There is no way to tell how much a sample will clip before you actually encode it and then decode it. The values defaulted in the --alt-preset are just recommended which will cut out most clipping, but you can never be sure if you are applying too much attenuation than you need or if you are applying enough. Not until after you encode it and decode it.

[DarkAvenger]

OK, even with this, then set normalize to 85% (or to that amount that will suit your target bitrate) and go. Then you can still use mp3gain. Still better than doing a "plain" decode and then using mp3gain. Nevertheless, I don't think than one or two clipped samples will lead to a big problem.

[tangent]

When you say "plain decode" do you mean decoding to 16 bit wav or decoding without gain?

I can understand that it's definitely superior (although whether the differences can be perceived) to decode the AC3 stream to a 24bit or fp wav. However, it is doubtful whether increasing the volume to maximum before encoding affects the quality of the encode.

I've actually discussed this with Robert (from LAME) recently, and what he said was that there will be differences, but really minimal because the gains we deal with (approximately 3-6dB) do not affect the ATH that much. Furthermore, LAME has some implementations of an ATH which automatically adjusts to the local level of the sample. Of course there will be some effect, but it is also very doubtful whether it is good or bad because it is a 2 sided issue. By normalizing, you may be introducing noise or inaudible tones above the ATH. Besides added noise, less bits are available to encode the more audible tones which will of course degrade the quality of the audible tones. On the other hand, if you do not normalize, audible harmonics may occasionally fall under the ATH and not be encoded but I feel that this is rather rare.

It will be interesting if I can get a grouped blind listening test to test this effect. I will see if I can arrange one, if you are interested.

Just out of curiosity, does BeSweet/HeadAche decode the AC3 directly to a 24bit/FP PCM stream or to a 16bit PCM stream before applying 24bit/FP normalizing?

[DarkAvenger]

When you say "plain decode" do you mean decoding to 16 bit wav or decoding without gain?

both :)

I were not referring to Lame's ATH stating that a norm. prior would make sound better. I dunno know much about LAME, so I don't know the effects. I am just speaking of the decoded WAV and the norm. will of course be sounding better, as the snr is much higher. So unless LAME's ATH is stupid (of course I beleive it is not), the result should be better as well.

It will be interesting if I can get a grouped blind listening test to test this effect. I will see if I can arrange one, if you are interested.

Well, you can arrange it, but I won't take part, as I don't have time for this. My PC sound system is not good enough. And testing with my amp and CD player is very time intensive.

Just out of curiosity, does BeSweet/HeadAche decode the AC3 directly to a 24bit/FP PCM stream or to a 16bit PCM stream before applying 24bit/FP normalizing?

I can't speak for DSPGuru (though he probably is smart enough to not do the second option), but of course the conversion is directly done to 24bit int PCM (I don't have 24bit float PCM target). But normalizing is done in 32bit float range (except hybrid mode, but here only negative gains are applied, you the snr will be the nearly the same, only minor rounding errors will of course be there), so it is virtually lossless! Even more, sometimes I am stupid, as well: You can set normalize to to 100% when using hacked lame_enc.dll (and presuming it works), since, as you stated, it will automatically scale down. Since we don't leave the 32 bit float region in a direct ac3->mp3 conversion, lame's scaling then should be virt. lossless, as well!

[tangent]

I don't doubt that using fp/24bit PCM, maybe with normalizing, will result in better quality WAVs. However, I am pretty much uncertain about the perceptivity of the quality differences. It's true that you get a very high SNR, but let's not forget that the actual SNR cannot really be higher than what has been limited by (a) the recording process, (b) prior audio manipulation processes, and (c) the playback process. Mostly the errors and inaccuracies in leaving things alone will be limited to bit errors, probably imperceptible to many.

For example, although we know that theoretically, things like dithering and SSRC's resampling techniques are superior, listening tests have shown that the difference is next to imperceptible even to expert listeners.

What does make a difference and is very perceptible is the MP3 encoding process. A good mp3 encode is easily distinguished from a bad mp3 encode. I would say that an AC3 soundtrack decoded into 16bit wav and encoded with lame --alt-preset 128 will easily sound better than the same AC3 soundtrack going through BeSweet or HeadAche high precision conversion process and being encoded with the default lame abr 128 parameters.

Another easily perceptible artifact, of course, is clipping. Unfortunately, very little attention has been paid to this as far as for the guides I have seen.

I don't doubt that BeSweet and HeadAche have a superior technical process in decoding to wav and feeding it into the LAME encoder. But I think that not being able to use the ABR --alt-presets becomes a severe handicap. I understand that most of the VBR --alt-presets are supported now, but not the ABR/CBR so far, but really VBR is not as useful for practical ripping purposes.

By the way, since the --alt-preset ABR/CBRs do not (currently) use custom tweaks and are all just parameters setting, perhaps if you are able to modify the parameters used when using the lame dll to be the same as the ones specified for the --alt-preset (see the sample of the source code in my previous message and parse.c in CVS), you can reproduce the ABR/CBR --alt-preset settings for the lame dll encoder.

[DarkAvenger]

Ok, slowly you are getting it, but still you didn't read correctly.

I said, don't go for direct converion, decode to wav! Then you can use lame.exe with alt-presets and using HeadAC3he to create the WAV will be def. better than using azid.exe and in hybrid mode it is only a little bit slower than one-pass decoding (azid.exe).

You are right about the official dll. DSPGuru is making his own mods to it, but I rather wait till the offical one have a good preset system with which you can choose the alt settings, as well.

I never recommended to use the .dll though one advantage is that you need not to go down to integers anymore and you don't need to pay attention to the norm. value. Nevertheless, since to the better tweaking I still recommend using the Lame.exe.

Have you tried using HeadAC3he in hybrid mode (wav decode!)? You will see how fast it is, and using 24bit pcm (which lame.exe can read) is nearly as good as having 32bit floats.

[zulu]

I said, don't go for direct converion, decode to wav! Then you can use lame.exe with alt-presets

what's the best commandline to do this in besweet?

-core ( -input in.ac3 -output out.wav -2ch ) -azid( -L -3db -c normal -g max) ?

does it give me a better result than using first azid with find-max-gain-pass and then using lame --alt-preset?
does it also prevent clipping?

TIA

[tangent]

If you intend to use mp3gain at the end, don't use -g. Instead, use lame --alt-preset xxx and set --scale 1.

If you don't intend to use mp3gain, then use first pass to find the recommended -g, then modify the recommended -g using this table (subtract dB-modify from the recommended -g), and set lame -alt-preset xxx to --scale 1.


bitrate scale dB-change
80 0.85 -1.41
96 0.85 -1.41
112 0.90 -0.92
128 0.93 -0.63
160 0.95 -0.45
192 0.97 -0.26
224 0.98 -0.18
256 1.00 0



If you find yourself too lazy, then use the recommended -g and leave lame --alt-preset alone without a --scale setting.


EDIT: Used a less ambiguous sentence structure. Thanks to doom9 for pointing it out to me.

[zulu]

@tangent:
thanks for the table, i'll implement it in my frontent app i use to automate azid/lame. how are the db-changes calculated?

i'm still interested in an answer regarding besweet in my previous post.

[para]

Originally posted by tangent

I think you don't understand the problem with LAME encoder clippings. At lower bitrates with more quantisation errors and missing frequency coefficients, reconstruction of the waveform during decoding will often cause clipping to occur. The clipping can be so bad that you


This kind of clipping does not occur while encoding but during decoding. The --scale xxx approach is a work-around as long as not all MP3 players support MP3gain.

The best approach is to find the maximum gain with Azid and encode with --scale 1. The decoder should take care of the clipping then. That's exactly the way replaygain for Musepack by Frank Klemm works.

I know that currently there is no DirectShow MP3 playback filter that takes care of the MP3gain value, but hopefully there will be one.

Basically it comes down to two options:

[list=1]
You can't wait for the filter: encode with --scale 0.xx
You can wait, encode with --scale 1 and enjoy a slightly better quality when such a filter comes out
[/list=1]

Best regards,
para

[tangent]

@zulu

20 log (scale)
That's a base-10 log.

Originally posted by para

This kind of clipping does not occur while encoding but during decoding. The --scale xxx approach is a work-around as long as not all MP3 players support MP3gain.


You are mixing up Global Gain (used in MP3Gain) and Replay Gain. MP3Gain does NOT use Replay Gain (which to date no MP3 players I know of support it), but uses something which is supported by ALL mp3 players because it is part of the MP3 standard and file format. It is a value written in the frame header. The limitation is that gain can only be adjusted in steps of 1.5dB while the proposed Replay Gain standard allows gain to be adjusted in 0.01dB steps.

[para]

I stand corrected :rolleyes:. Thanks for the information.

Best regards,
para