This question is asked frequently. The answer is yes, but there is an imporant caveat to bear in mind.

Drives are connected to the computer's PCI bus via "channels." For example, even the most basic motherboard has two IDE channels and each channel can support up to two drives - generally one master and one slave.

Here's the caveat. Communication on an IDE channel is one-way. That is, on any given channel, the PCI bus can either send data to one of the two possible drives or one of the two drives can send data to the PCI bus.

So, if you have two hard drives, and both drives are connected to the same channel, your system performance can actually be harmed rather than improved. This is particularly true if your application requires that data be read from one disk and written to the other. I believe that the slowest function possible is to copy files from one drive to another on the same channel.

Optimizing Vegas requires more than one disk controller. A reasonable setup is to install your "C" drive as "master" on IDE channel one and your DVD burner as "master" on IDE channel two. If your motherboard includes another onboard controller (or if you have a PCI controller), connect your second hard drive as "master" on IDE three.

A SATA controller will give the same benefit as an additional IDE controller.

Jan

That hasn't been my experience. Yeah, the fastest setup (other than RAID) is having separate drives on separate channels. But having 2 drives on the same channel STILL beats using one drive. Device calls take time, but not as much time as physically moving the heads. Of course, this depends on how far the heads have to move in a given case, so YMMV.

Assuming you're running at least an ATA-100 controller, the interface is so much faster than the drive itself, it really doesn't make much difference whether the drives are on separate channels or not.

John

I thought I'd seen results from a test of this before, but to refresh, I did a quickie. All drives are 7200RPM ATA100

Source is roughly 1GB MPG file on D: partition of primary master (25GB into a 40GB drive) to one of 2 locations:

C: partition on Primary Master (same drive) about 7GB into the drive - 91 seconds.

G: drive (primary slave) about 8GB into an 80GB drive - 36 seconds.

I know there is some fudge factor and as always YMMV, but...

So, if you have two hard drives, and both drives are connected to the same channel, your system performance can actually be harmed rather than improved. This is particularly true if your application requires that data be read from one disk and written to the other. I believe that the slowest function possible is to copy files from one drive to another on the same channel.

I have to disagree with this. One of the biggest advantage of two drives -- even when they are connected to the same ribbon cable, and hence to the same channel -- is the ability to dramatically reduce the time it takes to copy files or do simple renders. As jester and John pointed out, the speed of the interface is far faster than the drives, and therefore is not the limiting factor. Thus, if you have to read and write from the same drive, and it takes ten seconds to read, and fifteen seconds to write a given amount of information, then it will take twenty-five seconds to copy a file. By contrast, if you do this between two identical, but separate drives, it will only take a little longer than fifteen seconds.

This effect is really important when rendering AVI files. In this case, both the source media and rendered result are going to be the same size. If you have a project where much of your footage is cuts-only, and therefore not much rendering is required, a large part of the process is simply copying the source footage to the final AVI file (since Vegas does not "touch" DV AVI frames that aren't changed). For projects that are nothing but cuts, I have seen rendering times almost cut in half by rendering to a separate physical disk, even when that disk is on the same channel.

And do not forget external USB/Firewire Drives. I have a number of these specifically assigned to each project in process. After completion they may be archived or used again.

Another advantage I have discovered (now that I have added a second fast computer) is it is much easier to move files between computers to burn disks on one while working on the other.

Another way to look at it.

On my 1GHz Dell, SF and I went round and round about drop outs in the early days of V4. They helped me with DMA, virus checkers, background programs, and everything else they could thing of for several weeks. No go.

I had two drives, same channel. Nothing but drop outs. If I captured to 2 and worked on and rendered to 1 or 2, drop outs. If I captured to 1 and rendered on 1 or 2, nothing but drop outs. Any combination of 1 and 2, nothing but drop outs.

Added another drive, new channel. Used drive one for OS, 2 for the captured and work files, and 3 to render to. NEVER had another drop out.

By the way, # 3 is a removable standard drive. Never had a problem like may have with firewire drives. The computer just sees it as another bolted in standard drive, but I can remove it and stack it on the shelf and put in another one when I want. Takes about 5 seconds.

I had two drives, same channel. Nothing but drop outs.

Capturing to a drive other than the one that stores your O/S and program files can help eliminate dropped frames on a system that is marginal. However, with a fast computer (> 1 GHz), you shouldn't be experiencing dropped frames. I still routinely capture on an old 450 MHz PC, and also on a 700 MHz laptop, and don't get dropped frames. Your problem may well be something else, like DMA, background process, power saving features, indexing, virus protection, or almost a dozen other problems that I have personally verified can cause dropped frames.

What is the setup(fire wire, analog, cards, memory, etc) that allows you to capture on a computer this speed? I did not think that was possible. Using an older computer would speed my workflow.

Thank you for any information you could provide.

Here's my thinking on this issue. As always, I'm willing to be educated.

The issue of two draives on the same IDE channel is not one of shared bandwidth. If the two drives are each capable of 30 MB/sec sustained external transfer rates, that capability doesn't change if they are both on the same channel or on seperate channels. Further, there is no question that either drive's sustained transfer rate is substantially less than the PCI bus' maximum transfer rate of 132 MB/sec.

My comment had to do with communication protocol. The PCI bus can only "talk" to one device on an IDE channel at a time. This means that if one reads from one drive with the intent to write to either the same drive or to another drive on the same channel, the information must be read into system memory prior to writing back to either drive on that channel. This intermediate step has the potential to degrade performance.

What I have always understood to be true is that the PCI bus can access seperate IDE channells simultaneously. So, in essence, a read from a device on one channel can be immediately written to a device on another channel without first being written to system memory.

If I'm wrong in my understanding of PCI bus operation, please let me know. I don't want to be giving folks bad advice.

Jan

> If I'm wrong in my understanding of PCI bus operation, please let me know.

As far as I know you are 100% correct. Having just one drive incurs read time, seek time to the new location to write, write time, seek time back to the original location to read. Having two drives on the same IDE channel eliminates the two seek times (which could be significant) since the read head of one drive and the write head of the other can stay where they are, but the IDE bus will serialize the reads and writes just the same. This is still faster than having one drive. Having a two drives on two IDE channels does simultaneous reads and writes and is the fastest option.

I don’t have two drives on the same channel so I can’t test this but it would interesting if someone who had both configurations could copy a 2GB file and report back the times for a) same drive, b) two drives on one IDE channel, c) two drives on two master IDE channels. It would be even better the two drives were the same make and model number (or at least same specs).

~jr

Madk said: What is the setup(fire wire, analog, cards, memory, etc) that allows you to capture on a computer this speed? I did not think that was possible. Using an older computer would speed my workflow.

I have an old Gateway. I added Studio DV to it many years ago. This came with Pinnacle's 1394 card. I have no analog capture cards. I am running Windows 98 SE. I use a separate IDE 40 GByte drive, which is connected to the secondary IDE channel; my C: drive is connected to my primary IDE channel. I use Scenalyzer Live (a.k.a. SCLive) to do my capture, but years ago, I used to use Studio DV, and it worked just fine.

Just recently I started using an external Firewire drive on this old clunker, and this works great as well. This means I can use my main editing machine while capturing on the old clunker, and then simply plug the Firewire drive into my editing computer, start Vegas, and begin editing. I have a second Firewire drive, and I then connect it to the old clunker and keep on capturing. Very nice workflow.

I only dropped frames on this old computer on two occassions. The first was when I first set it up. I didn't have the DMA access set correctly on the newly installed 40 Gbyte drive. The second time I had a problem was after I added an HP printer that also installed software to monitor the printer's built-in CompactFlash card reader. This software -- HPHAMON -- is absolutely evil, and the card reader worked just fine if I eliminated the program from the startup file.

I have read Sony's Knowledgebase article on dropped frames, and I think it contains a lot of red herrings. In my experience with over a dozen computers, using Win98, WinME, Win2K, WinXP Pro, and WinXP Home, these are things that really matter if you are dropping frames:

1. DMA. Must be enabled. If it isn't, you will drop frames. Sony puts this as the 10th item in their dropped frame KB article. It should absolutely be the first item. DMA is mandatory.

2. Background programs. I disable EVERYTHING. I do not use anti-virus software or anything else. My computer boots in ten seconds. Most software that runs in the background is benign; some isn't. Get rid of it all using MSCONFIG, and then once everything is working, add back the programs you really think you need to have running in the background.

3. Indexing. Microsoft Office enables this by default. Turn it off.

4. Power saving. I only had one computer that was sensitive to this: My Presario 1800T (750 MHz Pentium laptop) would drop one frame every several minutes. I finally changed the options for powered operation to never turn off the screen or the disk drive. The strange thing was that the dropped frames happened long before either the screen or drive powered down. There must have been some power saving "polling" software that didn't give control back to the capture app in time.

Things that sometimes help include:

1. Drivers. It is amazing how much damage a poorly written driver can do. Video drivers are usually the worst culprits. Bad drivers can screw up the entire system.

2. Firewire devices. Some of the external Firewire drives are strange. I wrote about my experience with a Western Digital drive that caused all sorts of problem, but which WD was willing -- with no questions asked -- to replace out of warranty under a hot RMA. The replacement drive had no problems. This, plus the way WD handled it, leads me to believe that there was a design flaw in my drive that they knew about. Therefore, Sony's advice in their dropped frame KB article to disconnect all Firewire and USB drives is a good one.

Things that I have found to have no impact, and which take lots of time to track down, or to run:

1. Defragmentation. I guess it might be possible to get a disk fragmented to the point of dropping frames, but I really doubt it. In the old days of MFM drives (if anyone can remember them), when you had to worry about interleave settings, defragmentation was an issue. However, with modern drives, I can say with absolute certainty that I have never personally seen any performance issues related to defragmentation. Go ahead and defragment if you want to -- it won't hurt anything, except for the several hours of time wasted while your disk grinds away. Just don't expect it to do anything. (Take a stopwatch and time how long it takes an application to load immediately after booting the computer. Then, defragment. Re-boot, and immediately load the same application. See if you can measure any difference.)

2. IRQ settings. Modern "XP computers" are designed to share interrupts. I am not quite ready to say that shared IRQs could never cause a problem, but I can tell you for certain that it you try to change it, you will probably end up taking a pretty wild ride. Things might actually get broken in the process.

3. BIOS. Most modern BIOS are pretty well debugged. The updates usually address pretty mundane issues, like handling a peripheral device that didn't exist when the BIOS was first created. It has been a long, long time since I actually fixed anything by updating a BIOS (six years, to be exact, and it was needed to handle a 40 Gbyte drive on a BIOS that maxed out at 32 Gbytes).

I did one more test copying the 1GB file. Again, all drives are 7200RPM.
Review: Same drive - 91 seconds
Different drive, same IDE channel - 36 seconds

Different drive - firewire case - 42 seconds. This drive is pretty full; I'm 85GB into this 120GB drive, plus I'm sure the interface is the bottleneck here.

But my feeling is there's some splitting of hairs here and we're pretty much good to go as long as we're not on the same drive.