Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
19th January 2021, 08:42 | #2242 | Link |
Registered User
Join Date: May 2020
Posts: 188
|
@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 |
19th January 2021, 15:40 | #2243 | Link |
Registered User
Join Date: Oct 2001
Location: Austria
Posts: 50
|
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? |
19th January 2021, 15:52 | #2244 | Link |
Registered User
Join Date: May 2020
Posts: 188
|
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.
|
19th January 2021, 15:56 | #2245 | Link | |
Registered User
Join Date: Feb 2015
Posts: 33
|
Quote:
|
|
19th January 2021, 16:01 | #2246 | Link | |
Registered User
Join Date: Oct 2001
Location: Austria
Posts: 50
|
Quote:
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. |
|
19th January 2021, 16:41 | #2247 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,846
|
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 19th January 2021 at 16:46. |
19th January 2021, 17:09 | #2248 | Link | |
Registered User
Join Date: Oct 2001
Location: Austria
Posts: 50
|
Quote:
:-) |
|
24th January 2021, 14:00 | #2249 | Link |
Registered User
Join Date: Mar 2013
Posts: 15
|
Since upgrading to 2.1.7 I am getting the following error for all encodes when using VapourSynth:
Code:
Script exceeded memory limit. Consider raising cache size. Code:
out of memory: 3087360 |
24th January 2021, 17:18 | #2250 | Link | |
App Digger
Join Date: Sep 2018
Posts: 411
|
Quote:
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. |
|
25th January 2021, 02:48 | #2251 | Link | |
Registered User
Join Date: Mar 2013
Posts: 15
|
Quote:
|
|
1st February 2021, 20:17 | #2252 | Link | ||
Registered User
Join Date: Sep 2015
Posts: 16
|
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.
Quote:
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. Quote:
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. |
||
13th February 2021, 10:00 | #2253 | Link | ||
Registered User
Join Date: Sep 2015
Posts: 16
|
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. Quote:
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. Quote:
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. |
||
13th February 2021, 15:47 | #2254 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,846
|
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
13th February 2021, 19:49 | #2255 | Link |
Registered User
Join Date: Sep 2015
Posts: 16
|
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. Last edited by Trench; 13th February 2021 at 19:53. Reason: a word |
14th February 2021, 11:31 | #2256 | Link |
Registered User
Join Date: Dec 2014
Posts: 666
|
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
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR |
14th February 2021, 15:13 | #2257 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,251
|
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
Tags |
aac, hdr, hevc, nvenc, staxrip, x264, x265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|