AviSynth+ thread Vol.2

[flossy_cake]

ScriptClip appears to return audio from the clip being iterated on instead of the clip returned by the expression

global withAudio = ColorBars().ConvertToYV12().Text("withAudio")

global withoutAudio = ColorBars().ConvertToYV12().KillAudio().Text("withoutAudio")

ScriptClip(withoutAudio, "return withAudio", after_frame=true, local=false) 

# the returned clip appears to be equivalent to AudioDub(withAudio, withoutAudio)

[Gavino]

Originally Posted by flossy_cake

ScriptClip appears to return audio from the clip being iterated on instead of the clip returned by the expression

That's by design.
ScriptClip doesn't do any audio processing, it only operates on the video track.

[flossy_cake]

If it's by design, then I would say it's not very good design as I noticed just now that it also sets the field parity of the returned clip to that of the one being iterated on.

last = ColorBars().ConvertToYV12().KillAudio()
global tff = last.AssumeTFF().Text("TFF", align=9)
global bff = last.AssumeBFF().Text("BFF", align=9)
ScriptClip(tff, "return bff", after_frame=true, local=false)
info()

This will cause problems for filters downstream from the ScriptClip which need to see its field order, such as if the ScriptClip returns DoubleWeave which has alternating field order. Hopefully this can be worked around by manually setting the parity of each frame back to what it should be via a custom frame property.

[wonkey_monkey]

If it's by design, then I would say it's not very good design

It has to get its output clip properties from somewhere, and while it's easy for a human to look at "return bff" and know that it's just returning all the frames of bff, it would (correct me if I'm wrong, Gavino) be far too complicated for ScriptClip to be able to do this kind of introspection on arbitrary inputs. For a lot of scripts it would just be impossible - for example, if you wrote a ScriptClip that selected a frame from one of three clips depending on the frame number, how would it know which clip's properties (frame rate, field parity, etc) to use?

[flossy_cake]

Originally Posted by wonkey_monkey

for example, if you wrote a ScriptClip that selected a frame from one of three clips depending on the frame number, how would it know which clip's properties (frame rate, field parity, etc) to use?

I believe the fps of the input clip and return clip have to be the same for it to work correctly, otherwise eg. if input clip is 30 and return clip is 60, the output plays back at half speed.

I don't see the need to modify the audio or field order of the output clip.

[flossy_cake]

Also sorry if my comments about ScriptClip sound overly critical - I've been fighting with it the past few weeks and it's causing me a lot of headaches getting it to play nice with multithreading, avoiding memory leaks and my QTGMC output was broken due to this field order issue. Gavino's Grunt thread page 1 has some quotes from other members noting how quirky and strange the runtime environment is, so I know I'm not alone in this frustration.

[flossy_cake]

I'm just playing around with Avisynth's internal TimeStretch audio filter and was wondering about this:

Originally Posted by http://avisynth.nl/index.php/TimeStretch

Since tempo, rate and pitch are floating-point values, but sample rates are integers, rounding effects in calculations are unavoidable; the resulting audio track duration may be off by up to several 10's of milliseconds (less than one video frame) per hour.

Several 10's of milliseconds per hour doesn't seem trivial to me - a 3 hour movie could be off by 100ms then? That seems significant, and longer recordings of several hours, say, live events like sports or whathaveyou could become ruined by it.

I was thinking... is it possible to somehow force a manual audio resync every n minutes, to nudge it back in sync? Could this be done in Aviysynth scripting or only within the TimeStretch plugin itself?

[tebasuna51]

Originally Posted by flossy_cake

...
Several 10's of milliseconds per hour doesn't seem trivial to me - a 3 hour movie could be off by 100ms then? That seems significant, and longer recordings of several hours, say, live events like sports or whathaveyou could become ruined by it.

The time can't be stretched.

The audio don't be never stretched, if it is not in sync with the video is a video fps problem. Play the video at fps it was filmed and the audio is always in sync.

If you film the Usain Bolt 100 m WR (9.58 s) at 24 fps and play it at 25 fps you have a new WR of 9.2 s

BTW if you want modify the real audio duration to fit the wrong video duration you can add some correction at your taste, there are audio editors.

[flossy_cake]

Originally Posted by tebasuna51

If you film the Usain Bolt 100 m WR (9.58 s) at 24 fps and play it at 25 fps you have a new WR of 9.2 s

I think that depends if you used ChangeFPS() or AssumeFPS().

Anyway, I'm not modifying the video fps at all. The TimeStretch function only processes audio, and I'm going to be modifying audio pitch while retaining audio length, and the wiki says audio length will be slightly off due to unavoidable rounding errors, and if the audio length is different then it's not going to be in sync with video.

I tried to reproduce it by taking a 1hr clip and Loop(20).TimeStretch(pitch_n=24000, pitch_d=25025) to simulate pitch down of 4% and skipped to the end and audio was still in sync. But I don't think this simulates the issue - I'll probably have to leave the video running overnight and come back the next day and see if it's still in sync.

If it isn't, then I had an idea: split the clip into say 3 hour chunks with Trim, and do the TimeStretch() on each individual clip before joining them back together with ++. But then maybe there will be a little audio glitch every 3 hours at the splice point. I think the optimal solution would be for TimeStretch to handle it internally and when it detects drift is > some value it should smooth over the resync point using its own timestretching algorithms.

[r0lZ]

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible. So, unless you want absolutely to watch a 24 hours movie, you should not worry too much.

[flossy_cake]

Originally Posted by r0lZ

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible.

In MPC-HC I can adjust audio delay with hotkeys in 10ms increments and at 100ms it's noticeable to me the lip sync is off.