I can explain that very simply.
Place entire project onto HDD and Fedex it to them. Why would you think someone has not done that?

Do you not think if SCS had an answer they would not be all over this and other fora telling us?

Why are others not having problems?
That's pretty simple too. How many people are brave enough to trust $1M+ projects with 100s of tracks to Vegas when all their peers tell them they should be using something from the three As.


Also stop referring to this issue as a "bug". With systems as complex as Vegas every line of code can be perfect and still things go wrong. Bugs are simple to find and simple to fix, I spent years finding bugs with logic analysers and emulators, the kinds of issues we're seeing here can not be found as easily as a divide by zero error. Multithreaded applications can be / are a nightmare to find design problems in because they can be related to timing between threads and resource allocation. Even when you know what's going wrong it can be very difficult to resolve. These systems have to meed a conflicting number of design criteria, samples of audio MUST be delivered on time, frames of video ideally should be delivered on time, render speed should be as fast as possible. And just to make a programmers life difficult do it all on a general purpose CPU without using CPU specific instructions or specific hardware. I take my hat off to the guys that write this kind of code, in many ways it's a miracle it works at all. No other NLE works the way Vegas does.

Clearly I know more than I'm prepared to say, confidences are confidences. But still it doesn't take a genius to decode what's said in the current release notes to see the truth of the matter. Look for words like "improved".

In the end I keep on asking myself what you're trying to achieve.
What do you expect people to do, what do you expect SCS to do, are you helping the problem, are you part of the solution or part of the problem. As others have pointed out to you the only way to get problems fixed is to complain and loudly. While you keep making excuses and attacking those who dare to complain you are certainly not part of the solution and therefore must be part of the problem.

Bob.

That's a lot of words Bob... for a simple;

"no I can't explain it and I was wrong when I said Sony reproduced it."

So in other words your GUESS is no better or worse than any one else's.

Thanks Bob for solving this.

Certain software does not work properly in some otherwise fully functional and compatible hardware. That is, in harware that works ok and without problems with other software.

In this particular case it is the software that does not either comply with some rules how it should have been written, or then there is just some kind of bug or shortcoming in the coding. Wrinting multithreaded code is NOT a piece of cake. Please remember that Vegas ONLY uses the CPU and RAM as resorces during rendering, and some codec plugins. In this case the rendering codec is also coming from SCS. No other harware is needed during this process (exluding disk I/O).

SCS says: "the render is working when you allocate only one processor to the job, but not when all 4 cores are specified. This is usually due to some other process on your computer requesting resource allocation during the time of the render. Since you have cores open for outside resource allocation, the render is not crashing when only using one core. There are a few troubleshooting steps I could recommend for this issue..."

It seems that the Vegas render process is not running only in user space, but also running some kernel processes, occupying the CPU dramatically. Ok, that's only a wild guess since we have not seen the code. However, othervice it would be impossible for Vegas to steal all CPU resources so that external resources not getting their "share" will brings the application down. Freeing cores from the rendering task helps. If Vegas would run completely in the user space then Windows would be 100% in control of the resource allocation and this would not happend...

SCS does not directly write that they are able to reproduce this. However, you do not have to bee too smart to understand that if you get this kind of response from SCS - that they know about the problem. Have you ever heard of someone admitting software bugs - openly??? Or if you prefer - let's call it an issue. Many people have been (unfortunately) able to reproduce this. I'm not the only one of many that have reported about it. Blink - what else is needed to convince you that this IS a problem - not in our hardware - but in SCS software??? I have my doubts that you still insist that its a hadware issue (that got mystically fixed) when we receive the next release of Vegas and the problem is fixed.

I think that it is totally stupid to argue about such things like this. Ok - it's also me to blame because I let myself into this discussion, but I hate and must react when wrong assumptions are spread as facts. Everyone can be wrong sometimes, even you blink3t. To err is human. But please don't be so stubborn. I'm kind of a programmer myself, but I have consulted a chap that is a real programmer and he confirmed these thoughts to be more than plausible...

Christian

EDIT: BOB - very wise words !!! I couldn't agree more !

"Also stop referring to this issue as a "bug"."

And this Bob is a perfect example of how badly you read. If you actually LOOK above, I'M the one trying to tell Cliff above that this is NOT a bug.

"Blink - what else is needed to convince you that this IS a problem - not in our hardware - but in SCS software??? I have my doubts that you still insist that its a hadware issue (that got mystically fixed) when we receive the next release of Vegas and the problem is fixed."

i'll say it again for the 1000th time CG.... I'm not denying that there is a problem. What I am questioning is the rather SILLY notion that this is a "memory handling" issue or a "quad core" issue.

So far NO ONE here has explained why others are not having these issues.... and THAT is the key. What is the difference between your machine and mine? Why is it that I can do a 22 hour render on a 2 hour HD time line mixed with m2t 1440 and cineform avi @ 1920 with transitions, effects and all the rest of it with no hickups at all... and you can't.

You find the answer to this question and THEN maybe you will be a step closer to actually a factually assigning blame to some one. Short of that your anger albeit legit... is nothing more than sadly misplaced.

Solve this non-bug by using just one core? Nope. Again I state, I get the same pattern of crashes on my old P4 (a single-core chip), including when I set its bios for no hyperthreading. (Unfortunately, my P5B doesn't include a means to disable cores, but setting threads in Vegas to 1 or 2 doesn't work, even with a checkmark in the box for "Disable multi-processor AVI rendering"; although it is true that sometimes I seem to get more segments rendered before a crash by taking those steps).

It's possible that I have some piece of software installed on both machines that is causing this non-bug . . . I have around 100 programs installed (including the default Windows Accessories, etc.). However, I do not have the same anti-virus program (anyway, AV has long been disabled in my old machine since I only hook up the CAT5 cable in order to register a new installation of Vegas), nor, AFAIK, is there any other terminate-and-stay-resident user-installed program; nor are any hardware drivers common to both machines.

If I get time, I may make a new image of my boot disk and then create a clean WindowsXP install to see if I still have rendering problems . . .

There ARE differences blink.

You are running without virtual memory. I am not - like the majority of the people running Windows.

You are not rendering 1980x1080i (PAL) material to HD 1980 x 1080i (PAL) output, buty I am. Vegas 8.0c cannot handle that with all 4 cores engaged. Period. It says on the box that this software runs on 4 cores. It says it will render these formats. Separately perhaps, but not simultaneously. Unfortunately. But that is not my fault. Neither is it my computer's fault. It is SCS to blame, and they are the only party that can fix this. An I'm completely confident that they will soon....

It would be difficult for me to tell why the majority of the applications runs without problems, as difficult it is for you to understand that in our (the unlucky ones) cases. IF this is a quad core issue or not could be debated endlessy, but at least the problem disappears if I do not run on all cores that I purchased for a premium price...

I might try to disable the virtual memory to see if it affects this. I'm just so tired experimenting and finding "solutions" to these issues, it is sooooo time consuming...

Christian

"You are not rendering 1980x1080i (PAL) material to HD 1980 x 1080i (PAL) output, buty I am. Vegas 8.0c cannot handle that with all 4 cores engaged."

So regardless of where you want to place blame, you believe this is a PAL issue? And you're right BTW... I work strictly with ntsc. If you point me to a reasonable PAL sample though I will test it out if you wish. It would be rather interesting to see if it trips up my machine. Do you have a sample in particular that you're having problems with that I can try?

Would it be worth me pointing out that I can not replicate the 5.1 import bug? That does not mean it does not exist, it just means that the set of circumstances my system presents the software does not trip it up.

Unfortunately Blink does not seem to understand this concept. He appears to think that the software should behave the same way on every single machine, which anyone with an ounce of developer knowledge will tell you is the stuff of dreams. If it does not behave in the same way, it does not mean that there must be something wrong with the computer. It does not mean there must be a random factor introduced by malfunctioning member or overheating CPUs.

Back when the Amigas were one of the front line affordable video workstations, you would often find that one piece of software would work perfectly well on one machine and fail on an apparently identical machine. This was not down to the machine being faulty, it was to do with the coders "hitting the hardware". They relied on undocumented features of chips and even timings of components that may actually have only been present in a certain batch that got delivered during a certain period. Thus if the manufacturers switched suppliers for an apparently standard component, suddenly odd programs that "hit the hardware" would find that data was not arriving at registers as expected. It could then cause the program to get pointed to the wrong areas of memory and cause a violation. Sometimes it could even cause entirely wrong pieces of hardware to be addressed, generating very odd images, sounds and causing disk drives to act in a very odd manner.

These days it is not really possible to "hit the hardware" in the modern Windows platforms. However, I can not help but think that somewhere during development, coders have been taking for granted the behaviour of Windows, rather than following the documentation, and this is why there appears to be so many violations by Vegas when dealing with the Windows API. I suspect there are instances when Windows procedures used by Vegas which are now greatly depreciated. Like I said in another thread, and has been pointed out to me by others, Vegas is still based around a Video for Windows and Audio Compression Manager engine. This system is now archaic and really only supported by Windows in legacy, so it hardly bodes well for stability. I can only imagine that the announcements that are forthcoming will finally declare the arrival of something a bit newer.

"Would it be worth me pointing out that I can not replicate the 5.1 import bug? That does not mean it does not exist, it just means that the set of circumstances my system presents the software does not trip it up.

BLAH BLAH BLAH BLAH

here

I still can not replicate it. 5.1 import works fine for me. I moved to 8.0c just to use this feature. By Blink's definition, it can not be a bug.

EDIT:

And BTW, at no point in that page does it say that it is an issue that affects all users.

Where did you get the ac3 file from?

"By Blink's definition, it can not be a bug."
It is IN FACT a bug... and it's not MY definition. Sony HAS IN FACT reproduced it. That's why that page is there.... you silly little thing!

I was using a 5.1 wav. Worked fine.

5.1 wav is not ac3.

If you want to reproduce it (as Sony already has) then import a 5.1 avchd file from the sr11/12 cam.

Well that is not a "5.1 import bug" then, is it? Because if it was then it would suggest that the problem applied to all 5.1 importing, suggesting a different problem with the way 5.1 importing was handled internally in general.

What Blink is talking about is "the bug that affects AVCHD importing of AC3 5.1 files on the LFE channel". Blink needs to sort out his casual all encompassing bug descriptions otherwise he will cause misunderstandings. I had already gone to check how my 5.1 imports were being handled as a result of this sloppy conduct.

Blink,

These are just some "official BUG" fixes from Vegas release Notes.

Fixed a problem that COULD cause masked video to appear incorrectly on an external monitor.
Fixed a problem reading CERTAIN AVI files using DivX with MP3 audio.
Fixed a problem reading CERTAIN Xvid format files.
Fixed a problem reading SOME FLAC files.
Fixed a problem rendering to CERTAIN WAV/WAV64 variants
Fixed issues that prevented Wave Hammer and Acoustic Mirror from functioning properly in SOME CASES.
Fixed an audio buzz that COULD occur with certain combinations of automated track muting
Fixed an audio clicking issue with CERTAIN 29.97 or 59.94 fps MXF clips.
Fixed an issue reading CERTAIN MXF metadata.
Fixed an issue with the Height Map plug-in not functioning properly at CERTAIN settings with high project resolutions.
Fixed a POTENTIAL crash that could occur when switching to Markers or Regions view in the Edit Details window.
Fixed a bug where VST effects would NOT ALWAYS be notified of sample rate changes.

Notice something: There are KEY WORDS in these descriptions;

"potential"
"not always"
"certain"
"could"
"some"

Yes,..they sre still "bugs" even though only "some","certain", "potential" but "not always", Vegas users could "potentially" have these issues! (that are fixable inside Vegas code)

My God man,...quit fighting this thing.

I never had any of these problems listed,...or many others that people complain about. So,...why did SCS fix them? I cannot replicat them on my PC...therefore they do not exist?

They didnt need fix it for my PC.

If our problems dont appy to you, than dont worry about it. SCS will fix it for us.

This proves that a "bug" dosen't necessarily need to affect everybody, Blink.

CT

Maybe I should believe that all those people that had those bugs simply had odd Windows configurations or odd drivers or something not right with their hardware...it's not Vegas.

"I had already gone to check how my 5.1 imports were being handled as a result of this sloppy conduct."

If you wanted more detail there Robert.... aaaalllllll you had to do was ask. Pretty sloppy of you not to. ;)

As soon Blink mentioned a 5.1 issue I went and checked it. I do not see what would have lead me to think I needed to ask for more details. "the 5.1 import bug" seemed fairly self explanatory to me. Blink got it wrong.

"I cannot replicat them on my PC...therefore they do not exist?"

How do you know whether or not you can replicate them? Do you know what they're talking about when they say "Fixed a problem reading CERTAIN Xvid format files."

What problem are they talking about? What are the testing circumstances? Do you even do any kind of serious work with Xvid.

Look.... point of fact... somebody brought these issues to Sony... maybe a customer... maybe a beta tester who knows... but they are not officially labeled "bugs" on word of mouth. They are in fact tested and attempted to be reproduced.

"Blink got it wrong."

I got it wrong because you were too dumb to ask questions?

Okay Robert... what ever you say.

"potential"
"not always"
"certain"
"could"
"some"

These words mean: "Due to whatever factor,...not everybody will experience this...yet, we fixed it for everybody"

Dude,..you win. I give up....lol

You will recognize it only after SCS fixes it,..not before.

Stay tuned for future SCS release notes!

CT : - )

(LMAO)

Isn't it a bit arrogant to assume that you can be totally vague describing a problem and expect someone to chase up exactly what you mean? Does it not make more sense to just get it right in the first place? Is that not one of the basic elements of conversation?