> 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. ;)