Capture file format and Vegas woes

[Bwaak]

Several years ago when I got into the whole analog video digitizing thing, I wanted to standardize on my tools. So, I chose VirtualDub2 for capturing because it is able to save into more containers and because it has native Cineform codec. I've worked a little with Cineform 15 or so years ago and heard only the best things about it. I wanted a hiqh-quality but reasonably sized format, and this seemed as a good choice.

My NLE is Vegas, I've been using it since Vegas 6. Currently have both Vegas 13 and 14 installed, with shady origins. So, I bought Vegas 18 and recently 19 finally to own a proper official product

I captured a bunch of footage into Cineform 10-bit via VirtualDub2. Then when I started editing it in Vegas 14, I started having issues. First it seemed that Vegas did not like reversed clips, so I removed those, patched my timeline and managed to generate a 6-minute video. But the latest case is Vegas throws an exception right from the start when I drop the first Cineform clip onto the timeline!

I tried Vegas 18, the proper official version, it is not certified for Win7, so some functionality is not available, but it throws the same exception, so I suppose it uses the same driver. Who is to blame? Magix or GoPro?

Ok, maybe I should use a different format then. What other high-quality intermediate codecs are there? DNxHD? Grass Valley HQ/HQX? ProRes?

I have FFMPEG ProRes available in VDub2, I haven't tried it. I have DNxHD installed, but VDub2 does not show it.

So, I tried Grass Valley HQX. Everything seemed nice, VDub2 can read and write it, Vegas can play it too, great! But then I noticed weird black frames at the end and the beginning of clips - no rhyme or reason, sometimes Vegas shows a black frame, other times not. I selected "Best" option in the project, this did not help. A black frame is very visible in a rendered video. Vegas 13, 14, 18 - does not matter.

Same with Grass Valley HQ.

Finally, I tried Lagarith. I had similar issues with it with Vegas 14 and 18, but not in 13 (fingers crossed!).

So far, I was able to edit a project in Vegas 13 using Lagarith clips, but this is stupid - newer versions should work better not worse. I was thinking of upgrading to Win11 and install Vegas 19, but not sure now.

What to do now with hours upon hours of Cineform videos I captured off 2-hour 8-mm cassettes? The only solution is to pick and choose scenes in VDub2 and render into Lagarith. I hope my friend who is on Mac, will have fewer issues with these clips, I asked him to test whether he's able to read them, and he can. Gee, just a decade ago Cineform and DNxHD were the standard codecs for moviemaking, and recently Apple has stopped supporting them.

Kinda makes me want to encode everything in DV But VDub2 generates DV that does not jive with Vegas, so this won't work. The only option is sending video through a Digital8 or DV camcorder.

Kinda makes the approach chosen by 12voltvids and the like sensible - at least AVC/MP4 is well supported across the board.

[rgr]

8bit: UTVideo (RGB, YUV)
10-16bit: ? maybe FFV1 (don't tried but don't expect problems)

Don't use lossless H264 because Vegas won't read it correctly (unfortunately!)

Maybe Win7 is the issue...

[creakndale]

This may not be relevant to modern GoPro files but back in the GoPro Hero 2 days (2012), I ran into a similar issue of trying to get GoPro files to work well with Vegas. After a bunch of trial and error, my solution was to load the GoPro file into the GoPro Cineform Studio program. I would trim the front and back end of the file in the Cineform program and export a high quality AVI, DV or MP4 file, not sure which one anymore. Then import that converted file into Vegas Movie Studio and edit at will. Quality was good and Vegas had no issues.

creakndale

[Bwaak]

Yeah... I planned to use Cineform all the way through until the final render. I guess since I still need to deinterlace it, I can do it in VDub, saving into something that Vegas likes, and so far the only combination I found was Lagarith dropped into Vegas 13 (but not in 14 nor in 18). Ugh.

[rgr]

Yeah... I planned to use Cineform all the way through until the final render. I guess since I still need to deinterlace it, I can do it in VDub, saving into something that Vegas likes, and so far the only combination I found was Lagarith dropped into Vegas 13 (but not in 14 nor in 18). Ugh.

I use Lagarith with versions 17, 18 and 19 and I think 21 too. No problem (Win10).

Vegas uses the Windows Lagarith codec for this, so there should be no problem with either version.

Use QTGMC to deinterlace in VDub, save to UTVideo RGB and load into Vegas.

[Bwaak]

I had noticed that ]Lagarith captures I make are full range, not "video" range. I thought this is how Vegas treated these files, but Sharc noticed it too. Cineform is ok. I wonder what I am doing wrong. I use AmarecTV, Lagarith was set to RGB, I switched it to YUY2, it did not help.

[poisondeathray]

I had noticed that ]Lagarith captures I make are full range, not "video" range. I thought this is how Vegas treated these files, but Sharc noticed it too. Cineform is ok. I wonder what I am doing wrong. I use AmarecTV, Lagarith was set to RGB, I switched it to YUY2, it did not help.

That's normal behaviour for vegas . Native video codecs like DV, HDV, AVCHD, garden variety variants of h264/mpeg2, cineform, prores, dnxhd/dnxhr etc... get "Studio Range RGB" treatment . It's analogous to "mapping" 0-255 YUV to 0-255 RGB

Everything else - such as "lossless" codecs - get "Computer Range RGB" treatment. That's analogous to "mapping" 16-235 Y to 0-255 RGB, and this has the potential for clipping 0-15, 235-255 in vegas . Once exception for common "lossless" codecs for use in vegas is if you use magicyuv with the full range yuv box enabled. If you select RGB with various codecs then the codec will perform the YUV to RGB conversion, usually limited range RGB 601 to full range RGB, possibly incorrectly (progressive chroma upsampling instead of interlaced), also with potential clipping

You can read about Studio Range RGB vs. Computer Range RGB in various vegas articles. Those concepts still apply to older versions of vegas. Newer Magix versions have the more versatility in the ability to work with either range and to interpret files

Cineform has been rock solid for me in multiple versions of vegas . Not sure why you're having problems

[Bwaak]

That's normal behaviour for vegas . Native video codecs like DV, HDV, AVCHD, garden variety variants of h264/mpeg2, cineform, prores, dnxhd/dnxhr etc... get "Studio Range RGB" treatment . It's analogous to "mapping" 0-255 YUV to 0-255 RGB Everything else - such as "lossless" codecs - get "Computer Range RGB" treatment.

After the @Sharc's message, it seems that this is not just Vegas's treatment, although I am not sure what tool he used to check the levels. Also, I tried switching Lagarith to YUY2 mode, but I still get full range.

[poisondeathray]

That's normal behaviour for vegas . Native video codecs like DV, HDV, AVCHD, garden variety variants of h264/mpeg2, cineform, prores, dnxhd/dnxhr etc... get "Studio Range RGB" treatment . It's analogous to "mapping" 0-255 YUV to 0-255 RGB Everything else - such as "lossless" codecs - get "Computer Range RGB" treatment.

After the @Sharc's message, it seems that this is not just Vegas's treatment, although I am not sure what tool he used to check the levels. Also, I tried switching Lagarith to YUY2 mode, but I still get full range.

I didn't look at the other thread's files. There might be other issues with your capture

But looking at your screenshot of the waveform within vegas, that's the expected behaviour for cineform vs. lagarith YUY2 or RGB. For lagarith in the YUY2 case, vegas does the conversion (if it was flagged correctly interlaced, vegas should get that part right). In the lagarith RGB case, lagarith does the conversion (progressive upsampling, Rec 601, limited range YUV to full range RGB)

For cineform, YUV 0-255 => RGB 0-255 . The correct terminology is the full range of YUV is converted to full range RGB. This is also known as "studio range RGB conversion" . This is how vegas handles typical files like DV, HDV, AVCHD, prores... etc... Nothing extra is clipped (beyond values that expected to be clipped in the RGB conversion)

In the lagarith screenshot Y 16-235 gets range expanded to RGB 0-255. The terminology is limited range Y to full range RGB. That's "computer range RGB conversion" in vegas terminology, but it's the standard conversion for computers

[Sharc]

@Bwaak: As you referenced me here, I like to clarify and add some comments:
The levels issue which I addressed in that other thread was not specific to Vegas.
The clips which you presented were SD in YUV 4:2:2, and the range (limited aka TV, or full aka PC) was not specified in the metadata. Inspecting the luma using Avisynth's histogram and waveform monitor indicated that the luma of those clips extended into the Y<16 and Y>235 range (sometimes the luma even got clipped at Y=0 or Y=255). An 8bit decoder which converts from YUV to RGB for the purpose of filtering or viewing will most likely assume limited range by default and apply the corresponding conversion matrix, which expands the video from TV (limited) to PC (full) range, rather than applying the studio matrix with its 1:1 luma mapping. This means that all YUV samples in the range of Y 0 ... 15 and 236....255 will become invalid out-of-range RGB with negative or >255 RGB values which will normally be clamped to 0 or 255. Means color distortions and loss of details in the brights and darks. Therefore my recommendation to revisit the capture levels adjusting the proc-amp settings, or set it right in post as far as the YUV are not clipped.
(I showed you an example in one of your earlier posts where you lost details in the brights. You may not have noticed it because what one doesn't see one often doesn't miss, and the losses may sometimes be subtle).