Vegas v9 "foreign" HDV file issue.

John_Cline wrote on 5/31/2009, 2:13 AM
I just completed a six-hour, four-camera HDV shoot. The fixed-position, "wide" camera files were captured live directly to a laptop using the Vegas HDV capture utility. I recorded to tape on the other three cameras and subsequently captured the tapes using the Vegas HDV capture utility. There were a few tape dropouts over the 18 tapes. v8.0c would show some blocking at the dropouts but continued to play, v9 would just freeze the video at the dropout. The video would stay frozen at the last good frame and the audio would continue to play. I ran all the files that were captured from tape through MPEG2REPAIR to "fix" the files and identify exactly where the dropouts were. (Beats having to watch 18 hours of video to find dropouts.)

Here's the kicker....

Vegas v8.0c will happily read all the files, both the "live" files and the tape captures run through MPEG2REPAIR.

Vegas v9-32 and v9-64 will see the video and audio from the files captured with Vegas, but only the video from the MPEG2REPAIR files. It doesn't see that audio at all.

I tried converting all the .M2T files to .MPG program streams using VideoReDo. Vegas v8.0c will still happily read the files. Vegas v9 will now see both the video and audio.


v8.0c will work with all the files regardless, no problem.

v9 will only work with the files which were either captured directly using Vegas or converted to MPG program streams. It will not recognize the audio on "foreign" M2T files.

This adds an extra conversion step to the workflow on this project. I'm going to have to look at the headers of the MPEG2REPAIR files and see why they won't load into v9. I need to use MPEG2REPAIR because v9 doesn't handle tape dropouts as "gracefully" as v8.0c. In the meantime, I guess I'm doing this project in v8.0c.


zstevek wrote on 5/31/2009, 5:44 AM

Was the "Fail on droped frames" button checked in the capture preferences when you tried capturing the tapes?
blink3times wrote on 5/31/2009, 6:19 AM
I wonder what would happen John if you tried HDVsplit? I always had better luck with that as long as I captured the tape as a whole then used the "scene split file" option that it has.
John_Cline wrote on 5/31/2009, 7:04 AM
All the tapes were one continuous take, so scene splitting was turned off.

It wasn't necessarily a matter of the tapes not capturing correctly, there were a few dropouts which were on the tape itself. I ran the files through MPEG2REPAIR which generates a log of what it finds and I used it mainly to identify any potential problems in the 18 hours of tapes. This just led me to the realization that v9 doesn't like M2T files that weren't either captured with Vegas or rendered from Vegas. Vegas v8 would always load them no problem regardless of which application generated them. I'm not sure how v9 will handle files captured with HDVsplit. I'll run that experiment and see. Based on what I've seen with the other files, it wouldn't surprise me if it didn't like them.

Vegas v9 also freezes video playback (while the audio continues) when it encounters the least little wierdness in the file, v8 would just get blocky for a moment and move on. This behavior happens on previews and renders. Something has changed with the way Vegas v9 reads M2T files, it is a LOT more picky about them than it used to be.
Laurence wrote on 5/31/2009, 7:11 AM
Well the main thing the MPEG2REPAIR does is to rewrite the header so the older mpeg2 read engine is used. It really doesn't do much of anything (as far as I can tell) on the mpeg2 data itself. If Vegas 9 is still crashing on these clips, it is likely related to it's using a new mpeg2 reader regardless of what the header says.

My favorite solution to this is to shoot to CF card instead of tape where the errors don't occur in the first place.

My second favorite solution is that if you absolutely have to use tape, that you turn off virus protection and any other background apps and capture with HDVSplit with the video preview turned off. This minimizes these errors and in many cases gets rid of them entirely. Any clips that still have these errors you can rerender into either Cineform or XDCAM mfx format using Vegas 8 after fixing with MPG2REPAIR or with Vegas 7d without doing the "repair" step. I don't believe that most of these errors or actually on the tape. They are generated during capture as your virus checker interrupts capture occasionally just to make sure you don't have any viruses on the tape.

If you don't believe me about MPG2REPAIR merely rewriting the header, here's the little experiment that proved this to me:

Fix an offending clip with MPG2REPAIR. Smartrender it into a new mpeg2 clip. Try reading the smartrendered clip in Vegas 8. Notice that it will crash exactly like it did before it was "fixed". That is why you should NEVER smartrender a repaired mpeg2 clip. MPG2REPAIR is a handy utility that will get you out of a jam when faced with unreadable footage, but be fooled into thinking that it is doing more than it actually is. Ditto for MPEGVCR and MPEG Wizard from
John_Cline wrote on 5/31/2009, 8:20 AM
The few errors were actually on the tape, you can see them on the camera's LCD monitor during playback. As for virus checking, I don't use it on the production machine, so that isn't a factor.

MPEG2REPAIR does more than just rewrite the header. Regardless of what MPEG2REPAIR is doing or not doing, the fact remains that Vegas v9 is no longer able to read some "foreign" M2T files that v8 cheerfully used. This is inconvenient.
Terry Esslinger wrote on 5/31/2009, 8:49 AM
Using V8c and HDV.
I hahve had what I assume are dropouts (correct me if I am wrong) that will occur. On a 60 minute continuously acquired (no pausing) tape (of a play) there may be 3-4 spots that the video freezes, the sound continues, and then the video starts again after maybe a 1/2 second freeze. At first I thought it was a problem with the Vegas capture but I noticed the same thing watching the tape back on the camera, so it is on the tape. (Sony Premium). When I acquire directly onto a laptop using Vegas capture (no tape) I do not get the defects.. This would lead me to believe that the problem is either with the tape itself or with the recording process on the tape in the camera (record head?) I'm not sure how to make a delineation between thoise two causes.

Does this sound like what is happening with your footage?

My problem shows up in 8c - do not have 9 yet (or maybe ever)!

Would MPEG2REPAIR be of any use in my case. It can't really 'fix' the drop out which is a physical defect- can it?

Not quite an answer to your problem but along the same general lines. I hope not too far OT.
John_Cline wrote on 5/31/2009, 3:46 PM
99% of the time, I record straight to a laptop and tape dropouts are not a concern. On this project, I had to roll tape in three of the four cameras. One part of this thead is about how v8 and v9 handle the dropouts differently and the other part of the thread is about how v9 won't load files which v8 would.

Due to the nature of Long-GOP HDV recording, if a single dropout does occur on an HDV tape, the image may just get momentarily blocky or it may freeze for up to 15 frames. This is simply the nature of the beast. v8 and v9 seem to deal with it differently as far as playback and rendering is concerned, whereas v8 would recover from the error pretty quickly, v9 will freeze the video and stay frozen for minutes at a time while the audio continues to play. It's one thing to have the image break up for a frame or two, it's entirely another to have it freeze up for minutes at a time.

No, MPEG2REPAIR can't fix a tape dropout. The structure of a Transport Stream, as either an HDV file or a captured broadcast file, is much more complex than a Program Stream. All MPEG2REPAIR does is to make sure that the stream parameters are correct and continuous. It repairs the file's structure not the audio and video data contained within the structure.

There seem to be two primary differences between v8 and v9 regarding HDV transport streams; v9 seems to be much more "selective" about the M2T files that it will deem acceptable and load, if the file wasn't generated from or captured by Vegas, it may not recognize and load the audio stream. The other problem is how "gracefully" it handles GOP errors.

Laurence wrote on 5/31/2009, 4:36 PM
On a similar vein, I'm looking at a possible month long doc shoot in Africa in August. I'm seriously thinking about buying enough CF cards to handle four weeks of shooting without using tape at all. Transcend 32GB CF cards are just under a hundred dollars each at

Yeah it would be nice to just use tape on this sort of shoot, and that is why I bought the Z7 instead of the EX1: so that I could use tapes on extended shoots. The problem is that HDV on tape is nowhere near as reliable as is to CF card. I have tried the high end Sony "master quality" HDV tapes, I've tried regular Sony DV tapes, I've tried the ones in between. There is no difference that I can see whatsoever. None of them are reliable. Yeah you'll get most of your footage, but you are going to have problems. Going to tape is fine if you are going to downconvert on capture, or if you don't mind loosing an occasional bit of footage, but it is simply too unreliable to depend on for HD footage at least IMHO.

CF card is absolutely solid if you have the right cards. Some expensive Kingston Memory ones didn't cut it (which sort of annoyed me since Kingston is my last name). Inexpensive Transcend ones are just awesome.
jabloomf1230 wrote on 5/31/2009, 4:51 PM

Don't you have Cineform NEO Scene? Does NEO Scene give you the capture option of saving both the CFHD AVI and the m2t file? BTW, Vegas 9 opens the mt2 files from HDLink (I have Prospect HD) fine.

Laurence wrote on 5/31/2009, 5:47 PM
Yeah I have Neo Scene. Sometimes Neo will power through HDV tape errors. Other times it won't.
jrazz wrote on 5/31/2009, 6:04 PM
I find this strange Laurence. I may have had 3 issues I noticed while filming in HDV with all four of my HVR-A1u's and HC1's. I have always used Panasonic PQ tapes- either 63 or 83 minute ones depending on what I am filming. I think I have cleaned the heads on one of them once and I bought my first two when they first came out.

Am I just not as observant? Some of the shoots I do are 3 or 4 cam multicam shoots. I don't remember the last time I had dropped frames upon capture.

j razz
Laurence wrote on 5/31/2009, 6:11 PM
I've only ever used Sony tapes. I have been told that Sony tapes use a wet lubricant while every other brand uses a dry lubricant and that mixing wet and dry lubricated tapes is bad for your camera. Maybe I should switch brands.

My problem isn't drop-outs. It's Vegas crashing errors that will just stop you in your tracks. Im talking about errors where you need to hard reboot your computer, or where Vegas suddenly disappears in the middle of writing the audio waveforms before your first preview. Usually when I finally salvage the clips through a combination of MPG2Repair and a Vegas rerender into Cineform format, there are no drop-outs and the video itself is just fine.

Anyone else have tapes that they are happy with? I have had problems with the complete line of Sony tapes but have never tried any other brand in either of my HDV cameras.
jrazz wrote on 5/31/2009, 6:19 PM
True- the tapes do use different lubes. Even the Master Panasonic and the Professional Panasonic tapes use different forms of lube. I contacted Panasonic at some point (I posted it on this forum but it was years ago) to ask about the lubes on their tapes as I was thinking about going to the master tapes from the pq's.

If you are going to switch, run a head cleaner through the cam before doing so so your heads don't gunk up. This is where I get mine from: The Tape Company

j razz
farss wrote on 5/31/2009, 7:34 PM
We sell Sony tapes plus I've shot a fair amount of footage onto Sony's cheapest tapes. I've only noticed one problem. I'd seriously get your camera looked at, there's got to be something remiss with the camera for you to be having that much grief.
I should mention that ALL my HDV, DVCAM and DV footage is captured using the HVR-M15P VCR although I doubt that's a big factor.
I just finished capturing 2 hours of client's footage from their A1 camera. No problems apart from Vegas's capture splitting both tapes into 3 clips. Given what this client has done I'm not surprised. Then again I've captured 3.5 hours (large format tape in M15P) of HDV and Vegas only split it into 2 parts, that's understandable too. There was a major power surge and I was running off mains power.

All my work is done in V8.0b.

If you want uber reliable CF cards try the Hoodman RAW ones. For once the hype might have substance, they are expensive though. Regardless, you have a problem. I would not be heading off to a foreign country with dodgy kit anymore than I'd leave home without a passport.

Laurence wrote on 5/31/2009, 8:14 PM
I am pretty frustrated, but I don't think it is the camera because I have the same problem with two different models: an HVR-A1 and and HVR-A7. It could be the computer, but I am in no position to buy a third computer: Computer 1 is a P4 3.06 with Windows XP which is probably underpowered for HDV, and computer 2 is a Core2Duo with Vista 64 which refuses to capture HDV from tape as is mentioned in[/link] thread.

Video shot to inexpensive Transcend CF card is rock solid. The only problem is what to do on a four week extended shoot.
farss wrote on 5/31/2009, 11:14 PM
Mt old P4 captured HDV as well as my other PCs. In theory if it captures DV OK it should do fine with HDV as it's the same datarate.
The only difference is the CPU has to work a bit harder to decode the A/V for the preview.
What seems to be causing you're grief are correctable errors on the tape. From what I've seen the cameras do not do any error correction on the data they send out over firewire. I've never seen any partial dropouts watching hours of HDV that way. I've seen plenty of uncorrectable errors where you can a frozen frame for 1/2 second.

The question then is why is Vegas having problems with these or more to the point why is your system AND Vegas having such a problem. Have you tried going back to V8.0b, it seems pretty solid to me which is why I'm sticking to it.