ZipCD-Direct CD-Easy CD differences
Susan
used with a CDR disk and the Direct CD program with CDR when used to add
a few files at a time to the CD during different sessions. Direct CD
seems to "open" the CDR and allow file copying and before ejecting,
performs some process that allows the CDR to be read for data in other
CD ROMs. Easy CD doesn't seem easy, so far. Seems like I can copy a
few times but the disk will read full with no more room even tho not
enough data has been copied to fill it. I gather something is lost in
"opening" it for different session to add more data. Any ideas or
advice?
Thanks
Dee...@ix.netcom.com
I've only used DirectCD with CD-RW discs; it never seemed to me like a
good idea for CD-R discs (although at the moment, I couldn't provide a
very good explanation as to why).
Both DirectCD and Easy CD Creator should have help files, and you can
probably find still more support info at www.adaptec.com. Here's a
good starting point for finding general CD-R(W) information:
http://resource.simplenet.com/urls.htm
Look for information on UDF and "packet writing"; that's what DirectCD
uses.
Carsten A. Arnholm
<7sq7oh$j...@dfw-ixnews11.ix.netcom.com>...
>
>I've only used DirectCD with CD-RW discs; it never seemed to me like a
>good idea for CD-R discs (although at the moment, I couldn't provide a
>very good explanation as to why).
You could argue that quite the opposite is true (i.e. that DirectCD is good
for CD-R disks, but not so good for CD-RW) . Here is an unauthorised attempt
at explaining why:
DirectCD uses a technique called UDF which I am told is a form of "packet
writing", where the files are chopped up in "packets" (this isn't visible to
the end user). There are two kinds (at least) of packet writing techniques,
"fixed size" packets and "variable size" packets. As the names indicate, the
files are either split in packets all with the same size (fixed size), or
they may have different sizes (variable size).
Any spot on a CD-RW disk may be rewritten max 1000 times, so when writing to
a CD-RW disk the "driver software" (i.e. DirectCD) tries to spread the data
to many different locations, and thereby prevents that any particular spot
on the disk becomes overused. This is where the "fixed size" packets come
into play, they help achieve the goal of not overusing any spot on the disk.
Unfortunately, there are two (at least) major drawbacks when formatting a
disk with "fixed size" packets: Using DirectCD, it takes "ages" to complete
(between 30 and 90 minutes), and it consumes approximately 20% of the disk
space, so the remaining space available to you becomes ~520MB instead of
650MB. Also, a CD-RW disk is easily corrupted (=> data loss).
A CD-R disk can't be re-written, so the "spot overuse" issue isn't relevant.
Therefore, there is no need to try to prevent it. This means of course that
the software is free to use a much more efficient way of storing data:
"variable size" packets. If you format a CD-R disk with DirectCD, it
completes in a minute or less and the formatting consumes neglible space on
the disk, so you can use all 650MB for your data. The good news here is that
you can write to the CD-R disk using *any* program (excluding of course CD
mastering programs like Easy CD Creator), just like any other removable
disk. Finally, when the disk is full (this can be done in one or several
"sessions"), you can "close" the CD to ISO format, so it becomes readable on
almost any CD-ROM (although I believe you can't read it via DOS/MSCDEX).
DirectCD does not allow you to choose which form of packet writing to use.
You get fixed size packets when using CD-RW disks, and variable size packets
when using CD-R disks.
Summary:
Why is DirectCD not so good for CD-RW?
- Takes very long time to format
- Consumes 20% of available disk space
- CD-RW disks formatted with DirectCD are unsafe. Disk corruption is not
uncommon.
Why is DirectCD good for CD-R?
- Almost no time/space overhead
- Any program can write to the CD-R disk
- Can make the CD-R disk readable on any CD-ROM
- A closed disk can't be corrupted, so the stored data are safe.
>Both DirectCD and Easy CD Creator should have help files, and you can
>probably find still more support info at www.adaptec.com. Here's a
>good starting point for finding general CD-R(W) information:
>
> http://resource.simplenet.com/urls.htm
>
>Look for information on UDF and "packet writing"; that's what DirectCD
>uses.
Exactly.
Carsten Arnholm
http://home.sol.no/~arnholm/
arn...@online.no
Dee...@ix.netcom.com
>Dee...@ix.netcom.com wrote in message
><7sq7oh$j...@dfw-ixnews11.ix.netcom.com>...
>>
>>I've only used DirectCD with CD-RW discs; it never seemed to me like a
>>good idea for CD-R discs (although at the moment, I couldn't provide a
>>very good explanation as to why).
>
>You could argue that quite the opposite is true (i.e. that DirectCD is good
>for CD-R disks, but not so good for CD-RW) . Here is an unauthorised attempt
>at explaining why:
[snip]
>Any spot on a CD-RW disk may be rewritten max 1000 times,
I believe that should be *at least* 1000 times.
[snip]
>Summary:
>Why is DirectCD not so good for CD-RW?
>- Takes very long time to format
Usually a minor inconvenience, IMO, but a fair point.
>- Consumes 20% of available disk space
The good thing about CD-RW discs is that space isn't really "consumed"
(as it is with CD-R discs). That ~20% of the disc space is just
unavailable to you for as long as the disc is using the UDF format.
The full 650MB can be made available at a later time with the use of
normal mastering software (like Easy CD Creator).
>- CD-RW disks formatted with DirectCD are unsafe. Disk corruption is not
>uncommon.
Why is that? No technical info I've read suggests that this should be
the case, but Usenet posts saying this seem to be fairly common.
I haven't yet lost any data on a CD-RW with DirectCD (although I could
have had I not been careful to verify its presence on the CD-RW before
deleting it from the source).
>Why is DirectCD good for CD-R?
>- Almost no time/space overhead
>- Any program can write to the CD-R disk
But this one applies to CD-RW also.
>- Can make the CD-R disk readable on any CD-ROM
>- A closed disk can't be corrupted, so the stored data are safe.
I looked at the CD-R FAQ, and I followed a link to a detailed article
about Packet Writing & UDF. I had been under the impression that
there was significant overhead involved each time data was written to
a CD-R (which there is when you're using Easy CD Creator; each session
has at least 13MB of overhead), but this is apparently not the case
with UDF. So I can see where it could definitely make sense for some
people to use DirectCD with CD-R discs. However, because data written
to a CD-R can't be changed, I only like to use a CD-R when I have a
disc's worth of data that I know I want to keep as it is (and there's
no point in using DirectCD at that point). I don't want to end up
with a bunch of coasters full of obsolete data; I don't care how cheap
they are (CD-RWs are cheap too these days). And I usually don't
generate data that I want to keep "permanently" one file at a time.
Carsten A. Arnholm
Dee...@ix.netcom.com wrote in message
<7ssu6o$b...@dfw-ixnews17.ix.netcom.com>...
>"Carsten A. Arnholm" <arn...@online.no> wrote:
>
>>Summary:
>>Why is DirectCD not so good for CD-RW?
>>- Takes very long time to format
>
>Usually a minor inconvenience, IMO, but a fair point.
>
>>- Consumes 20% of available disk space
>
>The good thing about CD-RW discs is that space isn't really "consumed"
>(as it is with CD-R discs). That ~20% of the disc space is just
>unavailable to you for as long as the disc is using the UDF format.
>The full 650MB can be made available at a later time with the use of
>normal mastering software (like Easy CD Creator).
Yes, but the issue was DirectCD and CD-RW. The ~20% overhead is only
relevant for CD-RW since DirectCD and CD-R's don't use fixed size packets.
>>- CD-RW disks formatted with DirectCD are unsafe. Disk corruption is not
>>uncommon.
>
>Why is that? No technical info I've read suggests that this should be
>the case, but Usenet posts saying this seem to be fairly common.
I think it is simply because the technology is still somewhat shaky. When
ejecting a CD-RW after using DirectCD, you can't use the drive's eject
button or any ordinary software eject. It must be completely controlled by
DirectCD, as it must write some info on the disk (TOC?) before ejecting it,
in order to make it readable later. If something happens before the disk is
ejected (e.g. power failure), there is a significant risk the whole disk
becomes unreadable. In practice, less severe incidents can cause serious
problems. I had to erase one of my CD-RW disks after DirectCD gave up on it
(don't know why). Luckily, I had other copies of the data elsewhere.
In addition, there seems to be (at least theoretical) problems with
compatibility between different versions of DirectCD. Don't be too sure that
upgrading DirectCD causes no problems with disks formatted with older
versions of the same program. The format isn't 100% standardised, or so it
seems.
You also have the issue of wear and tear. Sooner or later the disk may
aquire physical problems. If that happens, you have a problem.
Finally, a CD-RW isn't as safe as a CD-R, simply because it is rewriteable.
Accidental erasures do happen, just like with Zip and Jaz disks.
>I haven't yet lost any data on a CD-RW with DirectCD (although I could
>have had I not been careful to verify its presence on the CD-RW before
>deleting it from the source).
That is a very good idea. Which software do you use to verify your backed up
data?
>>Why is DirectCD good for CD-R?
>>- Almost no time/space overhead
>>- Any program can write to the CD-R disk
>
>But this one applies to CD-RW also.
Not the time/space overhead.
>>- Can make the CD-R disk readable on any CD-ROM
>>- A closed disk can't be corrupted, so the stored data are safe.
>
>I looked at the CD-R FAQ, and I followed a link to a detailed article
>about Packet Writing & UDF. I had been under the impression that
>there was significant overhead involved each time data was written to
>a CD-R (which there is when you're using Easy CD Creator; each session
>has at least 13MB of overhead), but this is apparently not the case
>with UDF.
That is my impression too. The site http://resource.simplenet.com is down at
the time of writing, so I don't have any details.
>So I can see where it could definitely make sense for some
>people to use DirectCD with CD-R discs. However, because data written
>to a CD-R can't be changed, I only like to use a CD-R when I have a
>disc's worth of data that I know I want to keep as it is (and there's
>no point in using DirectCD at that point).
You can write to a CD-R using DirectCD many times before closing the disk,
and you can remove the disk from the writer between the burns. There's no
need to collect a disk full of data before writing to a CD-R (although I
agree that a little planning never hurts ...).
>I don't want to end up
>with a bunch of coasters full of obsolete data; I don't care how cheap
>they are (CD-RWs are cheap too these days). And I usually don't
>generate data that I want to keep "permanently" one file at a time.
The problem of "coasters full of obsolete data" is easy to solve, throw them
away. CD-R's *are* reusable, you just don't use the same disk every time :-)
The question is really: What is most valuable, CD media or your data? The
answer is of course that your data is much more valuable. If you don't have
confidence in the media and/or storage technology, don't store your work on
it.
There is also another kind of overhead involved when using CD-RW compared to
CD-R, the writer is often required to write at a slower speed. I have a 4x
writer that sometimes refuses to write any faster than 2x on some CD-RW
disks. I believe this may be a problem with cheap CD-RW disks.
Anyway, I use both CD-RW and CD-R disks, and I use both Easy CD creator and
DirectCD on both types of CD's. The experience has been, however, that
CD-RW's are slightly less useful than I originally thought, and CD-R's are
slightly more useful than I had thought...
Carsten A. Arnholm
arn...@online.no
http://home.sol.no/~arnholm/
Dee...@ix.netcom.com
>Dee...@ix.netcom.com wrote in message
><7ssu6o$b...@dfw-ixnews17.ix.netcom.com>...
>>"Carsten A. Arnholm" <arn...@online.no> wrote:
>>
>>>- CD-RW disks formatted with DirectCD are unsafe. Disk corruption is not
>>>uncommon.
>>
>>Why is that? No technical info I've read suggests that this should be
>>the case, but Usenet posts saying this seem to be fairly common.
>
>I think it is simply because the technology is still somewhat shaky. When
>ejecting a CD-RW after using DirectCD, you can't use the drive's eject
>button or any ordinary software eject. It must be completely controlled by
>DirectCD, as it must write some info on the disk (TOC?) before ejecting it,
>in order to make it readable later.
If I eject a CD-RW using DirectCD, the DirectCD eject window shows up
regardless of how I eject it (i.e. drive button, drive icon, or
DirectCD icon). I've been using all 3 methods at various times, and
it doesn't seem to be a problem.
I've noticed that after writing a file to a CD-RW disc, DirectCD
performs 3 or 4 further write operations afterwards; and at least one
of these will "freeze" up the system (e.g. WinAmp stops playing for a
moment even though the MP3 file is entirely in RAM). It may be that
people who are trying to do lots of other things while writing to a
CD-RW disc this way could be interfering with DirectCD somehow. I try
to wait until DirectCD has finished its little writing binge before I
start doing other things with the system.
>>I haven't yet lost any data on a CD-RW with DirectCD (although I could
>>have had I not been careful to verify its presence on the CD-RW before
>>deleting it from the source).
>
>That is a very good idea. Which software do you use to verify your backed up
>data?
All I do is use Explorer to verify that the copied file shows up in
the directory on the CD-RW as it's supposed to (a couple of times, it
hasn't - even though the space for it was "consumed"). I've never had
a problem with a file on a CD-RW once it has shown up correctly in
Explorer.
>You can write to a CD-R using DirectCD many times before closing the disk,
>and you can remove the disk from the writer between the burns. There's no
>need to collect a disk full of data before writing to a CD-R (although I
>agree that a little planning never hurts ...).
Planning is a major reason why I like to burn a whole CD-R in one
operation. I like to keep my stuff organized when possible; that way,
I don't have to use programs to help me find things. ;)
>The problem of "coasters full of obsolete data" is easy to solve, throw them
>away. CD-R's *are* reusable, you just don't use the same disk every time :-)
But now that CD-RW discs only cost about twice as much (and can still
be rewritten at least 1000 times), this is no longer cost effective.
It would also annoy the environmentalists (hmmm...maybe I'll consider
it <g>).
>There is also another kind of overhead involved when using CD-RW compared to
>CD-R, the writer is often required to write at a slower speed. I have a 4x
>writer that sometimes refuses to write any faster than 2x on some CD-RW
>disks. I believe this may be a problem with cheap CD-RW disks.
Yes, this is a good point. And it also seems to be true for reading;
I don't think CD-RW discs can be read at high speeds like CD-R discs
usually can be.
Carsten A. Arnholm
<7t1vs9$p...@dfw-ixnews7.ix.netcom.com>...
>
>"Carsten A. Arnholm" <arn...@online.no> wrote:
>>I think it is simply because the technology is still somewhat shaky. When
>>ejecting a CD-RW after using DirectCD, you can't use the drive's eject
>>button or any ordinary software eject. It must be completely controlled by
>>DirectCD, as it must write some info on the disk (TOC?) before ejecting
it,
>>in order to make it readable later.
>
>regardless of how I eject it (i.e. drive button, drive icon, or
>DirectCD icon). I've been using all 3 methods at various times, and
>it doesn't seem to be a problem.
This is what I meant. DirectCD intercepts the eject command, no matter how
you issue it. This isn't a problem as long as it works, but one day, when
the system stops before you have ejected the disk, the disk may become
corrupted. Therefore, you might say this technology isn't as safe as
magnetic media.
Also, since DirectCD does this interception, normal software eject is
disabled (notice, here I mean software eject from within a program like Zip
Explorer). I have been wondering how to make Zip Exporer eject a disk
controlled by DirectCD, but I haven't found out. Today the command issued by
Zip Explorer is simply ignored by the system if I try to eject a CD
controlled by DirectCD. For other removable media, this isn't a problem. For
example, even if I have never physically seen a Castlewood Orb drive, Zip
Explorer has no problems ejecting Orb media (so I am told by users), but
DirectCD controlled CD's are different. The point is that a CD-RW under
DirectCD control does not behave 100% like other removable media.
>I've noticed that after writing a file to a CD-RW disc, DirectCD
>performs 3 or 4 further write operations afterwards; and at least one
>of these will "freeze" up the system (e.g. WinAmp stops playing for a
>moment even though the MP3 file is entirely in RAM). It may be that
>people who are trying to do lots of other things while writing to a
>CD-RW disc this way could be interfering with DirectCD somehow. I try
>to wait until DirectCD has finished its little writing binge before I
>start doing other things with the system.
Sounds like a good idea. I do that too. I suspect many others don't.
>>Which software do you use to verify your backed up data?
>
>All I do is use Explorer to verify that the copied file shows up in
>the directory on the CD-RW as it's supposed to (a couple of times, it
>hasn't - even though the space for it was "consumed"). I've never had
>a problem with a file on a CD-RW once it has shown up correctly in
>Explorer.
I may have had this problem. I had several copies of Windows NT service pack
5. Some of them worked, some of them didn't. A copy I had on a CDRW didn't
work. This isn't a proof, but it made me a little suspicious. Maybe I am
paranoid <g>.
>Planning is a major reason why I like to burn a whole CD-R in one
>operation. I like to keep my stuff organized when possible; that way,
>I don't have to use programs to help me find things. ;)
Well, obviously you are more organised than most people <g>.
>>The problem of "coasters full of obsolete data" is easy to solve, throw
them
>>away. CD-R's *are* reusable, you just don't use the same disk every time
:-)
>
>But now that CD-RW discs only cost about twice as much (and can still
>be rewritten at least 1000 times), this is no longer cost effective.
I am more concerned about the safety (and cost) of my data than the cost of
the media. I feel CD-R's are safer, therefore I use them more.
>>There is also another kind of overhead involved when using CD-RW compared
to
>>CD-R, the writer is often required to write at a slower speed. I have a 4x
>>writer that sometimes refuses to write any faster than 2x on some CD-RW
>>disks. I believe this may be a problem with cheap CD-RW disks.
>
>Yes, this is a good point. And it also seems to be true for reading;
>I don't think CD-RW discs can be read at high speeds like CD-R discs
>usually can be.
I have read some of my DirectCD CD-RW disks on my 24x CD-ROM drive. It
seemed to work, at least some of the time. To do that, I had to install
Adaptec's udfreader software, which is completely transparent after
installation. So the main issue of speed is in writing.
Dee...@ix.netcom.com
>Dee...@ix.netcom.com wrote in message
><7t1vs9$p...@dfw-ixnews7.ix.netcom.com>...
>
>>If I eject a CD-RW using DirectCD, the DirectCD eject window shows up
>>regardless of how I eject it (i.e. drive button, drive icon, or
>>DirectCD icon). I've been using all 3 methods at various times, and
>>it doesn't seem to be a problem.
>
>This is what I meant. DirectCD intercepts the eject command, no matter how
>you issue it. This isn't a problem as long as it works, but one day, when
>the system stops before you have ejected the disk, the disk may become
>corrupted. Therefore, you might say this technology isn't as safe as
>magnetic media.
I don't see why that would happen. Nothing seems to be written to the
disk during the ejection process.
>Also, since DirectCD does this interception, normal software eject is
>disabled (notice, here I mean software eject from within a program like Zip
>Explorer). I have been wondering how to make Zip Exporer eject a disk
>controlled by DirectCD, but I haven't found out. Today the command issued by
>Zip Explorer is simply ignored by the system if I try to eject a CD
>controlled by DirectCD. For other removable media, this isn't a problem. For
>example, even if I have never physically seen a Castlewood Orb drive, Zip
>Explorer has no problems ejecting Orb media (so I am told by users), but
>DirectCD controlled CD's are different. The point is that a CD-RW under
>DirectCD control does not behave 100% like other removable media.
Are you sure the disk isn't just being "locked"? This seems to be the
case when using the UDF reader with my Plextor CD-ROM drive. I can't
eject the disk unless I first "unlock" it (either with the Plextor
Manager tools or with Adaptec's SCSI Explorer). If you know how to
make Zip Explorer issue an unlock command prior to the eject command,
it might be worth trying.
>>I don't think CD-RW discs can be read at high speeds like CD-R discs
>>usually can be.
>
>I have read some of my DirectCD CD-RW disks on my 24x CD-ROM drive. It
>seemed to work, at least some of the time. To do that, I had to install
>Adaptec's udfreader software, which is completely transparent after
>installation. So the main issue of speed is in writing.
Have you tried testing the read speed of your drive with a CD-RW disc
in it? Testing with Adaptec's SCSIBench shows that my Plextor 4/2/20x
CD-RW drive can only read a CD-RW at around 1MB/sec (roughly 7x). And
I have to force my Plextor 12/20 CD-ROM down to 4x before it can read
a CD-RW reliably.
Carsten A. Arnholm
<7t4nms$l...@dfw-ixnews8.ix.netcom.com>...
>>you issue it. This isn't a problem as long as it works, but one day, when
>>the system stops before you have ejected the disk, the disk may become
>>corrupted. Therefore, you might say this technology isn't as safe as
>>magnetic media.
>
>I don't see why that would happen. Nothing seems to be written to the
>disk during the ejection process.
Have a look at Mike Richter's primer at
http://resource.simplenet.com/primer/udf.htm, notably the sections
"Universal Data Format (UDF)" and "How UDF is implemented - and when it's
safe"
The following is a quote from the "Universal Data Format (UDF)" section of
that page:
"When UDF is applied on an erasable blank, a new option is available. In
addition to being able to write variable-length packets and to erase the
whole disc, you can write, read and erase individual fixed-length packets.
Now the CD-RW begins to resemble a conventional floppy, where the packets
are the sectors, at least from the point of view of the user. That
capability is reflected in DCD 2.x. However, one problem of erasable blanks
is that they support a limited number of erasures - nominally, a thousand."
Seems 1000 was an upper limit after all... Mike Richter goes on explaining:
"Another problem is that when one rewrites on any drive, data may be written
over previous entries. Overwriting results in 'scrubbing' or
disproportionate reuse of a single region of the disc; it also leads to
fragmentation of files so that their constituent blocks are no longer
necessarily contiguous. For fixed-length packets, the consequences include
high overhead to keep track of all the blocks and inability to convert the
disc to any Level of ISO 9660. So an erasable blank formatted for UDF offers
only 494 MB of storage,"
I believe this has been improved to around 520MB with the current version of
DCD. He goes on:
" slow access (about the equivalent of 1x) and inability to make the disc
readable in a conventional player. Neither Microsoft nor Apple will be
reading fixed-length packets in their promised OS's, so those discs are and
will remain for a while useful only in the writer or in a MultiRead reader
with a suitable driver (such as the one now available from Adaptec's WWW
site)."
That's the udfreader software, I believe.
>>Also, since DirectCD does this interception, normal software eject is
>>disabled (notice, here I mean software eject from within a program like
Zip
>>Explorer). I have been wondering how to make Zip Exporer eject a disk
>>controlled by DirectCD, but I haven't found out. Today the command issued
by
>>Zip Explorer is simply ignored by the system if I try to eject a CD
>>controlled by DirectCD. For other removable media, this isn't a problem.
For
>>example, even if I have never physically seen a Castlewood Orb drive, Zip
>>Explorer has no problems ejecting Orb media (so I am told by users), but
>>DirectCD controlled CD's are different. The point is that a CD-RW under
>>DirectCD control does not behave 100% like other removable media.
>
>Are you sure the disk isn't just being "locked"? This seems to be the
>case when using the UDF reader with my Plextor CD-ROM drive. I can't
>eject the disk unless I first "unlock" it (either with the Plextor
>Manager tools or with Adaptec's SCSI Explorer).
I have no problems ejecting UDF formatted CDRW's in Zip Explorer when they
are read via my CD-ROM drive. The disks aren't locked in that situation, and
i can understand why: there is no way to write to them via the CD-ROM drive
:)
It sounds like you have a minor configuration problem? Or did you mean your
Plextor writer?
>If you know how to
>make Zip Explorer issue an unlock command prior to the eject command,
>it might be worth trying.
This could be disastrous if it worked, as it appears that DCD *does* write
to the disk prior to ejecting the disk (see below). Here's another quote
from Mike Richter's "How UDF is implemented - and when it's safe" section:
"With fixed-length packets, the process differs in some significant ways.
The key fact is that when the disc is ejected the VFAT is written to the
disc so that the location of the packets forming each file can be traced.
Logically, one would ask: Why not write the VFAT each time the disc is
written. The answer is, simply, that that would increase the nuber of writes
to the space that it occupies and would kill the disc more quickly. The VFAT
in memory becomes a FAT on the disc. Since the runout track was written, a
suitable driver then gives access to the files. That driver is provided by
the UDF Reader from Adaptec. Since a fixed-length-packet disc is always RW,
that driver is only useful in a MultiRead drive or a writer capable of
reading erasable media. A fixed-length-packet disc still in the drive after
having been written must be ejected (and have the VFAT written) to give
access to the new files. If power fails or the system is reset before
ejecting the disc, the new information will be lost and the disc may be
unreadable. With luck, a utility to recover what can be recovered will
become available, but at this writing the disc is vulnerable to such a
failure."
As you can see, there are non-neglible risks with this technology, even to
the point where it is acknowledged that there is no way to recover data once
corruption occurs. Simply unlocking the disk would probably corrupt the
disk. After all, there would be no reason to lock the disk if it was safe
simply to unlock it.
>Have you tried testing the read speed of your drive with a CD-RW disc
>in it? Testing with Adaptec's SCSIBench shows that my Plextor 4/2/20x
>CD-RW drive can only read a CD-RW at around 1MB/sec (roughly 7x). And
>I have to force my Plextor 12/20 CD-ROM down to 4x before it can read
>a CD-RW reliably.
This seems to be consistent with the quotes above. I haven't done any such
formal tests, but it may perhaps be an interesting excercise. I have a
Yamaha 4416S CDRW and a 24x CD-ROM (unknown brand). How do you measure the
transfer speed? Copy one big file (similar to testing Zip drives) and time
it with a wrist-watch? And what do you do to slow down your CD-ROM? I've
heard there is a German program called cdbremse? A standard test that anyone
could perform (and compare with other peoples results) would be nice.
Dee...@ix.netcom.com
>Dee...@ix.netcom.com wrote in message
><7t4nms$l...@dfw-ixnews8.ix.netcom.com>...
>>
>>I don't see why that would happen. Nothing seems to be written to the
>>disk during the ejection process.
>
>Have a look at Mike Richter's primer at
>http://resource.simplenet.com/primer/udf.htm, notably the sections
>"Universal Data Format (UDF)" and "How UDF is implemented - and when it's
>safe"
So far, I've only read what you quoted. But this is old information,
and some of it no longer applies.
[snip]
>Seems 1000 was an upper limit after all... Mike Richter goes on explaining:
No, the 1000 rewrites is sort of like a warranty; they're supposed to
be good for at least that.
I went looking for supporting info at http://www.fadden.com/cdrfaq,
and I found this:
"CD-RW media is more expensive than CD-R, but recent price reductions
have narrowed the gap considerably. There is a limit to the number of
times an area of the disc can be rewritten, but that number is
relatively high (the Orange Book requires 1000, but some manufacturers
have claimed as much as 100,000)."
This should be a better source of information. Even Mike R. lists it
"first and foremost" on his page of CD-R URLs.
>"Another problem is that when one rewrites on any drive, data may be written
>over previous entries. Overwriting results in 'scrubbing' or
>disproportionate reuse of a single region of the disc; it also leads to
>fragmentation of files so that their constituent blocks are no longer
>necessarily contiguous. For fixed-length packets, the consequences include
>high overhead to keep track of all the blocks and inability to convert the
>disc to any Level of ISO 9660. So an erasable blank formatted for UDF offers
>only 494 MB of storage,"
>
>I believe this has been improved to around 520MB with the current version of
>DCD.
Also, the part about disproportionate reuse of certain regions of the
disk has supposedly been corrected. And there is a ScanDisc utility
included with DirectCD now.
[snip]
>>Are you sure the disk isn't just being "locked"? This seems to be the
>>case when using the UDF reader with my Plextor CD-ROM drive. I can't
>>eject the disk unless I first "unlock" it (either with the Plextor
>>Manager tools or with Adaptec's SCSI Explorer).
>
>I have no problems ejecting UDF formatted CDRW's in Zip Explorer when they
>are read via my CD-ROM drive. The disks aren't locked in that situation, and
>i can understand why: there is no way to write to them via the CD-ROM drive
>:)
>
>It sounds like you have a minor configuration problem? Or did you mean your
>Plextor writer?
No, I meant the reader. I can't find any configuration problems, but
it does seem strange. I just tried it again, and it doesn't happen
now, so I guess it'll remain a mystery as to why it was happening
previously. I've made a lot of changes to my system since I last
tried that, so I can't even make a good guess as to what might have
corrected the problem (I did install a patch from Adaptec recently).
>>If you know how to
>>make Zip Explorer issue an unlock command prior to the eject command,
>>it might be worth trying.
>
>This could be disastrous if it worked, as it appears that DCD *does* write
>to the disk prior to ejecting the disk (see below).
I just tested this. Using Direct CD and Explorer, I did a number of
file operations on one of my CD-RW discs (deletes, copies, moves).
When I ejected the disk, I carefully watched the drive's write lights,
and they did not light up during the ejection process. I think the
primer's information is again outdated. This was probably changed
when they made DirectCD avoid disproportionate use of certain regions
of a disc; now, it apparently updates the FAT as soon as changes are
made (that must be what all those extra writing pulses are about).
[snip]
>>>Have you tried testing the read speed of your drive with a CD-RW disc
>>in it? Testing with Adaptec's SCSIBench shows that my Plextor 4/2/20x
>>CD-RW drive can only read a CD-RW at around 1MB/sec (roughly 7x). And
>>I have to force my Plextor 12/20 CD-ROM down to 4x before it can read
>>a CD-RW reliably.
>
>This seems to be consistent with the quotes above. I haven't done any such
>formal tests, but it may perhaps be an interesting excercise. I have a
>Yamaha 4416S CDRW and a 24x CD-ROM (unknown brand). How do you measure the
>transfer speed? Copy one big file (similar to testing Zip drives) and time
>it with a wrist-watch?
I used Adaptec's SCSIBench32 (64KB Transfer Size, Sequential I/O).
But it tends to be close to results obtained by reading a single large
file and timing it with a stopwatch.
>And what do you do to slow down your CD-ROM?
Since I have Plextor drives, I use their Plextor Manager software. It
allows me to force them to operate at 1x, 2x, 4x, 8x, or full speed.
A. Guest
(of data written). If you write to the disc frequently, this is not the
recommended method.
DirectCD is the easiest way to save data files directly to CD. Some of the
uses for DirectCD include:
* Archiving data
* Backing up a hard drive
* Transferring and distributing data to other Windows systems
* Quick local storage area
1. DirectCD 2.x formats CD-RW discs in fixed-length packets for random
erase. This requires more space on disc than variable-length packets, which
vary in length to fit the size of the data, so it's normal to have about 550
MB left for writing after formatting.
Also, DirectCD uses a technique called 'sparing'. If you were to erase and
write to the same spot on CD-RW media over and over, that 'hot spot' would
eventually wear out (after a few thousand writes), even if the rest of the
disc was still unused. Sparing is a technique that writes data evenly over
the disc, significantly extending the life of the disc. However, sparing
also requires significant overhead.
2. Packet Writing: DirectCD gives us the ability to add data incrementally
to a disc in small or large quantities. Data is written to the disc in small
"packets". It is possible to record even a single file at a time. Unlike
previous methods of writing data to CD (Disc-at-Once and multisession),
packet writing does not waste much time or disc space. There is no arbitrary
limit to the number of packets that can be written to a CD.
Two kinds of packets can be written: fixed-length and variable-length.
a. Fixed-length packets are more suitable for CD-RW in order to support
random erase, because it would be daunting (and slow) to keep track of a
large, constantly-changing file system if the packets were not written in
fixed locations. The drawback is that these packets, with a length of 32
kilobytes (as required by the UDF standard), take up a great deal of
overhead space on the disc. The normal data capacity of a CD-RW disc
formatted for writing in fixed-length packets is about 500 megabytes.
b. Variable-length packets save space, because the size of the packet can
vary with the size of the data being written. This is more useful when
writing to a standard CD-R disc, because these are write-once media, and it
is not necessary to track and allocate free space when files are 'erased'
(Note: On CD-R discs, files cannot actually be erased, but can be made
invisible.), and formatted discs have over 600 MB free space.
3. UDF (Universal Disk Format): UDF is a new file system for use on optical
media (such as CD-ROM and DVD), and other media. UDF has several advantages
over the ISO 9660 file system used by standard CD-ROMs. UDF is designed to
take advantage of packet writing, and has been accepted and approved as the
industry standard by all the major players in compact disc storage,
including Philips, Sony, and OSTA (the Optical Storage Technology
Association).
Since CD-R media does not require random erase (CD-R is write once media,
and can not be erased), fixed packet writing and sparing is not required.
4. Please note that you must always eject the CD from the writer before
powering down your system. There is a small amount of UDF data that must be
written to the disk to "finish" the session so that it will be recognized by
DirectCD the next time it is inserted.
If you close a disc to ISO in DirectCD, then add a session in Easy CD
Creator, you will not be able to reference the previous session. This is a
known limitation of our software which we expect to fix in future versions.
* CD-R Advantages
Good for permanent data storage
Less expensive per disc than CD-RW disc
Convert it to a format (ISO 9660) that can be read on other CD-ROM drives
Use when you do not need to erase the data
* CD-RW Advantages
Allows you to erase data and re-write new information (for example, updating
files)
Useful for making a practice CD or for testing the contents of a CD before
making a permanent one
For CDRW media, because it uses fixed length packets to allow for erasing,
it is formatted in 64K blocks. These packets require more overhead and
results in about 490-495 MB of usable disk space.
Carsten A. Arnholm
>4. Please note that you must always eject the CD from the writer before
>powering down your system. There is a small amount of UDF data that must be
>written to the disk to "finish" the session so that it will be recognized
by
>DirectCD the next time it is inserted.
>
>If you close a disc to ISO in DirectCD, then add a session in Easy CD
>Creator, you will not be able to reference the previous session. This is a
>known limitation of our software which we expect to fix in future versions.
"Our software"? You are an Adaptec representative? Why "A. Guest"?
Other than that, this was a good summary. It seems that DirectCD *does*
require some data, however small amount, to be written to the disk prior to
ejecting the disk. My concerns about data safety wrt. DirectCD in
combination with CD-RW seems to be well founded after all. IMHO, DirectCD in
combination with CD-R disks seems better in almost every sense.
A. Guest
Carsten A. Arnholm <arn...@online.no> wrote in message
news:gKsK3.563$EM4....@news1.online.no...
> A. Guest wrote in message ...
> >4. Please note that you must always eject the CD from the writer before
> >powering down your system. There is a small amount of UDF data that must
be
> >written to the disk to "finish" the session so that it will be recognized
> by
> >DirectCD the next time it is inserted.
> >
> >If you close a disc to ISO in DirectCD, then add a session in Easy CD
> >Creator, you will not be able to reference the previous session. This is
a
> >known limitation of our software which we expect to fix in future
versions.
>
>
> "Our software"? You are an Adaptec representative? Why "A. Guest"?
>
> Other than that, this was a good summary.
Sorry about the confusion - this information was collated/copied from
numerous pages on the Adaptec website; I am not affiliated with nor work for
Adaptec. Glad you found the information useful!
Anonymous Guest
agu...@usa.net
Dee...@ix.netcom.com
[snip]
>It seems that DirectCD *does*
>require some data, however small amount, to be written to the disk prior to
>ejecting the disk. My concerns about data safety wrt. DirectCD in
>combination with CD-RW seems to be well founded after all.
I don't believe that the current version (2.5d) of DirectCD needs to
write anything to a CD-RW prior to ejecting it. I've been keeping an
eye on it, and all of the necessary writing seems to be done
immediately following the writing of data. Again, some of that
information was not up to date.
>IMHO, DirectCD in
>combination with CD-R disks seems better in almost every sense.
It can have some advantages, but so can CD-RW, IMO. Isn't it nice
that we have a choice? :)
Carsten A. Arnholm
<7tfa26$i...@dfw-ixnews21.ix.netcom.com>...
>
>[snip]
>
>I don't believe that the current version (2.5d) of DirectCD needs to
>write anything to a CD-RW prior to ejecting it. I've been keeping an
>eye on it, and all of the necessary writing seems to be done
>immediately following the writing of data. Again, some of that
>information was not up to date.
Ok. I guess your information isn't supported just by the fact that you can't
see any effect via the drive's write lights? Would that be reliable enough?
>>IMHO, DirectCD in
>>combination with CD-R disks seems better in almost every sense.
>
>It can have some advantages, but so can CD-RW, IMO. Isn't it nice
>that we have a choice? :)
Yes <g>. CD-RW does indeed have some advantages, but my point is that I
would think "thrice" before trusting DirectCD in combination with CD-RW for
critical data. For testing, non-critical storage etc. CD-RW is great. I use
it myself on my Yamaha 4416S.
Dee...@ix.netcom.com
>Dee...@ix.netcom.com wrote in message
><7tfa26$i...@dfw-ixnews21.ix.netcom.com>...
>>
>>[snip]
>>
>>I don't believe that the current version (2.5d) of DirectCD needs to
>>write anything to a CD-RW prior to ejecting it. I've been keeping an
>>eye on it, and all of the necessary writing seems to be done
>>immediately following the writing of data. Again, some of that
>>information was not up to date.
>
>Ok. I guess your information isn't supported just by the fact that you can't
>see any effect via the drive's write lights? Would that be reliable enough?
I think it's reliable enough, but I'll try something else.
Using an "empty" (formatted) CD-RW disc with DirectCD, I copied a
couple of files to its root directory. Then, I created a folder, and
I copied a few more files in there. When the write pulses ceased, I
used Ctrl-Alt-Del to close DirectCD. Then, I ejected the disc (I had
to use SCSI Explorer to unlock the drive first). I put the disc in my
CD-ROM drive, and all the files I had just written were visible and
accessible (with the UDF reader installed, of course). Then, I took
the disc to my other system and put it in my old Ricoh CD-RW drive. I
wrote a few more files to the disc there, and everything appeared to
be working normally.
>>It can have some advantages, but so can CD-RW, IMO. Isn't it nice
>>that we have a choice? :)
>
>Yes <g>. CD-RW does indeed have some advantages, but my point is that I
>would think "thrice" before trusting DirectCD in combination with CD-RW for
>critical data.
Well, one should keep multiple copies of anything deemed "critical" -
preferably on several different types of media. With that in mind, I
think CD-RW and DirectCD is fine as one of those types of media. I
wouldn't trust even CD-R with an only copy of anything critical; for
one thing, they can scratch fairly easily if you drop them.
Dave
"Carsten A. Arnholm" wrote:
>
> Dee...@ix.netcom.com wrote in message
> <7sq7oh$j...@dfw-ixnews11.ix.netcom.com>...
> >
> >I've only used DirectCD with CD-RW discs; it never seemed to me like a
> >good idea for CD-R discs (although at the moment, I couldn't provide a
> >very good explanation as to why).
>
> You could argue that quite the opposite is true (i.e. that DirectCD is good
> for CD-R disks, but not so good for CD-RW) . Here is an unauthorised attempt
> at explaining why:
>
> Summary:
> Why is DirectCD not so good for CD-RW?
> - Takes very long time to format
> - Consumes 20% of available disk space
> - CD-RW disks formatted with DirectCD are unsafe. Disk corruption is not
> uncommon.
>
> Why is DirectCD good for CD-R?
> - Almost no time/space overhead
> - Any program can write to the CD-R disk
> - Can make the CD-R disk readable on any CD-ROM
> - A closed disk can't be corrupted, so the stored data are safe.
>
> >Both DirectCD and Easy CD Creator should have help files, and you can
> >probably find still more support info at www.adaptec.com. Here's a
> >good starting point for finding general CD-R(W) information:
> >
> > http://resource.simplenet.com/urls.htm
> >
> >Look for information on UDF and "packet writing"; that's what DirectCD
> >uses.
>
> Exactly.
>
> Carsten Arnholm
> http://home.sol.no/~arnholm/
> arn...@online.no
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----