StaxRip 2.0 Support Thread

[Atlantis]

Question. I remember you said some time ago that you added a button for attachments in demux dialog to select none like Audio and Subtitles but I noticed it is not there.

[44vince44]

@LazyNcoder you should check up the Staxrip docs, downloads section. There you get links to the betas.
There have been 3 betas released since then.
https://staxrip.readthedocs.io/intro....html#download

[freezer]

Hi guys - I need some help with audio processing in Staxrip. Feeling really stupid right now as I can't figure out on myself what I am doing wrong.

Goal: import old interlaced footage, process the video and copy (or convert) audio to ProRes MOV with PCM audio.

I've got three types of source footage:

#1 miniDV AVI with stereo channel PCM audio - this does work as expected by setting audio to copy/mux profile. No problem here. A window pops up and asks for the audio track to get demuxed.

#2 HDV m2t with stereo channel MP2 audio

#3 XDCAM HD422 mxf OP-1A with 8 mono channel PCM audio

With #2 and #3 I just can't get any audio processed through the pipeline.

Staxrip stable 2.1.7.0 with local installations of
AviSynth 3.7.0
VapourSynth r52
Phyton 3.8.2150

Scripting runs through VaporSynth.

But no matter what I choose for audio as the profile, it doesn't get loaded when the video source gets loaded.
I can right click into the audio field and select the file again, then I get at least one track. That's ok for processing one file, but for batch processing hundreds it can't be the way to go.
Creating a ffmpeg -c:a pcm_s24le profile did not help either...

I have googled around for 2 days and read several threads but there must be something (setting/procedure) I am obviously missing.

Hopefully someone with more knowledge can give me a hint into the right direction?

[44vince44]

Can you please provide a mediainfo sheet of the source that has the problem, and a log of the processing as well (you may paste them in pastebin.com then link to them here). I'm sure we'll help once we got that information.

[LazyNcoder]

Originally Posted by 44vince44

@LazyNcoder you should check up the Staxrip docs, downloads section. There you get links to the betas.
There have been 3 betas released since then.
https://staxrip.readthedocs.io/intro....html#download

Thank you very much!

[freezer]

Originally Posted by 44vince44

Can you please provide a mediainfo sheet of the source that has the problem, and a log of the processing as well (you may paste them in pastebin.com then link to them here). I'm sure we'll help once we got that information.

Thanks!

I thought it might be easier to supply a short clip I am using for testing (43 MB)
This is the m2t file:
https://we.tl/t-i2vzqoQy8a

And this is the Staxrip Template:
https://we.tl/t-ehPbIfe6c1

I am looking for a sample of the MXF source I can upload too and will provide a link then.

[stax76]

The default configuration would demux and decode it with DgMpgDec, but that don't run because ffms2 is defined as source filter. What you can do is changing the source filter back to automatic or MPEG2Source, or you can remux it to mkv:

Tools > Settings > Preprocessing > ffmpeg remux > Edit > Input File Types > ts m2t

In the next build m2t will be found as audio source file, but this might result in async audio, so I recommend DgMpgDec.

[freezer]

Originally Posted by stax76

The default configuration would demux and decode it with DgMpgDec, but that don't run because ffms2 is defined as source filter. What you can do is changing the source filter back to automatic or MPEG2Source, or you can remux it to mkv:

Tools > Settings > Preprocessing > ffmpeg remux > Edit > Input File Types > ts m2t

In the next build m2t will be found as audio source file, but this might result in async audio, so I recommend DgMpgDec.

Many Thanks! Setting the source filter to automatic did the trick.
:-)

[creeve4]

Since upgrading to 2.1.7 I am getting the following error for all encodes when using VapourSynth:

Script exceeded memory limit. Consider raising cache size.

My encodes will not complete

out of memory: 3087360

How do I increase the memory limit? I have searched and read, but I cannot find an answer.

[JKyle]

Originally Posted by creeve4

Since upgrading to 2.1.7 I am getting the following error for all encodes when using VapourSynth:

Script exceeded memory limit. Consider raising cache size.

This issue was raised right after the default setting for x265 encoding of vpy was changed from vspipe to direct reading without piping.
See this issue thread.

You can solve this problem in two ways.

1) Select vspipe for Pipe in Input/Output section of x265 Options window.

or

2) get @DJATOM's new x265 build that is believed to have fixed this memory leak issue, and replace the current one with this new build. You need some more testing in this case.

[creeve4]

Originally Posted by JKyle

This issue was raised right after the default setting for x265 encoding of vpy was changed from vspipe to direct reading without piping.
See this issue thread.

You can solve this problem in two ways.

1) Select vspipe for Pipe in Input/Output section of x265 Options window.

or

2) get @DJATOM's new x265 build that is believed to have fixed this memory leak issue, and replace the current one with this new build. You need some more testing in this case.

Thank you so much!

[Trench]

Thanks all. I've been out of the office the past three weeks, and just now getting back to where I can test this. Note we did also have a Microsoft Patch Tuesday since this was observed, and the machine has automatically restarted to apply those updates since then.

Originally Posted by 44vince44

@Trench, is it possible to edit the properties of your C:\Files\Staxrip\ folder and set permissions (full control) to you as user? do mount points allow that ?

Agreed it's wise to check the permissions, given the evidence.

Although the point still remains that with the tools included and/or invoked by Staxrip 2.1.3.0.Stable or 2.1.4.8.Beta against the same source files in the same folder with the same set permissions, the temp area created by Staxrip could be written to successfully.

And also that using "Run as Administrator", for which those default permissions you're referring to grant Full Control to the Administrators group, hadn't avoided the issue either.

Originally Posted by stax76

The only relevant change I remember is changing the current directory of the staxrip process to the video temp folder, this was not long ago. Before the current folder of the staxrip process was usually the startup folder where staxrip is located. That's something a child process inherits.

Interesting observation that I will keep in mind while continuing to investigate. As you might have noted from the log, the Staxrip program directory in my case is actually outside of the mount point area; in "C:\Users\Trench\StaxRip-x64-2.1.7.0-Stable" instead of "C:\Files\Staxrip". So that kind of current process directory change does seem reasonable to consider.


But today -- as I test this issue which duplicated 100% for files inside of "C:\Files\Staxrip", and for which I had to work around the problem by moving my source files outside of the mount point area -- today the problem no longer occurs.

Since I've been away and not changing anything about the test or the configuration, for the moment I'm assuming Microsoft's Patch Tuesday corrected something here; whether it was also related to process' current directory or not. The patch that applied in my absence was https://support.microsoft.com/help/4598242/, but I do not see any changes with obvious correlation attributed there, other than "unspecified security updates."

Therefore the problem no longer exists at the moment. But should this symptom return, I can pick up with the recommended tests and report back.

[Trench]

Hmmm. I'm seeing the issue again, but it's starting to be difficult to believe.

After my previous post, I processed dozens of files on February 5 through February 7, using StaxRip 2.1.7.0 Stable, without any issue. Source files inside the mountpoint, StaxRip outside the mount point on the SSD, as intended.

Today I went to process more files, and StaxRip advises 2.1.8.0 stable is available. I download and extract to C:\Users\Trench\StaxRip-x64-2.1.8.0-Stable\, on the SSD and outside of the mount point, same as 2.1.7.0 was located.

Maybe it's worth noting that on February 10 Microsoft applied KB4601319 and KB4601050 for Patch Tuesday, but I'm finding it harder to believe that's actually important.

The very first file I attempt to process with 2.1.8.0 Stable fails, with the same "permission denied" and "error 1" as described before.

And, if I launch 2.1.7.0 Stable instead, it still works fine, using the same source file, in the same folder, with the same permissions that fail with 2.1.8.0.

So before, 2.1.7.0 was the failing version, and older versions of StaxRip worked. Now, 2.1.7.0 is the working version, and 2.1.8.0 is what fails. There is some kind of clue in that, but I don't know what.

I think I just need a priest. Logs of each version attempting to "open single file" the same source file are attached, once the attachments are approved, just in case you can see something I'm missing.

Originally Posted by 44vince44

So, @Trench, please check and do the permissions change, or set your paths to locations that you have R/W control on.

In this instance as well, the folder permissions that fail with 2.1.8.0 work just fine as-is with 2.1.7.0. So once again, I would just stipulate that the permissions really aren't blocking successful use of the folder.

But, there is no harm in granting Full Access. Granting Full Access to my user for the folder the source file exists in (and "Replace all child object permission entries...", although the temp file doesn't exist yet) doesn't change the outcome. Still the same permission denied & failure.

See attached screen shot confirming permissions that were set, once the attachment is approved.

Originally Posted by stax76

The only relevant change I remember is changing the current directory of the staxrip process to the video temp folder, this was not long ago. Before the current folder of the staxrip process was usually the startup folder where staxrip is located. That's something a child process inherits.

The test that came to mind for this was to setup StaxRip 2.1.8.0 Stable to run from a directory that was also inside the mount point, instead of being out on the SSD. In case "the current directory being on a different side of that mount point" was somehow the issue.

But that didn't change the symptoms or the failure either. The same "permission denied" and "error 1" happen even with StaxRip running from inside the mount point.

To rule out whether my shortcuts for launching StaxRip were any part of the problem, I also performed all testing this time by directly launching the StaxRip.exe from the program folder by double-clicking in File Explorer. But that didn't change the outcome either.

I don't suppose there is any hacky switch I can set that reverts back to the "keep StaxRip application folder as the current directory" behavior? Or maybe some other test you can think of that I'm ignoring.

[stax76]

In 2.1.7.1 Beta there was the following change:

- Revert current folder of process being set to video temp folder because it locks the folder and also because the .NET Framework allows only 260 characters for the working directory of a process.

I just searched the code for Environment.CurrentDirectory, it's not found anywhere, so the current folder staxrip inherits, is never changed.

So you can do the following to find out if that change is the reason for your issue:

1. Options > Misc > Use source file folder for temp files

2. Open terminal and change folder to where your source is

3. Start staxrip from terminal

If that solved it, then we can put it back as a setting, disabled by default.

[Trench]

Thanks for the info.

Sigh... Symantec antivirus. Or more specifically, Norton Data Protector. MKV and other media files are by default among those it wants to "protect".

The "C:\Files\StaxRip" folder WAS NOT in a directory tree that Norton Data Protector was configured to watch, though. The default folders it watches are just the user profile folders like Documents, Pictures, Videos, Desktop, etc.

But something about Symantec's evaluation of "should I be protecting this .MKV file" was apparently misfiring here, and seemingly "specifically when traversal of a mount point is involved in the path to the .MKV file."

Because as soon as I put the failing 2.1.8.0 Stable StaxRip.exe process on the exclude list for Norton Data Protector, no more failure.

This doesn't directly explain why 2.1.7.0 Stable changed from "failure case" to "success case" from January 2021 to February 2021, because it's not on the process exclude list.

But it was just very suspicious that "2.1.7.0 initially failed back in January, but in February 2.1.7.0 now works, but the newly-downloaded 2.1.8.0 fails." Which is what made me start looking at antivirus possibilities. My best guess is that the passage of time perhaps made Symantec "trust" the process, in ways it didn't trust the newly-downloaded process.

Off to figure out how to report to Symantec.


Oh, and just to confirm, the tests related to current directory did not change the outcome. So "good news" in that regard, that even if it was some other third-party's fault, the change in CWD for processes wasn't a factor in experiencing it. Even though the source file being inside or outside the mount point did affect it.

[Magik Mark]

Guys,

When converting audio to AAC how do you increase the dialogue (midrage). I plan to use qaac and fdkaac.
I find it annoying ac3 dts atmos and other sound technologies have very subtle dialogue. Increasing the volume would also increase the other channels

Thanks

[LoRd_MuldeR]

~closed~

Please use this thread:
https://forum.doom9.org/showthread.php?t=172068