Packet writing is new, flaky and ill-supported. Why in the world would anyone need it?
In fact, practically no one does need it. But it may make your life easier if you use it well. It will certainly make it harder if you use it badly.
With variable-length packets (yes, there should be a better term), you can write arbitrarily many files to a CD-R as they become ready to write. Each day, you download from a mainframe all of your correspondence, transaction history, presentation drafts and other information to get you started fresh the next day. That information updates your HD - but drop a copy onto a CD-R for permanent record and to be sure you can start at full speed tomorrow even if the network goes down. A few megabytes - or even tens of megabytes - need to get easy, non-volatile storage in chunks: a perfect application for variable-length packets. Or you have fifty pages to scan and OCR tonight and a batch-job program which will do it and will save both images and text as it goes. Let those pages be output to a UDF CD-R; when everything looks good the next day, finalize the disc to ISO 9660 Level 3 and file the disc. I update one WWW site each week with several MB of files. Each week, I archive the site to UDF so I can return to my mistakes later and apologize appropriately.
Variable-length UDF is rarely an alternative to conventional CD-R. Basically, it's the tool for what we used to do with floppies and now might do with Zip discs or flash devices. The price of the CD-R is low, so we can feel happier about saving history with it. But when you have truly critical data or very large blocks to deal with at once, packet writing is not your best choice for primary storage. In the example of HD update, primary storage is on the HD and the UDF disc is backup. In the case of OCR, the final output on your HD is the primary product; the UDF is a way to verify what was done and to repeat the OCR even if the originals are not to be scanned again. Once closed to Level 3, the UDF disc is as reliable as any CD-R and almost as versatile, so `wasting' the 15 MB or so to finalize should be routine.
Fixed-length packets are written only to erasable blanks and provide a very different sort of environment and very different potential. Think of a fixed-length UDF disc as a slow drive like a very large floppy - and try to think of its use as we used floppies before HD's became common. (That was not so long ago for Apple users.) You can install a program to such a disc and run it from there even as it updates its files. If the program is designed to be used that way, it will be CPU-intensive, not disc-intensive, and will manage DLL's and overlays differently from the way it would on a fast HD. There are few programs today written for that sort of thing, but three possibilities should be considered for CD-R use: cleaning and compressing audio and compressing video. Those are programs of modest size which write relatively little information after a lot of processing. On some computers, MP3 compression of a redbook WAV takes about as long as it does to play the WAV. The file can be read from a conventional CD-ROM (at about 150 kilobytes/sec) and execution and output can use fixed-length packets, writing 15 KB/sec. That format is written at around 2x, so the delay for slow writing does not matter much.
Using fixed-length packets where variable-length makes sense (e.g., for backups) is quite possible, but is usually a false economy. You can work that out for yourself, considering intial cost, loss of space to formatting, slow write, inability to finalize, and - most important for many - fragility and poor reliability. Fixed- and variable-length packets are good solutions for some situations, but can be frustrating or costly if used incorrectly.
E-mail me at cdrecording@mrichter.com
Return to Mike's home page