Subject: Re: [ecasound] Correct volume
From: Kai Vehmanen (k@eca.cx)
Date: Tue Jun 26 2001 - 23:53:39 EEST
On 25 Jun 2001, Mario Lang wrote:
>> Ecanormalize doesn't yet understand any parameters. If available, it uses
>> the input object's audio format, otherwise the default params. Hmm, this
>> needs to be added on the todo-list.
> Does this mean extension-detection of header-detection?
Possibly both. For instance .wav and .aiff both the necessary info in the
file header. Then again, .cdr files (CDDA format) only support one set of
params (16bit, be, 44100Hz), so the extension is enough... Same routines
are used throughout eca-based apps.
>> Btw; using ecanormalize (or any peak-normalizer) with pipes can
>> cause problems, as ecanormalize must first analyze the whole
> Uh, I really ment unix pipes. I am doing a project to produce
> synthesized speech for a streaming application (mp3 streaming).
Ok, then you can forget ecanormalize as it's not intended for streaming
(or realtime operation). But using ecasound in the middle of a pipe should
work ok.
> #!/bin/sh
> cat $1 |\
> festival_client --otype raw --ttw |\
> #ecasound -f:s16,1ch,16000 -i stdin -ea:350 -f:s16,1ch,16000 -o stdout |\
> lame -r -x -s 16 -m m - $2
[...]
> I think I can do aproximate -ea because it is
> alwqays above factor 400, but the version above (comment removed)
> sounds horrible. I wonder what I do wrong.
How about letting ecasound spawn lame, ie:
cat $1 |\
festival_client --otype raw --ttw |\
ecasound -f:s16,1ch,16000 -i stdin -ea:350 -f:s16,1ch,16000 -o $2
... if is still sounds bad, try outputting to a file from festival, and
try to play that with ecasound. This way you should be able to pinpoint
where the problem lies.
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Jun 27 2001 - 00:47:14 EEST