@browj2

Hi John

I would agree with Al's comment:

'Watch out for what's known in the business as the "ezycraps"'.

You may get lucky.

John EB

Hi @browj2

I agree with both @AAProds and @johnebaker . The IOData GV-USB2 has received good reviews and highly recommended. @AAProds, just on that note, can you tell if the Startech USB3HDCAP, has the same chipset as the IOData? I only ask because I think they both have the same unique Proc amp setting display. Also, do you prefer one over the other or do they essentially produce the same results?

@Can-Dive

can you tell if the Startech USB3HDCAP, has the same chipset as the IOData?

I don't know. I could make some enquiries if you want. The GV-USB2 has a Techwell chip:

https://www.digitalfaq.com/forum/video-capture/12709-dmr-es10-passthrough.html#post84137

I think they both have the same unique Proc amp setting display. 

All the USB digitisers have exactly the same Proc Amp control panel; the values vary but all the controls themselves are the same.

Do you prefer one over the other or do they essentially produce the same results?

Basically the same. The USB3HDCAP can capture HDMI, which I've done on occasion, but the quality is on-par with S-Video so it's probably not worth the extra cost. Pretty pricey beast, it is.

Hi @AAProds,

I stand corrected, rather than the proc amp I meant to say "Control Panel." My query is based on these two reviews of the GV-USB2 and USB3HDCAP. In the first video, the Control Panel is displayed at 3:24 for the GV-USB2 and the second video at 9:53 for the USB3HDCAP. Having the same Control Panel led me to think that both may have the same chipset;

Hi @AAProds, @Former user

@Former user, Unlike the stuttering playback of the Lagarith video on your machine, it played smoothy in MMS 2024 on my computer. Just wondering what playback settings you had switched on?

As for the MagicYUV, I do not have that codec installed on my machine so I was not able to play the video. What version of MagicYUV are you running; 2.4.0 or the free version 1.2?

I loaded the Lagarith video into Vegas Pro 19. I recently purchased it as a Fanatical Bundle so I'm still learning that program as well. Looking at the properties, the pixel aspect ratio is 1.0926 which is apparently Vegas Pro's 4:3 aspect ratio for PAL. See screenshot below. I have yet to determine how this number is calculated but I did find two interesting discussions on this topic. Suffice to say, there is a bit more to aspect ratio than just simple division.

https://www.vegascreativesoftware.info/us/forum/what-are-the-correct-pixel-aspect-ratios--39808/

https://creativecow.net/forums/thread/54-aspect-ratio-pixel-aspect-ratio-5954-4x3-vs-54/

@AAProds, I do have a question regarding the Lagarith video you provided. Looking at Vegas properties, its Field Order is "Upper field first" implying that this is a interlaced file. This surprised me because I looked at the image carefully and could not see any combing effect. Also Mediainfo didn't report a "Scan Type" so I thought maybe this was progressive although if this was the case, I would have expected 50fps rather than the reported 25fps. @AAProds did you deinterlace the video? 

@Can-Dive

I stand corrected, rather than the proc amp I meant to say "Control Panel."

Arr yes, got it. It could be.

As for the MagicYUV, I do not have that codec installed on my machine so I was not able to play the video. What version of MagicYUV are you running; 2.4.0 or the free version 1.2?

2.4

I do have a question regarding the Lagarith video you provided. Looking at Vegas properties, its Field Order is "Upper field first" implying that this is a interlaced file. This surprised me because I looked at the image carefully and could not see any combing effect. Also Mediainfo didn't report a "Scan Type" so I thought maybe this was progressive although if this was the case, I would have expected 50fps rather than the reported 25fps. @AAProds did you deinterlace the video? 

No, but I fell for the old trick of cropping before deinterlacing. It looks like it's come out pseudo-progressive. I wanted to crop the small black bars off the sides to show how Magix messes up the import.

Here's a raw 720x576 Interlaced Lagarith file (it does have small black side bars-all analogue captures have these, as well as the headswitching noise at the bottom):

https://drive.google.com/file/d/1OWqQDoSL597BOwUCb8717LNtc0tePv8k/view?usp=sharing

Re the reports of field order, these AVIs don't have any field information in the metadata, so sometimes the programs such as Mediainfo just guess. For example, Mediainfo reports these as 5:4 because 720/576 is 5:4. But the file is supposed to be viewed at 4:3.

the pixel aspect ratio is 1.0926 which is apparently Vegas Pro's 4:3 aspect ratio for PAL.

I have seen that number elsewhere but I must admit I don't know a lot about the background to it. Magix is good/simple in this regard because it allows you to set, crop or export using the 4:3, 16:9 terms.

A trick I use if I'm unsure what aspect ratio is being displayed is to use a screenshot program to draw out a rectangle around the video on the monitor (which must be square pixels, of course) and divide the width by the height to check. That Vegas screenshot is slightly stretched laterally at 1.36:1.

My current workflow is to save the file in Virtual Dub, deinterlaced to 50 frames/sec, cropped and resized to 768x576 with square pixels. Then nothing can go wrong when I import it to other programs.

@AAProds,

I think you may have sent me the Deinterlaced version of the video. Frame rate is 50fps and progressive. Pixel aspect ratio = 1. Doesn't that mean square pixels?

@Can-Dive

I stand corrected, rather than the proc amp I meant to say "Control Panel."

Arr yes, got it. It could be.

As for the MagicYUV, I do not have that codec installed on my machine so I was not able to play the video. What version of MagicYUV are you running; 2.4.0 or the free version 1.2?

2.4

I do have a question regarding the Lagarith video you provided. Looking at Vegas properties, its Field Order is "Upper field first" implying that this is a interlaced file. This surprised me because I looked at the image carefully and could not see any combing effect. Also Mediainfo didn't report a "Scan Type" so I thought maybe this was progressive although if this was the case, I would have expected 50fps rather than the reported 25fps. @AAProds did you deinterlace the video? 

No, but I fell for the old trick of cropping before deinterlacing. It looks like it's come out pseudo-progressive. I wanted to crop the small black bars off the sides to show how Magix messes up the import.

Here's a raw 720x576 Interlaced Lagarith file (it does have small black side bars-all analogue captures have these, as well as the headswitching noise at the bottom):

https://drive.google.com/file/d/1OWqQDoSL597BOwUCb8717LNtc0tePv8k/view?usp=sharing

Re the reports of field order, these AVIs don't have any field information in the metadata, so sometimes the programs such as Mediainfo just guess. For example, Mediainfo reports these as 5:4 because 720/576 is 5:4. But the file is supposed to be viewed at 4:3.

the pixel aspect ratio is 1.0926 which is apparently Vegas Pro's 4:3 aspect ratio for PAL.

I have seen that number elsewhere but I must admit I don't know a lot about the background to it. Magix is good/simple in this regard because it allows you to set, crop or export using the 4:3, 16:9 terms.

A trick I use if I'm unsure what aspect ratio is being displayed is to use a screenshot program to draw out a rectangle around the video on the monitor (which must be square pixels, of course) and divide the width by the height to check. That Vegas screenshot is slightly stretched laterally at 1.36:1.

My current workflow is to save the file in Virtual Dub, deinterlaced to 50 frames/sec, cropped and resized to 768x576 with square pixels. Then nothing can go wrong when I import it to other programs.

the pixel aspect ratio is 1.0926 which is apparently Vegas Pro's 4:3 aspect ratio for PAL.

I have seen that number elsewhere but I must admit I don't know a lot about the background to it.

1.0926 is the standard PAR for PAL 720x576 to be displayed as 4:3

1.4568 is the standard PAR for PAL 720x576 to be displayed as 16:9.

Both give images slightly wider than true 4:3 and 16:9.

Thank goodness we've nowadays with more modern formats moved away from stretched pixels.

@AAProds @johnebaker

Hi all,

Just to annoy me, or not, I plugged the Roxio into the Hub, it immediately made the connection song, and worked.

For the devices, I find the IOData GV-USB2 too expensive, the Startech is at or beyond the limit of what I want to spend. My choice, which I haven't ordered yet, was based on Amazon choice and the very high number or purchases. What to do?

At the very least, I'm ordering a head cleaning tape.

Back to the original problem raised by @RGBguy, I took a closer look now that I have this thing working. I found the same problem of resolution as per @RGBguy with my 352x240 capture. I reduced the Preview monitor to be about the same size as the monitor in the Video recording screen, put them side by side, and they look almost the same. That blurring in the details was gone. So, is it just the increase in size/resolution that is causing the problem? Is that what one would expect anyway?

Quality settings

Al, I assume that capturing to avi makes huge files. So capturing a 2 hour cassette is going to tax my hard drives, correct?

Like the OP, I'm on NTSC.

In VPX15, here are the choices:

Selecting AVI user defined, gives:

Note that there is no 720x480.

MXV DVD quality gives these choices:

Using 720x480 gives empty capture files and a message pops up to this effect.

Using 640x480 works fine. With the project at 720x480, the video automatically fills the screen. Checking SPR and clicking Original size changes to 640 wide with black bars, but the image looks squashed.

So, for NTSC, using mxv, I presume that the correct setting has to be 640x480. Is this correct?

Next, on the above screen, interlaced mode, Top field first by default. But, should I be using Interlaced or switch this to Progressive? I am assuming interlaced as the project is interlaced when choosing the NTSC settings. There is only 480i.

MPEG

I tried MPEG: DVD, the default is 720x480i 29.97. The details give bottom field first by default and accepting this gives a warning to switch to top field first. I tested both interlaced and progressive and the results looked the same, except for the first interlace test which had the frames all over the place.

The interesting thing is that the video proportions look correct on the screen. However, there are black bars top and bottom.

In SPR, I see that the clip is 720x426.7. So, I am totally lost as to what to do to get correct aspect ratio.

Finally, I put recordings at 352x240 and 640x480(automatically converted to 720) on the timeline and switching back and forth at about the same frames, I had trouble telling the difference. One frame on A would be good but not clear on B, but the reverse for the next frame, etc.

John CB

'owdo all, I'd just like to add my 2 penn'th to this.

@johnebaker said "however I would add, other recording formats, such as h.264 MP4, which applies compression to reduce the file size, are acceptable formats to use and do not suffer from the AR issue" and @ericlnz said "Thank goodness we've nowadays with more modern formats moved away from stretched pixels".

I couldn't agree more. After readings Al's (@AAProds) post in a previous topic I've adopted the deinterlace to 50 fps method with Virtualdub. The resulting AVI's suffer from the AR issue as has been noted here and so, as Al points out, resizing is required.

I found out almost by accident that the same job can be accomplished in Avidemux, as it has HuffYUV and UTVideo as codecs. Deinterlace with "dgbob" and select the double up frames option and the end result is the same as with Virtualdub - slightly quicker encoding I think. However the files still have the AR issue.

Now for the point to this post. Avidemux (well the current Beta version 2.8.2) allows the selection of Nvidia H.264 and HEVC as lossless - not to be confused with CRF 0 or CQ 0 - which is quite useful as I can save the file as an MP4 or MKV. No resizing is required, leave that MS2024 or whatever.

This produces a 720x576 file at 5:4 AR which obviously imports into MS2024 as a 5:4 video. Right click on the file in the timeline and select properties, video, change the aspect ratio to 4:3 and all becomes well with camera/zoom behaving itself as 4:3 (obviously assuming that the project is set at 4:3 😉).

AndyW

@browj2

That blurring in the details was gone.

John, the original issue was the washed-out look.

I assume that capturing to avi makes huge files. So capturing a 2 hour cassette is going to tax my hard drives, correct?

Depends on the AVI codec. You don't have any of the lossless codecs installed, only the "uncompressed" codecs. Install Lagarith and the bit rate will be about 35GB per hour.

So, for NTSC, using mxv, I presume that the correct setting has to be 640x480. Is this correct?

If you can capture at that, yes, that'd be great because that is true 4:3. 720x480 is a cludge.

But, should I be using Interlaced or switch this to Progressive?

The traditional wisdom is to capture Interlaced then deinterlace in post, but for MMS 2024 at least, Magix appears to have dumbed-down the deinterlacing so I would suggest trying Progressive. You really only need interlaced video for DVDs these days. It is harder on the computer to capture Progressive because the video's coming out of the dongle Interlaced, Top Filed First. But modern machines should be able to cope.

The interesting thing is that the video proportions look correct on the screen. However, there are black bars top and bottom.

Double check your movie setting: provided it's on 4:3, you shouldn't get black bars. Also check the "Ratio" under the droplist in your last image.

In SPR, I see that the clip is 720x426.7. So, I am totally lost as to what to do to get correct aspect ratio.

I think this is the bug I have been talking about. It always wants to apply the 5:4 ratio and will change the pixel size in SPR to match.

@browj2

Hi John

. . . . There is only 480i . . . . The details give bottom field first by default and accepting this gives a warning to switch to top field first. . . . .

This where things get really dumb.

As noted by the message for interlaced video this generalisation usually holds:

• NTSC (480i ) and Pal (576i) TV standards are TFF
   
• Cameras that record to mini (8mm?) tape cassettes are BFF
   
• Cameras that recorded to VHS-C, memory card or internal hard drive, record TFF.

Get the TFF/BFF conversions settings wrong and you end up with, to quote Al - frame salad

John EB

Greetings all,

I've just tried a very simple thing; I've only tried this for PAL.

In MS open a 4:3 SD project and add an AVI VHS file to the timeline (Al's [@AAProds] examples are ideal). Right click the video on the timeline and open properties / video / aspect ratio, type in 1.33 and click OK.

On my system that gives me a 4:3 picture that both section and camera/zoom respects.

AndyW

@AAProds @johnebaker

Hi,

Thanks for the info.

The Roxio just packed it in again. I noticed that it's getting warm. Oops, now it's working again.

I managed to get Roxio Easy VHS to DVD Plus installed and did a test. The choices are 16:9, 4:3. The export is to mpeg, 720x480. Importing this to VPX I see:

The proportions look right but notice that there are small black bars at the left and right, inside the frame of the image (SPR is on) as you had mentioned, Al, with your Lagarith file. So here I have another flavour. Also, the quality looks marginally better than the capture with VPX. Al, as you mentioned, one has to zoom in a bit to get rid of the bottom headswitching noise.

I guess that it's nice to have all the options in VPX, but it would be nice if there was one that would give the same result as Roxio. Maybe there is, but which one? The options in Roxio are 16:9 and 4:3 and it gives what I consider to be a good result.

John CB

@me_again

Right click the video on the timeline and open properties / video / aspect ratio, type in 1.33 and click OK.

On my system that gives me a 4:3 picture that both section and camera/zoom respects.

Andy's DA MAN! To be nominated for Magix Legend of the Year. What is it that JohnEBaker says, "lateral thinking gets thing done".

I won't ask why only 1.33 works and 1.333 doesn't (1.333 swaps back to 4:3), but it is a great workaround to the show-stopping framing bug (noting that 1.33 isn't technically correct; it should be 1.33 recurring, equating to 2.5 pixels across 768). I've added that to my bug report.

@browj2

John, all analogue recordings have those small side bars. It's part of the overscan area which you wouldn't see on an old CRT TV but we now do because of the nature of our current displays. The "active area' is apparently 704, but I have never come to grips with whether cropping them away and stretching back to 720, or simply overlaying the 4:3 Section crop box and cropping from all sides is correct.

I can't explain why Roxio appears to produce a better result than MXV: perhaps do an MPEG 2 export from VPX at the same bitrate to compare?

@AAProds

Hi Al.

Not strictly true about not being able to see the overscan area on an old CRT TV depending on how old the model of the TV set was. My parents had bought their first Black and white TV set years before I was born and had adjustable miniature cream coloured Bakelite potentiometers hidden under a spring loaded flap of similar material of their Bush TV set which was a floor standing model. I don't remember exactly how many potentiometers there were but you could individually adjust the spread of the beam for width, height, frequency and timing so as to compensate for the component value changes as parts either wore or changed value as the set components changed with the heat and humidity. There were other similar pots for contrast and brightness. You could increase or decrease the size of the image as well as the timing of the scan so as to prevent picture roll. The construction of the set was prior to the use of circuit boards and components were hard wired onto tabs in what was referred to as a Christmas tree arrangement. It was the reason there was a test card broadcast when there was no live broadcast in the days before 24/7 programming. You adjusted your picture when necessary so that the circle in the middle was a circle and not an oval and that you could see the individual vertical and horizontal lines without barrel distortion on the front curved surface of the screen and enlarge or shrink the size of the image so as to not see the sides or base of the scanning. If you did get those latter distortion problems you could call out the TV repair man to do a screen degaussing with a strong electric magnet.

By the time components got more stable those controls increasingly became moved to the rear of TV sets or put internally and only adjustable by use of a small flat headed screwdriver. My parents Bush TV set lasted well into the introduction of colour TV in the UK and they were one of the first adults in our immediate family to own a TV set, only beaten by one aunt an uncle who had a larger model with a smaller screen you had to view via projected image onto a mirror on the inside of a wooden lid which opened on the top of the unit and had to be viewed in a darkened room. Our set was much larger than this one and in a polished wooden casing and does show less but similar adjustable recessed controls at the front.

Ray.

@AAProds,

Thanks for providing the uncropped interlaced Lagarith sample. It allowed me to play with the video in VirtualDub, cropping the 2 black bars that are associated with every analog capture and bringing it into MMS 2024 and noting that even when cropped, the program squeezes the video creating black space/bars on the side. As you indicated, one needs to resize the video to 768x576 to create square pixels for the program to fill in the preview window.

A gold star 🌟goes to @me_again for his 1.33 workaround. Well done! 🙂 The two screen shots below demonstrate the black gap. I used the Object properties window to line up against the preview window to highlight the size of the black gap. The first screenshot shows the gap with aspect ratio at 4:3.

The second shot shows the gap eliminated when 1.33 is applied:

 As for Vegas Pro, I confirmed it does not have this issue. I again used the properties window to line up against the preview window. The first screenshot is of the uncropped video, so obviously the black bars are showing.

The second screenshot is of the cropped video; no back bar or gap.

Hopefully the development team addresses this issue along with the washout capture result as highlighted by the OP @RGBguy.

@CubeAce
That is a very cute TV! Thanks for the personal history lesson. Actually your old CRT is a good lead in to my next finding which I would like to share with you all.

@AAProds highlighted the fact that MMS has a problem with the 4:3 aspect ratio and I ask if other programs like Vegas Pro had this issue? I must admit this bug was a strange one and it led me down the rabbit hole of Vegas Pro. I came across this pixel aspect ratio of 1.0926. Where did this number come from I wondered?

Well I think I have the answer and it has all to do with @CubeAce's old CRT TV. The simple answer is CRT's don't have square pixels like modern computer screens and digital TVs; their pixels are more rectangle and for PAL its around 1.0926. Now I must emphasize that we are dealing with analog which is a wave form and not digital which are simple zeros and ones. Because analog is a wave, the numbers I'm going to use are a bit "wavy".

For the same height, a square is shorter in length than a rectangle. So if you have 720 rectangles lined up in a row and you want to chop them up into squares you end up with more squares.

For PAL, you actually end up with 720 x 1.0926 = 787 squares - lets make it 788 squares per row. And there is 576 rows of 788 squares per row. I'll come back to this number later.... 

There are three aspect ratios you need to know; DAR SAR and PAR. 

For PAL standard definition the following aspect ratios are as follows:

DAR - Display Aspect Ratio = 4:3

SAR - Storage aspect ratio = 720x576  (rectangles) 

PAR - Pixel Aspect Ratio = 1.0926 Some say its around 1.094 (see what I mean? - wavy)

These aspect ratios are related: DAR = SAR x PAR

But here is the important point; DAR (eg 4:3) is based on what you can visually see...

Of the 720, only 702 or 704 pixels are visible. The other 16 or 18 pixels are black. These are the 2 black bars on each side of the video making up around 8 to 9 pixels each. So to calculate DAR (eg 4:3) you do not include the black bars!

Because some say 702 and others say 704 pixels are visible, lets split it down the middle and use 703.

703 x 1.0926 = 768

768x576 is the square pixel 4:3 aspect ratio! 

This is the same square pixel aspect ratio @AAProds creates in VirtualDub before importing his old analog videos into MMS!

Now you are probably wondering; What about that row of 720 rectangles that were chopped up into 788 squares?

Remember, the 720 includes the two black bars. Each black bar is around 9 rectangle pixels so 9 x 1.0926 = 10 squares.

So take off 10 squares on each side of 788 squares and you end up with 768!

768x576 square pixel 4:3 aspect ratio.

All this math because @CubeAce's old TV had rectangle pixels... 🙂
 

Hi everyone

Going back to the original issue of washed out video,

If the recording device supports the different NTSC/PAL/SECAM options then it may be worth checking the alternatives.

I am in PAL territory and the various PAL options have subtle differences in the colour rendition of recordings, I would assume that NTSC is the same.

If you have the time, try recording short clips in each of the standard variants for your regional TV standard, to find the best result.

I went to test this a couple of days ago, dug out the VCR and dongle got everything setup went to get a tape - disaster - no ******* tapes. 😖😖😖😡

I must have disposed of them after digitising them over 10 years ago. 🙈🙈🙈

John EB

@Can-Dive

Sorry for causing a maths problem 🤣.

There were no pixels in a black and white CRT. Colour I suppose did with a mesh grid and a phosphorous layers ahead of it that glowed R,G or B when hit by the electrons. I suspect a few of those grids were not exact either. Quite impressive manufacturing for its day. I wonder if anyone ever bothered to VCR a test card? That may have proved useful.

So for the uninitiated like me at digitising VCR tapes, what is the conclusion on how to transfer such tapes using MMS/ or VPX?

Ray.

@CubeAce, @AAProds, @me_again

Hi

. . . . So for the uninitiated like me at digitising VCR tapes, what is the conclusion on how to transfer such tapes using MMS/ or VPX? . . . .

My advice would be either:

As I suggested above - play with the various settings, staying within the appropriate TV standard used by the VCR or camera, to see which gets the best results for your hardware combination and tape condition.

OR

Use Al's tried and tested method, with Andy's AR mod.

Nice one Andy 👍- never thought of doing it in that option, I do similar AR adjustment however in the project settings for video destined for Signal and WhatsApp,.

John EB