[MPlayer-dev-eng] Plugin for Graphics in Music Playing Mode

[D Richard Felker III]

On Sun, Aug 18, 2002 at 01:06:12AM -0500, Krister Lagerstrom wrote:
> Anders Johansson wrote:
> 
> > If you plan to do any spectrum analysis plugins please contact me
> > and I can get you started and help you develope it.
> 
> What's your plan for performing the spectrum analysis?
> 
> 1) Extracting the decoder-dependent frequency domain data like the
> spectral lines in MP3?
> 
> 2) Simple differential analysis in the time domain, like the Blursk
> plugin for XMMS?
> 
> 3) Full-fledged DSP analysis like FIR filter banks or FFT?

Just a thought....but it would be cool if mplayer's audio codecs (at
least liba52 and mp3lib, which are virtually the only frequency-domain
ones that matter) could output sound to the filter layer still in
frequency space, to be transformed back later down the filter line.
Lots of the most important filters should be able to benefit from
working in frequency space, in terms of performance, precision, and
sometimes even functionality. For example...

Resampling. Take the output block size from the codec and scale it to
what it should be resampled. Round up and down. Generate sine wave
tables for both the rounded up and rounded down number of samples,
then alternate between the two according to the remainder when
reversing the transform. No distortion, exact requested output
frequency.

Soft clipping/compression. Doing this in frequency space rather than
time space should avoid introducing bogus harmonics, but this is just
an intuition on my part.

Volume control. Scaling coefficients should be faster than scaling
every sample individually.

Equalizer. Pretty obvious benefits.

Visualization stuff. Ditto.

Of course there are obvious obstacles to supporting frequency space
audio like this. I'm not familiar with all the particulars of codecs,
just a bit of the mathematical theory behind it, but I'm sure there
are different block/window sizes at work here, and perhaps somewhat
different transforms as well. Perhaps these ideas would better be
implemented as a second audio filter layer, that goes inside the codec
rather than after the codec is finished with the data...

Comments?

Rich