Absolutely agree that this can't go on. If you've got the problem you need to talk to support as often as possible and really raise hell.

Support costs money and eats into profits. They'll take it more seriously if you can keep them tied up on the phone.

Bob, I've never heard the black frames described as being the same as flash frames-random frames that just happen to be black. That's an interesting take on it, that they're actual frame data.

Rob Mack

I have seen them several times,, someone had a thread going talkin about autoripple, which I never use. But I do use post edit ripple, so my theory is it is still related to the ripple function. No science or anything, just a theory (guess).

I don't know if it should be discounted. Just because some people aren't experiencing it doesn't mean that a reboot won't cure it for those that do.

Rob Mack

That's a better example. If the reboot doesn't cure it for you then maybe it's not just frames cached in memory. And if you are rebooting and then starting the render right away and getting black frames then it means that there's something up with either the media or the timeline.

I suppose it's possible that one thing leads to many symptoms or many things lead to one symptom...

Rob Mack

I think you may be right there. I always capture with scene detection on and probably 5% of my media files aren't an even number of frames long.

Vegas deals with media in terms of samples. I suppose that a frame might not even be divisable by a whole number of samples?

Rob Mack

I think the "lack of reboot" issue can be discounted.

Kelly, Rebooting may not be common practice its just something that I do after editing.
Like I said I have never, ever had this problem and I only do this for long renders.
the reason i started doing this was after waking up to find that half way thru the render
it decided it was low on memory. So after rebooting before rendering seem to cure this.
I have a gig of ram running on a p4. When this happend the machine was worked pretty hard.
But I don't think a reboot should be discounted yet after all we haven't been blessed with problem.
Maybe someone who has should give it a shot. I tend to agree with JJKizak that Vegas does strange things when the memory has been taxed. Dunno:)

Jimmy

I've been assuming that if you drag media pairs by the audio and snap them together when the audio is slightly long then everything will be falling off of the frame lines.

But there could be a lot of things causing the problem. Many sources for the same problem.

Rob Mack

farss said:

<..... Except the odd error creeps into that conversion causing Vegas to pull a frame from the wrong location, either way past the end of the media (giving you a black frame) or from elsewhere on the T/L giving you a flash frame. This may be only happening due to process switching in Windows, when Vegas stops/starts running from the other thread a value is lost or corrupted....<

Pursuing this idea.... would this mean certain combinations of mobo/cpu/ram are susceptible?

This is an excellent point. Consider this though. The default length for still images is something like 5 seconds. 5 seconds in NTSC does not add up to a whole number of frames, but 5.005 does. Nor do the default length for text, titles, or generated media add up to whole numbers of frames. And what happens if your media is sitting there off the frame lines and then you drag the end back to a frame line? Is the whole thing off?

I'd be curious to know what people see in edit details after they set their project ruler to abslute frames. That will show events that are off their frame count (to a few decimal places any way) and it'll show 0 length events.

Rob Mack

Yes but there's the problem with this problem. If it happens ONCE without any ripple being used then we can immediately state with 100% confidence that there's a problem that isn't in any way related to that. There maybe ANOTHER problem related to ripple of course but you should always address the basic issue first, the OTHER problem that occurs with ripple maybe just a symptom of the basic problem.
To give another example, if it was suspected this was DF/NDF issue but it happens in a PAL project you can discount the DF/NDF aspect immediately.
Bob.

If ripple were causing it then it'd happen whether you do it automatically or manually.

Maybe what we really need is some organized testing scenarios and reporting. Anyone want to tackle some sort of web reporting page?

Rob Mack

The key is to find, somehow, a reproducable scenario...the smaller the better.
Has anybody seeing this problem been able to isolate it in any sense?

It sounds like the empirical evidence points to over-tasking the PC during rendering. If so, then a small experiment probably won't surface the problem.

Nevertheless, without a way to reproduce the problem reliably, Sony will likely never be able to fix it.

I wonder if using a single clip with tons of FX (to really work the PC during rendering) would surface the problem? Or a series of clips (total being > 1 hr) with NO FX?

I got it to happen is simple short project, NO FXs, just a trim at the start and end. Heck Vegas wasn't even having to recompress the frames. No ripple, not even a cut in the entire video. And no I hann't used RAM preview either, why would I with no FXs applied. Vegas plain ans simply pulled the wrong frame when it was sending frames to the encoder.
Bob.

Bob, is that reproducible? Can you reboot, open the veg file, render, and still see the problem? If so, that is an excellent starting place!

If you can reproduce it, heck, put it all on a CD/DVD, and mail it to Sony!
Or send it to several of us to see if it reproduces on our setup.

I think the "lack of reboot" issue can be discounted
========
Agreed. I have always rebooted before rendering using Vegas 2, 3, and 4.

John
---------------------------
John, did you mean "always" or "never"?

-------------
I mean always. Rebooting does NOT solve the problem. I always reboot before rendering. I also close down everything that can take away from the processor including the mouse program. Systray and explorer are all that is running AFTER a clean reboot. So that's not the problem.

John

Absolutely agree that this can't go on. If you've got the problem you need to talk to support as often as possible and really raise hell.
====================
Yes it can and will go on. It has gone on through three versions and will continue to do so. None of these problems will be seriously addressed until you boycott new releases. New releases DO NOT address long standing problems. They often introduce new ones instead. I don't have a problem with new features as long as they take basic editing problems and Do Something About Them.

John

before you reboot for LONG render, try this. Set Vegas RAM preview to 0. Also, Windows Start -> Run-> msconfig; under Autostart tab, unclick everything but systray. Last, turn off all power mgmt schemes (screensaver, HDD sleep, zero activity stand-by). NOW reboot, start render, and walk away from machine. Use a second machine if you have other work to do on the computer. These steps go real quick once you're used to it, and you can re-set everything once you're done with that 10-hour (or longer) render. For renders less than [your breaking point], just send Vegas to background and continue using the machine for other things.
=================
I do this every time and I still get flash frames. The suggestion to set Ram preview to Zero was made by a Sony Rep a long time ago and it didn't work.

John

I will give that a try, Thank you. You know, come to think of it I do a lot of ram renders.

John, Marquat was making a suggestion for another issue I had :)
Jimmy

as for your issue, have you tried setting format to progressive in project properties? you can still render to whatever format you like. i only mention this because i had a similar quirk with Vegas Video 3 which has not revisited since i started setting project to progressive.
==========================
Are there any adverse complications with that setting? I have never used it.

John

I have sensed at times that possibly hitting the "undo" has something to do with the frame issue as the undo resets the whole doggone timeline.

JJK

I have sensed at times that possibly hitting the "undo" has something to do with the frame issue as the undo resets the whole doggone timeline.
=============
That's a good point. It would explain why no one has been able to put their finger on the problem since Vegas 2.0

John

In my case i just re-encoded, no reboot was necessary. I didn't waste time trying to find anything on the timeline, how could it be there when there was no cuts, all I did was capture a tape without DV scene detection from a DSR-11 (like that'd make a difference), drop the file onto the T/L in a project that matched the files format (PAL DV) with QTF ON, trim opening bars, add a fade up from black, trim a few frames off the end and add a fade down to black. Lordy, lordy, if I had a set top DVD burner I could have done the job quicker.
Anyway, play the DVD back in the home system and I sees a 'flash', thank god I saw it too, from memory this might have been a DVD going out for replication. Went back to Vegas, re-encoded, problem gone, or is it?
Which Sony engineer wants to put his hand up to diligently watch 40 hours of kids playing football every week just to make certain Vegas hasn't hiccuped? Who'se going to pay to repress 5,000 DVDs when this problem makes it's way into something important? It's not like this issue kind of leaps out at you like an error in CC or a getting your audio out of sync by 2 seconds.
Now can I add something that I thinks important. It's ALWAYS 1 FRAME.
So we need to get out of creative mode and get into cold hard deductive reasoning here:
1. Software is highly predictable, there's no ghosts in the machines, I've got an old 486 sitting in this office, its run the same loop of code waiting for a key press or a mouse movement that'll never come because it's beheaded for years without a hiccup.
2. But hang on, we're seeing a seemingly unrepeatable event, well again there's actually no such thing, just as there's no way to create a truly random number in a computer. You can make the period of repitition so long hell really would freeze over before it repeated but it will repeat.
3. So what can cause a seemingly random event in software. Two asynchronous things happening, the code running and it being interrupted by say a real time clock or network activity or any one of a host of things that cause the OS to switch your code off.

So how would I suggest Sony try to track this down. Well two things if I'm correct. Firstly it might take a lot of repetitive testing and secondly because you'll have to wait perhaps months for it to occur again you'd better have plenty of tracing running so you can get a good look at the event.

So you need something that keeps rendering out the same file. At the same time you need to check the result, that's not going to be simple either, I guess you could run some form of file comparison as you don't need any FXs to cause the problem it would seem, so the output file should be almost identical to the source file.

So I hope this gets someone in Madison going, this is a major problem, I seem to recall it even crept into one of DSEs training DVDs. As others have said, I too would have forgone every new feature in V5 to see this issue fixed, come to think of it I've never used ANY of the new features in V5, played with them a bit and that's all.
So lets see if they can get this resolved for V7, I suspect it's around how long it'll take to repo the problem in a controlled environment.
Bob.