Thanks Bob.

I tried something. I loaded the clip in 8.0b on my test PC witout the new .dll file, and it loaded fine. There was one or 2 black frames though at playback.

Then I installed the .dll and tried to import the same clip, and it froze again at 31%. So with either .dll I am stuck one way or the other.

I actually uploaded the 64 MB clip here if anybody would like to try it:

http://www.webbroadcast.dk/sony/test.m2t

Actually I was going to edit my peice in 7.0d until 8.0C comes out, but I got one place with a black frame or 2 ;-) - ironical.

I have played back the whole tape in another NLE without any probs at all, but I would like to edit this one in Vegas, and I hope to do so anyway with Bob's surgestion to render to another codec.

/Ulf


PS. I have mailed sony and put this info in the HDV-thread too.

Try running the clip through this piece of freeware:

http://www.videohelp.com/tools/mpeg2repair

I ran your clip through MPEG2REPAIR and this is what it reported:

------------------------------------
MPEG2Repair: test.m2t

Sequence Frame 383(10-B) / Time 0:00:15 :
VideoWarning: Discontinuity of (4+) packet(s). First packet ending at offset 52931024

Sequence Frame 390(8-P) / Time 0:00:16 :
VideoWarning: Discontinuity of (10+) packet(s). First packet ending at offset 53779280

Sequence Frame 396(10-B) / Time 0:00:16 :
VideoWarning: TemporalRef gap of 1012. Timestamp gap of 0.960000 sec. ending at file offset 53205916

Sequence Frame 459(5-P) / Time 0:00:19 :
VideoError: Invalid Huffman code in non-intra MPEG2 block. MBA=1137(912,192)
VideoError: Failed to decode macroblock at MBA=1137(912,192)
VideoError: Missing 4984 macroblocks in picture slice(s) at MBA=1136(896,192).
FileInfo: Last video errors span 61 bytes at file offset 63143875

Sequence Frame 460(5-P) / Time 0:00:19 :
Info: End of MPEG2 sequence

Sequence Summary:

File Size Processed: 60.22 MB, Play Time: 00h:00m:19s
1440 x 1080, 25.00 fps, 25.00 Mbps (23.79 Mbps Average).
Average Video Quality: 121.95 KB/Frame, 0.64 Bits/Pixel.
MPEG Audio.
1 of 460 video frames found with errors.
0 of 0 audio frames found with errors.
61 corrupted video bytes in file.
0.960000 seconds of video timestamp gaps.
0.000000 seconds of audio timestamp gaps.

End of Log

Just about everywhere I look users are having these kinds of issues, Ppro and FCP is having much the same issues possibly, even recording to CF cards in the Z7 is not immune to causing grief in post and yet the camera can play them back no drama. I see the same thing playing back HDV tapes. Worst case I get the classic frozen frame for the GOP duration.

Seems to me that all NLE vendors meed to put more work into this issue. If MPEG2REPAIR can wrangle the problem clearly it's doable or at least manageable without causing crashes. If there's not enough CPU power to handle the error correction during capture maybe we need something like the dropped frame warning and another non realtime utility to repair the captured file before we try putting it onto the T/L. This option really appeals to me as it seems the code to do the repair is fairly CPU intensive so better to fix it once rather than everytime the clip is accessed.

Bob.

Thanks for your time, Bob and John...

Great little util, John. Looked for it yesterday, but didn't remember it's name - great you reminded me; it fixed it :-)

/Ulf

I tried to load the test.m2t file into Vegas and it did indeed freeze at 31% while building the peaks. I ran it through MPEG2REPAIR and it loaded fine. However, there were a few frames at the end of the repaired file which had some glitches in the image. While MPEG2REPAIR can fix the structure of the file, it can't actually fix badly damaged data contained within the file. It's always a good idea to look at the log it generates and then go to those parts of the file to see if the image is so damaged that it is visually unusable.

I agree with Bob that maybe we need to have a warning pop up that all is not right with the file, but I certainly don't want Vegas to be able to load a file that is damaged and then pretend that nothing is wrong. In the absence of some sort of warning, I think I prefer that Vegas just doesn't load the file, although I wish it went about this a little more gracefully than just locking up,

...and another non realtime utility to repair the captured file before we try putting it onto the T/L.

Exactly, that would be great. Some kind of validation tool or wahtever you should call it. Like defraging your HDD: 'automaticly fix errors' could be on/off.

If this error correction was seen as part of the whole process, it would nok look like an error correction but more like a 'prepare' or 'defrag' or something. Maybe some NLE manufactors would have problems in making a workflow that first causes an error and then seconds later runs a fix-util ti fix that error, but if the workflow was 'sold' as a whole package included int he capture tool f.ex. it would not be that bad I think.

/Ulf

"Exactly, that would be great. Some kind of validation tool or whatever you should call it. Like defraging your HDD: 'automaticly fix errors' could be on/off.

That's exactly what MPEG2REPAIR is!

Like I said earlier, I don't want any utility to just repair the file if it's just fixing the structure without fixing the actual data 100%. Sometimes, this just can't be done.

I don't want any utility to just repair the file if it's just fixing the structure without fixing the actual data 100%

I see your point, John - of course not.

As more and more people are using some kind of HD / HDV / AVCHD material, it will probably get more attention, I hope.

/Ulf