Assistance with StaxRip

[branbran726]

I'm learning to use StaxRip to create video files from DVDs. The results are already much better than I was getting with Handbrake, almost to the point where I want to go back to all those files and replace them... but I have newer content to deal with first.

I recently got a 2-disc compilation (Warning: NSFW) that includes content in two or three different aspect ratios.

Part 1 Thumbnail panel Part 2 Thumbnail panel

Each rip seems to start out matching the aspect ratio of the first chapters on the DVD and then it stretches/compresses when it gets to a section in a different ratio.

Is there a way to reshape the masking (black bars/letterboxing) on the chapters ... maybe adding side bars to the 4:3 content? ... to make for one video per DVD that can be watched all at the same ratio?

Ideally I would like to do this with as little loss from the original DVD source as possible, so if there's a solution that does not involve encoding the chapters separately and then re-encoding them together that'd be great.

I was planning on sharing the DVD-ISO with the video so I've already got that uploaded, if someone else wants to give it a try directly. If they succeed, I'd be interested in learning how.

REAL-001A.zip.001 (950.0 Mb)
REAL-001A.zip.002 (950.0 Mb)
REAL-001A.zip.003 (950.0 Mb)
REAL-001A.zip.004 (950.0 Mb)
REAL-001A.zip.005 (950.0 Mb)
REAL-001A.zip.006 (950.0 Mb)
REAL-001A.zip.007 (950.0 Mb)
REAL-001A.zip.008 (258.4 Mb)

REAL-001B.zip.001 (950.0 Mb)
REAL-001B.zip.002 (950.0 Mb)
REAL-001B.zip.003 (950.0 Mb)
REAL-001B.zip.004 (950.0 Mb)
REAL-001B.zip.005 (950.0 Mb)
REAL-001B.zip.006 (950.0 Mb)
REAL-001B.zip.007 (221.8 Mb)

Same files, so free users can get some from Filejoker and some from k2s to speed up their download.
REAL-001A.zip.001
REAL-001A.zip.002
REAL-001A.zip.003
REAL-001A.zip.004
REAL-001A.zip.005
REAL-001A.zip.006
REAL-001A.zip.007
REAL-001A.zip.008

REAL-001B.zip.001
REAL-001B.zip.002
REAL-001B.zip.003
REAL-001B.zip.004
REAL-001B.zip.005
REAL-001B.zip.006
REAL-001B.zip.007

 

[SamKook]

Are the different section of the DVD part of different VTS in the DVD structure? Meaning do you only have files starting with "VTS_01" or are there multiple numbers like "VTS_02", "VTS_03", etc.?

You can't have a different aspect ratio on a DVD in the same VTS but you can in different ones so if they are different and actually using different aspect ratio for the different parts(which is very rare, usually they don't even if they use different VTS), then you'll have no choice but to deal with those separately. but if they use black bars and everything is inside the same VTS, then you should only have to use the correct aspect ratio to fix everything, unless they messed up the source which is also very possible so you'll have to fix multiple parts yourself in that case too.

I'll start downloading it to have a look but might take a bit to do.

 

[SamKook]

Finished downloading the first disc and I can see the issue is in the source. The guy who edited that compilation together really messed up, first time I see something that bad.

So yeah, you have to cut the video and resize the sections properly yourself. I don't know if you can do that with staxrip, I tried using it but it's trying to load the vobs with a 32bit plugin with 64bit avisynth for some reason and that doesn't work. And from just looking at the interface without a source loaded, I don't see a way to do it anyway, except maybe editing the script manually in the advanced menu.
I usually use avisynth directly which gives you more control, but it's a bit more complicated to understand at first.

 

[SamKook]

Did a test on it and basically the 3 different sections on the first disc are supposed to be normal widescreen(16:9), there's not even different aspect ratios...

So you either add vertical black bars on the sides and have a small picture for the sections that have horizontal black bars or you crop the horizontal black bars and resize accordingly(which is what I would do and did in my test).

Using avisynth, you can do different processing on different parts of the video without having to encode it so you just need to encode once. Staxrip does make use of avisynth but I don't know if it's possible to do this kind of split processing with it.
Else the way to do it would be to encode the different parts separately with a lossless codec and then join all the parts for the final lossy encode, but that will require a few hundred Gig of free disk space.

My avisynth script looks like this(I didn't check to make sure the aspect ratio was perfectly right, I just cropped the black but looks about right):

Vid1 = DGDecode_mpeg2source("K:\_2enc_\_ISO\REAL-001\REAL-001.d2v")
Aud1 = NicAC3Source("K:\_2enc_\_ISO\REAL-001\REAL-001 T80 2_0ch 256Kbps DELAY 0ms.ac3")
Mov1 = AudioDub(Vid1, Aud1)
Mov1

QTGMC(Preset="Placebo", TR2=2, EZKeepGrain=0.4, Sharpness=0.3)

Crop(0, 0, -0, -0, true)

Mov1 = last

C1 = Mov1.Trim(0,276959)
C1 = C1.Crop(4, 60, -4, -60, true)
C1 = C1.Blackmanresize(720,480)
C2 = Mov1.Trim(276960,583451)
C3 = Mov1.Trim(583452,882312)
C3 = C3.Crop(0, 104, -0, -104, true)
C3 = C3.Blackmanresize(720,480)

C1++C2++C3

First 4 lines load the source and set it up, next the QTGMC line is my deinterlacer, then a crop that crops nothing which I could have erased, then it includes the deinterlacing and crop into mov1 which represent the whole movie.
The C1 stuff cuts the first section with black bars(I interpolate to 60fps with this deinterlacer so the trim could need the values to be halved if you don't), then crops the black bars on all 4 sides since there are little ones on the sides too and then it resizes that section to the size of the video(still 720x480 since I deal with correcting the aspect ratio in the encoder instead of resizing it in the processing avisynth script).
The C2 just cuts the section that takes the whole screen, nothing to cut or resize here.
Then the C3 section cuts the 3rd scene, remove even more black on top and bottom as C1 and then resize it to DVD size.

Then you join all 3 section and the result looks like this in a 1 min sample I did which includes 20 sec of each 3 section with different aspect ratio in the source:

Filejoker link to sample: https://filejoker.net/jaobk9qvt488

 

[SamKook]

And for fun, in case you want to compare the 2 options, I also did a test with adding vertical black bars to fix the aspect ratio.

Filejoker black bars sample link: https://filejoker.net/6tdkl1h31eop



And here's the avisynth script for that:

Vid1 = DGDecode_mpeg2source("K:\_2enc_\_ISO\REAL-001\REAL-001.d2v")
Aud1 = NicAC3Source("K:\_2enc_\_ISO\REAL-001\REAL-001 T80 2_0ch 256Kbps DELAY 0ms.ac3")
Mov1 = AudioDub(Vid1, Aud1)
Mov1

QTGMC(Preset="Placebo", TR2=2, EZKeepGrain=0.4, Sharpness=0.3)

Mov1 = last

C1 = Mov1.Trim(0,276959)
C1 = C1.AddBorders(114, 0, 114, 0)
C1 = C1.Blackmanresize(720,480)
C2 = Mov1.Trim(276960,583451)
C3 = Mov1.Trim(583452,882312)
C3 = C3.AddBorders(272, 0, 272, 0)
C3 = C3.Blackmanresize(720,480)

C1++C2++C3

 

[SamKook]

So, I figured I hadn't replied enough to the thread yet(I'm kidding) and looked into fixing my staxrip issue, which seems they just used the wrong version of the dll so I copied the right one in the appropriate place.

To answer your question in a more useful way, it can be done in staxrip, you just have to hijack one of the AVS filters option and also make sure to change the DAR setting to 1.777777(16:9) and ignore the error % since it's smart enough to use the correct SAR when encoding which will fix it and is what I prefer doing since it doesn't introduce extra artifacts from the resize filter and lets the player handle it(or just resize it to 854x480).

The Main page stuff look something like this:

To have Cutting appear in the AVS Filters section, if you don't know, you need to go in the preview menu and create cuts there, but I only did that to get my 1 min sample for testing.
Then you double-click any of the filters in there and it'll open the code editor:

There I just used the resize section to add the avisynth stuff needed to fix the aspect ratio that I used in my other posts.
If you also want to resize, just make sure to put that stuff before the resize function of your choosing instead of deleting it like I did.
I also manually changed the Field section(deinterlacing) to my prefered QTGMC setting, but you can use whatever there, I just wouldn't use placebo alone without manually tweaking it since it produces worse results than very slow by default, but I think the author of staxrip tweaked it already, just not sure about that and it's probably overkill anyway.

Few things to keep in mind:
The order often matters in an avisynth script which is why I put the stuff in the resize section which is done last(unless you also cut up the video), you never want to do resizing on a video before deinterlacing it.

The Mov1 and C1-3 are just made up by me, you can use whatever else you prefer, it's just used to reference stuff.

The Mov1 = last is there so we can use whatever result of the previous processing that was done in the script as a reference for our custom processing. Just means put the last state of the script into the Mov1 variable.

And at the end we put everything back together with C1++C2++C3 so the script doesn't need to reference anything in its further processing. If we didn't, it would just ignore everything we did there.

You can't change the Cutting section manually(annoyingly), it'll revert it to whatever you did in the preview section. There may be other ways, I never used staxrip before except maybe once or twice a very long time ago.

You can open the .avs file from the temporary folder in a text editor to see what the actual avisynth script used is. It'll have a ton of loadplugin compared to my previous example scripts since mine get autoloaded but the rest is similar, except they don't load the audio there like I did.

 

[Porni]

you never want to do resizing on a video before deinterlacing it

It is allowed to change horizontally

 

[SamKook]

It is allowed to change horizontally

True, I wanted to change "never" for "don't usually" but seems I forgot.

There's usually not a reason to do it before so safer just not to do it, unless you know what you're doing. I've seen an IV video where the editor resized interlaced video and it was a pain to fix when I re-encoded that DVD.

 

[branbran726]

@SamKook Thanks for all the work you've done. Let me check my understanding:

Vid1 = DGDecode_mpeg2source("K:\_2enc_\_ISO\REAL-001\REAL-001.d2v")
Aud1 = NicAC3Source("K:\_2enc_\_ISO\REAL-001\REAL-001 T80 2_0ch 256Kbps DELAY 0ms.ac3")
Mov1 = AudioDub(Vid1, Aud1)
Mov1

QTGMC(Preset="Placebo", TR2=2, EZKeepGrain=0.4, Sharpness=0.3)

Crop(0, 0, -0, -0, true)

Mov1 = last

C1 = Mov1.Trim(0,276959)
C1 = C1.Crop(4, 60, -4, -60, true)
C1 = C1.Blackmanresize(720,480)
C2 = Mov1.Trim(276960,583451)
C3 = Mov1.Trim(583452,882312)
C3 = C3.Crop(0, 104, -0, -104, true)
C3 = C3.Blackmanresize(720,480)

C1++C2++C3

The first four lines define the video source, define the audio source, combine the two, and call the product "Mov1". If I'm using StaxRip, this is pretty much done for me. Then you deinterlace, crop nothing from the product, and re-define "Mov1" as the product of that step.

You then arbitrarily name three sections to match the three different visible aspect ratios. C1, C2, and C3 are defined by their range of frames. (If the original edit had been done by chapter, I'm guessing it's possible to do it like that, too? Less precise, though). The crops are done by pixels from left, top, right, and bottom in some predetermined order; since the cuts are symmetrical it doesn't matter which.

You then bring in a Black man to resize it, despite it not being an interracial title. This is a little bit mean. After all, Ran cried when she was asked to blow off a Black man.

Regardless of who is doing the resize, the size you choose here (720,480) is defined by the section you've called C2; that's the section you're not cropping. You've engaged Bicubic resize on the AVS filter to get that in StaxRip.

Finally, you add the three sections together to get a final product. I notice you don't re-define "Mov1" here.

=============
So, if I wanted to do this to part 2, I would repeat everything up until the step represented by the false crop after the deinterlace for the new source file. I'd find the range of frames I'm dealing with for each part. Is there a way to do that before deinterlacing; that is, do I just find the frame number from the interlaced source and double it?

Part 2, like part 1, has a middle section with an aspect ratio I don't need to touch, so again it would be C1 and C3 that needed cropping. It looks like the amount to be cropped is the same in either section.

I'd define the amount to be cropped, bring in another Black man to resize each section after cropping, and add the files together at the end.

All the while I've set the DAR (Default Aspect Ratio?) on the main GUI screen to be 1.77777 because that's what C2 is, and it doesn't need cropping.

How'd I do?

 

[SamKook]

That's pretty much it and you got the order right for the cropping. Just a couple small clarification, the arbitrary names with an = sign is when things are defined. If I simply put Mov1 as a single line, it just tells the script that from now until I say otherwise, everything should be defined into mov1.

I could have just done Mov1 = Mov1.QTGMC(Preset="Placebo", TR2=2, EZKeepGrain=0.4, Sharpness=0.3), same principle for the crop(or remove that line since it's useless, It's just there because of the way my personal script works) and remove the Mov1 and Mov1 = last lines and it would do the same thing. It's just easier when you have to do multiple processing on the same thing to do it this way. Again, it's this way because of my script since I have a lot more processing that gets removed once it's not useful anymore or not needed for that movie.

And at the end, the C1++C2++C3 final line is what the encoder will get. If I put Mov1 at the end it'll ignore all of the C1-3 stuff and just use the QTGMC stuff which was the last thing put into Mov1.

And what decides the 720x480(3:2) is the source. All DVD use that resolution and they get stretched according to if it's 4:3 or 16:9. Section 2 is actually 853.3333333x480 but if you set the DAR(Display Aspect Ratio) and stuff right, the encoder will add the necessary information for the player to properly display it in either 4:3 or, in our case, 16:9, just like it does when you play the original DVD.


To figure out where to cut, I temporarily use doubleweave() as my deinterlacer(which staxrip doesn't have in its menu for some reason, but you can type it manually in the field filter, it'll work fine, or just use another that gives you the right fps in the target section, like tdeint with double rate bobbing which should be pretty quick too) since it's super quick and doubles the frames like QTGMC does so no need to do math.
And to figure out the right frame number where you need to cut, I'm not sure what the best way would be in staxrip, you'll have to experiment a bit with that. You can make cuts for the first and the 3rd section, go check the Cutting section in the filters and deduce the 2nd section by the gap in numbers and then go back into the preview to remove your cuts and use the full video instead.
Me, I just load the avs file in a media player that tells me the frames like virtualdub and manually type the numbers in the script, but you can't do it that way with staxrip, you have to use their interface.


Now about part 2... They managed to screw it up even more than the first. First there's 4 different section for the ratio stuff and not 3, there's a small one at the end that's a little different than the first and 3rd, which are actually the same, like you thought.
But the fun part is that they also screwed up the field order of 2 section(different than the ones with bad ratio) so you also have to fix that before deinterlacing.
With a cheap deinterlacer that only give you half of the frames, you're not going to notice the issue but if you use one that preserves all the movement like QTGMC at 60fps, then you'll notice one frame going forward, one going back and then it skips forwards, then one frame back, etc..
So you have to tell the deinterlacer to either start with the top field or the bottom field and you end up with a script that looks like this:

Vid2 = DGDecode_mpeg2source("K:\_2enc_\_ISO\REAL-001B\REAL-001B.d2v")
Aud2 = NicAC3Source("K:\_2enc_\_ISO\REAL-001B\REAL-001B T80 2_0ch 256Kbps DELAY 0ms.ac3")
Mov2 = AudioDub(Vid2, Aud2)

Fld1 = Mov2.Trim(0,108626)
Fld1 = Fld1.AssumeBFF()
Fld1 = Fld1.DoubleWeave()
Fld2 = Mov2.Trim(108627,225270)
Fld2 = Fld2.AssumeTFF()
Fld2 = Fld2.DoubleWeave()
Fld3 = Mov2.Trim(225271,737485)
Fld3 = Fld3.AssumeBFF()
Fld3 = Fld3.DoubleWeave()
Fld4 = Mov2.Trim(737486,749788)
Fld4 = Fld4.AssumeTFF()
Fld4 = Fld4.DoubleWeave()
Fld5 = Mov2.Trim(749789,766148)
Fld5 = Fld5.AssumeBFF()
Fld5 = Fld5.DoubleWeave()
Mov2 = Fld1+Fld2+Fld3+Fld4+Fld5

C4 = Mov2.Trim(0,457059)
C4 = C4.Crop(0, 62, -0, -60, true)
C4 = C4.Blackmanresize(720,480)
C5 = Mov2.Trim(457060,706007)
C5 = C5.Crop(0, 2, -0, -0, true)
C5 = C5.Blackmanresize(720,480)
C6 = Mov2.Trim(706008,760401)
C6 = C6.Crop(0, 62, -0, -60, true)
C6 = C6.Blackmanresize(720,480)
C7 = Mov2.Trim(760402,766148)
C7 = C7.Crop(0, 106, -0, -104, true)
C7 = C7.Blackmanresize(720,480)
C4++C5++C6++C7

I haven't fully tested the Fld block yet and I've had some odd behavior with telling it to switch the fields that don't always do what I expect and I'm still working on that so that part might not give the desired result as-is.
Edit: All the trim values for the fld section are wrong in the example above. I used the doubled values but since it's before the deinterlacer, it hasn't been doubled yet which is why I was getting odd behavior. The BFF and TFF probably need to be reversed too because of that.
End of Edit.

For Staxrip, you would need to add a Mov2 = last before the Fld block(to put everything that was done before by staxrip into that so you can use it explicitely in the block) and change the last line of it to remove Mov2 =(so just Fld1+Fld2+Fld3+Fld4+Fld5) for it to return the result to staxrip properly instead of leaving it in the Mov2 variable you created and put that in the deinterlacer section(make sure to change all doubleweave() for your deinterlacer) and then also add a Mov2 = last before the C block and put that into the resize section.
You can obviously figure out all the values yourself, that's just a template of how it would work and you may not agree with all I did, like over-cropping 1 pixel at the top instead of leaving 1 pixel of black since you have to use even numbers for cropping.

Here's a sample file that compares the same 2 scenes but with the field order switched so you can see what it looks like. First 9 sec is good and the last 9 sec is wrong:
https://filejoker.net/p6jwnl3cflju

P.S. You don't have to hire the black man to resize your movie, you can use any other resizer you want, but he usually does a good job.

 

[SamKook]

So after a bit more testing, the Deinterlacer section should look something like this(still haven't done a real full test though since it takes me 6h30m to encode both parts):

Mov2 = last
Fld1 = Mov2.Trim(0,54313)
Fld1 = Fld1.AssumeBFF()
Fld1 = Fld1.SeparateFields()
Fld2 = Mov2.Trim(54314,112636)
Fld2 = Fld2.AssumeBFF()
Fld2 = Fld2.SeparateFields()
Fld3 = Mov2.Trim(112637,368743)
Fld3 = Fld3.AssumeTFF()
Fld3 = Fld3.SeparateFields()
Fld4 = Mov2.Trim(368744,374895)
Fld4 = Fld4.AssumeBFF()
Fld4 = Fld4.SeparateFields()
Fld5 = Mov2.Trim(374896,383074)
Fld5 = Fld5.AssumeTFF()
Fld5 = Fld5.SeparateFields()
Fld1+Fld2+Fld3+Fld4+Fld5

You'd replace SeparateFields() by a proper deinterlacer, I just used that to see better the movement between each individual fields since it's easier to see the motion with that rather than doubleweave.
I didn't notice before but the first section doesn't actually have its full range of motion, it's 30i instead of 60i(which jav usually is) which mean you basically get a repeat frame for every frames in that section and there's no benefit to going to 60fps(but since there is a benefit for the rest of the movie, we have to go to 60). BFF there seems more right to me so I put that but it doesn't matter much and it's hard to tell properly since there's always a little movement between each frame since on starts at the bottom and the other at the top so it constantly shift by 1 pixel.

Basically, there's no automatic way to tell which is right, you have to look at the motion for yourself and figure it out. But that's not something that usually change like this, it only does when the guy making the DVD is bad at his job.
I first noticed because I did a full encode test and quickly seeked through multiple part of the movie to check if everything looked right.

And if you wonder why I used mov2 and started at c4 for the second part, it's because I put both parts in the same script to make 1 file for both since it's a compilation so it fits well in 1 file.

 

[Porni]

And what decides the 720x480(3:2) is the source. All DVD use that resolution

PAL (720x576)?

 

[SamKook]

PAL (720x576)?

Lol, you have to read my replies

There is that one too but it doesn't apply to JAV or any other DVD from japan.

 

[branbran726]

This is really enlightening and incredible help. I almost feel bad now for giving up on encoding it properly and encouraging you to do the same. This was a free 2-DVD set that I got with another purchase, and it turns out that this is all content from her uncensored releases with a mosaic added after the fact. This is probably why the aspect ratios are all wrong: some of this was DVD content, some was streaming content, and even that content was initially released through a variety of sources. I'm betting some of it was even PAL, since uncensored content was 'technically' for overseas consumption.

If the problem was that the video metadata was forcing the chapters into odd aspect ratios, that would be one thing. It would make it more worth it to try and preserve the content in DVD quality. But learning that they just warped the original 1280x720 content, or otherwise downgraded content from other DVDs, makes me think that there is not an archival reason, nor an entertainment reason, nor even a sentimental reason to preserve this content. The DVD itself only exists because Monchi had enough of a fanbase in her time to make someone think it was lucrative to re-release her uncensored content to the masses... and the reason it's in my hands is that someone else thought it was only worth giving away for free.

I'm really amazed that it is possible to correct the bad editing of the person who put this together in the first place. Except as an exercise in problem solving, I think it's not worth the effort.

I will eventually post this DVD in the proper forum, and direct people to this thread for more information on everything wrong with it. If you do eventually produce a full video, I would be overjoyed if you'd allow me to share it. But please note that I'm not asking you to put another minute of effort into this problem if you don't want to.

But I did learn a lot from you, @SamKook (and a tiny amount from @Porni 's corrections). I want to thank you profusely for putting in all the time and effort and bandwidth that you have put in to this, including getting familiar with software you don't normally use. I hope that when another issue inevitably arises, you will be willing to provide advice again.

P.S. You don't have to hire the black man to resize your movie, you can use any other resizer you want, but he usually does a good job.

I'm glad you're at least paying him a living wage. He seems to do an exceptionally good job.

 

[SamKook]

I was a bit rusty so helped remind me how to do that weird stuff you almost never need but is very useful to know when you need it.
I like figuring stuff out or I wouldn't have done so much before you replied, lol.

Unless I messed something up, all problems are solved and I don't have to put any more effort into it to encode it(I'm actually 60% into a full encode test right now) so I can send it to you or upload it for you, whichever you want.

There's no pal in there, it's a different framerate standard(25 fps) so it would be very noticeable if they tried to cram that into the compilation and hd content wouldn't even need to be warped to fit there, just downscaled, the result is just pure incompetence, there's not even (correct) metadata that could force that weird aspect ratio, at least not that I can think of.

The field order stuff doesn't affect the quality at all once fixed, but to remove the black bars, you have to upscale it so there's some quality loss there, unless you do the add vertical bars option, but that's not a great viewing experience.

 

[branbran726]

I was a bit rusty so helped remind me how to do that weird stuff you almost never need but is very useful to know when you need it.
I like figuring stuff out or I wouldn't have done so much before you replied, lol.

Unless I messed something up, all problems are solved and I don't have to put any more effort into it to encode it(I'm actually 60% into a full encode test right now) so I can send it to you or upload it for you, whichever you want.

Well, that's just brilliant. Thank you!
I'll be uploading it onto k2s anyway for redundancy/expanded access, so I'll be downloading it one way or another.

Meanwhile, I do have another conundrum. The question is simple: why does the motion in this video look like crap?
It sort of looks better without being deinterlaced, although I'm pretty sure the source is interlaced.
SBOG-004_preview_x264.mp4 (34.0 Mb)
SBOG-004_preview_x264_no_deinterlace.mp4 (58.5 Mb)

Maybe if someone had experience with this error, they could tell what is going wrong from just the samples and my encoder settings.
If the ISO is necessary, I'll be uploading it to Filejoker tomorrow. Meanwhile, here it is on keep2share.
SBOG-004.zip.001
SBOG-004.zip.002
SBOG-004.zip.003
SBOG-004.zip.004
SBOG-004.zip.005
SBOG-004.zip.006
SBOG-004.zip.007
SBOG-004.zip.008

I feel like I'm also having the same sort of problem in this encode, so it'll be interesting to test out a solution and see if it works on both.
FTBD-036_test.mp4 (19.6 Mb)

 

[SamKook]

From looking at the interlaced preview, It's a field order issue. Just add AssumeBFF() or AssumeTFF(), whichever looks right, before the deinterlacer.

If you go through the video frame by frame you can see it going forward and backwards like I explained in an earlier post.

You have less chance of running into that issue if you use dgindex as the source filter rather than ffmpeg when working with DVDs, but I assume staxrip chose that automatically for you.

 

[Porni]

FTBD-036_test.mp4 (19.6 Mb)

This is not the original
There are no 60 fps here, but you use double fps.
If the source looks like interlace, you should set FPSDivisor=2 for QTGMC, if the source looks like progressive, then InputType=1

 

[branbran726]

From looking at the interlaced preview, It's a field order issue. Just add AssumeBFF() or AssumeTFF(), whichever looks right, before the deinterlacer.

If you go through the video frame by frame you can see it going forward and backwards like I explained in an earlier post.

You have less chance of running into that issue if you use dgindex as the source filter rather than ffmpeg when working with DVDs, but I assume staxrip chose that automatically for you.

Most of the things going on for me in StaxRip are just the default settings. My desire to share content far outstrips my ability to provide it in modern formats...

BFF/TFF, that's Bottom First/Top First? I notice it looks like it's autodetected TFF (or at least it says TFF in the [Source] box). Maybe it was incorrectly detected? As for source filter, I'm not sure how one would select that.


StaxRip has a function to Assume TFF/BFF, but when I activated it the encodes were blank, audio only. As though it did the assuming, but then nothing else.
Next I put it in the command line before the QTGMC line; looks like BFF was the right answer!
SBOG-004_Test_QTGMC_Assume_TFF.mp4 (17.9 Mb)
SBOG-004_Test_QTGMC_Assume_BFF.mp4 (17.4 Mb)

SBOG-004 Test QTGMC Assume TFF.mp4

17.94 MB

https://1fichier.com/?pn0fr7ojn7hfzg1v6bfc

SBOG-004 Test QTGMC Assume BFF.mp4

17.42 MB

https://1fichier.com/?voife84nepk6glhgi8oz

I'm guessing that the file size is smaller in the correct file because, with smoother motion, the codec doesn't have to work as hard to predict pixels.

This is not the original
There are no 60 fps here, but you use double fps.
If the source looks like interlace, you should set FPSDivisor=2 for QTGMC, if the source looks like progressive, then InputType=1

Not sure what you mean by "not the original"; it's straight from the DVD.
The source doesn't look particularly interlaced; there may be a little pixelation, but there's no combing on the edge of the fingertips in the screencap.
I tried both of those things, and the results don't look too different; though the Progressive/ InputType=1 encode produced a much smaller file.
FTBD-036_test_Div2.mp4 (42.8 Mb)
FTBD-036_test_Prog.mp4 (37.9 Mb)

FTBD-036 test Prog.mp4

37.92 MB

https://1fichier.com/?kvckt8m80gmsvyau07yv

FTBD-036 test Div2.mp4

42.79 MB

https://1fichier.com/?ei65mfbfe64lb9vo8pus

 

[Porni]

Not sure what you mean by "not the original"

mpeg2 without reencoding