Software glitches mar performance of Omniwriter - Loading the CD-RW recorder'ssoftware is a laborious task, complete with mystifying error messages

CD-recordable drives can make CD-ROMs but can't erase or reuse them. CD-rewritable
drives make disks that are reusable for nonarchival storage or backup. The Omniwriter
reads and writes both these types of disks as well as reads ordinary CD-ROMs. But it's not
yet an all-purpose CD resource.

Because recent GCN surveys have shown that almost half of federal desktop PC users
still use Microsoft Windows 3.x, I decided to test the Omniwriter CD-RW kit's Windows 3.x
software instead of the 32-bit Windows 95 or Windows NT version.

Hardware installation was straightforward, although the documentation had notable
omissions and errors, such as misstating the default directory (C:\SHTLMAN) for storing
driver files instead of the correct C:\EPST. The installation disk was also named
differently from what it was in the documentation.

Philips really should correct the documentation, which is in single sheets rather than
bound.

I used the included serial port SCSI adapter in my tests rather than a built-in SCSI-2
port. The only hardware problem I encountered was that, though I could install the
software under MS-DOS, the test system couldn't recognize the drive except under Windows,
and then only when the HyCD publishing software was running.

Even though the documentation is confusing, it has two pages of vital recommendations
for exactly what software you should use to record data, audio or backup CDs. Follow these
recommendations carefully to get the best compatibility under different operating systems.

For example, the documentation tells you to use the HyCD Music program with CD-R media
under Win95, but to change to CD-Publisher under Windows 3.x or NT if you are creating
audio CDs and want them as compatible as possible. If you make disks that might be read on
digital video disk players, run HyCD Data with CD-RW media under Win95, but use
CD-Publisher under Windows 3.x or NT.

I tried to follow the advice on Page 6 which reads, "If transportability is an
issue, we strongly recommend you use HyCD Data with CD-R media." Unfortunately, HyCD
Data is incompatible with Windows 3.x or NT, according to Page 9.

The same page indicated that HyCD Publisher is compatible with Windows 3.x, Win95, NT
3.51 and 4.0, so I used that.

Confused yet? The screen shots in the booklet didn't match up with the Windows 3.x
software, either.

Having worked with CD-R before, I knew it was important to do a test run first to avoid
wasting blank disks.

As it turned out, the first virtual image write ran nearly 10 minutes before halting
with the message that a certain file couldn't be recorded because its creation date
preceded Jan. 1, 1970. Apparently the software won't accept file dates that old.

Beware--many PCs hold a few oddly dated files generated in error by various programs,
and there's no easy way to spot them.

The same error popped up four more times as the software scanned 11,012 files on my
test machine's hard drive. I blocked the offending file each time, but I had to start
over. That meant the test took about 10 times longer than if the software had checked all
files for this error and reported them so they could be eliminated all at once.

I'm not complaining about the speed of each process, although a slow Pentium computer
won't perform well at such complicated tasks. My complaint is about having to start the
same thing over and over.

After I finally managed to block all offending files, the next test aborted because I
had not yet put a blank disk in the drive. Because it was only a simulated write, I had
left out the blank for safety's sake.

I've wasted CD-R blanks before, thanks to strange software quirks, so I prefer to keep
expensive blanks out of recorders unless I'm really going to write.

Apparently the software won't permit this even for a dry run, so I had to go all the
way back to the beginning again.

The drive ejected the test disk at almost every error, so I had to keep reinserting it.
For this reason, you should keep the drive close at hand during writes, even though you
would expect it to be a mostly hands-off process.

This time I saved the project at various stages. But when the next crash came, I
learned that the project I had saved was now marked old and couldn't be reused. I had to
start over once again. This time I did have a full list of the bad files on paper.

The documentation made no reference to any of these glitches, nor did it have any
suggestions for avoiding them.

I managed to save the next project and reload it as necessary. That was how I
discovered that a project file saved some details but not all. One thing it failed to save
was my alteration of the drive speed from 2X to 1X. That resulted in a ruined disk on the
first full test despite several hours of careful pretesting.

After five hours of preparation, I was ready to try the second write.

Although the software logged and displayed errors, and all the earlier ones had been
educational, the error messages were sometimes less than useful.

After my dozen or more test runs, each progressing a bit further before the software
rejected something and made me start over, I found the following message explaining why a
blank disk had just been ruined on the second write test: Error Log Info: e3,0,0,0,0: 0.

This cryptic message reappeared eight or nine times. But the documentation didn't
explain any error messages, so this one was totally useless.

When I finally did get the Omniwriter to work, the hardware did just fine, although it
was a bit slow compared with other CD-R drives I've tested.

On a different PC, under a different OS and a different file set, the results might
have been different.

That said, I find the documentation and the software supplied with the drive leave a
lot to be desired, at least under Windows 3.x.

I have easily created CD-Rs in previous tests using other software and drives. Philips
needs to rethink the software bundled with the drive. If it won't work properly with
Windows 3.x, Philips should say so.

Although it's labeled Philips HyCD, it's actually Creative Digital Research's $495
Publisher HyCD, among the most expensive programs and capable of creating ISO/HFS Mac,
MS-DOS, Windows and Unix disks.

The software problems didn't appear to be related to the new CD-RW capabilities,
because most errors occurred during CD-R creation--you know, the step that ruins the blank
if you make a mistake.

I tested on a system that just exceeded the minimum recommended configuration for this
hardware and software under Windows 3.1. Performance might be radically different under
Win95 or NT. But none of the problems seemed even remotely connected to the hardware's
slowness.

Philips' parallel port SCSI adapter is a great option for government users who lack a
SCSI port. It can move easily from computer to computer, even to notebooks, and it
eliminates the need to open up a chassis to install a SCSI card.

I had trouble configuring the test system to recognize the internal CD-ROM drive and
the Omniwriter simultaneously. This is not a problem when you write disks unless you want
to transfer data from a CD-ROM to CD-R or CD-RW. But it does mean you might have to
disconnect the Omniwriter entirely when you aren't creating disks.

Although CD-R and CD-RW drives can read CD-ROMs, it's a bad idea to use any $500
recorder regularly to take the place of a faster and much less expensive $50 CD-ROM drive.

Use CD-R and CD-RW hardware for recording and occasional reads--not as a substitute for
a cheap CD-ROM drive. This advice applies to all CD-R and CD-RW hardware, not just the
Omniwriter.

John McCormick, a free-lance writer and computer consultant, has been working with
computers since the early 1960s.