StaxRip

[Washka]

With Latest beta: StaxRip x64 1.3.1.3 beta (2015-05-21) I got problems with all *.mkv files. I upload encoded sample. Any other version have no this problem. Mp4 have no problems.
I upload sample video to dropbox, audio is Just Mux since it`s ac3.

https://www.dropbox.com/s/1e5ch01jy8nmuid/Sample_StaxRip.log?dl=0
https://www.dropbox.com/s/4ggq0kgrgdjaasj/Sample.mkv?dl=0

First one second is double than audio is not in sync.

[Havokdan]

StaxRip x64 have support for TextSub/Vobsub plugin? I dont see in filtters.

[burfadel]

Also remember you can still use Nero or FDK AAC.

I was thinking that exactly!

When it doesn't work, it doesn't work consistently, but when it does work it works consistently between encodes. Since the audio encoding happens first, I think I'll just start it again until it works! It's obviously something very minor, I just can't pinpoint what it is. I'm heavily suspecting it's a new bug, I guess that's expected on a beta OS.

[stax76]

With Latest beta: StaxRip x64 1.3.1.3 beta (2015-05-21) I got problems with all *.mkv files. I upload encoded sample. Any other version have no this problem. Mp4 have no problems.
I upload sample video to dropbox, audio is Just Mux since it`s ac3.

https://www.dropbox.com/s/1e5ch01jy8nmuid/Sample_StaxRip.log?dl=0
https://www.dropbox.com/s/4ggq0kgrgdjaasj/Sample.mkv?dl=0

First one second is double than audio is not in sync.

I made test where everything worked as usual, the frame rate detection was changed, when you double click the filters you can see StaxRip added AssumeFPS because ffmpeg returns often values that cause problems, maybe it has something to do with this. Maybe I can find something if you post a source clip and log file.

StaxRip x64 have support for TextSub/Vobsub plugin? I dont see in filtters.

I first removed the plugin and code but later found a x64 version so I re-added the plugin and code, I've not used it recently but believe it should work

[Havokdan]

I first removed the plugin and code but later found a x64 version so I re-added the plugin and code, I've not used it recently but believe it should work

Thanks

[luigizaninoni]

Remember the three issues with .ts ?:
1-slowing down
2-MT crashing
3- 64-bit plugins missing

Issue n.1 imo is solved:
Instead of FFVideoSource use DSS2mod. Speed is steady throughout the encode. Be very liberal in "cache" and "preroll" parameters. Demux with dsmux. Works with QTGMC, both interlaced and progressive mode.

If it does not saturate CPU, you can run 2 parallel encodes without problems.

Tried also MT, but with filter mode 3 does not even start. With modes 1 and 2 it starts but crashed after a few seconds.

Anyway n.2 is partially solved, given that you can use FrimSource for Qtgmc progressive (not for interlaced, unfortunately.)

N.3 still stands.

[jkilez]

Using the new 1.3.1.3 beta, I am getting 7 frames (300ms) of blank video added to the beginning of encoded videos causing audio sync issues. Actually the framecount stays correct (it cuts 300ms at the end), so the problem is more that the video is offset by 300ms. So far I have only had a chance to check this with an AVC source. The problem does not appear when previewing, only in the final encodes and happens regardless of output (1-pass/2-pass, Xvid/x264, AVI/MKV, AC3/MP3/None).

The problem appears to be with the ffms2 indexer that was updated. If I replace the /Apps/Plugins/ffms2 directory with the version that came with 1.3.1.0, there is no delay.

ETA: Just compared encodes from an MPEG-2 (DVD) source:
1.1.9.0 = 0 extra frames
1.3.1.0 = 0 extra frames
1.3.1.3 = 2 extra frames

[Washka]

Using the new 1.3.1.3 beta, I am getting 7 frames (300ms) of blank video added to the beginning of encoded videos causing audio sync issues. Actually the framecount stays correct (it cuts 300ms at the end), so the problem is more that the video is offset by 300ms. So far I have only had a chance to check this with an AVC source. The problem does not appear when previewing, only in the final encodes and happens regardless of output (1-pass/2-pass, Xvid/x264, AVI/MKV, AC3/MP3/None).

The problem appears to be with the ffms2 indexer that was updated. If I replace the /Apps/Plugins/ffms2 directory with the version that came with 1.3.1.0, there is no delay.

ETA: Just compared encodes from an MPEG-2 (DVD) source:
1.1.9.0 = 0 extra frames
1.3.1.0 = 0 extra frames
1.3.1.3 = 2 extra frames

Got same problems. I write about that at Post #201

[stax76]

Until the problem is solved I suggest using LWLibavVideoSource instead, go to:

Tools > Settings > Source Filters

Replace FFVideoSource every where with LWLibavVideoSource.

[burfadel]

Just giving feedback on the issue I was having with QAAC. Seems to be resolved now. I did all the stuff you shouldn't need to do (in-depth maintenance and repair stuff related), and it seems to work. Not sure what fixed it, and as long as it works reliably I don't care now :D! It appears it wasn't a 100 percent successful transition from build 10074 --> 10122. I guess you should expect things to possibly get muffed, but not sure how going from Windows 7 and 8.1 will be like. Microsoft really needs that to be effectively, 100 percent reliable.

[jkilez]

Hello everybody,

I was working on a couple of improvements and uploaded a new beta. I still like GUI programming so I improved the AviSynth editor a lot.

I'm pausing StaxRip now again for a while but don't worry, I'll be back and catch up with unanswered questions.

StaxRip x64 1.3.1.3 beta (2015-05-21)

Added Decomb x64 plugin
Greatly improved AviSynth editor
Thanks for the editor improvements--it is much more usable now.


One quick GUI bug...

Opening the log file for the current project using the menu item Tools->Files->Log File does not work as it is using the wrong file name "%source_name%_StaxRip.log" vs "%target_name%_StaxRip.log".


ETA: Another little bug...

When editing the "XviD 2 pass" encoder profile through "Edit Profiles..." section, it brings up a window listing "Codec Configuration", "Run Compressibility Check", and "Container Configuration" options. The "Codec Configuration" option brings me right to the "Batch Encoder" editing page as expected, but the "Run Compressibility Check" option just runs the compressibility check (if there is one defined) instead of taking me to the edit page.

[Patman]

Using the new 1.3.1.3 beta, I am getting 7 frames (300ms) of blank video added to the beginning of encoded videos causing audio sync issues. Actually the framecount stays correct (it cuts 300ms at the end), so the problem is more that the video is offset by 300ms. So far I have only had a chance to check this with an AVC source. The problem does not appear when previewing, only in the final encodes and happens regardless of output (1-pass/2-pass, Xvid/x264, AVI/MKV, AC3/MP3/None).

The problem appears to be with the ffms2 indexer that was updated. If I replace the /Apps/Plugins/ffms2 directory with the version that came with 1.3.1.0, there is no delay.

ETA: Just compared encodes from an MPEG-2 (DVD) source:
1.1.9.0 = 0 extra frames
1.3.1.0 = 0 extra frames
1.3.1.3 = 2 extra frames

Got the same problem. Every mkv file is async. Damn... :mad:

Edit1: Run test with updated ffms2... will report later...

Edit2: I've tested two encodes with the new ffms2 2.22 rc1. There were no async in mkv-files anymore... :) I'll test some other files...

Edit3: With ffms2 2.22 rc1 mkv-files still minimal async... go back to ffms2 2.20... Hope for solution

[stax76]

I noticed it too today, ffms2 2.20 is fine, the issue was introduced with 2.21, it's also fine to use LWLibavVideoSource: Tools > Settings > Source Filters

[jkilez]

Another bug: The "Options->Misc->Auto Forced Film Threshold (Percent)" is not being honored. MPEG-2 (DVD) sources with a DGIndex "Video Type" of between 95% and 99% Film are listed with a frame rate of 29.97 when they should be 23.976. The same sources work properly in 1.1.9.0.

[stax76]

Another bug: The "Options->Misc->Auto Forced Film Threshold (Percent)" is not being honored. MPEG-2 (DVD) sources with a DGIndex "Video Type" of between 95% and 99% Film are listed with a frame rate of 29.97 when they should be 23.976. The same sources work properly in 1.1.9.0.

StaxRip x86 modifies the d2v file for this. With DGDecode x64 there are problems on Win10, on Win7 probably too so it's not used until somebody fixes it.

Both ffms2 and L-Smash-Works have a parameter dealing with NTSC, I can add the parameter to the filter profiles but I don't know yet if it can be automated to set the parameter. I admit I'm pretty clueless about NTSC so how well NTSC is supported depends much on the quality of the feedback I get for it.

[Anakunda]

HI STAX
Trying to load demuxed project into latest beta (.dgi + .h264 file). On source open I get error System eception - Accesss Violation, H:\video\(workset)\test\encode_Source.avs, line 2)

encode_Source.avs is
LoadPlugin("D:\media\DGDecNV\x64 Binaries\DGDecodeNV.dll")
DGSource("H:\video\(workset)\test\source.dgi")


source.dgi is correctly referring to source.h264

What's wrong?

avisynth.dll in C:\Windows\System32\ is version: AviSynth+ 0.1 (r1825, MT, x86_64)

http://i.imgur.com/nL7DsHh.png http://i.imgur.com/uYQTa8d.png http://i.imgur.com/T9kvOSf.png

[stax76]

There was a problem with DGDecodeNV x64, a new build of DGDecNV was uploaded addressing this problem, it will work if you re-download DGDecNV.

[Anakunda]

Which build? 2047? I already have it.

+ I can't find DGIndexIM anywhere, all links in doom9 thread seem dead, a working mirror?

[Groucho2004]

Which build? 2047? I already have it.
2049, Link here (http://rationalqm.us/binaries.html). 2047 is ancient.

[Groucho2004]

+ I can't find DGIndexIM anywhere, all links in doom9 thread seem dead, a working mirror?
Probably from here (http://rationalqm.us/board/viewtopic.php?f=4&t=405).

[Reel.Deel]

Probably from here (http://rationalqm.us/board/viewtopic.php?f=4&t=405).

The link on that thread is dead. I believe the latest DGDecIM is always here: http://rationalqm.us/mine.html

Hmm, whats up with the naming scheme? b21 in March and b50 in May? :confused: Either a lot of development or something else...

[Groucho2004]

The link on that thread is dead. I believe the latest DGDecIM is always here: http://rationalqm.us/mine.html
Oops, didn't realize it pointed to the old build. Anyway, the thread might have some valuable info.

[videoh]

Hmm, whats up with the naming scheme? b21 in March and b50 in May? :confused: Either a lot of development or something else... The numbers are arbitrary but they do increase monotonically. :) The bigger the number jump, usually the more things changed functionally.

[jkilez]

I admit I'm pretty clueless about NTSC so how well NTSC is supported depends much on the quality of the feedback I get for it.
Let me know if there is something that I can do to assist. I have crates of NTSC DVDs.

[burfadel]

@Stax

New NNEDI3 9.9.4.10
http://forum.doom9.org/showthread.php?p=1662264#post1662264

[jkilez]

Another quirk...

FFmpeg does not like muxing to AVI. It creates an ostensibly usable file, but the audio tags are messed up which causes some programs/devices to not properly recognize the audio codec.

MP3 muxes have a minor issue in that they lack a "Frame Count" parameter which can cause CBR encodes to report as VBR. This does not appear to affect actual performance. The greater issue is muxing AC3 into AVI. In this circumstance, FFmpeg uses codec tags that may be completely foreign to some players causing them to balk with an error.

Here are the tags created by a VirtualDub mux (as shown from MediaInfo):
Codec ID : 2000
Codec : AC3
Codec : AC3
Codec/Family : AC3
Codec/Info : Dolby AC3
Codec/CC : 2000
And here is the same section from an FFmpeg mux:
Codec ID : 00001000-0000-0020-8000-00AA00389B71
Codec : AC3
Codec : AC3
Codec/Family : PCM
Codec/Info : Extensible wave format
Codec/CC : FFFE
From what I can research, this is a known issue with FFmpeg and the developers have basically said, "suck it--AVI is dead".

Given that I use Xvid/AVI just to maximize compatibility, I wish to use VirtualDub as the muxer instead of FFmpeg. To make this happen automatically, I have made an ad hoc muxing script using the old VirtualDubMod. This section of code can be added to the bottom of the XviD Batch Encoder sections:
set VD=<PATH TO VIRTUALDUBMOD.EXE>
set VCF=%temp_file%.vcf
set track1=%encoder_out_file_track1%
if "%track1:~-3%"=="ac3" ( set atype=0x00000203 ) else ( set atype=0x00000202 )
set txt=VirtualDub.Open("%encoder_out_file%","",0);
set txt=%txt% VirtualDub.video.SetMode(0);
set txt=%txt% VirtualDub.stream[0].SetSource("%track1%", %atype%, 0);
set txt=%txt% VirtualDub.stream[0].SetMode(0);
set txt=%txt% VirtualDub.stream[0].SetInterleave(1,500,1,0,%delay1%);
set txt=%txt% VirtualDub.SaveAVI("%target_dir%\%target_name%.VD%encoder_ext%");
echo %txt:\\=\\\\% > "%VCF%"
"%VD%" /x /s"%VCF%" && copy "%track1%" "%encoder_out_file%"
The output file that it creates has "VD" inserted before the extension so that you know which muxer created it. As listed, the code has a performance hack where it replaces the encoder output file with the audio file so that the native FFmpeg muxer can still quickly mux something without throwing an error.

[jkilez]

Another bug: The "Options->Misc->Auto Forced Film Threshold (Percent)" is not being honored. MPEG-2 (DVD) sources with a DGIndex "Video Type" of between 95% and 99% Film are listed with a frame rate of 29.97 when they should be 23.976. The same sources work properly in 1.1.9.0.

StaxRip x86 modifies the d2v file for this. With DGDecode x64 there are problems on Win10, on Win7 probably too so it's not used until somebody fixes it.

Both ffms2 and L-Smash-Works have a parameter dealing with NTSC, I can add the parameter to the filter profiles but I don't know yet if it can be automated to set the parameter. I admit I'm pretty clueless about NTSC so how well NTSC is supported depends much on the quality of the feedback I get for it.
A more significant problem is that even if I force it to use the proper frame rate, it does not count frames properly causing an A/V sync issue. When comparing a 1.3.1.3 encode against a 1.1.9.0 encode, sometimes the 1.3.1.3 is a couple frames ahead and sometimes it is a couple frames behind. The 1.1.9.0 encode stays in A/V sync throughout.

[burfadel]

@Stax

I came across this interesting bit of information regarding cropping:
http://avisynth.nl/index.php/Resize

Say you wanted to use Spline36resize, instead of:
Crop(%crop_left%, %crop_top%, -%crop_right%, -%crop_bottom%)
Spline36Resize(%target_width%, %target_height%)

You can use:
Spline36Resize(%target_width%, %target_height%, %crop_left%, %crop_top%, -%crop_right%, -%crop_bottom%)

It works for all internal resize filters (Sincresize, Lanczosresize, Blackmanresize etc). Would this be possibly, in general, more suitable than using the separate function?

[jkilez]

It works for all internal resize filters (Sincresize, Lanczosresize, Blackmanresize etc). Would this be possibly, in general, more suitable than using the separate function?
What advantage would it give?

I can see one possible disadvantage: any pre-resize filters would now also be pre-crop, which is simply disadvantageous if your filter is slow to begin with, but can be catastrophic if your source is mod 2 and your filter requires mod 8.

[burfadel]

I didn't mean as a replacement, just as an option :).

[ShamisOMally]

I managed to fix the audio sync problem by going and downloading the newest version of FFMS2 from Github.

Also come on, when am I going to be able to post without the damn random questions being asked of me?

[stax76]

New NNEDI3 9.9.4.10
http://forum.doom9.org/showthread.php?p=1662264#post1662264

updated and tested locally. :thanks:

FFmpeg does not like muxing to AVI

What about avconv, VirtualDub x64 or maybe even other tools, ideal would be CLI and small file size.

A more significant problem is that even if I force it to use the proper frame rate, it does not count frames properly causing an A/V sync issue. When comparing a 1.3.1.3 encode against a 1.1.9.0 encode, sometimes the 1.3.1.3 is a couple frames ahead and sometimes it is a couple frames behind. The 1.1.9.0 encode stays in A/V sync throughout.

1.1.9.0 used DGDecode which doesn't really work on x64, there are various other source filters, unfortunately I don't have NTSC experience but I've test material I want to experiment with.

I came across this interesting bit of information regarding cropping:

It's not easy to integrate it, do you think there is a worthwhile performance gain?

I managed to fix the audio sync problem by going and downloading the newest version of FFMS2 from Github.

Which version did you download?

[jkilez]

FFmpeg does not like muxing to AVI
What about avconv, VirtualDub x64 or maybe even other tools, ideal would be CLI and small file size.
avconv has the same issue as FFmpeg. VirtualDub x64 v1.10.4 (http://sourceforge.net/projects/virtualdub/files/virtualdub-win/1.10.4.35491/VirtualDub-1.10.4-AMD64.zip/download) with FccHandler's AC3 plug-in v1.9 (http://sourceforge.net/projects/fcchandler/files/Virtualdub%20Ac3%20plugin/) appears to work. The distribution size for the combo is less than 3MB compressed. As far as I can tell, VeeDub64 cannot mux from the command line as it still requires an external script file. The syntax is virtually identical to that of VirtualdubMod.

I will do some more testing with VeeDub64, if there is a possibility it will be incorporated into a release. If you have no real interest in it, I am content to stick with my current workaround.

[jkilez]

An xvid_encraw encoding process cannot be aborted via the GUI.
It should work in recent builds, for two command lines you have to abort two times.
A few notes here...

First, the abort now mostly works for the encoding process, but still does not work when using the "Run Compressibility Check" option.

Second, you could eliminate the need to abort twice for two pass encodes by simply adding "|| exit" to the end of the first pass line. As a general rule, you would want to do this anyway because it makes no sense to run the second pass if there was an error running the first pass.

Your example code would look like this:
"%app:xvid_encraw%" -smoother 0 ><...snip...>< -pass1 "%temp_file%.stats" -i "%avs_file%" || exit
"%app:xvid_encraw%" -smoother 0 ><...snip...>< -pass2 "%temp_file%.stats" -i "%avs_file%" -avi "%encoder_out_file%"

Third, the abort code just willy-nilly kills processes with the %app% name, whether they are tied to the current instance or not. If I have three encoding instances running, it will try to kill all three in sequence, starting with a random instance.

ETA: I was hoping that I would have a solution to the third problem before posting, but so far no luck. The problem would be trivially easy to resolve if there was just some mechanism in VB that would allow you to find Parent Process IDs.

ETA2: OK, here is stab at it from someone who has no way to check this stuff. The gist of the method is to use PerformanceCounter to find the PPID. First you need to find the unique instance of the process, then you can use that to find the parent. This is then compared to the PID of the CMD process that initiated the batch job. The code may be bad, but I believe the method is valid.

In file "General\Proc.vb" lines 282- (changes in red)

Sub KillAndThrow()
TrowException = True

Try
If BatchCode <> "" Then
Dim code = BatchCode.ToLower

For Each i In System.Diagnostics.Process.GetProcesses()
Try
If code.Contains(i.ProcessName.ToLower + ".exe") Then

Dim procName = System.Diagnostics.Process.GetProcessById(i.id).ProcessName
Dim procsByName = System.Diagnostics.Process.GetProcessesByName(procName)
Dim procIndexdName As String = Nothing
Dim tempIndexdName As String = Nothing

For idx As var = 0 To procsByName.Length - 1
tempIndexdName = If(idx = 0, procName, Convert.ToString(procName) & "#" & idx)
Dim procId = New System.Diagnostics.PerformanceCounter("Process", "ID Process", tempIndexdName)
If CInt(procId.NextValue()) = i.id Then
procIndexdName = tempIndexdName
End If
Next

Dim parentId = New System.Diagnostics.PerformanceCounter("Process", "Creating Process ID", procIndexdName)
Dim ppid = CInt(parentId.NextValue())

If ppid = Process.id Then

If Not i.HasExited AndAlso Msg("Confirm to kill " + i.ProcessName + ".exe",
MessageBoxIcon.Question,
MessageBoxButtons.OKCancel) = DialogResult.OK Then

i.Kill()
Thread.Sleep(2000)
End If

End If

End If
Catch
End Try
Next
Else
Process.Kill()
End If
Catch
End Try
End Sub

[ShamisOMally]

Which version did you download?

Whatever one was the newest on the page. I just downloaded the newest zip package of all the files and extracted the key files from it and replaced it

[stax76]

First, the abort now mostly works for the encoding process, but still does not work when using the "Run Compressibility Check" option.

should be fixed now.

Second, you could eliminate the need to abort twice for two pass encodes by simply adding "|| exit" to the end of the first pass line. As a general rule, you would want to do this anyway because it makes no sense to run the second pass if there was an error running the first pass.

Unfortunately I don't know the command shell and batch language really well. I've added this trick now to the xvid profile but without forcing to reset the video profiles.

OK, here is stab at it from someone who has no way to check this stuff. The gist of the method is to use PerformanceCounter to find the PPID. First you need to find the unique instance of the process, then you can use that to find the parent. This is then compared to the PID of the CMD process that initiated the batch job. The code may be bad, but I believe the method is valid.

Thanks for the patch. :thanks:

I didn't really try to understand it or test it thoroughly but it seems to work.

it's on github, only change since the last release since I'm still taking a break.

I will do some more testing with VeeDub64, if there is a possibility it will be incorporated into a release.

Adding new tools is problematic since the size is growing all too fast, what is no problem is adding features and show the Apps dialog asking for the path in case the feature is actually used, integrating VirtualDub this way would be fine. It would be very helpful if you can test it.

[Patman]

Hi everyone,

i've updated ffms2 to latest version (http://forum.doom9.org/showthread.php?p=1724587#post1724587) which was released by Myrsloik. Since that no further audio delays in final encoded files. I hope the same for you ;)

[stax76]

Hello patman,

I tested it too, the delay issue is fixed, since the bug was fatal I made a small release:

StaxRip x64 1.3.1.4 beta (2015-05-31)


Added feature to choose which source filter to use when a single file is opened, this gives more MeGUI manual workflow like control without giving up much of StaxRip's automated character
Fixed failing to show log file from main menu
Updated qaac to 2.49
Updated ffms2 to 2.22 RC2


http://github.com/stax76/staxrip/releases

I've a better understanding of NTSC now and some ideas how to make it easier to deal with. Also I've been thinking about more control and manual workflow for a very very long time now and implemented a first feature today, what will follow is a demuxing dialog for mkv/mp4 and maybe more formats similar to the eac3to dialog, this way demuxing might be skipped without modifying the settings, this is useful for instance if the file was previously opened and demuxed. It' not gonna be a paradigm shift, the automatic workflow will remain, there will be just some new options for more control and flexibility.

[Patman]

Hello patman,

I tested it too, the delay issue is fixed, since the bug was fatal I made a small release:

StaxRip x64 1.3.1.4 beta (2015-05-31)


Added feature to choose which source filter to use when a single file is opened, this gives more MeGUI manual workflow like control without giving up much of StaxRip's automated character
Fixed failing to show log file from main menu
Updated qaac to 2.49
Updated ffms2 to 2.22 RC2


http://github.com/stax76/staxrip/releases

I've a better understanding of NTSC now and some ideas how to make it easier to deal with. Also I've been thinking about more control and manual workflow for a very very long time now and implemented a first feature today, what will follow is a demuxing dialog for mkv/mp4 and maybe more formats similar to the eac3to dialog, this way demuxing might be skipped without modifying the settings, this is useful for instance if the file was previously opened and demuxed. It' not gonna be a paradigm shift, the automatic workflow will remain, there will be just some new options for more control and flexibility.

Hi Stax,

:thanks: so much for your continuous work on StaxRip x64 but a break looks different :D

[jkilez]

Another bug: The "Options->Misc->Auto Forced Film Threshold (Percent)" is not being honored. MPEG-2 (DVD) sources with a DGIndex "Video Type" of between 95% and 99% Film are listed with a frame rate of 29.97 when they should be 23.976. The same sources work properly in 1.1.9.0.

StaxRip x86 modifies the d2v file for this. With DGDecode x64 there are problems on Win10, on Win7 probably too so it's not used until somebody fixes it.

Both ffms2 and L-Smash-Works have a parameter dealing with NTSC, I can add the parameter to the filter profiles but I don't know yet if it can be automated to set the parameter. I admit I'm pretty clueless about NTSC so how well NTSC is supported depends much on the quality of the feedback I get for it.
A more significant problem is that even if I force it to use the proper frame rate, it does not count frames properly causing an A/V sync issue. When comparing a 1.3.1.3 encode against a 1.1.9.0 encode, sometimes the 1.3.1.3 is a couple frames ahead and sometimes it is a couple frames behind. The 1.1.9.0 encode stays in A/V sync throughout.
1.1.9.0 used DGDecode which doesn't really work on x64, there are various other source filters, unfortunately I don't have NTSC experience but I've test material I want to experiment with.

It looks like adding "rffmode = 2" to the FFVideoSource options achieves the same as "Force Film" in DGIndex. I just did a comparison with a new encode--setting "rffmode = 2" gave the same results as the 1.1.9.0 index for a 99% film source.

Problem solved!

[jkilez]

avconv has the same issue as FFmpeg. VirtualDub x64 v1.10.4 (http://sourceforge.net/projects/virtualdub/files/virtualdub-win/1.10.4.35491/VirtualDub-1.10.4-AMD64.zip/download) with FccHandler's AC3 plug-in v1.9 (http://sourceforge.net/projects/fcchandler/files/Virtualdub%20Ac3%20plugin/) appears to work. The distribution size for the combo is less than 3MB compressed. As far as I can tell, VeeDub64 cannot mux from the command line as it still requires an external script file. The syntax is virtually identical to that of VirtualdubMod.

I will do some more testing with VeeDub64, if there is a possibility it will be incorporated into a release. If you have no real interest in it, I am content to stick with my current workaround.
It turns out you can mux with vdub64 without using an external file. As long as your script is short enough, you can just cram it on the command line after the "/cmd" option.

So far, everything looks good with vdub64. Here is an updated muxing "hack" that can be added to the end of the Xvid encoding section:
set VD=<PATH TO VDUB64.EXE>
set track1=%encoder_out_file_track1%
if "%track1:~-3%"=="mp3" ( set atype=DAAAAE1QM08AAAAA ) else ( set atype=0 )
set txt=VirtualDub.Open('%encoder_out_file%','',0);
set txt=%txt% VirtualDub.audio.SetSource('%track1%', '', '%atype%');
set txt=%txt% VirtualDub.video.SetMode(0);
set txt=%txt% VirtualDub.audio.SetMode(0);
set txt=%txt% VirtualDub.audio.SetInterleave(1,500,1,0,%delay1%);
set txt=%txt% VirtualDub.SaveAVI('%target_dir%\%target_name%.VD%encoder_ext%');
set txt=%txt:\\=\\\\%
"%VD%" /cmd "%txt%" && copy "%track1%" "%encoder_out_file%"

[stax76]

It looks like adding "rffmode = 2" to the FFVideoSource options achieves the same as "Force Film" in DGIndex. I just did a comparison with a new encode--setting "rffmode = 2" gave the same results as the 1.1.9.0 index for a 99% film source.

Problem solved!

I played around with NTSC and that was one of the things I found out, I'm not sure if and how I can auto detect what setting to use but I plan making editing much easier: StaxRip will know about various important filter parameters so if the user right-clicks FFVideoSource the menu will show the options 'Enable Force Film' and 'Honor Pulldown Flags' or if the user right-clicks DGDource there will be the options 'Enable hardware deinterlacing' and 'Enable hardware cropping'. This and a few other things are planed for AviSynth editing.

It turns out you can mux with vdub64 without using an external file. As long as your script is short enough, you can just cram it on the command line after the "/cmd" option.

So far, everything looks good with vdub64. Here is an updated muxing "hack" that can be added to the end of the Xvid encoding section:
set VD=<PATH TO VDUB64.EXE>
set track1=%encoder_out_file_track1%
if "%track1:~-3%"=="mp3" ( set atype=DAAAAE1QM08AAAAA ) else ( set atype=0 )
set txt=VirtualDub.Open('%encoder_out_file%','',0);
set txt=%txt% VirtualDub.audio.SetSource('%track1%', '', '%atype%');
set txt=%txt% VirtualDub.video.SetMode(0);
set txt=%txt% VirtualDub.audio.SetMode(0);
set txt=%txt% VirtualDub.audio.SetInterleave(1,500,1,0,%delay1%);
set txt=%txt% VirtualDub.SaveAVI('%target_dir%\%target_name%.VD%encoder_ext%');
set txt=%txt:\\=\\\\%
"%VD%" /cmd "%txt%" && copy "%track1%" "%encoder_out_file%"

Interesting script, I've updated and committed the command line muxer, it's now batch based too like audio and video batch encoding.

If you like you can create a .NET sample application implementing the VirtualDub script generation, making a muxer would then be easier for me, C# would be fine too, SharpDevelop 4.4 has a extremely cool code translator.

edit:

Hi Stax,

:thanks: so much for your continuous work on StaxRip x64 but a break looks different :D


You are welcome, too much rain I guess. :)

[ShamisOMally]

FYI: This is near useless to use if you are doing batch encodes with two audio tracks, and want to select one

Its fine if you just need to do one file, as you can manually select the audio track, but if there's more than one file being processed it automatically forces you to use the first track and there is no way to select the second one.

There should be a drop down option under audio to be able to select a second track without having any text in the "Audio" area

*EDIT* annnnnnnd now its working after I let it do two files. The hell?

*EDIT2* Nope. Even if I right click and select other track its still making me use track 1 in a file batch

[stax76]

FYI: This is near useless to use if you are doing batch encodes with two audio tracks, and want to select one

What would the criteria be to decide which track to use?

[NikosD]

The new HandBrake will have AMD's VCE support for HW transcoding, for those interested.

http://arstechnica.com/information-technology/2015/06/sixth-time-lucky-amd-details-the-carrizo-apu/1/

[JohnAStebbins]

The new HandBrake will have AMD's VCE support for HW transcoding, for those interested.

That's news to me. Where did you hear this?

[NikosD]

That's why I posted the link above :)


AMD's in-house benchmarks show that Carrizo can transcode a 10Mbps 1080p H.264 file down to 5Mbps at around 162 FPS, versus just over 140 FPS for a Core i5-5200U, one of Intel's latest mobile Broadwell processors. This does, however, rely on a version of the popular video encoding application Handbrake that isn't actually out yet: AMD's tests were done using a beta version of Handbrake that's able to directly tap into AMD's Video Coding Engine (VCE) hardware, but the company doesn't know when it will actually be publicly released. Not to mention that older Kaveri systems would probably see the same uplift in performance, given they feature VCE hardware too.

[Dogspoin]

I'm using onlinetvrecorder.com to record and download movies from TV, some movies are offered in HD (1080p50, every frame just doubled). With Staxrip up to Version 1.1.9.0 I could activate the filter ChangeFPS(25) to delete every second frame, make some cuts and the resulting audio matched perfectly.
Now I'm using 1.3.1.4 beta and the resulting audio is only half as long as it should be. Would be great if this behaviour could be changed like it was before.
EDIT: tried with SelectEven(), same error.

[stax76]

I don't know what's wrong with audio, with 50p every second frame doubled, I'm not sure if SelectEven/SelectOdd or ChangeFPS is the best option if there even is a difference. If you cut and change the frame rate afterwards you must change the frame rate after the trim functions and not before.

[Dogspoin]

I changed the order for frame rate change and cutting but the audio track is still only half as long it should be.

I attached two images, as you can see the order is identical, 1.1.9.0 produces audio track as expected but 1.3.1.4 beta not.