Downmixing AC3 5.1 to MP3 2/0 keeping surround information

[numaios]

Hello!

I used to encode AC3 files to MP3 using this command line in AZID decoder: -s stereo -c normal -L -3db and encoding to joint-stereo MP3 files (112-128 kbps).

But now I have read that I can keep the surround information by using -s dpl or -s dplii instead of -s stereo.

-Are this settings recommended for a 1CD-rip of an episode or a movie?
-Is suitable to use more bitrate? 192 kbps, for example?
-Does -s dplii need more bitrate than -s dpl to achieve a good result?
-Can I still use joint-stereo? Or real stereo is needed?
-What about DRC? Can I still use the "normal" setting?
ADD:
-If I don't use -d 2/2, am I missing the rear channels information?
-The default setting -d 2/0 only takes information from the front channels, doesn't it?
-So the suitable command line would be this one? -s dplii -d 2/2 -c normal -L -3db or this one? -s dplii -d 2/0 -c normal -L -3db -f1

Thank you very much.

[shon3i]

You need some dpl decoder, maybe ffdshow can do that, but i am not sure. Aslo i heard that Joint stereo (any) not good for DPL encodes because destroys surround information.

112-192 is good anyway, but i wll not go upper than 128, and not under 96 for my encodings, because there is no reason for higher/lower bitrate. And normal DRC is recommended.

[numaios]

But even if I don't have a pro logic decoder, I will still get a correct stereo downmixing, won't I?

Aslo i heard that Joint stereo (any) not good for DPL encodes because destroys surround information.
Always? Mid Side Joint-stereo also does?

[Skelsgard]

-Are this settings recommended for a 1CD-rip of an episode or a movie?

Is actually a choice.

-Is suitable to use more bitrate? 192 kbps, for example?

Yes (as higher bitrate, higher quality), but not mandatory.

-Does -s dplii need more bitrate than -s dpl to achieve a good result?

Nop.

-What about DRC? Can I still use the "normal" setting?

Yes.

-Can I still use joint-stereo? Or real stereo is needed?

I disagree with shon3i, as joint-stereo M/S Stereo is matrix-preserving and can be perfectly used for DPL, against Intensity Stereo wich is not recommended at all.

Cheers.

[numaios]

Thank you very much!

Yes (as higher bitrate, higher quality), but not mandatory.So, for the same bitrate, using surround output won't give less quality than stereo output?

Do you know an answer to my last questions?

ADD:
-If I don't use -d 2/2, am I missing the rear channels information?
-The default setting -d 2/0 only takes information from the front channels, doesn't it?
-So the suitable command line would be this one? -s dplii -d 2/2 -c normal -L -3db or this one? -s dplii -d 2/0 -c normal -L -3db -f1

[shon3i]

I disagree with shon3i, as joint-stereo M/S Stereo is matrix-preserving and can be perfectly used for DPL, against Intensity Stereo wich is not recommended at all.
Am not sure about that, i see that on Hydrogenaudio forums, in some Joint stereo thread, where is ppl talking about M/S coding, and doing some tests, where corectly showed destroyed surround effects. (so we now live IS which is destroyable in any way), Anyway for higher bitrates lame uses less MS frames, on 160 and higher bitrates is sometimes better to turn off M/S. FOr movies you can safetly turn off JS/MS.

[numaios]

But full stereo is not recommended at 128 kbps, so although some effects were destroyed, I would get more effects with -s dplii & J-S than with -s stereo & J-S, wouldn't I?

[gameplaya15143]

But full stereo is not recommended at 128 kbps, so although some effects were destroyed, I would get more effects with -s dplii & J-S than with -s stereo & J-S, wouldn't I?

Try it and find out :)

I tried a small js v stereo dpl2 test before, but I can't remember if there was much of a difference. I think the stereo one had slightly better sound in the rear speakers (used ffdshow to upmix). I was using vbr though, so stereo also had a higher bitrate. :rolleyes:

[numaios]

Thanks! But I was asking about dpl2+js@128 Vs. stereo+js@128, not dpl2+js Vs. dpl2+s.

But you have already answered a question that sooner or later would have come to my mind. Thank you again :)

[tebasuna51]

Another opinion.

To ac3 decode:
-s dplii -d 2/0 -c normal
-L -3db Optional. Not recommended by Dolby
-f 1 Optional. Only if you experiment phase problems.

To mp3 encode:
-b 128 [-m j]
-b 192 -m s

In my test the dpl information are preserved with joinstereo mid/side.

[numaios]

Thank you :)

-s dplii -d 2/0 -c normal Does "-d 2/0" keep the information from the rear channels? Or it only decodes the front channels?
-L -3db Optional. Not recommended by DolbyNot recommended for dplii output? Or it's never recommended, even for stereo output?

So if I want to encode to -b128 -m j, can I safely decode with -s dplii? Or it's better to stay with -s stereo?

[tebasuna51]

Does "-d 2/0" keep the information from the rear channels? Or it only decodes the front channels?
-d 2/0 (not necessary because is default) only say the number of output channels. If the source is 5.1 the downmix method is fixed by the parameter -s (default dpl)

Dpl make something like this downmix:
Ls = L + 0.7 C - 0.7 BL - 0.7 BR
Rs = R + 0.7 C + 0.7 BL + 0.7 BR
We can recover 4 channels L, R, C, S (BL + BR)

Dplii make something like this downmix:
Ls = L + 0.7 C - 0.8 BL - 0.5 BR
Rs = R + 0.7 C + 0.5 BL + 0.8 BR
We can recover 5 channels L, R, C, BL, BR

Stereo downmix is:
Ls = L + 0.7 C + BL
Rs = R + 0.7 C + BR

Not recommended for dplii output? Or it's never recommended, even for stereo output?
From 214_Mixing with Dolby Pro Logic II Technology.pdf :
"There are other concerns when adding an LFE signal to the mix. If the LFE is simply redistributed within the other channels of the mix, they will usually be subject to some low-frequency bandpass filtering. This filtering causes phase shifts of the LFE signal. When they are acoustically added within a room, these phase shifts are fairly subtle and often go unnoticed. However, when they are electronically added together with the five main channels in the encoder, they may produce less than desirable results at certain frequencies. For this reason, it is recommended that the LFE signal not be used in a Dolby Pro Logic II downmix unless it contains unique information that is not repeated in any of the five main channels."
Maybe the comment can also serve for stereo, but is a personal choice.
So if I want to encode to -b128 -m j, can I safely decode with -s dplii? Or it's better to stay with -s stereo?
For me the choice stereo/dplii is not related with bitrate. I always select dplii because I have players with dpl decoders.

I select the bitrate by the source quality and the size needed,

I forget a parameter I use always with -c normal -s dplii, -a (--maximize).

[3dsnar]

I would recommend to donwmix LFE, because during upmixing it will go only to C and subwoofer (assuming that you will donwminx LFE in similar way as you downmix C).

Since the center speaker is usually used for speech, its frequency characteristics is not very wide, hence usually the low frequencies are not reproduced.

The only problem is that when you add LFE, the total gain will be lower (assuming that you want to avoid clipping), because it must be considered during DPLII weights normalization (or downmixed channels renormalization).
However personally I prefer to leave the LFE and adjust gain of my HT amp during playback if it is not loud enough :)

[Rockaria]

..If the LFE is simply redistributed within the other channels of the mix, they will usually be subject to some low-frequency bandpass filtering...
...
That's a good point when we consider the LFE is also an important component.
I also noticed stacking the front-mix(L/R,C,LFE) to the phase shifted(+-90 deg) rear-mix somewhat altering the rear channel seperations, let alone the invert-only versions.
And I believe we must also consider the SUB-Woofer redirecting of the LFE signal depending on the each different receiver setting. When I tested mixing the LFE to the rears, I found it actually reproduced the richer bass & better channel seperations than the simple mixing to the center(fronts).

Now if we are finally discussing based on the Dolby's documents(although a lot mixed with DPL I concepts), I STILL definitely believe we must FULLY present the Dolby's DPL II formula or matrix(+- 90deg rear phase shifts) not to mislead any more, regardless of the prev. investments, if any. We can also find the wikipedia updated the matrices since then to represent the CORRECT phase relations. http://en.wikipedia.org/wiki/Dolby_Pro_Logic

Another thing we must consider is that the DPL II matrices represented are the linear sound levels relative to the two fronts.
So, not to make the results clip, it is very natural to consider that the pre-attenuation(relatively enough, no absolutely optimized magic numbers) & post-normalization(or RG) should be applied to the mixing process before the final encoding to any phase-preserving-formats. http://en.wikipedia.org/wiki/Replay_Gain

[numaios]

OK, thank you guys for your great explanations.

For me the choice stereo/dplii is not related with bitrate. I always select dplii because I have players with dpl decoders.OK, great. :)

I forget a parameter I use always with -c normal -s dplii, -a (--maximize).What does exactly -a do? Is it some kind of normalization method? I can't enable this parameter with BeSweetGUI. EDIT: OK, I found it in "Normalize to 100%".
By the way, what is the most accurate/safer normalization method? I usually use OTA HybridGain, is this compatible with -a? In other words, should I use OTA "Gain" or "maximize" in AZID?

The only problem is that when you add LFE, the total gain will be lower
Even if you set it as -L -3db?

Thanks.

[tebasuna51]

By the way, what is the most accurate/safer normalization method? I usually use OTA HybridGain, is this compatible with -a? In other words, should I use OTA "Gain" or "maximize" in AZID?
OTA HybridGain is ok, my suggestion is for Azid.exe and after Lame.exe, if you use any BeSweet GUI with azid-lame dll's you can use OTA options.
Azid.exe -a, (--maximize in dll), (post-decoder) is equivalent to OTA PreGain (pre-encoder) if you don't need other function (samplerate change, timestretch, ...) between decoder and encoder.

[numaios]

OTA HybridGain is ok, my suggestion is for Azid.exe and after Lame.exe, if you use any BeSweet GUI with azid-lame dll's you can use OTA options.-Then if I use BeSweet, your opinion is that --maximize in Azid is the same than -ota( -g max ) which are better than -ota( -hybridgain )?

-But if downsamplig with shibatch is needed, for example, --maximize in Azid would be more accurate than -ota( -g max ), wouldn't it?

-In a BeSweet command line, the order of the parameters is important? I mean: OTA goes before or after AZID?

[tebasuna51]

-Then if I use BeSweet, your opinion is that --maximize in Azid is the same than -ota( -g max ) which are better than -ota( -hybridgain )?
-ota( -hybridgain ) is better or equal than PreGain or --maximize.
-But if downsamplig with shibatch is needed, for example, --maximize in Azid would be more accurate than -ota( -g max ), wouldn't it?
Many DSP functions (downmix, resample, timestretch, ...) can have overflow or lowvolume problems then is better normalize/maximize just before the encoder.
The encoder also can have this problems and Hybridgain make a limited PreGain before encode and the full gain after encode. Of course only work in certain output formats, work in mp3 but not in ac3.
-In a BeSweet command line, the order of the parameters is important? I mean: OTA goes before or after AZID?
Nope, the order is not important.
OTA can't be executed before the decoder AZID.

[numaios]

Thanks again.

Nope, the order is not important.
OTA can't be executed before the decoder AZID.Maybe I'm too dumb. Sorry if I am too boring... but if order is not important, why is better normalize/maximize just before the encoder?

[tebasuna51]

The order, of the parameters in BeSweet command line, is not important, because is not the execution order.

[numaios]

Aaaall right...! So the order of the parameters is not the same as the execution order... So when you said that OTA can't be executed before the decoder AZID is because AZID always runs before OTA, wherever you write the settings in the command line.

Thank you for being so patient :)