commandline burning to DVD-R (maybe OT?)

mkisofs and cdrecord would be my choice. I'm not sure if you can build working copies for WinXP, though.

They certainly work fine for CDR burning under W2K. Prebuilt binaries are available if you look around (try searching for CDR Front End).

Nero V6 comes with "nerocmd.exe" which can burn CD's & DVD's from the command line. I use it as a part of our backup scripts to burn files to a DVD-R. The only documentation I can find is the output of it's "help" option but it wasn't hard to get working.

Regards Peter

Thanks to all. I did stumble across cdrecord and mkisofs in my searches but it wasn't immediately obvious to me as to whether it can do file-at-a-time writing similar to the UDF driver.

I've never had to delve into the intricacies of CD/DVD buring before so my concerns about an implementation like this are:

My need is for the retrieved files to be written to the DVD media as soon as possible after they are received. This is a customer requirement not a technical one. Is this possible with cdrecord?

Are there any special steps that must be taken before the media is removed (i.e finalising etc)?

The media is typically re-used until it's full i.e inserted/removed many times. Is this possible with cdrecord (I'm assuming some sort of multisession operation)?

Thanks for any further suggestions.

Chris.

Thanks. Do you know how well it handles one file at a time (potentially thousands of them) and ejecting & re-using the same media (while there's free space on it)?

Chris.

You can make that work, but it will be a pain, and the result will not be as reliable as you might wish.

A better solution would be to put a low-cost PC with two hard drives on the other end of an ethernet cable and use XXCOPY (that's not a typo; XXCOPY, not XCOPY) to send the data to both.

I think if file-at-a-time is a requirement you are stuck with UDF. The only other standard way I know of to write only a little data at a time is to go multi-session. One wastes a fair amount of space for each session, and I am not sure how many sessions one may fit onto a disc.

Regards Anton Erasmus

We did a stand-alone embedded processor based "one touch" CD copier that was used with a robotic disk change station for unattended CD copying. The unit supported two IDE channels. One for the CD-ROM source disk and one for the writable drives.

By adding a Hard drive in place of the CD-ROM source disk, this unit could be adapted to spool data onto the Hard Drive and then copy data out to the writable drive.

We did some work with the Buffer Under Run Protection (Burn Proof) on the writable drives. Our early work inidcated that these drives should be able to handle streamed data. Data could be streamed into the drive. When the buffers reached some level, the buffer was released to the writer for transcribing onto disk. While this approach might be possible, using a hard drive to buffer records would be more reliable.

It was a great project. Did it first for SCSI and then when the market shifted, ported it to ATAPI.

Blakely