More Reviews




Using EIDE Drives in DV

This artcle first appeared on the and is reprinted here with permission

Using EIDE Drives in DV:
An Answer to a Common 1394 (Firewire) Question

by Kathlyn Lindeboom, Director,
Cambria, California USA

Just thinking about getting a new DV system or adding a DV system to your existing studio? Wondering what the issues are when setting up the drives for your new system? Still thinking that SCSI is the way to go? Not sure if the EIDE drives will be fast enough? The WWUG's co-founder, Kathlyn Lindeboom, explores these and other issues in this article that unravels the facts and the fiction about Firewire, iLink, DV, IEEE 1394.

A visit to many of the WWUG's forums related to using IEEE 1394 (DV, iLink, Firewire, etc.) for video production, shows that a common question which regularly arises is: "Can I use EIDE drives in my new system?" The reason this gets asked so often, is that many who come to the 1394 world after years of using high data-rate MJPEG systems like Avid, Discreet, Media 100, etc., find it almost hard to believe that the throughput issues they've lived with for so long simply don't exist in the magical world of IEEE 1394.

Motion JPEG (MJPEG) systems require extremely high data throughputs. And more importantly, these high data rates (usually 5-9MB per sec) need to be "sustained rates" -- "burst" speeds need not apply in the World of MJPEG. Any drive that can't sustain its maximum throughput, means dropped frames as the drives slow down and speed up. Because of these speed issues and the bandwidth needed by MJPEG systems, the only real solutions have been expensive SCSI drives.

Back in the early days of MJPEG nonlinear editing systems, the BUS architectures of the various PC motherboards (early PCI for PCs; Nubus for Macs) meant that the throughputs weren't adequate for capturing large data rates to a single drive; so manufacturers came up with "striping" schemes (like Remus, Anubis, etc.) which basically split the data into two or more streams with each stream handled by its own drive. Operating in this manner, no one drive was carrying more weight than it could handle. These multiple drives acted as if they were one large drive. But there was a downside to this: If one of the drives that made up this single "logical" drive failed, you lost access to all of your data. (And old-timers who owned Micropolis™ 1991's knew this experience especially well back in 1995-6.) The technical name for these set-ups were RAID systems.

When Apple invented the technology which we know today as DV, it created a standard that allows personal computers to handle sustained speeds of about 400MB (megabits) per second -- as compared with USB systems which only work at 12MB. But one of the smartest that Apple did with the technology, was to throw it into the public domain where the International Standards Organization dubbed it IEEE 1394. Apple trademarked their name for it -- "Firewire" -- but others use the exact same technolgy under names like 1394, iLink, DV, etc., and they are all referring to the same thing.

This robust and market-wide technology has many advantages and has allowed for the incorporation of drives that have no ID issues like SCSI, don't need to be terminated like SCSI drives and are faster than SCSI drives. They also don't suffer from the legendary heat problems that destroyed companies like the aforementioned Micropolis. These new Firewire drives are also hot swappable and that means that users don't need to shut down their systems and reboot to add or remove drives (as well as other peripherals like scanners, etc.).

The most revolutionary part of the Firewire system is the fact that for the first time, the same digital compression/decompression (codec) that resides on the computer is now also part of the camera or other DV peripheral. (Yes, in the magical world of DV, the camcorder is a peripheral the same as a hard drive, etc.) When you shoot your scenes using a DV-based camcoder, you are actually "recording" these scenes "through" the codec and in a format that is just binary 1's and 0's -- in the exact format that the computer's DV codec is using. So you are not really capturing your images as in an MJPEG system which takes analog data and "compresses it on the fly" by digitizing through an expensive video board to drives that are running at incredibly fast speeds -- in an effort to avoid dropping frames. EIDE drives are more than adequate to handle the transfer of data from your camera to your computer and to work with the files once they get there.

EIDE drives are more than fast enough to handle the 3.6MB per second data rate that is at the heart of the IEEE 1394 standard. This happens because as I mentioned earlier, the codec on the camera and the codec on the computer are operating to the same standard and whereas a 3.6MB transfer using an MJPEG based analog system would result in a terrible picture in all likelihood -- the 1394 gives a very high quality image at this data rate because there is no recompressing going on in the system. (This changes once you start the editing and compositing process but that's a subject for another article altogether.)

EIDE drives are very inexpensive and are more than adequate for use in 1394-based systems. If you are tempted to think that faster is better and that SCSI would be a better option -- think again! There is simply no need for SCSI prowess in the magical world of 1394. Save your money and buy extra RAM or more storage.

©2001 by Kathlyn Lindeboom. All rights are reserved.

copyright © Michael Horton 2000-2010 All rights reserved