Vegas is wasting my money......

bruceo wrote on 12/16/2008, 1:06 PM
WTF is up with peak building..... On almost every project this year with 8.0c we are having to rebuild peaks. Often peaks have to build everytime the project is open. On projects with 8-10 hours of source footage, some are all captures from tapes others are transfers from DR60 and CF units, but they all take 4-5 hours every time. This happens at 3 different locations and across several machines and I have had other colleagues using Vegas inquire to me if I had this problem. So literally on at least audio passes we are wasting about 15-20 manhours a day. This year
alone equates to thousands of lost revenue on at least 30 projects......

Comments

farss wrote on 12/16/2008, 1:37 PM
This has been complained constantly for as long as I've been using Vegas. It gets worse with HDV.

I'd like to know what is so precious about those waveform files. It's a pity Vegas doesn't show as much concern about its project files.

Bob.
johnmeyer wrote on 12/16/2008, 2:01 PM
I still haven't installed 8.0c or 8.1, but I know that with earlier versions of Vegas, these peak waveforms are re-built based on time/date information. As a result, if the computer clock changed during the daylight savings time change, all the peaks would be re-built (although I'm still not sure I understand how or why this change made this happen). So, if these files are being opened over the network, this might cause the problem. If your computer clock is being re-set via some network management software, that might cause the problem.

I'm not saying this should be happening, I'm just trying to come up with a way to help you and solve the immediate problem.

Thus, I'd suggest doing a test where you have all the files on a local drive and ONLY on a local drive. Disconnect from the network (this is just for the test; I'm not suggesting you do this permanently). Then, open the project. Do the peak files all get built? Then, save the project under a different name. Quit Vegas, and then immediately re-open. When Vegas is open, go ahead and find that new project file name and open it. Do the peaks re-build this time? If not, you are one step closer to coming up with a workaround or solution.

If the peaks re-build, then I'd say that Vegas has a pretty major bug that needs to be fixed ASAP.
Skuzzy wrote on 12/16/2008, 2:30 PM
Ok, I noticed the peak building, but it has never slowed down my editing work. It appears to happen in an asynchronous thread.
TGS wrote on 12/16/2008, 2:33 PM
Maybe it only happens to me since I've seen nobody else suggest it....
Vegas opens much much faster if I'm NOT online while opening.
I don't know why.
2G wrote on 12/16/2008, 3:16 PM
It's definitely different in 8.0c (and it takes a lot longer in HDV as expected). I, too, have huge projects, and it takes up to 30 minutes to rebuild the peaks.

It doesn't rebuild them every time I open the project. But it definitely does it more than it needs to. I capture the footage once. The peaks should build once and be done with it.

I have two edit bays and keep my footage on an eSATA drive. I have noticed that as I move the project between bays, one computer is never satisfied with the other computer's peaks (same 8.0c on both, BTW...)

You can cancel the peak building. But it'll just start up again the next time you open the project. And I use the peaks to help fine tuning the sync of multicam shoots. So I can't just do without them totally. And it may run on a different thread. But I have found that if you try to do an undo, you're locked out until the peaks are done. It's definitely not a completely separate procedure.

I don't mind paying the price one time after capturing the video. But it is a real pain to have vegas continually decide it doesn't like the peaks it built a few days ago and take a half hour to rebuild them.

I agree.... it's a bug.
farss wrote on 12/16/2008, 3:35 PM
"I agree.... it's a bug."

It's no bug, just bad software design. It could be fixed with a simple dialogue box along the lines of a file associated with this media could be incorrect, rebuild or continue using it (Y/N) ?

Vegas does give us the option to rebuild a peak file. It should also give us the choice to not rebuild one if we don't want it to.

Bob.
johnmeyer wrote on 12/16/2008, 4:43 PM
have noticed that as I move the project between bays, one computer is never satisfied with the other computer's peaks That behavior, whether correct or whether desired, is not new. Vegas has always operated that way AFIK.

BTW, I am not sure how any of us are served by the same person bringing up exactly the same thing over and over again. I refer, in particular, to the following thread, and to my attempt in that thread to provide some guidance and help:

Another ANNOYING thing about Vegas

While I wish Sony would fix the behavior, I do believe that it can be avoided. I consider this to be the ultimate "dead horse" thread. Click on my link above and you'll see what I mean.

This is now at least the eighth thread by the same person on exactly the same subject. When the same person does the same thing over and over, and expects a different result, I'm not sure what it is called, but it doesn't seem to me to serve much of a purpose.

bruceo wrote on 12/16/2008, 6:24 PM
John, It is no different than me continuing to complain about HDV black frames, frozen peak building, freezing M2t renders, crashing m2ts with on Sony CF unit files etc etc and all I got were continued posts about, flash card specs, drivers, etc etc all in defense of Vegas, when i said it was across many machines and consistent among them and it certainly was vegas and has to do with the mpeg reader and buffer and after at least a year all of a sudden a new reader and update and it is ALL GONE on all the same machines..... I have used Vegas since it was first released with V2 and this peak building situation is worse than it has ever been with peak building. I don't know why people haven't had the challenges with HDV across the board that i have had with Vegas, but knowing that I have troubleshot across different configurations, installs and colleagues doing similar work and have had consistent bugs just tells me that the majority are doing very short pieces.

I know I even made the effort to ask anyone who was doing long form projects with HDV and were having no problems to allow me to come to their studio and see it in action and I got nary a response. But I do feel vindicated when Sony finally released the update and new reader and all of those issues are pretty much gone. The only major ones that remain are with peak building.

Rarely now, but sometimes audio peak will flatline and often the audio drops to 0 on m2ts but you can pull the m2t up in any media player or basic NLE and it plays the audio and video streams fine. And of course the most frustrating issue is the peak building. Just this afternoon alone on 2 projects with 2 editors it took 8 hours combined to get the peaks rebuilt which had already been rebuilt several times.

I personally have done hundreds of long form projects over at least 10 years in Vegas exactly the same way on USB drives. It used to be pulg the drive in, drop the media on the timeline, Peaks build for a few hours and then you can move that drive to any Vegas installation of the same version and the peaks were good, it might build a couple for some reason, but not all. Now on the same machine, same drive, same port, it often rebuilds them all with at least 4 different editors that I know across at least 7 different machines.

So needless to say if i don't find a solution when I come to the board and then i come back 2 months later bitching about it and it is still unresolved can you blame me for continuing to bitch until it is corrected?

I'll gladly do whatever it takes to find a solution and certainly invite anyone to come out to the studio and show me what I'm doing wrong.
Laurence wrote on 12/16/2008, 7:20 PM
There is a way to minimize the peak building problem. What happens is that there is a separate peak file which goes alone with each clip. If you copy, move or rename the clip outside of Vegas, the peak file will be redrawn. The way around this is to do all your moves, copies and renames from within the Vegas Explorer window instead of the Windows XP or Vista one. What this accomplishes is that changes made from within the Vegas Explorer window will be automatically done to the support files and not just the main clips.

In other words, do all your clip moves, copies and renames from within the Vegas window and you should be able to avoid the extra waveform redraws. Working this way will also preserve your markers (which are also in a separate file).
blink3times wrote on 12/16/2008, 8:26 PM
I agree with Laurence. I just don't know what people are talking about with this "rebuilding peaks" stuff. The ONLY time I see peaks being built (or rebuilt) is when the clips are initially placed on the time line, or when I have moved/renamed the file(s) outside of Vegas, or when I have used an external drive. I have also seen peaks redrawn after a system restore. Other than this, rebuilding peaks just doesn't happen.

I have projects that are MONTHS old on the machine that I can open at any time with no redrawing. I just make sure that I do not disturb the files outside of Vegas

I seriously question those that are having this problem... I have to ask... what are you doing that Vegas doesn't like?
farss wrote on 12/16/2008, 8:48 PM
"what are you doing that Vegas doesn't like?"

Actually using it for paid for jobs. Probably by people they pay a wage to sit around and wait while it does its peak building thing.

I suspect some of the problem isn't the peak files actually being built. Some of my projects can take forever to open, it get worse with HDV and XDCAM EX footage. 10 to 20 hours worth of clips and lots of tracks and you need a lot of patience.

Here's a thought though. I wonder if some other process is changing something related to the file that causes Vegas to think it's dirty. One could try write protecting the file and see what that does.

Bob.
apit34356 wrote on 12/16/2008, 9:04 PM
Farss, has a point about large projects. Vegas could build "onetime" data/pointer files of all video and audio files. On re-opening vegas and moving down the timeline, only current files being needed could be open. These "onetime created files could contain all the pic thumbnails, etc.... in fact, the thumbnails could be easily resizeable plus could mimic the old proxy approach(greatly reduced). '-)
goodtimej wrote on 12/16/2008, 9:53 PM
I, too, see this same peak building problem. Not on the internet, no extra programs, no changes. A reboot does it.
blink3times wrote on 12/17/2008, 3:02 AM
"Farss, has a point about large projects."

Well first let me say that I don't for one second call people liars here. If they say it's happening to them then it's most definitely happening... but I question WHY, because it has NEVER happened to me unless I have somehow disturbed the files outside of Vegas. I should say there is one other time and that is when I import a 8c project into 8.1

I don't know what constitutes a "big" project, but I've had 2 hour HDV projects on the line with 700 events with no issues.

Is there a setting that is being missed (or used)... what is different that is causing rebuilding for some and not others??
ushere wrote on 12/17/2008, 3:55 AM
i have to agree with b3t, the only time i've ever had problems with re-builds is when i've moved media outside of v8.

however, i'm working on one pc and a couple of ex hd's (though connected to the net), and don't shuffle material around.

i strongly object to the TWO builds required in v8c with the original capture. does anyone one work with 4 channels, and if they do, surely they are the exception to the rule and should therefore ask for the extra build?

leslie
farss wrote on 12/17/2008, 4:32 AM
"Is there a setting that is being missed (or used)... "

There is only two settings that should affect this:

1) Build 8-bit peak files. This will make building peaks faster however they'll look ugly when zoomed in. This is the only aspect of any of this I've seen a comment on from a SoFo body. Yes it was way back then.

2) Build peaks for visible events only. This one is interesting. Save some typing and look it up in the help file. In summary "Clear this check box if you want to build all necessary peak files when you open your project....."


I'd be interested to know how Bruceo has these setup.

On an interesting note I forced Vegas to create two .sfk files from identical 1s sine wave .wav files. Looking at the binary stored in them where I'd expect the peak data to be the values seem different. The first 4 bytes still read "SFPK".

I also found using V7's explorer window to move the source file it did NOT move that attached .sfk file. It did rename both files though. Maybe V7 thought as the file is very short it didn't need to, need to check that with a large .sfk file.

You'd think after over 5 years of users bitching about this someone from SCS would throw them a bone. Surely it's no national secret how Vegas decides a peak file needs rebuilding. If we knew more we could help find the problem.

Bob.
JJKizak wrote on 12/17/2008, 5:07 AM
The only time I have had a peak rebuilding problem is with a TV HD program with 5.1 sound (Kentucky Derby) copied with MY-HD card. No problems with anything else.
JJK
blink3times wrote on 12/17/2008, 5:29 AM
I've tried to make Vegas rebuild a few times now... and can't. I've even moved the sfk files and then back again and I don't get a rebuild. I've played with the "Build peaks for visible events only" switch and it doesn't make a difference either way as far as rebuilding goes.

I don't have this issue so this is a fly-in-the-dark guess, but I doubt it has much to do with project size. If the sfk file is there in the proper place when the project is opened then a rebuild should not be (and for me it doesn't). Vegas for some reason simply is not accepting the existing sfk file as valid..... or doesn't see it. Maybe it has something more to do with one's system? Like maybe some one is operating with the sfk's on a RAID system?
Skuzzy wrote on 12/17/2008, 7:33 AM
Mine works the same way blink. It only builds the audio peaks one time, even when I change the audio.

But that rebuild time is not down time for me. I keep right on editing. As a matter of fact, the first time I used Vegas, I did not notice it building the peaks. By the time I noticed it, I had already completed half my editing work.
Sebaz wrote on 12/17/2008, 8:07 AM
In my case, Vegas insists on rebuilding peaks only if at some point I choose the Rebuild Peak files command. The problem is that after that it keeps on rebuilding again at random times even though I didn't tell it to. But even when it does, it takes minutes, never hours to rebuild them.

One suggestion I can give you (other people may have given you but I didn't have time to read the whole thread), is to separate the footage into different projects. I doubt that you have a timeline of 8-10 hours, and as far as I know, Vegas only rebuilds the files that are used in the timeline. So if you have one or two hour timelines you might reduce considerably the time it takes to rebuild files.
farss wrote on 12/17/2008, 1:14 PM
The clue is probably that bruceo's projects are taking considerable time to build the peak files. I'm testing one such project now, looks like it will take over 1 hour to build the files that I've forced Vegas to build. I'd consider this a moderately sized project with 18 hours of footage. In my case I'll be using this footage to build a 1 hour project. That's a shooting ratio of 20:1, a doco can easily have a 100:1 ratio or worse.
What everyone seems to be focusing on is the length of the project but when it comes to building peak files that is irrelevant, it's the amount of material being used in the project as Vegas has to build a peak file for the entire source file even if you only want to put 1 second of it on the T/L.
I do find that the time to build a peak file depends on disk speed. Files on my RAID 0 drive build faster. That makes sense, Vegas has to read the entire file but doesn't do many calcs as it does that, while doing this peak file build only one core is being used at is only running at 20%.

The other thing I'd like to know is if bruceo is using MM. I seem to recall he does and copies a common MM database between all his edit system regularly to keep them up to date. I'm wondering if this could be what causes Vegas to decide the peak files are dirty and hence need rebuilding. It's certainly a factor worth investigating, not too many use MM and not everyone is seeing this problem.

Bob.
John_Cline wrote on 12/17/2008, 1:36 PM
There are three timestamps associated with a file; the times is was created, modified or accessed. It seems like Vegas rebuilds the peaks when it sees that a file has been changed by looking at the modified time stamp. I'm guessing that something in Bruceo's system is changing the modified time stamp on all his files. Personally, I only see Vegas rebuilding peaks on unmodified existing files twice a year; when we change to/from Daylight Savings Time.

The time it take for Vegas to build peak files is sometimes a little annoying, but Premiere is much, much slower and Premiere's audio waveform display is just pitiful. I don't know why they even bother and Avid is no better.
Serena wrote on 12/17/2008, 1:42 PM
For what it's worth, I don't experience the problem.
farss wrote on 12/17/2008, 2:00 PM
From what you're saying then Vegas modifies the file everytime it opens it and hence changes that time stamp.

I cannot understand though how changing the system time of day would make Vegas assume the file was dirty. Assuming you run a utility like Atomic, system time shifts fairly regularly. On top of that there'll be a 1 sec change in time at the end of this year.

My test project just completed building it's peak files, 62 minutes.
Reloading that projects takes roughly 30 seconds. It's actually faster than some of my smaller projects, that's strange.

I tried changing system time by one hour to simulate daylight saving. Nope, Vegas does not rebuild the peak files. To be honest I'd be pretty staggered if it did but time permitting I'll try harder to provoke it.

I'm still wondering about Media Manager. I don't run it so I can only theorise, would be interesting to know if those who report having this problem do run it.

Bob.