The memory bandwidth/clock speed thing is sounding appealing as a culprit. It's what my dear old programmer/engineer father would call a "timing issue".

Seems like with 4 cores working and trying to write to memory that you'd need a good and fast memory controller as well as good memory. Even though they're slower, all the modern AMD CPUs have an onboard memory controller and a faster bus to RAM than Intel can currently provide.

Seriously, though, most people buying dual cores or quads for Vegas will buy Intel CPUs so it's no surprise that problem reports seem to mostly be on Intel systems.

I had also read a passing comment somewhere on the web about how a system with four dimm slots populated would be more error prone than just two slots-timing errors again. Don't know why, take it as a faint whiff of a clue.

The other way of looking at it would be that Vegas isn't doing a good job of putting things in memory and making sure they really arrived there.

Rob

Thanks for the clip.
This is the same problem that Darren showed me!
Indeed this looks exactly like a corrupted mpeg-2 stream and yes David has hit the nail on the head, it would have come from a tape dropout.
EXCEPT!

This is supposed to NEVER happen with HDV. One of two things should happen:

a) The error gets corrected. HDV makes use of significantly more error correction than DV and for good reason, dropouts cause very ugly artifacts like that. Watch DVB OTA broadcasts and you'll see these same artifacts, yuck!

b) The error is uncorrectable. The decoding system duplicates the last known good frame. Seems the standard outcome of that with HDV is a frozen frame for an entire GOP i.e. 15 frames.

It's curious that others are having very little grief with V8 and HDV. Ushere (Leslie) is one and he's using a M15 VCR to capture. I've had very few problems too and I too don't use a camera as a VCR.

I'd be interested to see what happens if you capture the clip and then convert it to CF or some other codec using Vegas.

Bob.

rmack350 said:

"...a system with four dimm slots populated would be more error prone than just two slots-timing errors again..."

All four slots on my AM2 GigaByte Mobo are filled with PC6400 Corsair XMS Dual Channel ram @ 4x1gb. I wonder if ECC RAM would make a difference???

So one of two things - FCP, Avid - even Adobe to a certain extent, have pretty strong cases that support specific hardware that will run their apps as flawlessly as possible - is this the Achilles heel of Vegas since it is suppose to be pretty hardware neutral? I'm almost wondering if the kinds of hardware being released now for handling the editing process is moving faster than software can keep up - and vendors like Apple and Avid - being more conservative in their release cycles - now seem to have a valid point for doing it their way.

farrs said:

"...This is supposed to NEVER happen with HDV..."

So now I go back to the idea of vendor approved hardware. Windows-based workstations and laptops that have been qualified by Avid and Adobe, as well as Apple's line seems to indicate that hardware is not as friendly to something like editing HDV content as we are led to believe. Is Vegas beginning to show it's inherent weakness due to it's supposedly supporting virtually any PC hardware configuration???

It now makes sense to me - Make a specific set of hardware approved for use with your software, and you remove the chances for issues like this to arise.

I wish SCS would release 8.0c so I could find out if it has addressed these issues I've experienced recently.

Cliff Etzel - Solo Video Journalist
bluprojekt | SoloVJ.com

"So now I go back to the idea of vendor approved hardware."

Don't jump the gun too quickly on this.
As I've seen with DV I don't know where the error correction is meant to take place. I have never seen such errors monitoring the HD component outputs from a VCR. I have seen the classic 15 frame freeze.
Does the VCR do the error correction when we capture via firewire or is it left upto the capture device/software or the NLE as it reads the stream from the captured file, that is the question.
Aside from that though I do agree with your sentiments about supported hardware however with Avid that's not just PC hardware, it includes VCRs or at least it used to.

Bob.

I have had such a problem, and in fact much worse. The corruption spread from the first corrupted frame, which sort of stayed there (in part) and gradually the following frames streamed into pixels. This wasn't a drop out (on the tape) and appeared to be in the Cineform capture process. That was the time my work around was to use Vegas for capture. That was well before NEO HDV. Initially I thought I had a firewire problem on the camera, but was advised that wasn't so. Can't remember what fixed it.. Possibly a run over the computer by System Mechanic.

Now that's an interesting input!
However both Cliff's and Darren's problem correct themselves within a few frames and both exhibit the problem in blocks which really looks like something related to mpeg-2. As far as I know the CF codec uses something like variable sized blocks so your issue with the frames degrading down to the pixel level could be another issue.

Then again, I wonder why we're busting our boilers trying to work out what's causing it. Even if we knew the definative answer there's not much we can do about it apart from maybe try to avoid whatever causes it. Plus for all we know SCS might release the fix tomorrow.

Bob.

farss said: "...for all we know SCS might release the fix tomorrow."

One can only hope ;-)

Cliff Etzel - Solo Video Journalist
bluprojekt | SoloVJ.com