Firewire Hard Drive Freeze

rmack350 wrote on 5/26/2003, 7:26 PM
A user at the DMN forum posted this work-around to the (rare but totally show-stopping) 1394 drive playback freeze problem:

=======================================================

"http://www.dmnforums.com/cgi-bin/tdisp.cgi?forum=sonic-foundry_vegas&post=030419174123.htm

I'm having (had) the same problem with my external FireWire drive (LaCie 120 GB DV Ed.). Sometimes I got an error message (but not always) that stated "unable to mix audio". The only thing that eliminated the problem was the following workaround:

Right click the audio on the timeline. Choose "Apply Non-real-Time Event FX...". The plug-in window opens. Double-click any plug-in, for example Graphic EQ and click OK. Now the EQ window opens. Bypass the effect by unchecking the box in the upper left corner and click OK. The Save dialogue opens. Save with the suggested name, or any other, to the same drive. It does not have to be a different drive. Done. Apply this workaround to all audio clips on the timeline. No need to copy the whole AVI.


Hope it helps.

Best/Tommy

www.stormstereo.com "

========================================================

Essentially, what this does is render a separate audio file and add it to the current track as a separate take. It's a fairly clean and elegant (but indirect) way to separate your audio from it's original media file.

I can't vouch for how well this work-around works yet just because I haven't had enough time with it. If it's helpful then the next thing to do would be to find or write a script that does this to all of the audio events on a track.

I'm not sure if this workaround provides a clue to the cause of this problem.

On a side note, I recently tried adding a set of 1kw png files to the timeline to try to simulate the effect I was thinking SFK files might have-small files having too much overhead all at once. I set the stills to last for just a frame to be sure they'd be a quick file read and nothing else. I also turned off waveforms in the timeline.

I saw no stalls. This makes me think that small files like the peak files aren't the culprit. It doesn't PROVE they aren't the problem but neither does it show that they ARE. I'm willing to back off about asking to be able to put peak files on a separate drive, though.

As I test out the above fix I'm only applying it to clips I get stalls on. The point is to see if the stalls eventually go away even if not all the audio files have been re-written.

I'm also wondering if the stalls increase in frequency as you go along.

For any of the SoFo folks: is their a way to make V4 behave more like V3? I'd like the program to stop dead after a stall. This way I could walk away without missing a stall. Is there a setting in the extended prefs?

Rob Mack

Comments

rmack350 wrote on 5/26/2003, 7:56 PM
So far, after re-writting the audio files of only the clips that stalled in the previous 4 passes I've been able to get entirely through a 15 minute series of 31 clips without a stall. Just once so far but I have to go so I'll try again later this eve.

This is on my slower P3 at home. I expect the 2GHz P4 at work to stall more because it just does.

BTW, when I made the new audio files I put them in the same folder on the 1394 drive as the rest of the media. I reset the audio from the default 44.1k to 48k to match my project and the sample rate of the original DV footage.

Rob Mack
24Peter wrote on 5/26/2003, 11:04 PM
If I understand it correctly, this workaround seems like a huge pain, esp when I have 50 events on my timeline with audio attached. But, the good news is, maybe it gives SoFo someplace to go in terms of solving this problem for us. Any of you SoFo guys care to comment?
rmack350 wrote on 5/27/2003, 1:22 AM
24P,

It does indeed seem like a huge pain although the actual writing of new wave files doesn't take too long. I think that this will need a script written for it. I also think it's reasonable for someone at SoFo to write it.

Of course, more people should be trying this out. A lot have fixes and work-arounds haven't panned out over time.

The disadvantages are:
-It's a hassle (but it would be less so if it could be automated with a script).
-It takes up about 5% more disk space.
-We don't really know if it's a silver bullet yet.
-It doesn't actually fix the problem.
-It takes the pressure off to find a fix.

Otherwise, it's not too terrible. The new file just gets added as a take so the tracks and events don't really change. At least it holds out the promise of letting people use the software until (and if) the problem gets fixed.

Rob Mack

jetdv wrote on 5/28/2003, 1:09 PM
The script is now available. It is called "Audio to new take" and can be downloaded from http://www.creativecow.net/articles/vegas_scripts.html

It is not very sophisticated and will try to use the same file names each time it is run. So, either only run it once or modify the file name between runs. If I get a little more time, I'll try to make the filenames more unique.
Albert Shroyer wrote on 5/28/2003, 2:13 PM
That is a usable workaround for Events (I used it to solve my problem with VV3).

But what about when this problem shows up when playing back from the Trimmer?
That's the real showstopper for me.

Regards,
Albert
joamoa wrote on 5/28/2003, 10:36 PM
Haven't tried this yet, but if you do a "save as" and select "copy and trim media" I believe that Vegas will split the Audio from the video. At least it did in VV3. This way, you could do it to the whole project and walk away. Granted, you will need twice the storage until the copy is complete.

Just a shot in the dark. Won't have time to try it for a few days. I'll report back.

PS: This problem really irks me beyond belief! I wish I knew this existed before I went out and bought a FW drive.