Count me in.

Darren and GS,

Go up this thread to the last message from the Forum Administrator, there are download and install instructions for the new .dll.

John

image to show the color problem with new plugin:

old:
http://img244.imageshack.us/img244/460/oldsx2.jpg

new:
http://img154.imageshack.us/img154/2694/newsg0.jpg

edit: the plugin from dvdarchitect 5 also shows the same problem.

Yeh bummer,

tried the new .dll and still can't render ...

tried a couple of different 10 minute segments and I get the same
old same old ... renders to 19% then 'sorry for the inconvenience' ...

or ... simply gives an exception.

Bob (Farss) has checked my project here at my office ...and he seemed to think it was fine in terms of structure etc ... ie: I'm not doing anything really really dumb ...

Anyway, Bob is convinced that it's m2t errors on capture etc ... I hope I don't have to totally recapture my project using this new reader
thingo ...

What do you reckon DH ... is Version 8.0 ever going to be stable?

Cheers,

Darren Powell
Sydney Australia

Darren,

It might be worth a shot to try MPEG2REPAIR, a free program that will scan .M2T files for errors and, optionally, fix them. Run it on your suspect files and then replace the media in your project with the repaired files. It will also generate a log to tell you what it found and what it fixed. If it works for you, it will be much easier than capturing your files again.

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

Version 8 is very stable for me, I produce hours and hours and hours of HDV stuff and have never had a problem that I could attribute to Vegas. Occasionally though, I have had a "strange" capture and it's usually some sort of tape instability. I've had HDV files get wonky capturing with both Vegas Vidcap and HDVSplit. All things considered, HDV is a lot more fragile than DV. MPEG2REPAIR has saved my butt on more than one occasion.

"All things considered, HDV is a lot more fragile than DV."

Sorry but that's simply wrong. HDV is more robust than DV.

From Sony themselves:

"By changing the error correction method from error correction within a track, as specified in the DV-SD format, to error correction among multiple tracks, the HDV format offers improved error correction capability and enhanced resistance to lost data caused by dropout"

My own observations would backup Sony's claim as well. I see way, less problems with playback of HDV than DV and I'm talking about tapes from cameras that have been to hell and back and tapes that have taken a pounding. Our test tapes get threaded and unthreaded many times per day, five days a week, spooled back and forwards and replaced about once per year. They're not the expensive Sony "HDV" tapes either.

It's not HDV that's in question, it's Vegas's ability to handle errors that the cameras and VCRs are more than capable of correcting. Attempting to shift the blame to the HDV format is plain dumb, if there was such a major problem with the design of HDV the outcry would be deafening.

Furthermore, if some 3rd party shareware software is capable of correcting these errors it does beg the question of why can't Vegas. We shouldn't be having to jump through hoops to get a tape captured and edited.

Bob.

Well, Bob, you and I have had different experiences with HDV. It is my opinion that long-GOP intra-frame MPEG2 editing is technically more difficult and potentially less reliable than inter-frame DV-SD editing. (Although the new beta HDV reader .DLL is a big improvment.) In the literally thousands of hours of DV I've edited over the years, I only had one noticable dropout, I have had perhaps half-a-dozen with HDV in just the last few years. (Most of them using the expensive Sony HDV tape.) These errors were visible on the camera during playback, so it's not like they were corrected by the camera and then somehow got scrambled by Vegas.

Sony only claims "enhanced resistance" to dropouts. If it weren't for extending error correction across multiple tracks, HDV probably wouldn't work at all.

If an error is under the threshold of the error correction's capabilities, it will be perfectly corrected. If it's above a certain threshold, it will be "concealed" with an "educated guess" on the part of the error correction algorithm. If it exceeds the ability of the algorithm to either correct or conceal it, then it will glitch and this glitch can last up to 15 frames instead of one frame or maybe two frames with a DV dropout.

Now I do agree with you. When the capability of the error correction mechanism is exceeded the results are worse than they are with DV. In fact all digital system degrade less gracefully than analogue. And yes, it gets much worse with HDV. Yes I've seen the classic uncorrectable errors with HDV, a freeze for upto 15 frames. And yet on the same grade tapes and cameras we'd see DV dropouts all the time. In fact one of the better known experts on DV once claimed it's unlikely to get any DV tape that's dropout free. Never tested that theory myself but I've sure seen plenty of them and very few people notice the tiny glitches in the audio, whenever I can I record SD in DVCAM.

And yes, HDV is harder to edit, any long GOP system is harder to edit. That some NLEs don't edit native HDV is hardly surprising.

But that's irrelevant. Vegas Pro 8 makes certain claims, including native HDV editing. Either it lives up to what it claims it can do or it doesn't. The thing is software shouldn't crash because of errors in the data it's reading, that's software 101 stuff. Even if we accept your argument that HDV is more fragile then what, if you know that I'd hope SCS knew that as well, if they didn't then Vegas is really in dire straights.

Bob.

I capture probably 95% of my HDV live on location from the camera via Firewire directly to a laptop using Vegas Vidcap. Vegas has never failed to read an HDV file captured live to hard disk in this manner.

Now that you mention it, I'd really like to see a camera and deck that recorded HDV to tape with DVCAM's track pitch and speed using the large DVCAM tapes. This won't happen though, tape seems to be on its way out.

This has been an interesting discussion but, now back to our regularly scheduled thread, already in progress...

With Mini-DV, using Sony EX tape (only - I NEVER mixed brands), with careful viewing, I would see a small partial-frame correction maybe once every 5 or 6 tapes (in 300+ tapes). With HDV with the same tape, I see the 1/2 second image freeze once or twice about every 1 or 2 tapes (also EX). I have not yet gotten into my supply of Sony HDV-specific tape. As for editing HDV, it has been a nightmare for me (see www.donferrario.com/ruether/hdv-editing.htm, the Vegas section, for the details). With the help of several people on the rec.video.production and rec.video.desktop NGs and some research here, I was able to (I think....) finally escape the "red/black" problem, but then two more problems appeared I had never heard of. When files were made of changed footage and transitions and then returned to the timeline (to avoid the problem of a bad frame somewhere in the render causing Vegas to crash at video output to tape), playing the clips would often reveal a bad frame and the program would promptly crash. On the next making and importing of the clip, all would be fine(!). I figured this was a cludgy way to need to edit, but whatever works... But, I discovered that when scrubbing the new clips frame by frame, there would often be a duplicated frame near the beginning of the clips. What is odd is that the new clip would fit perfectly over the edited source material on the timeline and be frame-accurate at both ends, and the same thing would STILL be true, illogical as that seems, when I rolled back the front of the clip past the duplicated frame! I hope the new .dll solves all of this, since I really like Pro-8 (except for all the grief it has caused me...).
When this edit is completed and out to tape, I will eagerly try the new .dll with this footage to see if these last two problems go away.
--DR

Just an FYI for everyone, after installing the new DLL, I am now able to read and edit Panasonic SD9 file. This is most excellent, thanks Sony!

Joe

The new DLL seems to be good and bad news for me......

The good news - VP8 will now happily open MPEG2 transport stream files created by other applications (like VideoRedo) from HDV captures - with the old m2tsplug.dll VP8 would either take a long time to open them (short files) or just silently give up trying to load them (long files).

The bad news - I have an HDV .m2t file captured with VP8b with a corrupt section (approx 1 second of video corruption) a few seconds in from the start. With the new dll, on the timeline this shows 'flatlined' - silent - audio for 4 minutes after the corrupted section, and the video freezes for about 10 seconds when previewed. With the old dll it opens using the MC codec instead - mcplug.dll, so presumably it's been rejected by m2tsplug.dll - and plays/shows on the timeline OK (apart from the expected brief video corruption near the start). If I process the file through VideoRedo, it plays OK (with expected minor corruption) in VP8 with the new dll - presumably because the header/timestamp corruption has been fixed.

So the new m2tsplug.dll is an improvement, but it still isn't as good as it needs to be when handling corrupted MPEG streams - the MC codec in VP8 has much better error handling....

Tony

i echo jc's recommendation of mpeg2repair. i had one particularly bad 'point' / 'error' on a capture that crashed 8b every time - sony agreed it was completely replicable. ran it through m2repair, played fine....

with new dll the original now plays happily.

leslie

I have confirmed malowz's discovery.

The new plug-in does not work correctly with Sony XDCAM HD MXF files.

I am getting the same color shift that malowz got as shown in his posted images.

The vectorscope shows that my phase appears to be rotated 5 degrees clockwise from where it was (correctly) with the old dll. Luma values have also changed with the new dll.

I also discovered something else, a problem in the preview with the new dll. I am working with XDCAM HD MXF footage in a DV Widescreen project at Preview>Auto quality. The playback looks normal with the old dll in terms of the edges of moving objects. With the new dll and nothing else changing, the edges of moving objects show large aliasing on their edges that is not there with the old dll.

@ScorpioProd

i think Houston is very busy right now.. ;)

what LOOKS like:

the "Preview>Auto" looks like the new one is doing a field blending to get both fields on interlaced material/project

BUT

"Preview>Auto" on progressive material/project looks now its doing "field discarding", getting only half of fields.

i believe they got "swapped" on the decoder. it doing the inverse as it should, to get a sharper/non-aliased image on interlaced and progressive using "preview-auto"

correct for interlaced:
discard field > resize

correct for progressive:
resize.

i hope they fix it before 8.0c...

Maybe change the subject lines of your posts to "PROBLEM" to stand out in this thread?

Rob

(Edit...Guess I should have done it too)

Good idea - I've updated the title of my post above...

Tony

Seemed like a good idea... :-)

@rmack350

oh yah! ;)

I capture with HDVSplit and previously with 8.0b I was getting 2 "frozen" repeat frames at the start of all my clips, which I had to remove using the "TrimCapturedClips" script. With this new reader I am not getting those repeat frames. So that is a nice improvement for me!

Yet to test a big project render.

sorry i accidently started a new post to report that the new DLL fix works for me.

BUT IT WORKS!!! whoo hoo!!!! I was just about to deliver my first HD wedding job that had black frames in it but rerendered the video and burned a new BRD for the client and they will never know!

Thanks for solving this problem SCS. Bullocks to all the SCS haters out there.

thanks for this tip regarding MPEG2Repair, what a great piece of freeware. I installed it and ran my current project through it and was able to fix things that I didnt know were lurking under the surface before it was too late.

thanks for sharing John_Cline !!!