StaxRip

[Reel.Deel]

Originally Posted by Groucho2004

Probably from here.

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? Either a lot of development or something else...

[Groucho2004]

Originally Posted by Reel.Deel

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]

Originally Posted by Reel.Deel

Hmm, whats up with the naming scheme? b21 in March and b50 in May? 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]

Originally Posted by stax76

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.ph...64#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]

Originally Posted by stax76

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]

Originally Posted by burfadel

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]

Originally Posted by burfadel

New NNEDI3 9.9.4.10
http://forum.doom9.org/showthread.ph...64#post1662264

updated and tested locally.

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]

Originally Posted by stax76

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 with FccHandler's AC3 plug-in v1.9 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]

Originally Posted by stax76

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]

Originally Posted by stax76

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.

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 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]

Originally Posted by 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.

Hi Stax,

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

[jkilez]

Originally Posted by stax76

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!