Another ANNOYING thing about Vegas

Laurence wrote on 7/3/2008, 6:12 PM

Just do all your renaming, moving, copying etc, from the Vegas explorer instead of the Windows explorer and you should be able to avoid this. This will avoid the peak rebuilding process. It's actually easier anyway once you get used to it.

Terje wrote on 7/3/2008, 6:26 PM

As said, move things around in Vegas only, then you'll be fine. The problem is that checking the filen ame is not enough. What if the video changed? So, it also checks last modification time, and if last mod time of video is greater than last mod time of .sfk, you will have a re-build. Moving things around will change last mod time, and in ways that are not 100% predictable. There are probably other scenarios too where Vegas will, just to be on the safe side, re-build the .sfk. All fixed by not doing anything with files in the regular windows explorer.

goshep wrote on 7/3/2008, 6:29 PM

"Compare filenames if .m2t filename = .sfk filename use the sfk, don't freaking rebuild!!!!"

Ah if only coding were that simple...

10 If "a$" = .sfk then WTH? Why rebuild? Goto 30
20 Rebuild Peaks...and take your sweet time doing it.
30 Open file
40 If command = "render" goto 50
50 Insert random black or red frame
60 goto 50

ushere wrote on 7/3/2008, 6:35 PM

55 if 50=0 then go 70
70 collect cheque
75 bank cheque
80 if 75 = bounce go mafia

mafia = end

Harold Brown wrote on 7/3/2008, 6:48 PM

I guess no one would ever replace a file with one with the exact same name. Is that what is being said here? Leave the coding to the pros.

Chienworks wrote on 7/3/2008, 6:56 PM

Or edit the file in another application and save it back over the same name.

One thing i've found is that if i open a file in Sound Forge, then Vegas has to rebuild the peaks when i switch back to it if Sound Forge is still open and vice versa.

Can't do anything else on a Q6600 while peaks are building? What's wrong with your computer? I used to keep on editing merrily away while peaks were building on an old 350MHz AMD K6/2 processor with 64MB of RAM. Heck, i even seem to recall doing it on a 133MHz celeron system. It barely slowed down the interface at all. Now with my 3GHz Core Duo system i don't even notice it happening. What's wrong with your setup?

Laurence wrote on 7/3/2008, 6:57 PM

The point is that the Vegas explorer window realizes that there are up to three files per clip and that what you want to do is just see the video clips, but when you rename or copy or move them, you want to change the peak and marker files along with the video clips. The Vegas explorer window does whatever changes you make on all three files at once. This avoids the time consuming peak redraws and also preserves any markers or regions you have defined. The Windows explorer window doesn't do this.

bruceo wrote on 7/3/2008, 8:06 PM

See everyone chimes in defending Vegas. Who cares about the complexity of scenarios. I'm talking about projects where NOTHING is done. Just close it and open it back up, on every machine, with everyone I know that works in vegas doing what I am doing. I thought, well maybe moving an external project drive to another compter where it gets assigned a different drive letter might cause the problem even though that should not make a difference if it is in the same folder as the main file. But it happens if the project stays on the same system.

If you have a potentially awesome car because it is designed to take all things into consideration when transporting you to your destination, but it doesn't do a simple thing like start then it is just a hunk of metal.

Therefore if Vegas takes 10 minutes to load a large source clip filled project another 2 hours to rebuild peaks and then after 10 hours of editing it decides it doesn't like a frame in the project and now will never let you load the project again and you now have wasted over 12 hours on 1 project what does that make it? An awesome car that doesn't drive, a video editing program that can't edit video.

I have said it before but i'll ask again. If there is anyone here shooting projects that are 6-10 hours of footage on Sony CF units or even DR60 with 500-700 clips and/or never having to randomly build peaks and/or no black/red frames and/or full HDV renders on the first go around let me know and I'll come visit you with at least 5 300GB drives of projects waiting for a Vegas that works like an actual NLE. Jeez more often than not Vegas doesn't even like the M2ts it renders itself. It's m2t output looks perfect but drop it in and render an avi or mpg2 and often it will freeze, have an audio drop, black frames you name it. Which reminds me that every so often projects will have spurrious flatlined audio.

All these problems were terrible in V7, much improved in V8, but still very problematic. Where is the new reader. :-)

blink3times wrote on 7/3/2008, 9:58 PM

"Therefore if Vegas takes 10 minutes to load a large source clip filled project another 2 hours to rebuild peaks and then after 10 hours of editing it decides it doesn't like a frame in the project and now will never let you load......."

Then there is something wrong with your machine.The only time I've ever seen peaks RE-built with EITHER explorer is when I have physically moved a file.

With my system, after the initial peaks are drawn it takes about 3 minutes to reload a project (1 hour of HDV with about 150 scenes)

bruceo wrote on 7/4/2008, 12:11 AM

So there is something wrong with a Sony Vaio P4, Two different Dell Q6600, Hp Q6000, Guy Graphics Dual Xenon. And the machines of several others who I have seen or talked with on the phone.....

farss wrote on 7/4/2008, 1:01 AM

I see exactly what you're complaining about as well, nothing wrong with the PC or what you're doing. It is another frustrating Vegas quirk.

Bob.

blink3times wrote on 7/4/2008, 3:00 AM

"So there is something wrong with a Sony Vaio P4, Two different Dell Q6600, Hp Q6000, Guy Graphics Dual Xenon. And the machines of several others who I have seen or talked with on the phone....."

Okay... so let me re phrase that.... there is something wrong with MY machine.... it DOESN'T re-build peaks after the initial build file is written unless I move the file to another location (and of course when I apply a filter or something like that).

Upon re-opening the file after a save and shut down, it takes about 3 minutes to load

blink3times wrote on 7/4/2008, 4:07 AM

In fact, I just timed it....

My present project is M2t, 142 scenes, 3 video tracks, one audio track, and 67 minutes long... it takes 1 minutes, 24 seconds to open. At no time were peaks re drawn. Even if I remove a scene from the time line and then change my mind, and re insert it at a later time, the peaks are not re drawn. The original peak file is ALWAYS used (unless of course I have changed the audio in some way or physically moved the file to another folder)

I find that M2T files are the slowest to load.... Cineform files load at least twice as fast.

I will say though that I do have a minor irritation... and that is when a saved project is opened it always opens fully zoomed out and the scrubber at the beginning. I would much rather have it open EXACTLY how it was saved..... including the scrubber being where you left it upon closing.

blink3times wrote on 7/4/2008, 4:25 AM

You also said that the SFK file holds one or two lines of code. I guess my machine is broken again then because an average SFK file on the project I'm working on is about 250 Kb and is a HELL of a lot more than a few lines. If I open it in a hex editor it goes from line 00000 to 439c0. That's about 10 to 15 pages of hex.

My guess is that you're viewing it with NotePad or something similar which can't read or display Hex.

JJKizak wrote on 7/4/2008, 5:00 AM

In the 6 or so years I have used Vegas I have never ever had a problem with rebuilding peaks.
JJK

baysidebas wrote on 7/4/2008, 5:48 AM

"I will say though that I do have a minor irritation... and that is when a saved project is opened it always opens fully zoomed out and the scrubber at the beginning. I would much rather have it open EXACTLY how it was saved..... including the scrubber being where you left it upon closing."

Amen, I've taken to go into standby instead of completely shutting down just to avoid that little bit. But you can't do that too often [without a complete shutdown] before you start getting odd behavior from the machine.

Laurence wrote on 7/4/2008, 7:16 AM

Okay... so let me re phrase that.... there is something wrong with MY machine.... it DOESN'T re-build peaks after the initial build file is written unless I move the file to another location (and of course when I apply a filter or something like that).

There must be something wrong with my machine too ;-)

Harold Brown wrote on 7/4/2008, 7:53 AM

I have never had a problem with Vegas rebuilding peaks. Using it since 2003 on both XP and Vista.

johnmeyer wrote on 7/4/2008, 12:45 PM

This is now the seventh thread started by bruceo about rebuilding peaks. Here are the previous threads:

Peak building still a major problem

Rebuild peaks

Rebuilding peaks!! Ugh

Vegas & HDV for real?

Vegas Questions

Error building peaks HDV again...

More V7 woes....

Now, you can take this list in one of two ways:

1) He is a complainer who is doing something wrong;

or

2) He is a loyal user who is continuously frustrated by a persistent bug that Sony isn't fixing, and is having his workflow seriously hampered by having to wait for unnecessary operations to complete.

We've had people express both sides in this thread, but based on facts, I tend to believe #2: this is a long-standing bug, and it is at best very annoying and at worst a deadline-buster.

For those that say they have never seen this, you are both lucky and -- perhaps in some cases -- new to Vegas. This problem of peak rebuilding used to happen regularly after the release of each new Vegas version:

For instance, here's one from five years ago. Everyone was having the problem.

Aargh!!? Vegas is rebuilding all my sfk files

I don't have time to search all old posts (if you search on "build peak" you get 511 hits), but there have been dozens about this problem over the years. To the extent that a solution was found, there seemed to be four root causes:

1) Upgrading to a new version. When you opened an old project in a new version of Vegas, it would rebuild the peaks.

2) Daylight savings time. When the system clock changed, it caused the peaks to re-build. I never understood how or why this would happen, but it definitely has been reported:

Why do I occasionally have to rebuild all my peak files?!

It's back AGAIN!!! ALL Audio peaks are being re-built

3) Moving and/or renaming media files without moving and/or renaming the various sf* files.

4) Opening the media files in other Sony Creative Software programs. Open in Sound Forge and it will often re-build. Save and then re-open in Vegas and it will often re-build. This happens to me all the time, although my versions of SF and Vegas are several years apart (in when they were released).

Hope this helps!

P.S. Oh, here's a really old description of the problem that may also help:

Audio Peaks Rebuild on Every Startup--why?

[Edit] Just to add one additional thought ... I have had several problems over the years with applications that look to the date/time stamps on files and do comparisons. There was never a problem until NTFS, but when that file system came out it created all sorts of interesting problems with these stamps no longer staying consistent. If you look at files copied to network drives, for instance, and look at the timestamps, you may be quite amazed at what you find: There is often a one second difference!

farss wrote on 7/4/2008, 3:20 PM

What's so daft about this problem is there's a mechanism in Vegas for the user to rebuild the files IF they want. I've never once had cause to do so.
On the other hand a simple message box along the lines of "One or more peak files seem out of date, rebuild. Yes/No" would seem such a simple solution to all the user grief. I'm not much of a prgrammer but I'd certainly never write code that'd launch itself off into some process that causes the user to loose control of the application for a considerable time without at least asking the user first. Even more of a worry, there's a button to cancel the process that doesn't, reliably.

Bob.

johnmeyer wrote on 7/4/2008, 6:02 PM

Spot used to chime in and remind us to go to the General tab of the Preferences dialog and check "Build 8-bit peak files." He claimed it made building sfk files much faster. I remember testing this in Vegas 5, and it didn't seem to make any difference. Let's see what happens in Vegas 7.0d ...

OK, I made two copies of the same 426 MByte WAV file (to avoid problems with caching). I put the first one on the Vegas 7.0d timeline and measured how long it took to finish creating the sfk files. 17 seconds.

I then enabled the "Build 8-bit peak files", quit and then re-started Vegas (just in case this preference doesn't take effect until a re-start) and then tried the same thing. I repeated the test several times. I was unable to detect any difference whatsoever. I wrote to Sony four years ago and suggested that the 8-bit peak building preference was probably broken. I would suggest that it probably still is. I have given up, however, reporting such things as they never seem to get fixed.

PeterWright wrote on 7/4/2008, 6:11 PM

If some people are having problems waiting for peaks to rebuild and others, including me, are not, there must be something different in their set ups, hardware or software.

This must be traceable, but where to look?

bruceo wrote on 7/6/2008, 10:24 AM

For example I have 2 .veg for the same source files. One is a documentary and the other is a highlight. I loaded up the highlights this morn ans it had to rebuild the peaks for approximately half the files. Then I loaded the documentary as a repository for clips to move into the highlight .veg. It wanted to rebuild the peaks again even though they were just built in the previous .veg. I canceled peak building since i am not cuttin on that .veg. When I copy a clip over from the flatlined documentary .veg to the highlight the waveform shows up immediately, which is what I expect, but then why is vegas rebuilding the file every time the projects are launched even though absolutely nothing has changed.

If I take this project drive to any other computer it will do exactly the same thing. This does not happen on every project, probably 1 out of 4, but enough that it is a major headache and resource waster. As Bob said why is there not a confirmation dialog. And I also agree that if you let any process go on for a bit in vegas and then try to cancel it almost always results in a freeze. The only reliable "cancel" button in Vegas is a task manager kill.

A tip.... when rendering m2t and you get a lockup at a certain percentage DO NOT CANCEL. If you cancel the rendered portion will dissapear. If you kill vegas the rendered m2t up to the point of freeze will be there. The you can drop it on on the top layer (make sure to line it up by waveform or sight since it wont if you put start to start since Vegas renders are not frame accurate) then most of the time you can rerender and it will quickly smartrender through to the freeze point and often blast through it since memeory has not clogged up at that point. If it still freezes then you have a frame at that point that vegas does not like. You can adjust that edit point so that there is different footage there and then your render will go through fine.

Another tip: For those who are getting black frames with m2t to mpg2 or photomontage to mpg2 just loop select the project and right click on the loop line and selectively pre render. Make sure to select the proper render format and then it renders your project in hundreds of little files. Then render out the project normally and you will have no black frames. It seems that baack frames come in when Vegas hits a spot it doesn't tolerate and memory fills up. But selective render builds such small files that memory never gets filled up and then the final render is just basically stiching all the renders together. It takes about 50% longer than just rendering out initially like it should but it is better than delivering bullcrap with black frames.