Version 1.04, 2002-10-28, written by Steffen Huber, steffen@huber-net.de
During support, it turned out that some questions are asked quite a number of times, therefore it seemed to be sensible to produce that document.
One of the most frequently asked questions, and the most difficult to answer. In the PC world, CD-R software manufacturers usually get new drives for free to ensure wide compatibility of new drives with software. Unfortunately, the RISC OS market is (at the moment) too small to be interesting for the drive manufacturers. So testing of drives with CDBurn is clearly limited and often carried out by RISC OS dealers who sell CDBurn/drive bundles. I have some of the most popular drives myself to ensure compatibility of new versions. And every customer is asked to report working drives.
There are several "classes" of drives which can be distinguished:
For a list of known supported drives, please look at the Supported Devices page.
Generally, things don't look that bad. Drives are nowadays mostly MMC compatible, and CDBurn's writing routine is now very stable and "forgiving". At least for IDE drives, interface compatibility is a more pressing issue. Another problem that has recently come up is that of power consumption. There are a number of drives out there that need more current at 12V than the 70W Risc PC power supply can deliver. Please watch out for power consumption when buying a new drive - errors caused by insufficiently available current are incredibly hard to track down and come in many disguises.
CDBurn is a very stable product. While it is possible that e.g. during ISO image creation or during operations with the ISO filer errors are reported, a complete freeze of the machine is almost certainly not the fault of CDBurn.
A crash during a write operation is much more likely due to a problem with either the drive, the SCSI/IDE subsystem or other hardware-related errors. Sometimes, there is an incompatibility between drive and SCSI podule which can be resolved by e.g. switching off synchronous transfer mode or block transfer mode, changing the operation mode of the SCSI podule (e.g. disabling DMA) or changing the disconnect/reconnect settings if possible.
There is a known incompatibility between the Connect32/SCSIConnect/Yucani F1 SCSI podule and many CD Writers. The only known workaround is to restrict the "continuously read/written blocks" setting in the CDBurn Advanced Configuration window to 16 blocks. If this doesn't help, try to set the podule to 8bit I/O.
There are three possible sources for "clicks". First of all, there was a bug in the MMC and Sony drivers of CDBurn version 1.48 and earlier. Please enquire for a free upgrade to the latest version. Second, there is the possibility that the source of the audible glitch was already in the source samples used - please test the Audio tracks with tools like !Player, !PlaySound or !SoundCon before writing a CD to ensure their integrity. Third, "clicks" might be introduced by so-called "link blocks" which are written at track boundaries in the CD writing mode "track at once". If CDBurn supports "disc at once" for your drive, it is recommended to use that writing mode - you get the additional bonus of being able to determine the pause length between tracks precisely.
First of all, you have to use "Disc at once" as a writing method to avoid automatic pauses between tracks. Keep in mind that not all drives are Disc at once-capable, and that not all CDBurn drivers are Disc at once-capable, e.g. the IDE driver.
Additionally, there is the "pause between tracks" setting which is adjustable for every audio track (by double clicking onto the track and editing the "Pause" field. You can also set a "default" for newly added tracks in the advanced configuration.
Please note that the Red Book standard requires a 2 second pause between tracks. By setting the pause to 0 blocks, you are essentially breaking the rules of the standard. However, there are countless professionally mastered Audio CDs which bent the standard there, so you should be safe.
The origin of this problem is the ISO9660 standard. This standard only allows the use of a very restricted character set - upper case letters, digits and the underscore. This character set was chosen to guarantee maximum compatibility between the then available platforms.
Nobody stops you from putting lower case filenames onto your CD-ROM. In fact, CDBurn is easily configurable to allow this - just choose the right filename translation standard. "Acorn CDFS", "ISO Level 1" and "ISO Level 2" will all translate filenames to upper case, while "WSS CDROMFS", "new ISO Level 2" and "raw" will retain the original filename casing. You can easily check this by switching the ISO filer to Display->View as raw.
However, this might not suffice. Many CD-ROM Filing System implementations (including Acorn's CDFS) automatically uppercase all filenames, so no matter what you write onto the CD, the filenames will always be shown as uppercase. Fortunately, Warm Silence Software's CDROMFS does not do that, and CDFS can be patched (with David O'Shea's CDFS patch - download as standalone patch or as a ROM patch in conjunction with many other RISC OS 4 patches).
The most elegant solution is of course to use the Joliet extensions. This allows you to retain full ISO9660 compatibility and still have your original filenames, but of course only on Joliet-capable CD-ROM Filing Systems (CDROMFS, RISC OS Select CDFS, Windows 95 and above, Linux, *BSD, Mac OS).
There is an annoying bug in CDFS that does not allow a file to have both a "." in its filename and still carry the Acorn CDFS extensions (like filetypes). So you end up with two possibilities: break the ISO9660 standard (by using the semi-official Acorn file extension separator "/" instead of translating it to the ISO9660 standard "."), or throw away the Acorn CDFS extension (and with it the filetype information).
If you select "Acorn CDFS", "WSS CDROMFS" or "raw" as your filename translation standard, the first approach is chosen. Keep in mind that the resulting CD will not be readable on either Windows or Unix derivates because they either do not allow a "/" in a filename or they use it in a completely different way. However, if you additionally select "Add Joliet extensions" in CDBurn, everything will be well with Joliet-capable systems, because they will automatically use the Joliet names instead of the broken ISO9660 names.
If you select "ISO Level 1", "ISO Level 2" or "new ISO Level 2", CDBurn automatically removes the Acorn CDFS extensions from files that contain a "." after the filename translation. This means that without a proper DOSMap (CDFS in RISC OS up until 3.7x) or MimeMap (CDFS in RISC OS 4.xx and later) entry, you will not be able to see a filetype. Unfortunately, DOSMap did not work properly in early CDFS versions - you will need to use CDFix to correct this.
The Quick Blank is at least as quick (and likely quicker) than a Full Blank.
This answer might seem surprising or strange, but the problem is that the MMC standard does not give any guarantees on what happens when you do a Quick Blank. The drive is free to choose any type of blank it likes, including a Full Blank, and it does not have to tell the driving software that it does not implement "true" Quick Blanking, so there is unfortunately no safe way for CDBurn to detect if a drive supports Quick Blanking.
The usual behaviour of a Quick Blank is however to just delete the Table of Contents (Lead-In) and the run-in and link blocks as well as the pregap of the first track of the program area. This means that not all of the disc is really "blanked", but it looks exactly like a blank disc, because the writer only examines the Lead-In area. This means however that the writer has to overwrite the old data in the program area directly - this does not always work. If you encounter problems when writing CD-RW, use a Full Blank first.
The target date for a release is End of 2002. It is intended to support both APIs - the main problem is working out how to drive the device, not how to use the API, insofar the support of both APIs seems to be quite easy.
All future versions of CDBurn will automatically contain USB support (as soon as it is ready of course!), upgrade prices are yet to be announced (but likely to be non-existant).
The drive I do my tests with is an Iomega ZipCD 4x writer. It is intended to test USB CDBurn with other devices before release.
There are many things to be said about that design decision. The other approach would have been to implement something like an image filing system for the ISO9660 format and consequently having the RISC OS filer do the display work. However, a special custom-written filer-like display was implemented to visualize the ISO9660 structure.
Pros:
Cons:
Short answer: you can't. This functionality should be part of the CDFS driver, but there is currently no driver available that lets you select another session.
CDBurn will soon be extended by a standalone CD reader with such features and more, and you will be able to import arbitrary sessions into the ISO pseudo filer. Watch this space.
CDBurn is able to produce both standard types of CDs where mixing Audio and Data is possible: Mixed Mode and CD Extra. Please consult the CDBurn manual, Chapter 7 for a detailed description.
Definitely not. There are now myriads of different protection schemes for both Data CDs and Audio CDs - without a massive amount of manpower and money it is impossible to analyse all those schemes to develop methods to copy them. The situation is made worse by the fact that the capabilities and features of CD-ROMs and CD writers that might enable you to do a 1:1 copy differ widely, so a lot of system-dependant solutions would need to be developed, multiplying the needed manpower and money.
If you happen to have a PC, use products like DiscJuggler or CloneCD to try to backup your copy protected CDs. However, it is usually a much better idea to just avoid buying such CDs - copy-protected Audio CDs usually violate the Red Book standard, which means they are not really Audio CDs and are not allowed to carry the Compact Disc Digital Audio logo - bringing them back to the store where you have bought them sends the right signals to those in the Content Industry who think that it is OK to jump on the Customer's rights.
Work is well underway to produce a version of CDBurn which works on current (26bit) and future (32bit) versions of RISC OS. Upgrades are expected to be free. Do not worry ;-)
Difficult question. I will try to list the pros and cons:
Nowadays, it is sometimes very hard to get SCSI drives. A good source of drives is definitely eBay - look for old 4x Plextor rewriters if you want a solid, reliable and cheap CD rewriter. The later models are still quite pricey.
| Home | © 1999-2002 Steffen Huber, steffen@huber-net.de |