Unusual audio damage - every 3rd sample

[TCmullet]

BACKGROUND: Sometimes my DVR creates a strange artifact on the audio output that is inaudible to me. It's not til after I capture the video and extract the video and .wav files for Avisynth processing that I discover the problem. (And I worked hard to trace down that it was the DVR causing it, which is solved temporarily by rebooting the DVR. But eventually it slips into artifact mode again without warning.) If I catch it before I've erased the program from the DVR, I can simply recapture. However, I've capped and done a bunch of deleting, so I cannot go back and recapture.

THE NEED: What I need is a way to massage the audio. I need to subtract the value 16,384 from every 3rd sample in the right channel, starting at a specified offset (which will be 0, 1 or 2). Is there some way in Avisynth to do this with my audio track???

I open my audio like this:

audio=wavsource("myvideo.wav")

[TCmullet]

Would some kind of usage of BeFa be in order? But man, that filter is cryptic, even if you use Google Chrome to translate from the original Japanese.

[StainlessS]

BeFa English doc:- http://web.archive.org/web/20071105084352/http://www.geocities.com/fredthompson6/Kiraru2002/Kiraru2002sROOM.htm#Befa

Linked from wiki, External filters:- http://avisynth.nl/index.php/External_filters#Audio_Filters

[TCmullet]

Stainless, yes I saw that. But I discovered that Chrome's real-time (when I tell it to) translation of the original reads a lot better. But it's still cryptic. Have you or anyone ever used BeFa?

Every 3rd sample of my 48khz audio equates to a tone of 16000 cycles per second. By looking at the waveform in Audacity is how I determined that whatever is causing this is adding a fixed value to my signal. And it looks very closely like the value is 16384.

I'm worried that the only practical way to solve this is to write a C++ program to read the bad wave file as input and write out a new one with 16384 subtracted from every 3rd sample in the right channel.

[TCmullet]

I posted a graphic of the view in Audacity here:
https://forum.audacityteam.org/viewtopic.php?f=46&t=102710

The solution that I reported there was to recapture from the DVR after rebooting. But now I'm dealing with files old enough that they no longer can be recaptured. So I DO need a way to fix the corrupted waveform.

[StainlessS]

Have you or anyone ever used BeFa?


Cant speak for anyone, just for me, no never even heard of it.

Give me a little time to finish a few other things and I'll see what I can do.

[wonkey_monkey]

What happens when the underlying samples have a high enough value that adding 16384 would push them over the top?

By the way I'd say your left channel needs a smaller amount (2000) adding every three samples as well. And I don't think the offset on the right channel is 16384 - it's more like 20000.

StainlessS: I've got this one covered if you don't want to spend any (more) time on it ;) Just waiting on an answer to the above question before finalising.

[TCmullet]

What happens when the underlying samples have a high enough value that adding 16384 would push them over the top?I had wondered that too. This is a cable TV signal, and the volume never increased high enough to cause the tone to go above the max (+32767?) That made me think it was intentional. But rebooting killed it.

Also I just learned today it's not happening immediately and at 16384, but starts gradually after audio starts, taking a few seconds to reach max value. (16384 is my educated guess.)

[wonkey_monkey]

Well that makes things trickier. What do you mean by "after audio starts"? If there's a period of silence, does the offset reset to 0, and then start climbing when the period of silence ends?

[StainlessS]

StainlessS: I've got this one covered

Lovely, was not looking forward to it. :)

[TCmullet]

Well that makes things trickier. What do you mean by "after audio starts"? If there's a period of silence, does the offset reset to 0, and then start climbing when the period of silence ends?No, after a couple seconds audio, it's stable the rest of the recording, even hours long. I think it ties to the DVR's start of playback. It takes 2-3 sec. maybe to ramp up to it's normal constant of ~16384. (I could probably measure it.)

[wonkey_monkey]

Can you upload a longer sample? I've just realised I forgot to allow for something which I can't test without a longer sample. A few seconds should do.

[TCmullet]

Longer sample? You mean a sample longer than the one I didn't send or include? Uh, well I guess you must be talking about the 300 sample file I put up on the Audacity board earlier. Okay, I can give 10 sec. if I leave it in the captured AAC format, then you can decompress to .wav to view it. It (the aac file) is contained in a zip file attached. This is the 1st 10 seconds of audio in the capture.

I think I was wrong about it taking 2+ seconds for the amplitude of introduced 16k tone (which shows as every 3rd sample being boosted by a fixed large amount, 16k-20k). It's not 2 sec, but rather .02 seconds. After that time, the amplitude is the constant value (16k or 20k) Before that, the amplitude starts at 0 and rapidly (over .02 sec.) ramps up to the high value constant thru the rest. I'm not try to stop the ramp up. I'd simply skip over it to apply whatever fix to everything BUT the 1st .02 or .03 seconds.

[TCmullet]

A reason I'd like an Avisynth solution is that I don't discover the problem until I have set up a script for processing and I SEE the boosted right channel. If I had nothing to do to the audio, I could let it go unchanged. But you can see that if I need to do something as simple as normalizing, the normalizing won't work as those inaudible spikes every 3 samples max out the normalizing logic, that is, normalizer cannot boost it any more as the louder ones are already maxed out.

Edit: Also, I have a lot of files to process, and adding a line of code in the Avisynth script (if there is such a line) is much faster than doing an Audacity step to process and fix the audio file before finalizing (and running) my Avisynth script. Plus I'm not crazy about notching out something.

[Groucho2004]

A reason I'd like an Avisynth solution is that I don't discover the problem until I have set up a script for processing and I SEE the boosted right channel.
How so? You can load the audio in Audacity, run a FFT and display the frequency spectrum. That should make it easy to identify the spurious signal. Then apply a notch filter. This was already suggested to you in the Audacity forum.

Working on this problem in the time domain seems rather error prone, not to mention that there is no software or Avisynth plugin (of which I am aware) that can do this.

[TCmullet]

Let's call the amount by which the signal is erroneously boosted every 3rd sample "boosted value" or BV. My thought process when I first saw this close up was, if I follow the path of the waveform and when one of the 3rd-samples would cross the x-axis (the time domain) if it had not been boosted, then the value of that boosted sample would be BV. I could see that subtracting BV from every 3rd sample would restore all the boosted samples to their original values. So, what could be error-prone about that? It's exactly every 3rd sample, and once we nail down the value of BV, it is constant throughout (except for the first fraction of second where it is ramping up).

[wonkey_monkey]

Okay, the start is a bit more complicated because it looks like there's another aberrant signal at a different offset which fades in and then fades out, but this should help for the rest of the audio:

http://horman.net/avisynth/download/audiofix.zip

If you're not sure which DLL you need, you're probably using 32-bit Avisynth so you want audiofix(x86).dll

Parameters:


offset - bad sample offset
step - defaults to 3
add - amount to add to selected samples
channels - AF_LEFT, AF_RIGHT, or AF_BOTH (default)
ramp - number of samples to ramp up over at start


Code to mostly fix the longer sample:


convertaudioto16bit # it only works with 16-bit audio
audiofix(offset=2,add=-20000,channels=AF_RIGHT,ramp=1000)
audiofix(offset=2,add=2000,channels=AF_LEFT,ramp=1000)

[TCmullet]

Wow, thank you, David! I look forward to trying this soon.

[TCmullet]

I was puzzled why you did something in left channel. but on looking more closely, it appears that yes, the left DOES have a disruption, albeit much smaller in amplitude that the right channel disruption.

If I start my frames of concern far into the clip, can I set the ramp to zero? In most cases, I don't need the footage at the start. But in at least one case, I probably do. (It was something where no audio started until the real audio for the program did.)

I was puzzled at first by "offset", but I think that is the means to sync processing to where it's now every 3rd (the step parameter) sample.

Also, how accurate are your BV values (-20000 for the right, 2000 for the left)? Do you feel they're the best possible estimates, or do I need to work to get them more accurate?

[wonkey_monkey]

Yes, you can set ramp to zero so it has no effect. The BV values are pretty accurate as far as I can tell, probably within 1% for the right channel. Ideally you should check a recording which has a period of complete silence (on an ad break, if there are any, for example) so you can be certain of the value.

[TCmullet]

Hi Wonkey! (Though it's been 5 months!) I've been very swamped. (Still am but didn't need this til now.)

A probably simple problem getting started. I get "I don't know what AF_RIGHT means". Was there something else I was supposed to do beyond putting the DLL into my plugins folder and reloading the Avisynth script into Vdub?

[wonkey_monkey]

If you're getting that then the plugin may not not be loading at all. Make sure you've used the right DLL, and try replacing AF_RIGHT with 2 (which is its value).

[TCmullet]

Now it says that there is no function named audiofix.

I put audiofix(x86).dll into:
C:\Program Files (x86)\AviSynth+\plugins

and restarted Vdub.

[wonkey_monkey]

And you're definitely not running a 64-bit version of VirtualDub? Might need to check your plugin folder paths with AVSMeter. If you've previously installed AviSynth 2.5, AviSynth+ may still be using its plugin folder.

[TCmullet]

I only have one Avisynth version installed. I use 32-bit Avisynth and Vdub. There are 4 plugin folders; plugins, plugins+, plugins64, plugins64+. I am using the 1st one, "plugins". There is little than can go wrong, that I can think of or observe. Do I need to reboot Win10? How do I get and use AVSMeter? (Never heard of it.) Note that I did not rename the dll.

Update: I have found AVSmeter, but it is failing without getting very far. My Avisynth version has (and requires) SetMTMode. But AVSMeter barfs saying "Script error: There is no function named 'SetMTMode'." Therefore AVSmeter is useless to me, apparently. (Apparently, it was designed for a specific environment.) I had first used AVSmeter64, thinking 64 referred to my Windows environment. But after it barfed very badly, I suspected 64 refers to NOT my Windows, but to the bit-domain of Avisynth (which for me is 32). So I used the plain version of AVSmeter and got the SetMTMode error.

[MysteryX]

But AVSMeter barfs saying "Script error: There is no function named 'SetMTMode'."
That means you're running AVSMeter with either Avisynth+ or a non-MT version of Avisynth. Make sure you have the right version of Avisynth.dll that it can find.

First it looks in the same folder as AvsMeter, then it looks into the system32 or syswow64 system folder.

AvsMeter isn't doing any parsing itself.

[StainlessS]

You sure that you aint puttin avisynth plugin in the virtualdub plugins folder ? (Vdub usually *.vdf or *.vdplugin, not *.dll)

The "There is no function named 'SetMTMode'." error is coming from Avisynth, NOT AvsMeter. (AvsMeter is just telling you about it)

Forget SetMTMode at least for now and load script into virtualdub.

return version


And also post result of

AvsMeter avsinfo

[Groucho2004]

And also post result of

AvsMeter avsinfoOr use the Avisynth Info Tool (https://forum.doom9.org/showthread.php?t=176079) which for some may be easier to use. Functionality is (more or less) the same as "avsmeter avsinfo".

My Avisynth version has (and requires) SetMTMode.
"My Avisynth version" can mean many things, I just assume that you mean "The Avisynth version I installed and believe is currently active on my system".

Secondly, it sure does not "require" SetMTMode.

[TCmullet]

Forget SetMTMode at least for now and load script into virtualdub.

return version


Dang, why didn't *I* think of that??
Here's the avsmeter output:

AVSMeter 2.9.2 (x86) - Copyright (c) 2012-2019, Groucho2004

VersionString: AviSynth+ 0.1 (r2506, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2017-06-08, 18:58:00 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+


[CPP 2.5 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\avssr.dll [2014-01-09]
C:\Program Files (x86)\AviSynth+\plugins\dgbob.dll [2003-07-06]
C:\Program Files (x86)\AviSynth+\plugins\DGDecode.dll [1.5.8.0]
C:\Program Files (x86)\AviSynth+\plugins\DirectShowSource.from-i5.dll [2.5.8.6]
C:\Program Files (x86)\AviSynth+\plugins\exinpaint.dll [0.2.0.0]
C:\Program Files (x86)\AviSynth+\plugins\ffms2.dll [2014-06-20]
C:\Program Files (x86)\AviSynth+\plugins\FFT3DFilter.dll [2.1.1.0]
C:\Program Files (x86)\AviSynth+\plugins\LSMASHSource.dll [2015-02-15]
C:\Program Files (x86)\AviSynth+\plugins\masktools2-25.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins\MSharpen.dll [2003-04-08]
C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll [2.5.11.9]
C:\Program Files (x86)\AviSynth+\plugins\NicAudio.dll [2012-08-27]
C:\Program Files (x86)\AviSynth+\plugins\svpflow1.1-28.dll [2.0.0.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow1.1.3.5.0.dll [1.3.5.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow1.2.0.3.0.dll [2.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow2 - Copy.dll [1.5.8.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow2.1-28.dll [2.0.0.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow2.2.0.2.0.dll [2.0.2.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow2.2.0.3.0.dll [2.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins\TIVTC.dll [1.0.5.0]
C:\Program Files (x86)\AviSynth+\plugins\TTempSmooth.dll [0.9.4.0]
C:\Program Files (x86)\AviSynth+\plugins\WhiteBalance.dll [2016-12-28]

[CPP 2.6 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [2017-06-04]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [2017-05-29]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [2017-06-04]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [2017-06-04]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [2017-06-04]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [2017-06-04]
C:\Program Files (x86)\AviSynth+\plugins\audiofix(x86).dll [2019-06-02]
C:\Program Files (x86)\AviSynth+\plugins\aWarpSharp.dll [2016-06-24]
C:\Program Files (x86)\AviSynth+\plugins\ClipBlend26.dll [2018-01-03]
C:\Program Files (x86)\AviSynth+\plugins\DGDecodeNV.dll [0.0.0.2052]
C:\Program Files (x86)\AviSynth+\plugins\DirectShowSource.dll [2.6.0.3]
C:\Program Files (x86)\AviSynth+\plugins\DirectShowSource.newer.dll [2.6.0.3]
C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll [2.1.0.0]
C:\Program Files (x86)\AviSynth+\plugins\MedianBlur2.dll [2016-12-25]
C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll [0.93.0.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow1.4.0.0.132.dll [4.0.0.132]
C:\Program Files (x86)\AviSynth+\plugins\svpflow1.dll [4.0.0.132]
C:\Program Files (x86)\AviSynth+\plugins\svpflow2.4.0.0.136.dll [4.0.0.136]
C:\Program Files (x86)\AviSynth+\plugins\svpflow2.dll [4.0.0.136]
C:\Program Files (x86)\AviSynth+\plugins\TCPDeliver.dll [2.6.0.7]

[Scripts (AVSI)]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.avsi [2016-07-01]
C:\Program Files (x86)\AviSynth+\plugins\ChromaShiftSP.avsi [2018-01-27]
C:\Program Files (x86)\AviSynth+\plugins\colors_rgb.avsi [2015-03-30]
C:\Program Files (x86)\AviSynth+\plugins\FFMS2.avsi [2014-06-24]
C:\Program Files (x86)\AviSynth+\plugins\GameDropFixFuncs.avsi [2015-08-18]
C:\Program Files (x86)\AviSynth+\plugins\GameDropFixV5.avsi [2017-10-04]
C:\Program Files (x86)\AviSynth+\plugins\InterFrame2.avsi [2015-07-22]
C:\Program Files (x86)\AviSynth+\plugins\LimitedSharpenFaster.avsi [2017-01-03]
C:\Program Files (x86)\AviSynth+\plugins\QTGMC-3.33.avsi [2017-01-02]
C:\Program Files (x86)\AviSynth+\plugins\Rm_logo-TCs.avsi [2016-12-27]
C:\Program Files (x86)\AviSynth+\plugins\TCS-Video-Functions.avsi [2017-12-16]

[Uncategorized DLLs (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\libflowgpu.dll [1.2.7.0]
C:\Program Files (x86)\AviSynth+\plugins\libflowsse.dll [1.3.0.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow_cpu - Copy.dll [1.7.2.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow_cpu.dll [1.7.2.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow_gpu - Copy.dll [1.8.4.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow_gpu.dll [1.8.4.0]

[Uncategorized files]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.txt [2016-07-01]
C:\Program Files (x86)\AviSynth+\plugins\aWarpSharp(v1).xdll [2012-03-28]
C:\Program Files (x86)\AviSynth+\plugins\Builds.txt [2015-04-25]
C:\Program Files (x86)\AviSynth+\plugins\ffms2.lib [2014-06-20]
C:\Program Files (x86)\AviSynth+\plugins\ffmsindex.exe [2014-06-20]
C:\Program Files (x86)\AviSynth+\plugins\GameDropFixFuncs.(my-attempt).avsiX [2015-08-17]
C:\Program Files (x86)\AviSynth+\plugins\GameDropFixV5_01.Xavsi [2016-12-21]
C:\Program Files (x86)\AviSynth+\plugins\InterFrame2.html [2015-07-22]
C:\Program Files (x86)\AviSynth+\plugins\Rm_logo.ORIGINALavsi [2016-12-25]



[Plugin errors/warnings]
__________________________________________________________________________________________________________

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins/LSMASHSource.dll'. Platform returned code 126:
The specified module could not be found.

Dependencies that could not be loaded:
MSVCR120.dll

Note: Visual Studio 2013 Runtime doesn't seem to be installed
__________________________________________________________________________________________________________

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins/audiofix(x86).dll'. Platform returned code 126:
The specified module could not be found.

Dependencies that could not be loaded:
MSVCR120.dll

Note: Visual Studio 2013 Runtime doesn't seem to be installed
_______________________________________________________________________

FWIW, I no longer use LSMASH, and the audiofix(x86).dll IS in the folder that avsmeter says it's not in.

[TCmullet]

"My Avisynth version" can mean many things, I just assume that you mean "The Avisynth version I installed and believe is currently active on my system".

Secondly, it sure does not "require" SetMTMode.
No, I meant it as is. 1-2 years ago, I was forced to wrestle with this. As best I can remember, I was interacting with personnel from the SVP Team. (Again, as best I can recall,) I installed their free version player which included Avisynth+. But after installing it, all my scripts were bombing. It came out that I still needed SetMTMode for things I was using that COULD NOT be upgraded to not need it. They had me leave the SVP free version installed, but said to copy back certain dlls (SVPflow1, 2, I believe) over the top. So SetMTMode statements are in all my standard skeletons. There may be some that don't need it, but I use skeletons that will work for anything I'm doing, and having SetMTMode stuff is the standard that I need to follow for now.

BTW, I'm working hard these days (passively) to always have only one version of Avisynth on my system (each of my systems), the one I need and nothing else.

But thankfully, I don't think any controversy over SetMTMode has to be resolved to allow the kindly development function "audiofix" to work. Could it be as simple as a Microsoft Runtime package never got installed on this particular PC?

[Groucho2004]

Could it be as simple as a Microsoft Runtime package never got installed on this particular PC?
Yes, look at the error message in the AVSMeter log, it seems pretty clear to me.

[Groucho2004]

the audiofix(x86).dll IS in the folder that avsmeter says it's not in.That error message ("The specified module could not be found.") comes from Windows and is the explanation of the error return code. Quite confusing, I admit. However, checking the dependencies does show the real problem.

[TCmullet]

I'm a little confused. (Ha ha, nothing new there!) I find that I have a copy of vcredist_x86.exe in a folder of mine I called "Microsoft.VC+Redist". When I run it, it is "Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.24516". But it fails giving (in it's log) "Cannot install a product when a newer version is installed."

So the meter is telling me I need it. When I try to install, it says I have a newer one already. What am I missing (in my head)?

[Groucho2004]

I'm a little confused. (Ha ha, nothing new there!) I find that I have a copy of vcredist_x86.exe in a folder of mine I called "Microsoft.VC+Redist". When I run it, it is "Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.24516". But it fails giving (in it's log) "Cannot install a product when a newer version is installed."

So the meter is telling me I need it. When I try to install, it says I have a newer one already. What am I missing (in my head)?The problem is that you did not read the error message properly. You need "Microsoft Visual C++ 2013 Redistributable".

If you're on Windows 7 or later, I highly recommend the All-In-One installer you can find here (https://github.com/abbodi1406/vcredist/releases). It updates all runtimes and uninstalls outdated ones if required.

[TCmullet]

Thank you I will pursue your link. But if I need "Microsoft Visual C++ 2013 Redistributable", then why wouldn't every newer version of the same thing (including the 2015 version) meet the need? Aren't all these upgrades backward compatible??

That is,
Microsoft Visual C++ 2014 Redistributable
Microsoft Visual C++ 2015 Redistributable
Microsoft Visual C++ 2016 Redistributable
etc. should ALL work to accomplish the goals of
Microsoft Visual C++ 2013 Redistributable.

[Groucho2004]

But if I need "Microsoft Visual C++ 2013 Redistributable", then why wouldn't every newer version of the same thing (including the 2015 version) meet the need? Aren't all these upgrades backward compatible??
It's not about newer or older, each runtime is for a different version of MS VC++ (2005, 2008, 2010, 2013, 2015, ...).

[TCmullet]

AHH, then when I ran my 2015 install, it was saying I already had a newer version of 2015. I didn't realize the versions of VC++ were that separate. (Maybe if I had been more than a dabbler in VC++ in 2008, I'd know that.)

[TCmullet]

Dear Wonkey-monkey,

It's functioning now. However, I have reason to believe we may be screwed. It appears that the "offset" is changing after 3/4 of a frame.
So it's the wrong offset for 2 more "3/4ths", then ends up being accurate again temporarily. I'll show you a pic from Vdub. Then add some comments.

https://ibb.co/7VT5Z2W

[Groucho2004]

So SetMTMode statements are in all my standard skeletons. There may be some that don't need it, but I use skeletons that will work for anything I'm doing, and having SetMTMode stuff is the standard that I need to follow for now.OK. However, do you realize that you're not using SEt's Avisynth MT (which supports SetMTMode) but an old-ish version of Avisynth+ (which does not support that statement)?

[TCmullet]

Wonkey, assuming you can see the Vdub image, do you concur that we are screwed?

Before trying to start using your kindly developed function, I actually thought of another algorithm that would be better. Instead of estimating BV as I described earlier, simply derive the "offset" correctly. Then replace every bad value with the average of the two values surrounding it. That is, replace the bad value with the average of the sample BEFORE the bad value and the sample AFTER the bad value. This would work great, but also allow you to ignore ramping. We wouldn't need or care what the BV value is (your "add" parameter). We'd simply replace whatever it is with a synthesized value.

I think this would be great and a better solution, however, today's test seems to show that we CANNOT know the offset, as it keeps changing every 3/4ths of a frame. (3/4ths of 0.033 seconds).

Do you have any thoughts about this??

Also, I replaced the video in this file (much newer than the 10 sec. clip i gave you) with that 10 sec. clip. It turns out the 10 sec. segment displays the same problem I described. Shows up 2/3 of the way through the 1st frame. I'm using these code lines:
audiofix(offset=2,add=-20000,channels=AF_RIGHT,ramp=1000)
audiofix(offset=2,add=2000,channels=AF_LEFT,ramp=1000)

And I'm ASSUMING and INFERRING that the problem is a brief (1 sample) loss of offset due to an extra or a missing sample. I can't see it as it would be too much like hunting for a needle in a haystack to find (in Audacity) where the offset pattern broke. But it explains the visual pattern that we CAN see at the zoomed back view from VirtualDub.

[richardpl]

I would use ffmpeg:

This filter combination fixes both dc offset and buzz sound: ffmpeg -i input.file -af bandreject=f=16000,highpass=f=1 output.file

[StainlessS]

TC, clean up you plugin directories, you've got a lot of multiples in there, you seem particularly fond of have every version of svpflow,
and DirectshowSource, and Masktools, colors_rgb.avsi,

Not sure what you should do with these, see relevant docs (presumably svpflow docs, probably for system32/SysWOW64)
C:\Program Files (x86)\AviSynth+\plugins\libflowgpu.dll [1.2.7.0]
C:\Program Files (x86)\AviSynth+\plugins\libflowsse.dll [1.3.0.0]

same for these (which version do you use, CPU or GPU)
C:\Program Files (x86)\AviSynth+\plugins\svpflow_cpu.dll [1.7.2.0]
C:\Program Files (x86)\AviSynth+\plugins\svpflow_gpu - Copy.dll [1.8.4.0] # rubbish this
C:\Program Files (x86)\AviSynth+\plugins\svpflow_gpu.dll [1.8.4.0]

Get rid of all other Uncategorized dll's and files.

If you have a v2.6 ver$ dll, then you dont need any v2.5 dll.
And you have no idea which dll is being loaded if you have lots of version of the same one, and v2.5/2.6 dupes make even more of a mess.

get Pinterf Lastest avs+, r2772:- https://github.com/pinterf/AviSynthPlus/releases

Also, could stand a few updates to dlls:- http://avisynth.nl/index.php/External_filters

Reading install docs can avoid future problems for yourself, dont just dump everything in plugins directory, including readme.txt's and doc.html SupaDupaPlugin.cpp etc.
when you install a dll, remember to remove the old one.

Lastly, check your setup with the fantabulous AvsMeter avsinfo, or the equally gorgeous Avisynth Information tool both by the illustrious G2K4 (Grouchy2004).

[TCmullet]

Doesn't renaming a dll prevent it from getting used? Having the version number as text WITHIN the file name allows me to have a backup of the file and easily see what version it is. AND it let's me keep it in the same folder as the "live" one, for easy visibility when we're talking about lots of dlls to manage.

Yes, removing older versions of a dll (avisynth filter) would be cleaner to view when looking at a directory listing. But seeing as renaming a dll prevents it from being used by Avisynth, it is easy to put off clean-up when I have way too much for 3 people to do (and getting paid nearly nothing for it, though it's more than full-time often).

I'll revisit your comment, now that your advice is cast in stone here. Thanks.

Update: I believe that my habit was to rename a dll to include version RIGHT BEFORE I was to install a new one. That way, it's VERY easy to go back to the old one if the new one causes trouble (which it often has).

[Groucho2004]

Doesn't renaming a dll prevent it from getting used?Not in the slightest.

Edit - My answer above applies to implicit loading of DLLs such as Avisynth's auto-load mechanism.

Update: I believe that my habit was to rename a dll to include version RIGHT BEFORE I was to install a new one. That way, it's VERY easy to go back to the old one if the new one causes trouble (which it often has).And creating a directory just for these old versions is just too much of a hassle, isn't it? :rolleyes:

[StainlessS]

Renaming SuperPlug.dll to eg SuperPlug.dll.BAK would stop it loading, as no longer a recognised dll file, is .BAK file instead (or to .dll_BAK is a .dll_BAK file).
Easier just to make a BAK directory and chuck all of you rubbish (dll's) in there.
I create directories for script, various other plug type, or eg GPU plugs, or svp stuff or C type plugs, or whatever, and copy to main plugins as needed (C plugin need avsi script loader, except on avs+), excepting
for a few that always remain in-situ. (eg GScript [on x86], Grunt, RT_Stats + a few more).

If you have loads of dlls with same filters inside, then you have little or no control over which one is loaded, so updating to new one may make no difference at all.
(it probably depends upon directory sort order that is in effect)

EDIT: I also have directory in Plugins for dll related .EXE files, like those that work together with MultiDecimate/MDec2, and another for dll's that need to be copied
to system32/SysWOW64 on new install (for eg FFT3DFilter).

[TCmullet]

Not in the slightest.

Edit - My answer above applies to implicit loading of DLLs such as Avisynth's auto-load mechanism.

You may call me a monkey's uncle! I tested your allegation. Flushed a job out of Vdub queue, renamed a dll (DGBob.dll in this case; one critical to my script), loaded Vdub, loaded script and it WORKED! (DGBob was found even though I had renamed the dll in plugins to something else.)

I am stymied as to how I came to conclude that a faulty name on a dll would prevent it being used.

Question now would be, if there are 2 versions of one module, same name internally, but from differently named dlls and both were loaded, which one gets used?

[StainlessS]

If you have loads of dlls with same filters inside, then you have little or no control over which one is loaded, so updating to new one may make no difference at all.
(it probably depends upon directory sort order that is in effect)


You were probably writing when I added that edit.

You may call me a monkey's uncle!
I would think Wonkey_Monkey might have issue if he did.

EDIT: (Plugin_Autoload_and_Name_Precedence AND Plugin Autoload and Conflicting Function Names ):- http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Name_Precedence

[Groucho2004]

Question now would be, if there are 2 versions of one module, same name internally, but from differently named dlls and both were loaded, which one gets used?Without digging into the Avisynth code I'd boldly assume that they are loaded in the same order they were written do disk, i.e. the order in which they are in the partition table/MFT - IF they are in the same directory.
As for multiple plugin directories which are supported by AVS+ I'm not sure, I'll have to look at the auto-load code and how AVS+ enumerates the plugins.

So, for now just assume it's random and therefore it's a good idea to just keep one version of each.

[StainlessS]

It has I think seemd to me in the past that the loaded one was last in alphabetical order (but I usually have my defaults sorted in that order,
however, that was on XP where I could set it to keep current (as I move from directory to directory) sort order file display type details (icons, list, etc, but W7 seems to make that impossible, bloody infuriating).

EDIT: On XP you could set it to make current directory characteristics to all folders (and Not to remember previous setting for any directory), W7 has a nasty tendency to switch to showing bloody icons where directory contains some kind of media, and I get real annoyed about having to switch it back every time even in FileSelectors, Windows 7 Sux big time.

If is in order written to disk, I assume means directory order (where NO sorting is used), so would likely be affected where files deleted, leaving open slots, where next written files would likely take up squatting rights.

[Groucho2004]

and another for dll's that need to be copied
to system32/SysWOW64 on new install (for eg FFT3DFilter).Nowadays I much prefer to not copy dependencies such as the fft3w libraries to System32/SysWoW64. Instead I use the SysInfo plugin and load them this way (https://forum.doom9.org/showthread.php?p=1867424#post1867424).