Subject: [linux-audio-dev] LADSPA plugins with oversampling - digital audio restoration
From: welty_AT_harbornet.com
Date: Thu Apr 11 2002 - 07:33:35 EEST
[This is a long post ...]
I am going to release the latest version of the Gnome
Wave Cleaner in the next couple of days, just waiting
on a test to make sure the configure works on suse-linux.
The project seems to be fairly mature, and now I am
*finally* thinking about making plug-ins for de-noising
and declicking and decrackling audio.
All of the techniques used in the GWC project use some
sort of oversampling to clean the audio, whether it is
the fft noise removal or the click detection/repair.
Here's my really dumb question (you *were* holding your
breath, right? :-) Feel free to point me to a FAQ or
sample plugin if I missed something on the ladspa site.
It looks like a LADSPA plugin, by the time it sees the
data is only seeing a subset of the data -- potentially.
If that subset of data is the entire portion of the
audio to be filtered, that is potentially mmaped (or a
huge buffer), that would be acceptable. If the application
is throwing individual frames at the plugin, then the oversampling
will not work because it cannot get the data beyond the
frame boundary.
Is there a way for the plugin to tell the application using
the plugin that buffering of the audio data is not allowed?
If buffering was required by the app, could the plugin tell
the app the location of the next frame of data to pass it
after processing a single frame?
Would it be a problem if the output data buffer pointed
to the same memory location as the input data buffer (which
is what GWC does right now using mmaped wavfiles)?
--Paul Davis asked about a command line version of cleaning audio files, and I have been thinking hard about that. Declicking is more or less easy, the problem comes when there are "false positives" during the click detection phase, and some of the audio data actually gets corrupted, in subtle ways but it can be noticeable. Increasing the click detection threshold will reduce the false positives, at the expense of more false negatives... When you are doing this interactively, you repair the clicks in a region, audition the result, and "undo" if you don't like the repair job. Command line versions mean you get what you get, I think...
To denoise, gwc needs a noise fingerprint, often one finds that at the start of an audio track -- even a 1/2 second is plenty. My immediate reaction to an automated denoise was that it couldn't detect the case where say violins "faded in" at the start of a track, and would include the low volume violins as part of the noiseprint and hence remove some violin sound at that frequency from the rest of the audio track.
I now think it may be possible to use the fft analysis to detect even that case where violins fade in -- by looking at the fft spectra from frame to frame, if there are spikes which are correlated from one frame to the next, even those violins could be "seen", and the frame where they start would be excluded in the noiseprint.
Any pointers/ideas/wisdom you all have would be very welcome!
Jeff Welty aka jeff_AT_www.redhawk.org aka welty_AT_harbornet.com
This archive was generated by hypermail 2b28 : Thu Apr 11 2002 - 07:28:02 EEST