I am seeing some strange behaviour with HDV .m2t files in Vegas Pro 8.0c.
1. Length of 60i HDV
I have been capturing 1080-60i material with HDVsplit, trimming it as an m2t file on the 8.0a or 8.0b timeline with "quantize to frames" ON, and rendering it as an m2t file to my archive with "no recompress" ON.
Now when I grab a bunch of these files and dump them from Vegas explorer onto the 8.0c timeline in an HDV 1080-60i project, every now and then a 1-frame gap appears between the events instead of the files being butted up against each other. This happens apparently randomly after around 8-9% of the events, and its not always the same events each time (it depends on the combination of files being put on the timeline). It's as if Vegas thinks some files are 1 frame longer than it is displaying them as. If, at these gaps, I butt the later file up against the earlier file then the little rectangle appears over the events reporting an overlap of "0.00" and any event fades that I had set are deleted (note that I have automatic crossfades ON and "view > event fade lengths" ON). Vegas appears to think that I'm overlapping the events when in fact I'm (visually) not. Also the snap indicater line is dashed in this case, indicating that the snap point is not on a frame boundary, even though it is
(visually).
The problem can be fixed by trimming the earlier file in the timeline back by 1 frame, but it means every time I drop a bunch of files on the timeline I have to go through and check for gaps. And sometimes I don't want to have to trim the file by a frame.
Preferably it can also be fixed by dragging the end of the earlier event by a little to extend it, so that it loops, then dragging it back to its original length. Then the later event can be butted up against it with no problems. Even lengthening and shortening without even letting go of the mouse button will achieve this.
Alternatively the problem can be fixed by turning off "Quantize to frames" when dropping the files in the timeline, and then turning it on again. But I don't like doing that since a couple of times I forgot to turn it on again and really screwed up some big projects.
If I rename or move m2tsplug.dll so Vegas can't find it then all the files are read by mcplug.dll instead and there are no such problems gaps etc.. But doing that is not a viable solution in production since 8.0c still crashes when lots of mcplug.dll-decoded files are put on the timeline (the number has improved in 8.0c in my experience from around 30 files to around 76 files. Not the hundreds I would need).
I notice that when the files are read by mcplug.dll the (single) audio stream is invariably reported in the properties window as being longer than the video stream. Perhaps 8.0c is using that "invisible" longer audio length when it quantizes to frames?
There is no problem with 1080-50i material, and I'm pretty new to working with 60i, so maybe this problem has always happened(?). I don't think it was happening in 8.0b but I have a feeling it was happening in 8.0b when I installed that beta HDV reader dll file.
It seems to me that different components of Vegas are working to different levels of precision. Or they are rounding decimals in different ways. Perhaps Vegas doesn't truly render an exact number of frames with 1080-60i material when quantize to frames is on, or it just doesn't work to enough decimal places and then later that affects how "quantize to frames" handles the file. But trying to nail down a precise pattern to the problem just gives me a headache!
2. Extra HDV Streams
A second problem is that 8.0c is seeing all my HDV m2t files as having 2 audio streams. It's building a .sfk0 and a .sfk1 for each file, in addition to the .sfk that was there already from previous Vegas versions, and the active take information reads [Stream 2] on the audio event.
Perhaps problem 1 is related to problem 2?
Pics illustrating the problems are below.
I don't really want to go back to 8.0b because of the duplicate frames at the start of HDV files, which I have to remember to delete before starting editing.
Is anyone else getting these problems? Can anyone shed any light on causes or solutions?
Thanks!
1. Length of 60i HDV
I have been capturing 1080-60i material with HDVsplit, trimming it as an m2t file on the 8.0a or 8.0b timeline with "quantize to frames" ON, and rendering it as an m2t file to my archive with "no recompress" ON.
Now when I grab a bunch of these files and dump them from Vegas explorer onto the 8.0c timeline in an HDV 1080-60i project, every now and then a 1-frame gap appears between the events instead of the files being butted up against each other. This happens apparently randomly after around 8-9% of the events, and its not always the same events each time (it depends on the combination of files being put on the timeline). It's as if Vegas thinks some files are 1 frame longer than it is displaying them as. If, at these gaps, I butt the later file up against the earlier file then the little rectangle appears over the events reporting an overlap of "0.00" and any event fades that I had set are deleted (note that I have automatic crossfades ON and "view > event fade lengths" ON). Vegas appears to think that I'm overlapping the events when in fact I'm (visually) not. Also the snap indicater line is dashed in this case, indicating that the snap point is not on a frame boundary, even though it is
(visually).
The problem can be fixed by trimming the earlier file in the timeline back by 1 frame, but it means every time I drop a bunch of files on the timeline I have to go through and check for gaps. And sometimes I don't want to have to trim the file by a frame.
Preferably it can also be fixed by dragging the end of the earlier event by a little to extend it, so that it loops, then dragging it back to its original length. Then the later event can be butted up against it with no problems. Even lengthening and shortening without even letting go of the mouse button will achieve this.
Alternatively the problem can be fixed by turning off "Quantize to frames" when dropping the files in the timeline, and then turning it on again. But I don't like doing that since a couple of times I forgot to turn it on again and really screwed up some big projects.
If I rename or move m2tsplug.dll so Vegas can't find it then all the files are read by mcplug.dll instead and there are no such problems gaps etc.. But doing that is not a viable solution in production since 8.0c still crashes when lots of mcplug.dll-decoded files are put on the timeline (the number has improved in 8.0c in my experience from around 30 files to around 76 files. Not the hundreds I would need).
I notice that when the files are read by mcplug.dll the (single) audio stream is invariably reported in the properties window as being longer than the video stream. Perhaps 8.0c is using that "invisible" longer audio length when it quantizes to frames?
There is no problem with 1080-50i material, and I'm pretty new to working with 60i, so maybe this problem has always happened(?). I don't think it was happening in 8.0b but I have a feeling it was happening in 8.0b when I installed that beta HDV reader dll file.
It seems to me that different components of Vegas are working to different levels of precision. Or they are rounding decimals in different ways. Perhaps Vegas doesn't truly render an exact number of frames with 1080-60i material when quantize to frames is on, or it just doesn't work to enough decimal places and then later that affects how "quantize to frames" handles the file. But trying to nail down a precise pattern to the problem just gives me a headache!
2. Extra HDV Streams
A second problem is that 8.0c is seeing all my HDV m2t files as having 2 audio streams. It's building a .sfk0 and a .sfk1 for each file, in addition to the .sfk that was there already from previous Vegas versions, and the active take information reads [Stream 2] on the audio event.
Perhaps problem 1 is related to problem 2?
Pics illustrating the problems are below.
I don't really want to go back to 8.0b because of the duplicate frames at the start of HDV files, which I have to remember to delete before starting editing.
Is anyone else getting these problems? Can anyone shed any light on causes or solutions?
Thanks!