Log in

View Full Version : StaxRip


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

Groucho2004
1st June 2020, 16:39
I thought it might already be compatible with my CPU it's an old Xeon x5675 but just remembered it has no support for AVX instructions this is why I can't use QTGMC.Have a look at my post here (https://forum.doom9.org/showthread.php?p=1889362#post1889362).

jlw_4049
1st June 2020, 17:23
Thanks for the update @stax76

:)

Sent from my SM-G986U1 using Tapatalk

lordalibaski
1st June 2020, 20:48
Have a look at my post here (https://forum.doom9.org/showthread.php?p=1889362#post1889362).

Grabbed it mate thank you very much for that, funny how the XP_SSE2 release works with Windows 10 but none of the newer ones will.

Going to do some testing with this see how it differs from the normal fieldDienterlace method.

JKyle
1st June 2020, 23:26
Save it with file name BeforeProcessing.ps1 under:

Main Menu > Tools > Scripts > Open Script Folder

If the audio source file extension is flac and the audio encoder is qaac it sets decoding mode to Pipe.

Thanks.
After some testing, I found two issues: with the ps1 script itself and with StaxRip 2.1.1.8.

1) When the source mkv file is not demuxed in loading, your script does not work.
The decoding method for qaac still remains as FLAC.
Only in audio re-encoding mkvextract demuxes the flac audio track in mkv as it is.
But qaac fails to read it, as you know.

2) StaxRip 2.1.1.8 cannot read ps1 scripts when their names do not have spaces.
For example, BeforeProcessing.ps1 does not appear in the Tools > Scripts menu, while Before Processing.ps1 does.



2.1.1.8 Beta
============

- f3kdb Neo r6
- DFTTest Neo r7


1) Replacing flash3kyuu_deband with f3kdb Neo causes these dependency problems.

mClean.avsi
uses f3kdb, not neo_f3kdb in line 143.

G41Fun.mClean in VS Scripts > G41Fun.py
calls f3kdb, not neo_f3kdb in line 2557.

For these two files, simply replacing f3kdb with neo_f3kdb seems to fix the problem.


2) Replacing DFTTest with DFTTest Neo causes this dependency problem.

dfttestMC in VS Scripts > muvsfunc.py
calls dfttest not neo_dfttest in line 2672.

Well, since dfttestMC is not listed in the default VS profiles, I think this will not be an issue unless a user puts it manually in the VS script.


BTW, thanks for putting Zs_RF_Shared.avsi. Now I can remove the file from the plugins folder. :)


All in all, thanks for the update.
:thanks:

mcjordan
2nd June 2020, 14:51
MVTools 2.7.43
Changelog: MCompensate: fix crash for GreyScale formats when overlap is used
https://github.com/pinterf/mvtools/releases/tag/2.7.43

craigpro
6th June 2020, 15:23
when I start StanRip and I have the automatic template set to "automatic workflow", I add files to the batch, it then asks me select a template again (automatic workflow etc.).

what's become corrupted with my config please? It started doing it in beta 2.1.0.8 (most likely due to PEBKAC - I think I overwrote an .srip file accidentally), but I just downloaded 2.1.1.8 beta and overwrote all files and it's still doing it.

any help to reset config is most appreciated - is it something in registry? thank you.

stax76
6th June 2020, 18:44
@craigpro

There is a setting Show template selection when loading new files, by default it's disabled but even when enabled this should be ignored in batch mode, just tried it, here it's not shown in batch mode.

Overwriting files can cause issues, so I absolutely don't recommend it. The new build blocks custom paths stored in the startup folder (unless enabled in the danger zone settings, bad idea).


@all

It's not easy to address all feedback, so I focus on the issue tracker.


2.1.1.9 Beta

- The cut feature was missing the last frame.
- In case the cut feature is used, flac input for qaac is disabled so if necessary a w64 file is created.
- Many nvenc improvements.
- Layout and scaling fixes.
- PowerShell script host supports events, script examples use events.
- The menu in the Jobs dialog was improved.
- mvtools2 2.7.43

chipxtreme
6th June 2020, 20:53
2.1.1.9 is buggy, when I load I get errors

"Load x265 first"

"Load VapourSynth first

Filters > Filter Setup > VapourSynth"

"Re-mux"

"PowerShell Scipt Exception

Method invocation failed because [StaxRip.TaskDialog`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]] does not contain a method named 'AddCommandLink'.

at: line 25

System.Management.Automation.RuntimeException: Method invocation failed because [StaxRip.TaskDialog`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]] does not contain a method named 'AddCommandLink'.
at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
at StaxRip.PowerShell.Invoke(String code, String varName, Object varValue) in D:\Projekte\VB\staxrip\General\PowerShell.vb:line 40
at StaxRip.GlobalClass.InvokePowerShellCode(String code, String varName, Object varValue) in D:\Projekte\VB\staxrip\General\GlobalClass.vb:line 51"

stax76
6th June 2020, 21:17
Maybe you did the cardinal sin to copy over, its one of the most reliable ways to break any software, I wrote that one post before. :)

chipxtreme
6th June 2020, 21:51
Maybe you did the cardinal sin to copy over, its one of the most reliable ways to break any software, I wrote that one post before. :)

Yes that has sorted the errors out but now when I go to add an .mkv it complains about DGIndex which has been removed in latest builds

stax76
6th June 2020, 21:58
You can create a d2v file with d2v Witch.

chipxtreme
6th June 2020, 22:03
You can create a d2v file with d2v Witch.

How? I'm used to Staxrip just working

Also with 2.1.1.9 the boxes to adjust bitrate and filesize aren't editable

JKyle
6th June 2020, 23:24
How? I'm used to Staxrip just working

Also with 2.1.1.9 the boxes to adjust bitrate and filesize aren't editable

Video bitrate option is in the video encoder 'Options' menu.

https://i.imgur.com/FTEqVx9.jpg

I highly recommend you fresh install StaxRip after deleting all the settings hidden in C:\Users\<your Windows username>\AppData\Roaming\StaxRip or C:\ProgramData\StaxRip.

Always choose the local folder where the app itself is unarchived for your settings data.

When a d2v file generation fails due to lack of DGIndex, uncheck DGIndex item in Tools > Settings > Preprocessing.

stax76
6th June 2020, 23:57
@chipxtreme

Or if you want to restore the old behavior you can set the bitrate to 0 in the encoder dialog.

craigpro
7th June 2020, 04:08
@craigpro

There is a setting Show template selection when loading new files, by default it's disabled but even when enabled this should be ignored in batch mode, just tried it, here it's not shown in batch mode.

Overwriting files can cause issues, so I absolutely don't recommend it. The new build blocks custom paths stored in the startup folder (unless enabled in the danger zone settings, bad idea).



@staxrip - thank you so much for the response, I checked my 'Show template etc.' setting and it was disabled, so I tried enabling it, running a batch and then dis-abling it and still no luck.

It did give me an idea though and I deleted my "\Staxrip\Settings\Templates\Automatic Workflow.srip" file and then looked for the file in the StaxRip-x64-2.1.1.8-beta.7z archive and was surprised it wasn't there.. so then I thought it must be auto-created - so with the original file deleted I re-ran staxrip.exe and yes, the file was created and after a little customising and re-saving it it's now all working fine - thank you so much for an excellent app and your assistance!

chipxtreme
7th June 2020, 16:47
@chipxtreme

Or if you want to restore the old behavior you can set the bitrate to 0 in the encoder dialog.

Sorry what I meant was this. I mainly convert x264 to 10 bit x265.

With 2.1.1.8 the Size and Video Bitrate is visible so I can adjust them, but under 2.1.1.9 the boxes aren't there.

https://www.dropbox.com/s/9fldcilptays7wj/staxrip.jpg?dl=0

stax76
7th June 2020, 17:03
It's probably because the video encoder setting use some kind of quality mode, you need to change it to use a bitrate mode.

chipxtreme
7th June 2020, 17:16
It's probably because the video encoder setting use some kind of quality mode, you need to change it to use a bitrate mode.

I use VBR HQ

stax76
7th June 2020, 18:39
It works here, maybe there is something wrong with the encoder profile settings, possibly because I changed the encoder framework last time I worked on nvenc. Create new profiles in the Encoder Profiles dialog, either using the Add button to create only nvenc profiles or using the Restore button to re-create all encoder profiles, and check your templates for bad encoder settings.

jlw_4049
8th June 2020, 05:20
stax76,

was wondering if there was a way to setup an AVS script in StaxRip via an already indexed file. FFindex?

shodan5000
8th June 2020, 16:00
So MCTemporalDenoise is totally broken in Vapoursynth because of the switch to using DFTTest (Neo) instead of just DFTTest. Sadly, I have zero programming type troubleshooting skills to fix this on my own. Stax, can you please correct this issue? Thank you.

JKyle
8th June 2020, 18:01
So MCTemporalDenoise is totally broken in Vapoursynth because of the switch to using DFTTest (Neo) instead of just DFTTest. Sadly, I have zero programming type troubleshooting skills to fix this on my own.

DFTTest Neo seems to be a complete replacement for DFTTest, so for a quick stop gap measure, you can change some lines in <StaxRip folder>\Apps\Plugins\VS\Scripts\havsfunc.py like this:

core.dfttest.DFTTest(... ⇒ core.neo_dfttest.DFTTest(...

in lines 1191, 3026, 3210, 3353.

And you need to provide a new version number for havsfunc in Apps > Manage.

I verified that this works fine, but like I said, this is not an official fix. :)

shodan5000
8th June 2020, 19:41
DFTTest Neo seems to be a complete replacement for DFTTest, so for a quick stop gap measure, you can change some lines in <StaxRip folder>\Apps\Plugins\VS\Scripts\havsfunc.py like this:

core.dfttest.DFTTest(... ⇒ core.neo_dfttest.DFTTest(...

in lines 1191, 3026, 3210, 3353.

And you need to provide a new version number for havsfunc in Apps > Manage.

I verified that this works fine, but like I said, this is not an official fix. :)

Thanks for the tip. I'll give that a shot.

stax76
9th June 2020, 01:11
stax76,

was wondering if there was a way to setup an AVS script in StaxRip via an already indexed file. FFindex?

The logic in staxrip is: if the cachefile param exist in the script and the index file does not exist in the location where staxrip expects it, then staxrip triggers indexing. But if it exists in the expected location, then staxrip does not trigger indexing but the index file is reused. If no cachefile param exists in the script then staxrip does not trigger indexing.

ffms2 does the same, it triggers indexing only if the index file does not exist in the location where ffms2 expects the index file when no chachefile param exists.

So where is the expected location for staxrip if the cachefile param exists?

And where is the expected location for ffms2 if the cachefile param does not exist?

I leave this for you to figure out. ;)


2.1.2.2 Beta
============

- The Processing dialog has a new feature: Stop After Current Job.
- GPL licensed DGIndex binary re-added.
- D2V Witch added and enabled by default for VOB/MPG.
- Command line for some processes like ffmsindex wasn't shown while processing.
- DFTTest VS re-added to fix dependency issue.
- MCTemporalDenoise AVS dependency issue fix.
- Render, scaling and layout fixes and improvements.


I hope a stable version can be released this week.

jlw_4049
9th June 2020, 01:23
The logic in staxrip is: if the cachefile param exist in the script and the index file does not exist in the location where staxrip expects it, then staxrip triggers indexing. But if it exists in the expected location, then staxrip does not trigger indexing but the index file is reused. If no cachefile param exists in the script then staxrip does not trigger indexing.



ffms2 does the same, it triggers indexing only if the index file does not exist in the location where ffms2 expects the index file when no chachefile param exists.



So where is the expected location for staxrip if the cachefile param exists?



And where is the expected location for ffms2 if the cachefile param does not exist?



I leave this for you to figure out. ;)





2.1.2.2 Beta

============



- The Processing dialog has a new feature: Stop After Current Job.

- GPL licensed DGIndex binary re-added.

- D2V Witch added and enabled by default for VOB/MPG.

- Command line for some processes like ffmsindex wasn't shown while processing.

- DFTTest VS re-added to fix dependency issue.

- MCTemporalDenoise AVS dependency issue fix.

- Render, scaling and layout fixes and improvements.





I hope a stable version can be released this week.Idk if its possible but would there be a way to batch index ahead of time with staxrip. Then later do the cropping etc

Sent from my SM-G986U1 using Tapatalk

stax76
9th June 2020, 01:52
If you want to batch preprocess then you can try to disable everything else, mux encoder, 'No Muxing' muxer etc.

And after batch preprocessing is done then open it with a template that has the preprocessing disabled.

Another approach would be using the CLI.

Alexander
11th June 2020, 12:34
x264 encoder updated to 160 r3007

chipxtreme
11th June 2020, 15:28
NVEnc updated to 5.04

stax76
11th June 2020, 16:03
NVEnc updated to 5.04

Seems he forgot to upload the x64 build.

chipxtreme
11th June 2020, 16:26
Seems he forgot to upload the x64 build.

It's there now.

VaterGans
12th June 2020, 07:20
Hello everybody,

at first i want to say Thank you for all the work and effort that was put into staxrip.
Since ffmpeg is capable to create DD+ (eac3) files i'm using it frequently on the cmdline. DD+ offers a good compatibility and good encoding qualtiy and size.
Is it possible to integrate eac3 in the audio encoding menus of Staxrip?

Kind regards,
VaterGans

jlw_4049
12th June 2020, 07:29
Hello everybody,

at first i want to say Thank you for all the work and effort that was put into staxrip.
Since ffmpeg is capable to create DD+ (eac3) files i'm using it frequently on the cmdline. DD+ offers a good compatibility and good encoding qualtiy and size.
Is it possible to integrate eac3 in the audio encoding menus of Staxrip?

Kind regards,
VaterGans


It's already there :P

EDIT: I thought you meant eac3to.
https://i.imgur.com/AzfhDa5.png

VaterGans
12th June 2020, 10:50
It's already there :P

EDIT: I thought you meant eac3to.
https://i.imgur.com/AzfhDa5.png

Maybe it was not so clear. It should be available in the codec selection.

Regards,
VaterGans

Condo Ghost
12th June 2020, 12:47
I'm an oldie still using StaxRip-x64-1.3.1.7-beta and very happy to be doing so. I've managed by trial and error to set 'most defaults' for my purpose including 'subtitles all', output bitrate, and have them saved and stored Project -> Save As Template.

Most everything except for 'audio track' which is by default 'English'.

I'm guessing this requires an edit maybe of StaxRip-x64-1.3.1.7-beta > Apps > eac3to? I'm stuck on the 'how to do'.

I've looked everywhere. I can see the 'edit screens' in the 'documentation' but not the 'how-to' to access/change/update/save these 'edit screens.

I'm looking to change audio track setting to be 'all languages' not just 'English language'.

Much obliged for help on this.

Thank-you.

'Stay healthy Stay safe'

UPDATE

13/06/2020 00:21

@Condo Ghost
The version is probably some years old, most maintainers require people trying the latest beta first before making a request.
Thank-you @stax76. Much obliged for letting me know the point about most maintainers requiring people trying the latest beta first before making a request.

With StaxRip 2.1.3.0 indeed I have it fully set-up with my defaults saved in a template including Options -> Project Options Preferred Languages all.

I have all previous versions StaxRip-x64-2.0.6.0-stable, StaxRip-x64-2.0.1.0-stable, StaxRip-x64-1.7.0.0-stable, StaxRip-x64-1.6, StaxRip-x64-1.5.0.0, StaxRip-x64-1.3.2.0 and StaxRip-x64-1.3.1.7-beta set-up with my defaults, templates saved, running each extensively over time comparing outputs, logs and job complete times.

For me I am still more than happy with the output from StaxRip-x64-1.3.1.7-beta compared to all newer versions.

I continue to use it because job complete 2-Pass x265 is much faster, for example, 01:50:40 compared to StaxRip-x64-2.0.6.0-stable 03:30:51.

The only point I have to address is not seeing 'Options -> Project Options Preferred Languages' with StaxRip-x64-1.3.1.7-beta.

Being able to set this in the template would be a 'bonus' though of course I've been working with setting this manually for some years now for all encodes where audio language is not English.

If there is a way to update the StaxRip-x64-1.3.1.7-beta template 'audio language all' 'great', if there isn't then that's 'great' too.

Thank-you.

stax76
12th June 2020, 13:22
Is it possible to integrate eac3 in the audio encoding menus of Staxrip?

StaxRip generally supports 4 types of audio profiles:

GUI profile
CLI profile
Mux profile
Ignore profile

For unsupported features you can try the CLI profile, for GUI support feel free to create an issue on the tracker (https://github.com/staxrip/staxrip/issues).


@Condo Ghost

The version is probably some years old, most maintainers require people trying the latest beta first before making a request.

jlw_4049
12th June 2020, 15:56
Its easy to bring your settings forward with you as well

Sent from my SM-G986U1 using Tapatalk

stax76
12th June 2020, 16:05
I've uploaded the new version now and hope it doesn't have severe issues, people that didn't want to test Betas might as well wait few more days.

Thanks to everybody who contributed in some form!

2.1.3.0

- Web URL is included in the search of the Apps dialog.
- Numerous bugs fixed.
- The Processing dialog has a new feature: Stop After Current Job.
- D2V Witch added and enabled by default for VOB/MPG.
- Command line for some processes like ffmsindex wasn't shown while processing.
- Render, scaling and layout fixes and improvements, especially for 96 DPI.
- PowerShell script host supports events, script examples use events, better error handling.
- Improved Log File Viewer (Main Menu > Tools > Log File). Tip: The Log File Viewer has a context menu.
- The Preview dialog can be resized with the mouse.
- Support for character # in filenames because MP4Box was finally fixed.
- Various dialogs made resizable and remember their size.
- Maximum number of parallel processes increased from 4 to 16.
- The documentation was greatly improved (still far from perfect though).
- Muxer dialog supports Drag & Drop for subtitles, audio and attachments.
- Video Comparison has hardware render support added.
- aomenc.exe GUI re-enabled.
- Dark color theme for built-in help.
- Improved built-in F1 help.
- ffmpeg video encoder codec FFV1.
- x264 and x265 dialogs have a new Bitrate option, the default value is 0 which means the bitrate of the project/template in the main dialog is used.
- For file batch jobs only the file name is shown in the jobs dialog and not the full path.
- Audio encoder supports extracting DTS core using ffmpeg.
- The audio Copy/Mux profile has a Extract DTS Core feature.
- The command line audio encoder has a Default and Forced option.
- New chunk encoding feature for x265 parallel processing.
- Media info dialog replaced with MediaInfo.NET.
- The command line video and audio encoder uses cmd.exe directly without creating a bat file, this avoids creating a temporary bat file and adds full unicode support.
- Portable support added, no need to install anything.
- Setting to allow to use tools with wrong version, for this a Danger Zone tab was added in the settings.
- The auto crop feature shows progress both in the processing dialog and in the crop dialog.
- Improved issue templates on the github issue tracker.
- The ExecuteCommandLine command has a new Working Directory parameter.
- The launch button in the Apps dialog for a console tool shows its help via Windows Terminal
- Windows Terminal available in the main menu with special StaxRip environment (apps and macros).
- The video encoder dialog feature *Show Command Line* is shown using Windows Terminal.
- Execute Command Line in video encoder dialogs is shown via Windows Terminal.
- In the Apps dialog the tools can be listed using PowerShell Out-GridView.
- Shell Execute flag was added to the command ExecuteCommandLine.
- The global setting 'Add filter to convert chroma subsampling to 4:2:0' uses now ConvertToYUV420 instead of ConverttoYV12.
- In various command line features the path environment variable of the process has all exe tools added and all macros are available as environment variables.
- Check added that blocks source files with too long path or filename. A setting that allows to change the limit exists in the Danger Zone section.
- SVT-AV1 support with GUI.
- Media info folder view was replaced with a new powershell based (Get-MediaInfo) dialog that supports caching for fast startup perforance.
- When a Event Command executes it writes a log entry, this is now disabled by default but there is a new setting: 'Write Event Commands to log file'.
- In the Jobs dialog there is a button that shows a menu, this menu can now also be shown as context menu via right-click on the jobs list and it has various new features.
- The Apps dialog allows to clear custom paths.
- The Apps dialog allows to locate files via Everything.
- Check for Updates added to main menu in Help section.
- Version is shown in main dialog title bar.
- 'Main Menu > Help > Info' shows list with contributors.

jlw_4049
12th June 2020, 16:40
I've uploaded the new version now and hope it doesn't have severe issues, people that didn't want to test Betas might as well wait few more days.

Thanks to everybody who contributed in some form!

2.1.3.0

- Web URL is included in the search of the Apps dialog.
- Numerous bugs fixed.
- The Processing dialog has a new feature: Stop After Current Job.
- D2V Witch added and enabled by default for VOB/MPG.
- Command line for some processes like ffmsindex wasn't shown while processing.
- Render, scaling and layout fixes and improvements, especially for 96 DPI.
- PowerShell script host supports events, script examples use events, better error handling.
- Improved Log File Viewer (Main Menu > Tools > Log File). Tip: The Log File Viewer has a context menu.
- The Preview dialog can be resized with the mouse.
- Support for character # in filenames because MP4Box was finally fixed.
- Various dialogs made resizable and remember their size.
- Maximum number of parallel processes increased from 4 to 16.
- The documentation was greatly improved (still far from perfect though).
- Muxer dialog supports Drag & Drop for subtitles, audio and attachments.
- Video Comparison has hardware render support added.
- aomenc.exe GUI re-enabled.
- Dark color theme for built-in help.
- Improved built-in F1 help.
- ffmpeg video encoder codec FFV1.
- x264 and x265 dialogs have a new Bitrate option, the default value is 0 which means the bitrate of the project/template in the main dialog is used.
- For file batch jobs only the file name is shown in the jobs dialog and not the full path.
- Audio encoder supports extracting DTS core using ffmpeg.
- The audio Copy/Mux profile has a Extract DTS Core feature.
- The command line audio encoder has a Default and Forced option.
- New chunk encoding feature for x265 parallel processing.
- Media info dialog replaced with MediaInfo.NET.
- The command line video and audio encoder uses cmd.exe directly without creating a bat file, this avoids creating a temporary bat file and adds full unicode support.
- Portable support added, no need to install anything.
- Setting to allow to use tools with wrong version, for this a Danger Zone tab was added in the settings.
- The auto crop feature shows progress both in the processing dialog and in the crop dialog.
- Improved issue templates on the github issue tracker.
- The ExecuteCommandLine command has a new Working Directory parameter.
- The launch button in the Apps dialog for a console tool shows its help via Windows Terminal
- Windows Terminal available in the main menu with special StaxRip environment (apps and macros).
- The video encoder dialog feature *Show Command Line* is shown using Windows Terminal.
- Execute Command Line in video encoder dialogs is shown via Windows Terminal.
- In the Apps dialog the tools can be listed using PowerShell Out-GridView.
- Shell Execute flag was added to the command ExecuteCommandLine.
- The global setting 'Add filter to convert chroma subsampling to 4:2:0' uses now ConvertToYUV420 instead of ConverttoYV12.
- In various command line features the path environment variable of the process has all exe tools added and all macros are available as environment variables.
- Check added that blocks source files with too long path or filename. A setting that allows to change the limit exists in the Danger Zone section.
- SVT-AV1 support with GUI.
- Media info folder view was replaced with a new powershell based (Get-MediaInfo) dialog that supports caching for fast startup perforance.
- When a Event Command executes it writes a log entry, this is now disabled by default but there is a new setting: 'Write Event Commands to log file'.
- In the Jobs dialog there is a button that shows a menu, this menu can now also be shown as context menu via right-click on the jobs list and it has various new features.
- The Apps dialog allows to clear custom paths.
- The Apps dialog allows to locate files via Everything.
- Check for Updates added to main menu in Help section.
- Version is shown in main dialog title bar.
- 'Main Menu > Help > Info' shows list with contributors.Beautiful release! Thank you [emoji4]

Sent from my SM-G986U1 using Tapatalk

Condo Ghost
13th June 2020, 11:13
StaxRip-x64 2.1.3.0-stable...
Source file path or filename is too long
In theory Windows supports paths that are longer than 260 characters, in reality neither Windows, nor the .NET Framework or the used tools have full long path support.

This message does not occur with StaxRip-x64 2.0.6.0-stable or any of the earlier versions when I select this exact same source file path filename

Thank-you

shodan5000
13th June 2020, 11:26
StaxRip-x64 2.1.3.0-stable...
Source file path or filename is too long
In theory Windows supports paths that are longer than 260 characters, in reality neither Windows, nor the .NET Framework or the used tools have full long path support.

This message does not occur with StaxRip-x64 2.0.6.0-stable or any of the earlier versions when I select this exact same source file path filename

Thank-you

Change the path character limit setting found at Tools>Settings>Danger Zone>Path Character Limit.

jlw_4049
13th June 2020, 15:30
StaxRip-x64 2.1.3.0-stable...

Source file path or filename is too long

In theory Windows supports paths that are longer than 260 characters, in reality neither Windows, nor the .NET Framework or the used tools have full long path support.



This message does not occur with StaxRip-x64 2.0.6.0-stable or any of the earlier versions when I select this exact same source file path filename



Thank-youThis message is meant to keep you from indexing and then getting an error after indexing. Shorten the filename and try again.

Sent from my SM-G986U1 using Tapatalk

Condo Ghost
14th June 2020, 05:46
This message is meant to keep you from indexing and then getting an error after indexing. Shorten the filename and try again.Excuse me? Shorten the file name? A filename of only 77-characters? No. Character limit in the build was set at 150; that's 'short', isn't it?
Change the path character limit setting found at Tools>Settings>Danger Zone>Path Character Limit. Thank-you. I re-set it to 255.

jlw_4049
14th June 2020, 06:20
Excuse me? Shorten the file name? A filename of only 77-characters? No. Character limit in the build was set at 150; that's 'short', isn't it?

Thank-you. I re-set it to 255.Every now and then it will error after indexing with a longer path.

Sent from my SM-G986U1 using Tapatalk

chipxtreme
14th June 2020, 16:09
NVEnc 5.05 has been released

markiemarcus
16th June 2020, 00:46
Many thanks for your continued work on this! Unfortunately, as of the switchover to AVS+ 3.6 and higher in the latest versions, I'm getting system exceptions and other problems with certain filters, including some added externally. The external issues I was able to solve by commenting out certain functions in the Zs_RF_Shared file, but these issues remain:

AvisynthShader turns up "System exception Access Violation". Shader.avsi, line 218.

AnimeIVTC (real.finder's mod) shows "TMM2.dll cannot be used as a plugin for Avisynth".

Any versions of Staxrip built around ~3.5.1 seem to work fine. Any suggestions? I'm not sure whether the problems lies with Staxrip or AVS+, though it's possibly a combination of both. Unfortunately there's no way of testing the latest Stax release with an older AVS+ version.

Edit: Opening the .avs in MPC shows the same error. So I'm guessing the problem lies in AVS+?

jlw_4049
16th June 2020, 01:06
Many thanks for your continued work on this! Unfortunately, as of the switchover to AVS+ 3.6 and higher in the latest versions, I'm getting system exceptions and other problems with certain filters, including some added externally. The external issues I was able to solve by commenting out certain functions in the Zs_RF_Shared file, but these issues remain:

AvisynthShader turns up "System exception Access Violation". Shader.avsi, line 218.

AnimeIVTC (real.finder's mod) shows "TMM2.dll cannot be used as a plugin for Avisynth".

Any versions of Staxrip built around ~3.5.1 seem to work fine. Any suggestions? I'm not sure whether the problems lies with Staxrip or AVS+, though it's possibly a combination of both. Unfortunately there's no way of testing the latest Stax release with an older AVS+ version.

Edit: Opening the .avs in MPC shows the same error. So I'm guessing the problem lies in AVS+?Yes the plug-ins aren't updated to latest avisynth

Sent from my SM-G986U1 using Tapatalk

markiemarcus
16th June 2020, 01:15
Yes the plug-ins aren't updated to latest avisynth

Sent from my SM-G986U1 using Tapatalk

Ah, well that explains it! Thanks.

jlw_4049
16th June 2020, 01:32
Ah, well that explains it! Thanks.No problem, can stick with older version of staxrip for a while until the plug in you need is updated.

Sent from my SM-G986U1 using Tapatalk

JKyle
16th June 2020, 04:00
x264 is updated to 160 r3009 (https://www.videohelp.com/software/x264-Encoder).

apophis906
16th June 2020, 15:09
Many thanks for your continued work on this! Unfortunately, as of the switchover to AVS+ 3.6 and higher in the latest versions, I'm getting system exceptions and other problems with certain filters, including some added externally. The external issues I was able to solve by commenting out certain functions in the Zs_RF_Shared file, but these issues remain:

AvisynthShader turns up "System exception Access Violation". Shader.avsi, line 218.

AnimeIVTC (real.finder's mod) shows "TMM2.dll cannot be used as a plugin for Avisynth".

Any versions of Staxrip built around ~3.5.1 seem to work fine. Any suggestions? I'm not sure whether the problems lies with Staxrip or AVS+, though it's possibly a combination of both. Unfortunately there's no way of testing the latest Stax release with an older AVS+ version.

Edit: Opening the .avs in MPC shows the same error. So I'm guessing the problem lies in AVS+?

I noticed the same thing. I created an AVS file outside of staxrip and just called AnimeIVTC with not loading any of the plugins except for the one for the video and it loaded and worked. However if I just loaded TMM2.dll I would get the same error. So not sure what is going on but creating an AVS file and importing that should work fine I would think.