#Really Dumb Question
8 messages in this thread
I have seen, for the last couple of years, discussions about how CD-ROM
recording is a tricky process. One of the basic issues that everyone knows
about is the need for a fast hard drive that can get info to the recorder
without interuption.
Things like lots of small files, complex directory structures and the like can
also create problems. Most of this seems to be related to a need to get
everything written in one smooth pass with the recording. If all is not just
right, you end up with a wasted CD-ROM disc.
The blank media is not as expensive as it used to be, but it is still costly,
time consuming and wasteful to end up with an unusable CD.
I have never seen anyone ask the question, Why? It seems like it would be easy
enough to wait for a few spins if the buffer is empty, before writing the next
sector. Why does it need to be uninterupted, and is there hope for getting
around this problem?
BB
Britt,
Yes, use an Audio Visual drive and write your data to an image file before
writing it to the recorder. If you do this, you should have practically a 100%
success rate. This is not always necessary, but if your main concern is the
cost and not time, this method will save your discs!
Steve Styerwalt
OMI
The drive can't wait "for a few spins" while recording for a variety of
reasons, but there is hope. The problem can be solved entirely in software
without exposing customers to these issues.
My company makes a product called Spira that provides drive letter access to a
CD-R drive from any Windows application. You never have to worry about file
fragmentation or access speed. All these issues are dealt with at the Windows
device driver level, rather than in an application.
Check out our latest press release in the CD-Recordable library section of this
forum.
David Multer
Moniker, Inc.
Britt,
this is a difficult question but i try to answer it. Not all information here
will be absolutely accurate but this is not because i do not want to tell you
it's simply because i do not know better.
Now the top ten list why CD-Recorders cannot link write commands:
10. To help CD-WO media manufacturers double their income
9. Otherwise nobody would buy those expensive A/V drives
8. To get some suspense in the process of cutting disks
7. Because the standard (Orange Book) says so
6. To make software producers like me work out solutions to that problem
5. because it has always been so
4. to give me the opportunity of competing with D.L.
3. to trouble some CD pressing plants
2. It's getting hard finding additional reasons
But the top ten reason why CD Recorders cannot link write commands is:
the CIRC encoder which will devide the content of one CD sector into blocks and
interleve these blocks with blocks from two other sectors. In order to record
one sector you have to write three sectors to have all information flushed to
disc.
Peter
>>4. to give me the opportunity of competing with D.L.<<
D.L.????
>>the CIRC encoder which will devide the content of one CD sector into blocks
and interleve these blocks with blocks from two other sectors. In order to
record one sector you have to write three sectors to have all information
flushed to disc.<<
I suppose this was all done for some trivial reason, like performance. <g>
Thanks,
BB
Hi Britt,
In fact is was done to spread the information on the disc to increase the
efficiency of the error correction:
It is easier to correct 3 slightly damaged sectors as it is to correct one
really damaged sector.
Sincerely Peter
Thanks, Peter!
BB
Dear Britt,
The problem you are stating is the most basic problem of Track-at-Once writing
— you have to write a whole track in one smooth pass, any interruptions are
fatal.
One solution would be packet writing, where you write your data in much smaller
chunks, smaller than the CD recorder's buffer even, so you _can't_ suffer a
buffer underrun. The problem is that no existing CD-ROM drive can read a disc
written in packets. The ECMA 168 standard has been proposed as a way to stretch
the ISO standard to deal with this, but it would require CD-ROM manufacturers
to support it by hardware changes, and no one is jumping up to volunteer (many
of them are only just now waking up to the fact that their drives need to be
able to read recordable discs!). ECMA also doesn't address the needs of the
installed base of 50 million "dumb" CD-ROM drives.
Incat has applied for a patent on a whole new approach which would support
packet writing, while maintaining full backward compatibility with ISO and
existing hardware. It's called FlexCD, and there's a press release about it in
our library (GO INCATS). FlexCD was announced (and received enthusiastically)
at the February meeting of the Optical Storage Technology Association. BTW, it
will be licensed to whoever wants it, including our competitors.
Best,
Deirdre' Straughan
Incat Systems