You are here

Disk Storage

Cutting Edge By Dave Shapton
Published November 2000

Magneto‑optical disks (as used by this Yamaha D24) are normally amongst the safest of storage media.Magneto‑optical disks (as used by this Yamaha D24) are normally amongst the safest of storage media.

Disk storage may well be the future of recording but, as Dave Shapton explains, it pays to be aware of some of the potential pitfalls before entrusting your precious original master recordings to such media.

I think it's fantastic that we're starting to see fully‑featured multitrack disk recording systems. The latest offerings from Yamaha (see the AW4416 review this month) and Akai are so powerful that I read about them with a feeling of disbelief. And this was despite the fact that all the trends in the audio and computing industries have been pointing towards cheap professional hard disk recorders for years. Why is it, then, that if I had to complete a major recording project for a client, I'd still think twice about committing the multitrack master recording to a hard disk.

A Question Of Dependability

Akai's DPS16 hard disk recorder offers various Project backup and copying options. Backing up can be managed via SCSI, to fixed or removable hard drive or CD writer. Alternatively, you can back up to DAT using the S/PDIF output.Akai's DPS16 hard disk recorder offers various Project backup and copying options. Backing up can be managed via SCSI, to fixed or removable hard drive or CD writer. Alternatively, you can back up to DAT using the S/PDIF output.

A couple of years ago, I had a call for help from a colleague who was working at a major west London studio that specialises in recording orchestral works. He was assisting a record producer to whom he had sold a hard disk recording system that recorded directly to magneto‑optical (MO) disks. MO disks are actually one of the most reliable of storage media: you can throw them across the room and (as long as they are in their protective cartridges) jump on them, although such activity would not be considered to be 'best practice'.

The recording project in question had been going well. You could only describe a methodology of recording a 50‑piece orchestra direct to MO drives as 'bold' but, nevertheless, it was looking good: the quality, (which was at 24‑bit resolution with a 48kHz sampling rate) was excellent, and it was a flexible way to record. As a precaution, a Sony 48‑track recorder was paralleled with the disk recorder. As it happened, this was a very good thing because, on playback, some of the tracks were missing. It was as simple as that. They weren't distorted or out of sync. They were just missing. This is not what you want when recording orchestras.

It turned out that the MO media was the problem. The media met all the manufacturer's tests, but the disk recorder didn't like them. In order to extract multitrack performance from MO drives, the manufacturer had designed a disk operating system that wrote to the disks in a specific way. Although disks normally give very low error rates (they have to because a single‑bit error could cause a program to crash — or an airplane for that matter), by bypassing the 'firmware' in the drives to improve performance, the 'safety' of the data was compromised. It seems that the compromises introduced by the disk recorder manufacturer to aid performance were tolerated by disks from some makers, but not others. This kind of 'high‑level' error (see box, right) is endemic to the use of non‑linear media for recording.

The relationship between hardware and software in disk recorders is, to the user, a completely grey area, and it's an area that just doesn't exist with digital tape recorders. Actually that's not strictly true, because digital tape recorders probably have as many processors running software in them as the average digital audio workstation. But what they don't have to do is rely on tables of contents to find audio on the tape. To find a piece of audio on a tape you just go to it, physically, by moving the tape. Moreover, if one part of a tape is destroyed, then the rest of it is probably intact. Destroy the directory on a disk drive and the rest of the contents are meaningless.

Now, I don't want you to think that I'm making a case for staying with tape for ever and relegating disk recorders to the status of curiosities that never really worked. Far from it. I absolutely believe that disk recording is the future and that tape use is, shall we say, winding down. But for this to happen I'd like to see improvements in a few areas.

Room For Improvement

Firstly, automatic backup of projects. I know what it's like because I've done it myself: worked for days on a project without saving it. I know this is madness but people still do it. I've lost enough material to have learned that risks like this aren't worth it and that the tedium of a backup routine is trivial compared to the trauma of losing work. Anyone who uses their computer for a living is going to have data on it that is worth more than the computer.

So it's surprising that major application programs such as sequencers and audio editors don't have more in the way of backup protection. Autobackup, where a copy of the current project file is created using preset timed intervals, helps. Even better is version management. This is like a sort of infinite undo facility but better, because you can go to any version of a project directly — without 'undoing' all the previous versions.

What's possibly even more important than this is backing up disk directories, and any type of data structure that can influence the integrity of a project. There also needs to be better monitoring of media data files. I've seen plenty of projects that won't load or play properly because of bad media. Even if media becomes corrupted by being written to a bad area on a hard disk, there's no reason why it should bring a whole project to its knees. Why not test the media dynamically as it is called for use in a project? If the numbers don't add up, the program should warn the user, who can decide whether to delete the problematic media, or to soldier on and take the consequences.

Then there are the hard disks themselves. Let me reiterate that I'm not anti hard‑drive at all. When you look at the technologies involved, at the prodigious storage capacities available these days, and then look at the cost, I think hard disks are something of a technological miracle. Even more so when you consider reliability: these things are designed to work reliably for three or even five years, 24 hours a day!

But they do go wrong. And when they go wrong the chances are that you will lose all your data. It's like cars and airplanes. If your car breaks down you'll gently slow down and then stop. Then you get out and phone the breakdown service. That's a bit like a problem with an audio tape recorder. Get the engineer in and he or she will fix the broken part and off you go. If the tape is damaged, you can splice it together with little or no loss. When an airplane fails it's different. It's catastrophic. That's also how it is with disk drives. And that's why I would not use them for a live, unrepeatable recording.

Solutions

So how can you make recording to hard disk as safe as tape? The answer is to build in redundancy. Redundancy is a word from the IT universe, and it means storing or recording extra information that will allow your data to be retrieved in the event of a partial failure in the storage medium. It goes without saying that if you are going to store information that will help you retrieve data from a duff drive, then you can't store it on the dodgy device itself.

What you need is a stack, or array of drives. (This involves some more IT terms). JBOD stands for 'Just a Bunch Of Drives'. A JBOD array is what you might have already. It's what you have whenever there is more than one drive. The alternative to JBOD is a RAID array. RAID stands for Redundant Array of Inexpensive Drives. The technique has been around for ages and was originally a way of building large drive capacities from smaller, cheaper drives.

Using drives in RAID arrays opens up all sorts of possibilities. Put several of them in parallel, so that the data is spread uniformly between them, and they act like one big, very fast, drive. Effectively you are using their speed in parallel. This configuration is called RAID level 0 and Windows NT and 2000 support it without any additional hardware (apart from the extra drives, of course). The increase in speed can be phenomenal. A recently released video capture card can process four channels of uncompressed video. That's around 100Mb per second. To handle this reliably you would need something like an eight or 12 disk RAID 0 array (ignore the claimed data rates for hard disks — they bear little resemblance to real‑world sustained data‑rate performance). There's a downside to this. If any of the drives in a RAID level 0 array fail, you lose all of your data. It's as simple as that. If you have eight drives then you have eight times the chance of losing your data.

<h3>Speed And Safety</h3>

So what if you need speed and data safety? Well, you have to use extra drives. The easiest RAID level to understand, level one, is also called 'disk mirroring', because that's exactly what it does. It writes the same data to two identical drives. If a drive fails, the drive controller switches to the spare drive with no performance or data loss. The downside is that your storage costs are exactly doubled. Another RAID level that is worth considering is level five. With this level, you have as many disks as you need to hold your data, plus an extra one. Data is spread across the disks in such a way that if any one disk fails, the entire data set can be reconstructed from the data on the others. If you use 'hot swap' drive bays, then you don't even need to power down and reboot!

I was demonstrating a digital audio workstation to a client a few years ago using a RAID level five disk system. One of the drives failed during the demo, but the first I knew about it was when I looked at the status LED on the drive array. Neither I nor my client was aware of the failure at the time. With level five there is a performance penalty: it takes time to write the redundant data to the drives — but drives are getting so fast now that this is less of a problem than it used to be.

RAID level five may be the answer to data safety in direct to disk recording. And it's easy to set up, too. You can either use a RAID controller (in place of your normal SCSI card) or — if your workstation/recorder doesn't allow you to replace its SCSI controller — you can get external RAID controllers that sit on top if a bunch of drives, and have a SCSI to SCSI interface to your existing SCSI controller. As far as your workstation is concerned you've just added another, very large drive. You can even get controllers that let you install a 'spare' drive, which is only brought into use in the event of another drive's failure. Which means, incredibly, that as many as two drives could fail before your data was even under threat from another drive failure.

Of course, none of these RAID configurations will help you if you fall victim to the kind of 'data corruption' error that I was talking about earlier — but it's certainly nice to know that your session isn't likely to be trashed by a power spike or a mechanical failure in the almost inconceivably complex technology that you find in modern disk drives.

High Level Errors

'High‑level' errors are errors in finding the data and interpreting it, rather than what I would regard as 'low‑level' errors, which show up as damage to the media data itself. Low‑level errors affect the sound. With high‑level errors — there is no sound.

The consequences of high‑level errors can range from a segment or region of audio that refuses to play (or stop playing!) to the loss of a whole project. Disk drives don't get the blame for all of this, because it is just as common for recording or editing software to corrupt the project. I've seen several examples of faulty timecode arithmetic trashing projects, sometimes traceable to the fact that American software was not tested with European timecode (or vice‑versa).