[MPlayer-dev-eng] Dithering 16-bit output for libmad

[Reimar Döffinger]

Hi,
On Mon, Jan 31, 2005 at 01:13:20AM +0300, Vladimir Mosgalin wrote:
>  On 2005.01.30 at 22:48:16 +0100, Reimar D?ffinger wrote next:
> > Now I know why mad is so slow! That scale function should not be there!
> > Instead it should only support certain mad_fixed_t types and return them
> > directly.
> 
> Eh? Mad gives high-quality output, so 32 bits are necessary. 16-bit
> fixed point calculations for mp3 decoding just won't cut. It does it in
> 32 bits instead of doing it in floating point. And since internal
> processing is 32 bit, it returns 32-bit data. 24 meaningful bits padded
> to 32. And you can either round them to 16 or use dithering.
> 
> mad_fixed_t is always 32 bit, except for 64-bit systems, where it is 64
> bit ;)

Well, MPlayer filter chain supports 32 bit. And adding 64 bit support
also would only be a matter of adding conversion routines to af_format.c
(but that file is getting a bit overloaded already).
But I have to admit when MPlayer converts it into 16 bit by only taking
the most significant bits (in af_format) you would probably loose
quality...

> > [...]
> > > padded to 32 bit, actually). For example, ad_libmad returns result as
> > > 16-bit data in ints, but what would happen if it would return full 32
> > > bits of output? Will they be rounded to 16 bit in audio output driver or
> > > before it?
> > 
> > They will be rounded where it is neccessary, i.e. before the first
> > filter that doesn't support 32 bit - which currently means before any
> > filter.
> 
> Converting some filters to 32 bits would be very easy, but won't it also
> be rounded in general audio filters interface, i.e. before and/or after
> filter chain?

No, it's just plain unspecified data with a lenght there...

> If no audio filters are used, will be it rounded in output driver or
> before that?

Well, it is just a filter chain with the decoder at the beginning and
the output driver at the end. MPlayer normally will insert filters
(format, resample, channels) to make them fit together (-af-adv can be
used to control this).

> Also, where it is declared that audio filters don't support 32 bit? It's
> not like "16" is defined somewhere inside or they are returning short
> ints.

It is. Look for e.g. AF_FORMAT_S16_NE

> > > in mplayer's output, but it playbacks the file. The output is 16 bit,
> > > and even -ao pcm writes 16-bit files, so I can't test whether 24 bits
> > > would be rounded to 16. And mplayer doesn't play 32-bit files at all.
> > 
> > There is no reason for that... Can you provide a sample?
> 
> Hmm.. Do you have audacity? Open a wav file, select 32-bit float output
> for wav in preferences and try to play the result (codec value will be
> 0x3).

Oh, 32 bit float! Now that's more of a problem then...

Greetings,
Reimar Döffinger