GetAudio() returning different output given same input...

[Jocko Homo]

I'm writing an audio filter and I couldn't help but notice that multiple calls to the GetAudio() method of an IClip don't necessarily return the same output even when given the same start and count parameters. How is this possible? Is this a bug in Avisynth or, perhaps, a bug in my decoder of choice? In my case, that would be ffdshow.

Has anyone any guesses as to what's going on?
Thank you...

[IanB]

Well it is certainly a bug. The rules of the game are GetFrame(), GetAudio() and GetParity() all return the same output each time they are called with the same input.

The most troublesome case of violation I know of is DirectShowSource when seeking is involved, hence the seek=false and seekzero=true options to combat sample approximate seeking DirectShow components.

If ffdshow is looping thru direct show it may well be exposing this problem.

For problem sources the recomended workaround is to transcribe the source to a seek friendly format in a single contiguous pass e.g. huffyuv and wave. and process that.

If you find the bug is in any internal Avisynth components please report the problem here with, full sample scripts, short source clips and explicit instruction to reproduce. (or source code reference with suggested fix :D )

[Jocko Homo]

Thank you for you kind help...

It turns out that it is, indeed, a seek problem. Everything is fine if a let things play out from the beginning but, if I seek, then these errors occur (although sporadically, so it almost works. It kind of stutters...). This happens while decoding MP3s using ffdshow. When decode a .wav file using WaveSource(), things seek just fine.

I guess I will have to live with the work-around of decoding the wave file. It's too bad because I enjoyed not having any intermediate files!

Actually, now that I think about it, what puzzles me most about this problem is that seeking works fine if I use MixAudio(). My audio filter doesn't do much more than what MixAudio() does.

The cause of the problem is that my filter calls GetAudio() on the same clip (whose source is a DirectShowSource() call to ffdshow) twice with two different start parameters (two different locations in the file). If I only make calls to this function at the same starting point, everything is fine.

When I couldn't figure out the source of my bug, I did a sanity check and made an additional call to GetAudio() with the same parameters as a previous call and checked to see if the output were the same, just to make sure the bug was still in my code. You can imagine my surprise when the output turned out to be different!

[IanB]

You can try EnsureVBRMP3Sync() it will guarantee linear access to the source stream and it also allocates a big Audio buffer, 4Meg I think, so if your access points are within this it should work nicely. Also add a SeekZero=True to your DSS call is case you exceed the buffer width. The reseeking to zero each time may be slow but at least it should work.

Another option is to open the stream twice and access each stream linearly but at different points.