[mad-user] re wishlist

[Anthony Airon Oetzmann]

On Mon, 18 Dec 2000 23:02:40 -0500, Rob Leslie wrote:

>> Remember that the DSP will rake in the dithering code, since all else would
>> destroy the profit made from having 24 or 32 bit output in the first
>> place. It's not great to dither audio twice either if you're going 16 bit
>> out and DSP'ing it to 16 bit again after processing it perhaps in 24 or 32
>> bit with the DSP plugin.
>
>Eh? I'm not suggesting to dither twice.
>
>Here's the current picture for 16-bit output:
>
>  +-----+                        +-----+         +----------------+/
>  | MAD | --32--> dither --16--> | DSP | --16--> | Output Plug-in |- audio
>  +-----+                        +-----+         +----------------+\

>Here's what I'm proposing with the high-res DSP option:

>  +-----+         +-----+                        +----------------+/
>  | MAD | --32--> | DSP | --32--> dither --16--> | Output Plug-in |- audio
>  +-----+         +-----+                        +----------------+\

>In all cases "--32-->" means MAD's internal 24-bit + 3-bit headroom sample
>representation.

You should scrap that first approach. Processing dithered 16 bit output is bad,
compared to what you get with the second signal flow. Both cases bare a slight
disadvantage. In the first you'll get dithered 16-bit output, but won't have a
clip correcting limiter and if you shift that in to the DSP part, NO
attenuation.
THe second approach requires a mandatory DSP plugin, otherwise people won't be
able to do a thing with MAD's output. A check if there's a DSP plugin that turns
the special 32-bit output in to a compatible output for the soundcard would fix
this, so I think the second approach should be the default.

>> I'm not shure a modular design has that many advantages, but to provide two
>> seperate setting controls.
>
>While I think this is indeed probably an advantage, the other advantages are
>(1) I can eventually call the MAD input plug-in "finished" and concentrate on
>the DSP stuff independently, (2) the DSP plug-in can be used with other input
>sources, not just MPEG audio, (3) maybe others would be interested in
>contributing to the DSP plug-in, being less complex than a full-blown decoder,
>(4) a bug in one plug-in can be isolated from the other, (5) etc.

All the plugin authors could write 32(24+3) bit output modes for their plugins.
You'd have to design a spec so that the DSP plugin can reveal its presence, so
the input plugin switches to 32bit MAD mode, no?

 Tony