CDBurn logo CDBurn
hubersn Software Logo Home
Navigation Map Home News Products Support Buy! About us
 

 

Quick Links

 
CDBurn
 
CDBurn Support
 
FAQ
 
Supported Writers
 
Upgrading
 

 

CDBurn Frequently Asked Questions

Version 1.05, 2004-05-30, written by Steffen Huber, steffen@huber-net.de

Overview of questions

  1. What is the purpose of this FAQ?
  2. Is drive "XYZ" supported?
  3. CDBurn crashes my system completely during writing a CD. Why?
  4. When recording an Audio CD, there are audible "clicks" or "pops" between tracks. How can those be avoided?
  5. I want to record a live Audio CD. However, I always get a two second pause between tracks. Why, and how to avoid it?
  6. Why are all the filenames on my Data CD uppercase?
  7. Why have some of my files lost their filetype information?
  8. What is the difference between "Quick Blank" and "Full Blank"?
  9. When will USB support be ready? Will the Simtec or the Castle API be supported?
  10. CDBurn uses its own "filer-like" display for image creation. Why was this approach chosen?
  11. How can I access other sessions than the latest on my Multisession CD?
  12. How can I mix Audio and Data on one CD?
  13. Is it possible to copy protected CDs with CDBurn?
  14. What about a 32bit version of CDBurn?
  15. Should I buy an IDE or a SCSI drive?
  16. Am I allowed to use CDBurn on more than one machine?

Questions and Answers

  1. What is the purpose of this FAQ?

    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.

  2. Is drive "XYZ" supported?

    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:

    • I own some drives myself, and those are likely to be supported best (for obvious reasons).
    • There are drives which are used by customers or dealers and are reported to be working. It is normally a safe bet to buy one of those.
    • There are drives that the manufacturer says are compatible with either previous drives or a common command set standard. Usually, these give only little problems which are easily resolved.
    • There are drives which don't work at all, for known reasons. Avoid, or ask if CDBurn support is in the pipeline.
    • There are drives which don't work, for unknown reasons. Avoid at all cost.

    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.

  3. CDBurn crashes my system completely during writing a CD. Why?

    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.

  4. When recording an Audio CD, there are audible "clicks" or "pops" between tracks. How can those be avoided?

    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.

  5. I want to record a live Audio CD. However, I always get a two second pause between tracks. Why, and how to avoid it?

    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 old blocking IDE driver (which is still the default).

    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.

  6. Why are all the filenames on my Data CD uppercase?

    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).

  7. Why have some of my files lost their filetype information?

    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.

  8. What is the difference between "Quick Blank" and "Full Blank"?

    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.

  9. When will USB support be ready? Will the Simtec or the Castle API be supported?

    Work on USB support is currently on hold because of severe lack of interest.

  10. CDBurn uses its own "filer-like" display for image creation. Why has this approach been chosen?

    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:

    • All code is written in Ada95, which means higher quality, less development time and better maintainability. Everything runs in user mode, which means higher overall stability of the machine.
    • Ability to have a different menu structure with specific entries and configuration possibilities tailored to the needs of ISO9660 format.
    • RISC OS 3.1 users get a filer display with auto-resizing columns and full name display for long filenames
    • Better possibility to add specific features
    • ISO9660/Joliet specific sorting and display modes possible
    • The ISO9660 standard was not designed for "on-the-fly" manipulations, it is a very static format. An image filing system implementation would have required very clever code to minimise performance problems due to image restructurings.

    Cons:

    • less optimized code with slower redraw
    • filer extensions for the standard filer (FilerPro, FilerPatch, RISC OS 4/Select etc.) cannot be used
    • some features from the RISC OS filer might be missing, the CDBurn filer is not an exact copy
  11. How can I access other sessions than the latest on my Multisession CD?

    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.

  12. How can I mix Audio and Data on one CD?

    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.

  13. Is it possible to copy protected CDs with CDBurn?

    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.

  14. What about a 32bit version of CDBurn?

    A 32bit version of CDBurn is now available. Upgrading is free. Support for the IYONIX IDE system is included.

  15. Should I buy an IDE or a SCSI drive?

    Difficult question. I will try to list the pros and cons:

    SCSI pros

    • SCSI drives can be put into an external case, because SCSI is a proper bus and allows a quite long maximum cable length (up to 3m if you use standard SCSI2). This has the advantage that the Risc PC's weak power supply does not make problems, and that the drive is much better cooled than inside the suboptimal Risc PC case. This means that overall writing reliability is a lot higher, and you can easily move the drive between your RISC OS machine and perhaps your PC.

    • The quality of the drives is usually better. An exception to that rule is Yamaha - they use exactly the same drive in IDE and SCSI models and just change the interface electronics.

    • Experience has shown that SCSI compatibility is much better than IDE compatibility. With SCSI, you don't have to think about the master/slave problems, and nearly every SCSI drive works with nearly every SCSI podule. CDBurn is also much better tested with SCSI drives than with IDE drives, mostly because IDE support was added quite late.

    IDE pros

    • Drives are much cheaper and now have the "technology lead" in terms of speed and features (but note that, with current hardware and the current CDBurn version, you won't be able to use most of them).

    • Many RISC OS machines already have IDE inbuilt, you don't have to buy a possibly expensive SCSI podule.

    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.

  16. Am I allowed to use CDBurn on more than one machine?

    It depends. You can choose whether to use the CDBurn licence you have bought as a single user or a single machine licence.

    This also means that if you already own a CDBurn licence, and you also have an IYONIX pc, you don't need to pay for the CDBurn Lite -> CDBurn upgrade - upgrading to the 32bit version of CDBurn is free, so if you are the only user on both machines, everything is free.

 
     

   © 2004 by hubersn Software   •  webmaster@hubersn-software.com

   Impressum