Converting DVDs: Suggestions for an absolute newbie willing to learn

[MGRV]

Hi all, this is my first post here. I'm absolutely zero tech-savvy (the litte I know, I learned it in the last few days reading this forum) and English isn't my mother language, so please be patient! Also, I'm not sure if this is the proper way to create a thread, as there are a few things I'd like to ask which could be treated separately, so feel free to correct me and I'll edit the thread accordingly.

My goal: Convert some old 4:3 NTSC DVDs into any type of format that makes sense (for PC / TV playback).

My problems:

a. Deinterlacing
As far as I can see, playback deinterlacing isn't very reliable. I get different results in VLC than PotPlayer even after fiddling with the deinterlace settings (which I'd rather not do every time), so I'll probably need to deinterlace at encoding. I've read about the subject here and general consensus seems to be that QTGMC at double frame rate is usually the best option for purely interlaced material. Without really knowing what I was doing (I still don't), I was able to apply QTGMC with StaxRip (because I read that I didn't need to deal with AviSynth, which scares the hell out of me, although I'm eager to learn). I was impressed with the results. Whatever the filter does, it looks much smoother compared to the original no matter what player deinterlacer I use.

The only problem I've had is some weird artifact/flickering thing that happens in a specific part with QTGMC or other deinterlacing methods that use double frame rate. I think it's because the original segment itself is weird, sort of an early-'90s cheap motion effect. Only double-rate versions have that flicker (which seems to be because each two fields become two distinct frames repeated a few times, instead of being blended together into one blurry frame as probably intended... jeez, I hope that makes sense when you watch the samples). I know it's a small nuance (the original doesn't look too good, either) but my concern is I have a bunch of these and I remember there were a lot of cheesy effects, graphics, etc. Is there anything that could be done to prevent things like these?

I'll attach a very small sample of:

1- interlaced video
2- an EEDI3 same-rate version I did
3- the QTGMC version (where the flicker is present).

Note that I cut the samples using FFMpeg in a very crude fashion, so please let me know if that's no good and which the right procedure would be.

b. Aspect Ratio
Ok, so I read a lot about PAR, SAR, ITU, non-ITU until my head exploded. I think I'm starting to understand it. But just to be sure, I wanted to ask something that's been bugging me. I tried cropping to 704x480 (2 pixels left, 14 pixels right) and letting StaxRip deal with the PAR calculations. I want to use ITU because it looks better to my eye, at least for this video. But I don't know what that Aspect Ratio Error is, why it is so high (9,69%) and if it should be a concern. I tried googling about it but I couldn't find anything that clarified this. I'm attaching an image of what the settings look like.


[Attachment 47458 - Click to enlarge]

c. Playback compatibility
This is a last-minute addition. I don't yet own the TV in which I'll be playing this yet, but I copied a few of the test files I've been making to a USB stick and tried playing them in a TV. For some reason, only the MKV made with MakeMKV and an interlaced version made with ffmpeg worked. The other ones (made with StaxRip) were deemed 'invalid files'. I know my process is all over the place (like this thread), so could you point out to any reason why this could happen or -even better- suggest a method to carry out the whole process as smoothly as possible?

Thanks in advance!

[Edit: I guess attachments don't work or need to be approved, so here's a WeTransfer link for the samples and the screen capture: https://we.tl/t-Z1SCjhm0bO ]

[jagabo]

A) The flickery result of QTGMC is what you would see on an interlaced NTSC TV when viewing the source. The interlaced source consists of interlaced frames repeated for a total of 5 frames. Since the frames are interlaced and there was motion between the fields, the final picture on the TV bounces back and forth 5 times. With digits representing the field numbers: 010101010123232323234545454545... Your eedi sample discards every other field so you're left with 000002222244444...

B) Cropping the frame doesn't change the PAR. Think of a piece of graph paper. No matter how much you cut off the edges the remaining blocks remain the same shape. What changes is the overall shape of the paper (the SAR). The PAR for 4:3 NTSC video is 10:11.

DAR = SAR * PAR

DAR is the final display aspect ratio, the shape of the final displaed picture
SAR is the storage aspect ratio, the dimensions of the video frame, width:height
PAR is the pixel aspect ratio, the width:height of individual pixels

DAR =  704:480 * 10:11
DAR = 704 / 480 * 10 / 11
DAR = 1.3333...
DAR = 4:3

The reason StaxRip is reporting the big error is because PAR information is lost in the AviSynth script. StaxRip thinks the incoming video is square pixel (PAR 1:1). Since you are treating the PAR as 10:11 it reports a substantial error.

Note: you may find confusing information about aspect ratios because the older terms DAR, SAR, PAR where changed in later documents to DAR (still Display Aspect Ratio), FAR (Frame Aspect Ratio), SAR (Sampling Aspect Ratio) to more correctly represent what they really mean (pixels have no shape, they are theoretically points with spaces between them horizontally and vertically). Also many programs don't differentiate between ITU and MPEG aspect ratios.

C) The videos made with StaxRip are encoded with 10 bits per channel. Very few devices support 10 bit h.264. Switch to 8 bit if you want wide compatibility.

[LMotlow]

I'll attach a very small sample of:

1- interlaced video
2- an EEDI3 same-rate version I did
3- the QTGMC version (where the flicker is present).

Note that I cut the samples using FFMpeg in a very crude fashion, so please let me know if that's no good and which the right procedure would be.

Nope. We don't want incorrectly re-encoded samples of originals.
How to make an undamaged m2v sample from a DVD using the free DGIndex utility: How To make And Upload A Sample from a DVD.
All we need is an m2v piece of the original to start with.

[MGRV]

A) The flickery result of QTGMC is what you would see on an interlaced NTSC TV when viewing the source.

Indeed, I forgot to mention that I saw it happen with the interlaced video I tried on the TV. I was really surprised, I expected it to be more like what I see in VLC or PotPlayer, but I guess both players are set up to discard frames as well (as does EEDI)?

B) Cropping the frame doesn't change the SAR. [...]

SAR is the storage aspect ratio, the dimensions of the video frame, width:height

Ok, I'm totally lost. If SAR is the dimension of the video frame, how does cutting it not affect it? Unless you meant Sample AR the first time? Just when I thought I was getting the hang of it...

Also many programs don't differentiate between ITU and MPEG aspect ratios.

I'm still a bit confused about this. I've read that the ITU PAR for 4:3 NTSC is 4320:4739, MPEG PAR is 10:11 and there's a 'generic' PAR of 9:10 (I'm looking at the notes I gathered these days). Is this correct? If I check/uncheck the ITU setting in StaxRip, the PAR changes from 10:11 to 8:9. What would those two be?

Very few devices support 10 bit h.264. Switch to 8 bit if you want wide compatibility.

Ah, I had no idea, thanks for the tip.

And thanks for your reply!

[MGRV]

All we need is an m2v piece of the original to start with.

I think jagabo pretty much 'solved the mystery' about the jumpy frames, but anyway, just to oblige, let me try that.

I really didn't pay too much attention to the clip's length (I couldn't see the running time in DGIndex) but I guess it's long enough to see the pattern I was referring to.

Thanks for your reply!

[jagabo]

B) Cropping the frame doesn't change the SAR. [...]

SAR is the storage aspect ratio, the dimensions of the video frame, width:height

Ok, I'm totally lost. If SAR is the dimension of the video frame, how does cutting it not affect it? Unless you meant Sample AR the first time? Just when I thought I was getting the hang of it...

Sorry. I originally wrote the post with the new conventions but then went back and changed to the old convention since that's what StaxRip was using. It looks like I missed some of the acronyms when I updated the post. The post should have said "Cropping the frame doesn't change the PAR". I'll review the post and fix any remaining errors.

Also many programs don't differentiate between ITU and MPEG aspect ratios.

I'm still a bit confused about this. I've read that the ITU PAR for 4:3 NTSC is 4320:4739, MPEG PAR is 10:11 and there's a 'generic' PAR of 9:10 (I'm looking at the notes I gathered these days). Is this correct? If I check/uncheck the ITU setting in StaxRip, the PAR changes from 10:11 to 8:9. What would those two be?

The DVD spec refers to the MPEG 2 spec for aspect ratios. The MPEG 2 spec only flags the display aspect ratio (4:3 or 16:9), and it clearly specifies the flagged aspect ratio refers to the full 720x480 frame and references the usual "DAR = frame_width / frame_height * PAR" equation. So there is a discrepancy between the DVD spec and the ITU spec. That discrepancy is almost always ignored in the industry: when analog sources are converted to DVD they are usually captured at 720x480 with ITU spec equipment and written to DVD without correcting for the aspect ratio difference (ie, without cropping to 704x480).

The ITU spec results in a non-integer frame size for the 4:3 image, 703.? by 480. Actually the active picture is 485 scan lines: 484 full lines, half a scan line at the top, and half a scan line at the bottom. In practice a few lines at the top and bottom are not captured and that remaining ~703x480 is rounded to 704x480. So none of the usual pixel aspect ratios is exact. 10:11 is value used for 704x480 -- I gave the math earlier. 8:9 is the value when following the DVD spec:

DAR = 720:480 * 8:9
DAR = 720 / 480 * 8 / 9
DAR = 1.3333...
DAR = 4:3

In reality, the difference isn't really noticeable. And old analog TVs had very poor regulation of the frame dimensions and were usually off by more than that anyway.

In my experience DVD players are schizophrenic. They upscale the full 720x480 frame to 1440:1080 or 1920x1080 for HDMI output (following the DVD/MPEG2 spec) but At the composite/s-video outputs they follow the ITU spec.

[MGRV]

The DVD spec refers to the MPEG 2 spec for aspect ratios. The MPEG 2 spec only flags the display aspect ratio (4:3 or 16:9), and it clearly specifies the flagged aspect ratio refers to the full 720x480 frame and references the usual "DAR = frame_width / frame_height * PAR" equation. So there is a discrepancy between the DVD spec and the ITU spec. That discrepancy is almost always ignored in the industry: when analog sources are converted to DVD they are usually captured at 720x480 with ITU spec equipment and written to DVD without correcting for the aspect ratio difference (ie, without cropping to 704x480).

The ITU spec results in a non-integer frame size for the 4:3 image, 703.? by 480. Actually the active picture is 485 scan lines: 484 full lines, half a scan line at the top, and half a scan line at the bottom. In practice a few lines at the top and bottom are not captured and that remaining ~703x480 is rounded to 704x480. So none of the usual pixel aspect ratios is exact. 10:11 is value used for 704x480 -- I gave the math earlier. 8:9 is the value when following the DVD spec:

DAR = 720:480 * 8:9
DAR = 720 / 480 * 8 / 9
DAR = 1.3333...
DAR = 4:3

In reality, the difference isn't really noticeable. And old analog TVs had very poor regulation of the frame dimensions and were usually off by more than that anyway.

In my experience DVD players are schizophrenic. They upscale the full 720x480 frame to 1920x1080 for HDMI output (following the DVD/MPEG2 spec) but At the composite/s-video outputs they follow the ITU spec.

I don't think I ever watched most of these DVDs in a standalone player -mostly PC playback. But I've always noticed in many DVDs that the picture seemed to be a tad 'thin'. When I decided to start this project, I did some tests and encoded the DVD with FFMpeg and then with either StaxRip or Handbrake (don't remember) and noticed the output was slightly wider and looked much better to me. I did some research (I didn't even know how to google it... "DVD aspect ratio conspiracy"?) and that's when I fell into the rabbit hole of aspect ratios and came across very informative posts, many by you. That's how I got to understand a bit of the whole deal about anamorphic video and this PAR/SAR/DAR nightmare. But I'm dumb, and it's a cofusing subject! So, aside from the fact that there seems to be no way to know for sure the exact aspect ratio of a commercial DVD, am I safe to assume what I'm doing is fairly accurate? I'm cropping 16 pixels in total (not 8 and 8 because the padding black bars in this one aren't equally distributed) to make it 704 and then using ITU PAR 10:11. I think I read that usually applies for NTSC 4:3 DVDs. If TVs or certain players don't use the ITU I'm setting, which one would they use? 8:9?

[jagabo]

So, aside from the fact that there seems to be no way to know for sure the exact aspect ratio of a commercial DVD, am I safe to assume what I'm doing is fairly accurate? I'm cropping 16 pixels in total (not 8 and 8 because the padding black bars in this one aren't equally distributed) to make it 704 and then using ITU PAR 10:11. I think I read that usually applies for NTSC 4:3 DVDs.

Seeing black borders at the left/right usually indicates an ITU cap. So cropping to 704x480 and assuming 4:3 DAR, 10:11 PAR is called for.

If TVs or certain players don't use the ITU I'm setting, which one would they use? 8:9?

Yes, they are assuming the full 720x480 frame is 4:3 DAR, 8:9 PAR (MPEG spec).

[MGRV]

If TVs or certain players don't use the ITU I'm setting, which one would they use? 8:9?

Yes, they are assuming the full 720x480 frame is 4:3 DAR, 8:9 PAR (MPEG spec).

Ok, I'm trying to figure this out myself but I can feel my brain overheating... So I have to ask. If a player assumes the full 720x480 frame is 4:3 DAR, 8:9 PAR, how will it display my 704x480 4:3 DAR, 10:11 PAR video? I know the difference is pretty neglegible, I just want to understand it.

[jagabo]

If a player assumes the full 720x480 frame is 4:3 DAR, 8:9 PAR, how will it display my 704x480 4:3 DAR, 10:11 PAR video?

Who knows! But my guess is it will be handled correctly since both specs match at 704x480.

[MGRV]

Who knows!

LOL... Ok, I'm relieved! If you don't know, I definitely don't need to know. My mind is at peace with 704x480 4:3 DAR, 10:11 PAR, MTU all the way (unless later into the collection I notice any changes, ie. lack of padding... the horror!).

So, with that out of the way, let me ask you a few more things about the process. I used MakeMKV to get -as I understand it- the same stream as the VOB files in a workable container. That MKV is what I used as the input in StaxRip. Is that an acceptable way to do it? I've never done any video encoding before, aside from a few basic (and probably wrong) things with FFMpeg. That means, I'm not familiar with any software, so I'm open to suggestions about better ways to handle the process. I'm just going by trial and error but I wouln't want to mess things up and find out later.

As I mentioned, the reason I used StaxRip was that I wanted to try QTGMC without having to delve too deep into so much new information. I just went whatever-whatever-QTGMC Medium-Next and didn't care much about the other options (except for the AR thing). Now, having seen the improvements, I'm sold on QTGMC, but wonder if I need to change any other settings on StaxRip (for instance, the 10-bit thing you mentioned, which I can't find yet!) or learn to do it some other way.

Thanks a lot for your help!

[LMotlow]

If a player assumes the full 720x480 frame is 4:3 DAR, 8:9 PAR, how will it display my 704x480 4:3 DAR, 10:11 PAR video?

Who knows! But my guess is it will be handled correctly since both specs match at 704x480.

Sounds about right to me. Looks that way, too -- Image below is 720x480 at 4:3 (top) -vs- 704X480 at 4:3 (bottom) in MPC Player:



Avisynth script (adjust crop and borders below for 720x480 or 704x480):

MPEG2Source("D:\forum\VH\MGRV\VTS_01_1_sample.d2v")
AssumeTFF()
QTGMC(preset="very fast",FPSDivisor=2,border=true)
Crop(4,0,-16,0)
AddBorders(10,0,10,0)  # <- 720x480
# AddBorders(2,0,2,0)    # <- 704x480

[jagabo]

I used MakeMKV to get -as I understand it- the same stream as the VOB files in a workable container.

Yes, MakeMKV only extracts the original MPEG 2 video and AC3 audio from the VOB container and re-wraps it in an MKV container.

That MKV is what I used as the input in StaxRip. Is that an acceptable way to do it?

I've never used StaxRip but it seems to be working for you.

I've never done any video encoding before, aside from a few basic (and probably wrong) things with FFMpeg. That means, I'm not familiar with any software, so I'm open to suggestions about better ways to handle the process. I'm just going by trial and error but I wouln't want to mess things up and find out later.

As I mentioned, the reason I used StaxRip was that I wanted to try QTGMC without having to delve too deep into so much new information. I just went whatever-whatever-QTGMC Medium-Next and didn't care much about the other options (except for the AR thing). Now, having seen the improvements, I'm sold on QTGMC, but wonder if I need to change any other settings on StaxRip (for instance, the 10-bit thing you mentioned, which I can't find yet!) or learn to do it some other way.

That's a pretty wide open question. I don't do much with DVDs anymore but when I do I use DVDFab (free version) to rip the DVD to a VIDEO_TS folder, DgIndex/Mpeg2Source/AviSynth to access the VOB files and to perform any filtering, x264 CLI to encode the video, and MkvToolnix to mux the resulting video and AC3 audio. This gives me full control of the processing and encoding. StaxRip seems to be doing a lot of this for you but you may occasionally run across DVDs that it can't handle properly. One example might be PAL/NTSC converted DVD -- see if StaxRip has the AviSynth filter called SRestore.

[MGRV]

StaxRip seems to be doing a lot of this for you but you may occasionally run across DVDs that it can't handle properly. One example might be PAL/NTSC converted DVD -- see if StaxRip has the AviSynth filter called SRestore.

Thanks again for your reply. It's interesting to see how someone who actually knows what he's doing works. As you said, I might be ok to stick with StaxRip which takes care of many things for me. I'm just worried about things like the 10-bit depth thing which I wouldn't have figured out in a million years had you not mentioned it (it took me quite a while to even find where to change the settings).

I couldn't find SRestore under the list of StaxRip AviSynth filters. Is that used specifically for PAL/NTSC converted DVDs or does it have other uses? I don't know how I would detect such a case, if I came across something like that.

[lingyi]

c. Playback compatibility
This is a last-minute addition. I don't yet own the TV in which I'll be playing this yet, but I copied a few of the test files I've been making to a USB stick and tried playing them in a TV. For some reason, only the MKV made with MakeMKV and an interlaced version made with ffmpeg worked. The other ones (made with StaxRip) were deemed 'invalid files'. I know my process is all over the place (like this thread), so could you point out to any reason why this could happen or -even better- suggest a method to carry out the whole process as smoothly as possible?

I've said this dozens of times and will say it dozens of times more. Forget the built in media player on even the smartest TV and get a dedicated media player starting at <$50 for an Android box.

$50 - $100 - Android Box or Raspberry Pi . Stick with the 4 star+ boxes on Amazon and the build quality is generally solid with higher cost giving you additional streaming features that you may not need.

$100 - $150 - Blu-Ray player. Be sure the player will play DVD .ISOs (if you have them) and .MKVs. Newer players may not support all types of video files.

$150+ - KDLinks, Nvidia Shield, laptop, HTPC. Note that the newer KDLinks models (e.g. A400) run Android and IMHO, doesn't warrant the premium over a $100 Android Box. While the Nvidia Shield is highly praised, most of the praise is for it's gaming capabilities, not the video capabilities.

Any these will play just about any video file you have and you won't have to fuss with having to reencode your videos to play on your TV's media player.

[MGRV]

I've said this dozens of times and will say it dozens of times more. Forget the built in media player on even the smartest TV and get a dedicated media player

Thanks for your suggestions. I'll check them out (as I said, I'm in the tech-impaired bunch, so I'm not too familiar with some of that stuff.

I do travel quite often though, and would like to have a copy of these DVDs that I can play pretty much anywhere. I'm not fanatical about it either, just trying to avoid something as my recent 10-bit depth fiasco that jagabo spotted.

[lingyi]

Post what type of device you're planning to playback on, i.e. smartphone, tablet, Android, IPhone, etc. If you don't mind that large file size ~4 to 8GB, you could use VOBtoMPG to convert your ripped discs to mpeg files that will play on just about any device. If you want to make them smaller, which most people do, others here can recommend good programs and settings to compress your DVD rips (which are an exact copy and size as the files on the disc).

[MGRV]

Post what type of device you're planning to playback on, i.e. smartphone, tablet, Android, IPhone, etc. If you don't mind that large file size ~4 to 8GB, you could use VOBtoMPG to convert your ripped discs to mpeg files that will play on just about any device. If you want to make them smaller, which most people do, others here can recommend good programs and settings to compress your DVD rips (which are an exact copy and size as the files on the disc).

That's the thing, I don't quite know yet where I'll be playing these videos (other than my laptop and the TV that's in the house now). But I plan on buying a decent TV (or whatever setup suits me, such as what you suggested) after I move. Video compatibility only became an issue in this thread because I (unknowingly) encoded a few sample videos in h.264 10-bit depth mode and couldn't get them to play on the TV via-USB. But I don't expect that to be a major issue. I do want to reduce the filesize, as I'm mainly encoding them for convenience and not for archival purposes (and because I definitely don't want to leave the deinterlacing process as a quality variable at playback time when QTGMC does such a nice job).

[MGRV]

I have a few (interrelated... or interlaced?) questions about QTGMC.

1. I've noticed it removed a lot of noise from the original, but it's not clear to me whether that's just a by-product of deinterlacing itself or if it's actually applying some denoising as well (I read it can be set to do both). I don't know how much I can play around with its settings via StaxRip (I'll check later once it's done encoding my current test), but I'm ready to bang my head against the wall and struggle with AviSynth if need be. I'm very pleased with the results I got from just leaving it set to whatever the default is. If anything, I'd like to try a few variants with a tad less aggressive approach on noise reduction just to compare the results and see if it makes any difference to me. I don't think the noise on this DVD adds much of a 'natural' feel to it, so it's not something I want to keep, and I don't think too much detail gets lost. But just to try it out and judge it for myself.

2. Related to that, I've noticed QTGMC results are consistently smaller than other approaches given the same CRF (even those at half the frame rate). Is it possible that noise reduction plays an important role in such a noticeable difference? Just curious. I won't complain about lower filesizes!

3. Usually, I read the same thing regarding presets: "go as slow as you're willing to tolerate". However, I've also read that it's possible QTGMC reduces more noise in slower presets (or at least does a different job). Is that correct? Should I take speed into consideration aside from the usual "the slower, the more efficient" mantra?

[MGRV]

Avisynth script (adjust crop and borders below for 720x480 or 704x480):

MPEG2Source("D:\forum\VH\MGRV\VTS_01_1_sample.d2v")
AssumeTFF()
QTGMC(preset="very fast",FPSDivisor=2,border=true)
Crop(4,0,-16,0)
AddBorders(10,0,10,0)  # <- 720x480
# AddBorders(2,0,2,0)    # <- 704x480

Thanks!

Just curious: I'm (still) Avisynth-illiterate. It took me a while to figure out what that script is doing, because it seemed counterintuitive that it crop 4 & 16 instead of 2 & 14 (which it makes up for in the 704 version adding 2 & 2). I suspect there's a technical reason for doing it that way?

Am I correct assuming FPSDivisor=2 is pretty much the same as SelectEven?

[LMotlow]

Just curious: I'm (still) Avisynth-illiterate. It took me a while to figure out what that script is doing, because it seemed counterintuitive that it crop 4 & 16 instead of 2 & 14 (which it makes up for in the 704 version adding 2 & 2). I suspect there's a technical reason for doing it that way?

Am I correct assuming FPSDivisor=2 is pretty much the same as SelectEven?

If you look at a frame from the video in VirtualDub, there are 4 pixels of black on the left. On the right there are actually 15 pixels of border and noise, but you want at least 2 pixels in cropping, and there is also another pixel of ragged noise on the right, so 16 clears it all up without taking too much off the image. It also makes for even borders when you add new black borders. New black borders are also handy after color correction, which can affect border color that becomes obvious against the black backgrounds of wide screen displays.

FPSDivisor=2 is faster than SelectEven because it eliminates one field earlier in the processing (that's what I've read, anyway). It works both ways.

[MGRV]

If you look at a frame from the video in VirtualDub, there are 4 pixels of black on the left. On the right there are actually 15 pixels of border and noise, but you want at least 2 pixels in cropping, and there is also another pixel of ragged noise on the right, so 16 clears it all up without taking too much off the image. It also makes for even borders when you add new black borders. New black borders are also handy after color correction, which can affect border color that becomes obvious against the black backgrounds of wide screen displays.

I still don't know exactly how things work (I had downloaded VirtualDub some time ago and probably couldn't get it to work), so let me ask you: I attached a m2v file here as you requested, but I see you somehow produced a d2v file from it, which is what the script calls. Is that correct? If I want to try your script, do I have to cut a sample again (and use the resulting d2v file which I previously discarded) or should I do whatever you did to get that file?

Also, I assume you meant it's always recommended to crop a minimum of 2 pixels per side? I get what you mean about borders and color correction. I don't plan to color-correct (unless it's being done without me even knowing) so I guess I shouldn't worry too much.

FPSDivisor=2 is faster than SelectEven because it eliminates one field earlier in the processing (that's what I've read, anyway). It works both ways.

Interesting! Thanks for your input.

[jagabo]

I attached a m2v file here as you requested, but I see you somehow produced a d2v file from it, which is what the script calls. Is that correct?

Yes. Use DgIndex to create a d2v (index) file.

If I want to try your script, do I have to cut a sample again (and use the resulting d2v file which I previously discarded) or should I do whatever you did to get that file?

You can use the m2v file you uploaded before. Open it in Dgindex, select File -> Save Project. You'll get an d2v file suitable for use with Mpeg2Source()*.

Also, I assume you meant it's always recommended to crop a minimum of 2 pixels per side?

You need to crop by multiples of 2 (ie, 2, 4, 6, 8...). The output from Mpeg2Source() is uncompressed YV12 video. It has the luma channel (greyscale image) at full width and height, 720x480, but the chroma channels (colors added or subtracted from the greyscale) are half width and height, 360x240 (almost all consumer video comes in this form, DVD, Blu-ray, Youtube, etc.). If you were to crop by an odd value, say 719x480, the chroma channels would have to be 359.5x240. You can't have half pixels, hence the requirement to crop by multiples of 2.


* Mpeg2Source() is not included with AviSynth, it is a third party filter. You'll need to download the TIVTC package and put a copy of TIVTC.dll in AviSynth's plugins folder.

[LMotlow]

* Mpeg2Source() is not included with AviSynth, it is a third party filter. You'll need to download the TIVTC package and put a copy of TIVTC.dll in AviSynth's plugins folder.

Excellent reply and detail, as usual. But Mpeg2Source is a function in the DGMPGDec package.

When you download and unzip the DGMPGdec package, you'll find DGDecode.dll in the DGMPGdec folder. Copy DGdecode.dll into your Avisynth plugins folder. DGdecode.dll contains the Mpeg2Source function.


If you already downloaded TIVTC, keep it. It's used to reverse telecine in telecined video.

[jagabo]

* Mpeg2Source() is not included with AviSynth, it is a third party filter. You'll need to download the TIVTC package and put a copy of TIVTC.dll in AviSynth's plugins folder.

Excellent reply and detail, as usual. But Mpeg2Source is a function in the DGMPGDec package.

Oops! Yes, DGMPEGDec. I was dealing with TIVTC in another thread.

[MGRV]

Thank you both for your help!

So, I used my own uploaded m2v file in DgIndex to get a d2v file.

I already had DGMPGDec installed, but I didn't know. I guess it's one of the many tools I installed while reading suggestions to other people's questions in the forum. I previously made the m2v file using DGIndex from an "Apps" folder that came with my StaxRip download (has fewer files compared to the DGMPGDec folder). Now I see it called "DGMPGDec DGIndex" in the download page. Are they the same thing?

Anyway, I followed the steps you provided but got an error message when trying to open the file in VirtualDub. It's complaining there is no "QTGMC" function. I only got QTGMC via StaxRip, so I assumed there had to be a QTGMC.dll file somewhere that I could throw into the AviSynth plugins folder. I checked but could only find the file QTGMC.avsi under \\StaxRip\Apps\Plugins\AVS\QTGMC so I'm not sure how to fix this (I'm not even sure I should be looking for a dll at all, I'm just aping what I was told to do before with the DGdecode.dll file).

Thanks again for your patience!

[jagabo]

The problem is StaxRip has it's own private version of AviSynth and all its filters. Other programs don't know it's there. Opening an AVS script in VirtualDub requires a system installed version of AviSynth and all the required 3rd party filters. You have AviSynth installed so you should be able to use StaxRip's versions by manually importing them with import("X:\Path\toStatxrip's\plugins\QTGMC.avs") and LoadPlugin("X:\Path\toStatxrip's\plugins\plugin.na me.dll") for each of the required dll files. Or you can copy QTGMC.AVS and any missing dll files from StaxRip's plugins folder to AviSynth's plugins folder.

[LMotlow]

QTGMC.avsi would be a copy of the code for QTGMC, but the plugin actually requires several support plugins, a Windows system library file, and some VisualC runtimes. I don't use StaxRip except to encode occasionally but I don't use its Avisynth functions. It seems you should be able to edit the Avisynth script that StaxRip uses. If not, I'll attached a .zip file (NOTE: not attached. see EDIT and link below) of all the requirements updated as of Nov 2017, which uses the original QTGMC and is current except for some 16-bit versions of the plugin that you don't want at this point anyway. The .zip has subfolders with everything you need.


Create a new folder or subfolder somewhere for the .zip file, then download it to that folder. When unzipped, look first at the "READ ME FIRST.txt" file.

[EDIT] Videohelp's uploader isn't working, so use this link below for the original zip file compiled by an acquaintance of mine at digitalfaq.com:
http://www.digitalfaq.com/forum/attachments/video-capture/6322d1467077360-vhs-capturing-qtgmc_newzip.

When you have QTGMC and its support files you'll also have a handy bunch of popular standalone filters that are also used in several other high-octane plugins.

[MGRV]

Thank you both.

The problem is StaxRip has it's own private version of AviSynth and all its filters. Other programs don't know it's there. Opening an AVS script in VirtualDub requires a system installed version of AviSynth and all the required 3rd party filters.

Yeah, I figured what StaxRip did (not that it doesn't do a lot of other things, but what it did for me here) was pack everything I needed to use QTGMC without caring what was going on behind the scenes. But I knew AviSynth could come handy in the future, that's why I installed it separately from StaxRip. But I don't know exactly what I installed. I guess it's the basics? AviSynth itself with its own filters?

You have AviSynth installed so you should be able to use StaxRip's versions by manually importing them with import("X:\Path\toStatxrip's\plugins\QTGMC.avs") and LoadPlugin("X:\Path\toStatxrip's\plugins\plugin.na me.dll") for each of the required dll files. Or you can copy QTGMC.AVS and any missing dll files from StaxRip's plugins folder to AviSynth's plugins folder.

I have zero knowledge of how scripts (or the whole frameserving process) works, so I'm lost here. But I'm willing to learn, I know it can't be that hard (I just recklessly got here doing whatever was needed to get the filter to work, and now I'm working my way back figuring things out). Do you mean (on your first suggestion) adding those lines to the script I load in VirtualDub? Would that mean having a 'template' with all the stuff I need to import every time I run a script? Sorry for the dumb questions!

It seems you should be able to edit the Avisynth script that StaxRip uses. If not, I'll attached a .zip file

Sorry for the dumb questions part deux. Are you suggesting the same as jagabo's second suggestion, or is it a different method? Would that be copying that avsi file (converted to avs) to the proper folder, plus copying (or importing manually) what I need from StaxRip? Anyway, I'm pretty sure the best approach would be a clean install from the .zip file, which I already downloaded and will deal with later (I need to gather some morale). Let me know otherwise!

[LMotlow]

It seems you should be able to edit the Avisynth script that StaxRip uses. If not, I'll attached a .zip file

Sorry for the dumb questions part deux. Are you suggesting the same as jagabo's second suggestion, or is it a different method? Would that be copying that avsi file (converted to avs) to the proper folder, plus copying (or importing manually) what I need from StaxRip? I'm pretty sure the best approach will be a clean install from the .zip file, which I already downloaded and will deal with later (I need to gather some morale).

Programs like StaxRip and MeGUI that use Avisynth internally have customized their setup for their own use -- which might not always agree with the current state of a user-installed Avisynth setup. Also, the plugin support packages for QTGMC will differ for different versions of QTGMC. To date, the "safest" version of QTGMC.avsi is the "original" version 3.32. The support files in the .zip package are updates for that version. Later QTGMC versions are mostly compatible with those support files, but later versions require additional support pieces. For myself, I like playing it safe most of the time with the old "3.32" and storing updated and matching support filters in the official plugins folder. When I want to play with later and more experimental versions I have separate plugin folders for those, where I keep the new .avsi's and all of their support files, and which I explicitly load and import into a script by name and location.

It's been so long since I used freebies like StaxRip, Avidemux, etc., I don't recall in detail how they worked. I might be confusing Avisynth usage in StaxRips with usage in MeGUI or some other ancient app, I don't remember. Meanwhile I use and update my main in-system Avisynth installation "by the book", so to speak. This doesn't interfere with the free apps, and the free apps don't interfere with my Avisynth.

Two tips about building up Avisynth plugins:

First, don't download plugin packages into your plugins folder. Downloads usually have a bunch of files that aren't filters and that don't belong in the plugins folder. Make subfolders for those packages so you'll know where to find spare copies and documentation. Then, just copy the .dll, the .avsi, or the .avs plugin itself into the official folder. Otherwise you'll have a huge mess on your hands.

Sometimes a plugin in one of those packages will be older than the plugin you already have. It's safest to use the newer version. But keep the old one in a safe place. You never can tell. Sometimes the newest comes with a bug.