[FFmpeg-devel] [PATCH] Support for reducing from 5.1 and 4.0audio to stereo audio

[Rich Felker]

On Wed, Oct 31, 2007 at 09:18:46PM +0100, Axel Holzinger wrote:
> Rich Felker wrote:
> > On Wed, Oct 31, 2007 at 04:38:57PM +0100, Axel Holzinger wrote:
> > > > > +static void quad_to_stereo(short *output, short 
> > *input, int n) {
> > > > > +    int i;
> > > > > +    for(i=0; i<n; i++) {
> > > > > +        output[0] = (input[0] + input[2]) >> 1;
> > > > > +        output[1] = (input[1] + input[3]) >> 1;
> > > > >   
> > > > 
> > > > shouldn't it be /2 instead of >>1 ?
> > > 
> > > It's ints, what is the difference?
> > 
> > The difference is what happens to negative values. However, I 
> > think rounding in the consistent direction (towards -?) is 
> > better than rounding towards 0. The latter could create 
> > artifacts; the former will only create DC bias which is inaudible.
> 
> Shifting right is perfectly right (if you want to divide by 2).
> There is no -? with shorts.

I never said there is. I said rounding _towards_ -?, i.e. always-down
as opposed to towards-zero.

> But I recommend to just clip, meanig check, if the value is smaller
> than SHORT_MIN tie it to SHORT_MIN and if it's greater than
> SHORT_MAX tie it to SHORT_MAX.

Clipping is always wrong and creates horrible artifacts.

> Not really, just listen to a AC3 DVB-S radio signal. Most of the
> content is stereo, but the radio stations don't switch formats from
> take to take (you would have a constant resyncing of your receiver
> at take boundaries, annoying), but they do route the stereo signal
> to front left and front right. If they have a real 5.1 take, they
> send it to all channels.

They should 'upmix' the stereo to fill all the channels. Just because
they're doing something stupid doesn't mean we should write incorrect
code to compensate for them.

> On a digital mixing console it's the same, there is no division by
> the number of channels you have, it's just summing up all channels.
> The operator has to reduce gain of the inputs, if the sum is going
> into overload. The console will just do correct clipping to prevent
> a numerical overflow, what would lead to a distortion with maximum
> energy.

Clipping is just as bad as overflow...
Anyway this is not a digital mixing console, it's a fully automated
process which has to avoid doing things which are fundamentally wrong
even if they do preserve more dynamic range in certain situations.
Degrading information gracefully (which a filter like this should be
expected to do anyway!) is nothing like applying massive distortions
to the spectrum.

Rich