Re: [Audacity-devel] Getting Label Linking to enabled-status

[James C. <cr...@in...>]

On 20/03/2010 17:44, Al Dimond wrote:
> I don't think we're far
>    
Me neither.  Gale too.  I think there's some excitement that at last 
after having the initial work for this done back in GSoC 2008 we're 
actually reaching a point where we can release it.

> Truncate Silence is slower because the algorithm had to be changed.
> Linking was far from its most serious problem -- the biggest problem
> was that it didn't handle clip boundaries correctly, and I didn't
> think there was a reasonable way to fix that within the existing
> algorithm.
Hmm...  I'm surprised if (just) adding support for clip boundaries on 
its own would slow it down.  I'd need to look at that if so.

> The only sensible way to handle clips correctly is with the
> standard edit routines, which are a lot slower than the old method.
This is ringing alarm bells for me!  If 'standard edit' routines mean 
cut and paste then these should be virtually instantaneous, massively 
dominated by the time taken to find the regions of silence.  Besides 
which, we micro fade-out/fade in at edges to avoid unwanted clicks in 
this effect, so using standard cut on its own would not be enough.

> I'm working on an optimization that should speed things up with
> multiple tracks selected (skipping over regions already detected as
> non-silent in subsequent tracks). The speedup will depend a lot on the
> input data;
>    

It sounds like you are doing 'logical operations' on the regions.  
Rather than optimising these, wouldn't it be simpler to program to use 
the existing mixing routine to mix into a buffer, then detect silences 
on that buffer and use that to decide where to cut?  I believe we do do 
mixing reasonably efficiently.  The only strange effect here would be if 
someone is working with anti-sound (e.g. sin(x)  in one track -sin(x) in 
a second track).

I suspect you're not optimising the real culprit.  Possibly the real 
issue is that our 'cut' code is inefficient, or at any rate poor when 
doing multiple cuts.  Our worst case is likely to be lots of small 
silence removals near the start of a longish piece of audio.


--James.