Bug? ApplyRange and audio

[stickboy]

ApplyRange doesn't seem to restrict audio operations to the specified range. For example, given the following script:
ColorBars(640, 480)
ApplyRange(10, 20, "Amplify", 0.0).AudioGraph(1)
I expect that only frames [10, 20] would be silent, but instead the entire clip is.

Is this a known limitation with ApplyRange? Can it be fixed?

[WarpEnterprises]

AFAIK ApplyRange and Animate won't treat the audio.

[stickboy]

Oh, right. The bundled documentation even says so:This filter will not correctly handle a changing sound track, so I don't recommend its use with filters which modify the sound track.Well, that kind of sucks.

I guess the ApplyRange substitute I wrote for AviSynth 2.0x (http://www.avisynth.org/users/stickboy/#range) is still useful after all.

[sh0dan]

I will look into this - no promises. I have quite limited time available.

[WarpEnterprises]

Anyway, I wondered if there SHOULD be a difference in the nice function you (stickboy) made and the way ApplyRange is internally implemented via Animate.
Isn't it an overkill to use Animate and not to simply Trim and Splice?
(Although it looks as it was straightforward to use Animate)

[Bidoche]

It is overkill, I agree.

The same thing happens in a couple other filters : I wonder why FreezeFrame, Dissolve take the bother to reinvent Splice and Trim...
(I recently adapted them for 3.0)

[stickboy]

sh0dan:
Thanks! ApplyRange seems to be working with audio now in the September 12 build. However, if I use my script example from above, AudioGraph reports that frames [10, 20) get silenced instead of [10, 20].

[sh0dan]

There is no clear cut on how applyrange should handle audio. I choose to make the first frame inclusive end the last exclusive, so that the transition consistently happends at the beginning of the specified frame.

I can however see it is a bit inconsistent with the way it works on video, as the last frame is inclusive. I'll change the audio function to reflect this.

[Bidoche]

IMHO, users would generally expect it as having the effect of the wanted part being trimmed out, filtered and put back in.
And the command should simply just do that, directly invoking Trim and Splice.

[sh0dan]

... just saving stack space. :)

Anyway when I see ApplyRange(start_frame, end_frame, ....) I would also expect the end_frame to be filtered.

[Bidoche]

Don't overthink about stack space. Saving a bit of candles at the cost of added complexity is not a good idea.

It's just stupid to duplicate the functionality of Trim and Splice...
And it contradicts the KISS rule.


If stack overflow becomes an issues (and they don't unless in very recursive scripts), we can :
- increase stack size with proper compilation directive
- implement terminal recursivity so recursivity is done in place
- imbed cache into filters, in order to divide filter chain size by 2
- implement filter refactoring so the chain can eliminate useless redundancies (like 2 successive Trim)


Personally, I would expect to do it like Trim does, and he takes end_frame too, no ?

[sh0dan]

If you want it rewritten - please rewrite it - otherwise I couldn't care less.

Sorry - I'm getting tired of these discussions with no point. You have implemented it as trim/splice in 3.0 - I have no objections. I'm against syntax changes in 2.5, as it will break peoples scripts.

[Bidoche]

I don't want it rewritten, it was just a general observation.

I'm against syntax changes in 2.5, as it will break peoples scriptsSorry if you thought if was advocating that, I am not that familiar with ApplyRange (never used), so I may misunderstood the expected behavior.