[Paul Goelz]

Perhaps I mis-understood. I thought the reset trick was a permanent fix. Unfortunately, in my case at least, after shutdown and restart, the projects once again take forever to load.

Paul

[Paul Goelz]

Accidentally discovered that resetting Veags to defaults (CTL-SHIFT while opening Vegas) has resolved this issue as well. At least the first couple times I tried to crash Vegas this morning were unsuccessful.

Paul

[Paul Goelz]

FWIW, in addition to speeding up project loads this was also the solution for my problem with Vegas crashing when editing text items. At least preliminary evidence suggests it solved it.

Paul

[Paul Goelz]

With the exception of my text item crashes reported in another post, the 32 and 64 bit versions of 9.0 have been 100% stable for me on Vista Ultimate 64 bit. No issues whatsoever on SD or HD assets.

Paul

[Paul Goelz]

No ideas? I was sure this had come up before.

I just updated to 9.0d and I can confirm the issue still exists in the 32 bit version of 9.0d. However, instead of crashing with the “Vegas has encountered a problem” message, it simply froze when I attempted to edit an existing text item. Attempting to close the unresponsive program was successful. Haven’t tried 64 bit yet.

If no one has any ideas, I’ll open a ticket and report it as a bug.

Paul

[Paul Goelz]

OK, that makes sense. I was originally thinking dropped frames might also refer to a frame that did not arrive when the capture device expected it.

What I have in this case are second generation dubs of 3/4″ U-matic originals, from 1982. I don’t know where the problem occurred, but in one section there is massive sync disruption. This caused the ADVC-55 to skip a number of frames. I saw it happen during capture and it affected the analog monitor too so I was expecting it. Just was curious why the capture device reported zero dropped frames is all.

TKS
Paul

[Paul Goelz]

Actually, I don’t think it is quite that simple. Not all my captures result in non-zero starting timecode but I play short sections at the beginning of each capture to find the beginning. And the ADVC-55 is continuously powered whenever the PC is on. I’ll have to do some experimentation to see what triggers the beginning of timecode. Perhaps it is the first captured (ie., recorded) frame after turn on?

Yeah, I’ve already done the spreadsheet thing to offset everything by the starting timecode. Just hoping for a better solution.

I take it there is no way to make the trimmer ignore the recorded timecode and start from zero at the beginning of the file? If not, the next time I make up a shot list I’ll do it in the trimmer instead of dropping the file onto the timeline. That way, I’ll get the actual recorded timecode.

BTW, unrelated question…. there was a damaged section on one of the tapes that resulted in a large number of skips in the captured file. The capture application did not flag these as dropped frames although they clearly were dropped. Is a dropped frame one that was captured but not actually transferred to the file (ie., a firewire error rather than a frame that was never captured due to synch issues)? This was a capture from a Panasonic AG-1970 with TBC off. With TBC on, the entire frame wiggles back and forth during capture (but not on a video monitor). Seems opposite from what I would expect with a TBC. The AG-1970 was purchased used in perfect condition but there might be a problem with the TBC….

Paul

[Paul Goelz]

Thanks, that is what I figured was wrong. But….. how do I deal with it? I can re-capture but I can’t find any way to zero the timecode display prior to beginning the capture for instances like this. For that particular capture, the time at the beginning of the capture was non-zero before I started and nothing I could do would make it go back to zero…. not even closing the application and re-starting. I didn’t unplug and replug the ADVC-55 though…. is it the culprit? Remember, I’m capturing from VHS and there is no incoming timecode.

What is the recommended workflow here….. I play and rewind a couple times before capture to find the entry point for the capture. This seems to result in a non-zero time display that I can’t zero.

Paul

[Paul Goelz]

For anyone else researching this issue…..

After a great deal of communications between me and Sony, they now say they can duplicate the registration issue and there will be a fix forthcoming some time in the (unspecified) future.

Paul

[Paul Goelz]

Well, Sony doesn’t seem to have any ideas why this is happening. DVDA starts without incident if I boot into safe mode but in normal mode it thinks it is not registered unless I run it as administrator. I have carefully looked at the permissions for the executables and the entire Sony folder tree and compared them to the permissions on my laptop (which works normally) and I don’t see any differences.

I have asked Sony several times what is involved when DVDA determines whether or not it is registered and they have not answered. I understand why they might be reluctant to explain it, but I am at an impasse here. Does anyone have any insight into how DVDA determines whether it is registered? That would be the place to look.

I can always run it as administrator, but I shouldn’t have to and it bugs me 😉

Thanks,
Paul