Subject: Re: [ecasound] Fade in and fade out
From: Julian Dobson (juliand_AT_braverock.com)
Date: Tue Nov 04 2003 - 16:04:07 EET
I see what you mean.
I was thinking along the lines of using a buffer to determine the end of
the file - the buffer would be sized to contain all the samples required
for the fade-out, and when the buffer input terminated, the fade-out
As you point out, a signal processing component would only see the
current block, but that doesn't matter if you are buffering that block.
The problem with this, however, is that you would need to allocate about
176K per second of fade-out (assuming 2 channels, 16bit, 44.1KHz).
My other option is to make sure I have good lengths in my database and
use those instead... :)
Kai Vehmanen wrote:
> On Mon, 3 Nov 2003, Julian Dobson wrote:
>>I was hoping to avoid having to use an external program to measure the
>>playtime of the file before-hand, as I've had problems doing this due to
>>VBR in the source (for example ecalength reports 1529.861s for a song
>>which is only 254s actual length - and mp3check reports 382s; MP3::info
>>correctly reports 254s, at least for this song). And this is why I was
> Yep, this is a real problem. But the only real solution is to decode the
> whole file and see how many samples come out. And this is slow.
>>hoping that there was some way of processing ecasound's internal buffer
>>or secondary buffer.
>>I guess I may have to look into writing a LADSPA plug-in to do this.
> The problem is that a single singal processing component only sees the
> current sample or a block of sample, it does not have access to the whole
> file (which might be gigabytes long and not fit to the memory, etc). This
> limitation applies both to Ecasound as well as LADSPA plugins. In any case
> you will need a two-stage processing to make the tail-fade.
> I'd recommend that you implement a more robust ecalength that decodes the
> whole file and reports how much data did the decoder provide. Using this
> info you can make a realiable fade-out.
This archive was generated by hypermail 2b28 : Tue Nov 04 2003 - 16:01:14 EET