Re: [ecasound] -ev or -ea option overdid it

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] -ev or -ea option overdid it
From: Kai Vehmanen (kaiv@wakkanet.fi)
Date: Tue Feb 29 2000 - 01:11:11 EET

On Mon, 28 Feb 2000, Christopher Taylor wrote:

> It occured to me last night what the problem is. The -ev option is
> returning a number with a higher precision than the -ea option is using.
> The -ea option, instead of truncating the value (which it should do) is
> rounding the value to the lower precision. In approx. 50% of cases of
> using the output of the -ev option as the input of the -ea option, this
> will cause clipping of the waveform.

Yes, you're correct. Ecasound represents all parameter values and sample
data as floating point values. Currently the exact data type is 32bit
float. So the actual nomrmalization multiplier is a 32bit float value,
and thus it's not reasonable to print it with this much precision.

> I hope this is helpful to you. For my part, I will just truncate the
> value myself before passing it to the -ea option. Does
> ecatools_normalize take this situation into account?

Ecatools_normalize (and _fixdc) on the hand use the 32bit values
directly. And as a reminder, writing apps with libecasound is easy.
For instance, ecatools_normalize takes just a screenful of code. And
this includes command-line code. ;) 

-- 
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux multitrack audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2a24 : Tue Feb 29 2000 - 01:54:52 EET