i have to say that as much as i love vegas, and have recommended it wholeheartedly to all my students in the past (since ver 4), if this bug isn't fixed pretty damn soon, i'll simply have to jump to.... well, i wish i knew, pp2 perhaps?
Do a search of the forum for "black frame," and you will find many recent posts on the subject. I believe it happens with M2T footage and, as Spot mentions, may depend on the hardware being used.
As I've mentioned in the past, I work in HDV (m2t) and DV proxy via GearShift. In my most recent 2 1/2 hour project, I had about 5 blackframe issues at various points. Not that huge a deal going back to the master and replacing the offending clips, but what was maddening was that doing so would sometimes fix the issue, and sometimes not. Or the issue would be fixed for a while but the next time I went to render, black frames would be back in exactly the same locations. The picons representing the black frames on the timeline appeared normal, but appeared as two adjacent black frames on the Preview window and in the render. No correlation with location within a clip as far as I can tell.
HDV tape pulled in via HDVSplit, GearShifted into DV proxy, edit with proxy (black frames on m2t source), AMD 3800x2 system, very stable platform and no other Vegas7c issues.
The absolute worst thing about working with Vegas is that ridiculous two black frame bug. I just hate it.
Using a Sony-HC3.
I have encountered black frames using VMS7_Platinum. Sometimes a black frame can crash VMS7. I found that this occurs more using HDVSplit to capture with compared to VMS.
But, either way after removing the 2 black frames and rendering to a new TS.m2t file and many times to the cineformhd codec I never have any problems with the new ts.m2t file. I delete the original file because it has the black frames which to me is corruption in the file. Maybe an incomplete GOP, the black frames I've encountered usually are where I've had a bad spot on the tape or at the end of video when using HDVsplit to capture. When using HDVSplit to capture with scene detection on the black frames are at the end of a few split files.
At least on my system I think it's some small corruption in the ts.m2t file. I've edited enough mpeg2 video to be aware that a small amount of corruption will yield different results, dependant on the editior, user, project settings and computer system . It's mpeg2 video, I would remove the black frames and convert to cineformhd, render a new ts.m2t file or render the original to a new ts.m2t file.
Then start editing with this new file that Vegas has produced, delete the original.
Posted this because someone mentioned that the latest release is crashing with their ts.m2t files and they have reverted to a previous release. Maybe the crashing is small corruption in the ts.m2t file.
So basically my question is are you sure it's the program, or possilbly an incomplete GOP in the TS mpeg stream. I'm curious when I stop a recording (not pausing) and start a new recording on the tape how the mpeg2 file gets appended on the tape. This is mpeg2 recording with long GOP's as compared to DV frame accurate recording. Surely the last GOP of the preceding recording must be truncated to start a new recording? I don't know. But, depending on how the video is captured from tape this spot on the tape (where the recordings are appended to each other) is where I seem to encounter the blank frames.
Soon I plan to upgrade from my full VMS7_Plat & purchase either Vegas7 or 8. Right now I'm using the trial version of 7.0e. Main reason for upgrading is more rendering selections and separate audio tracks in DVDA.
m2t native phenomena I think is related to the fixed length of the GOP using I-frames. The Sony GOP 10 frame structure for the camera encoder is probably the source of the problem when its generating null I-frames,( not that Sony is incorrectly executing the M2t guidelines). The M2T decoders used by Vegas 7 now are using some of the video hardware( I think), and I think the null I-frames handlers are screwing up, thinking the null frame is an actual new frame. SInce there is no I-frame data buffer to merge with the previous frame, the coding jumps to the next I-frame, basically returning a blank frame.