How low-level can CD writing software go?



i am interested in knowing and controlling the EXACT pattern of bits that gets written to the physical CD. i want to construct a .raw file of data, and then burn it to the CD to obtain the pattern that i want.

i know that i can bypass most of the error correction coding using the -raw96r writing mode with cdrecord, which is a step in the right direction, since it will theoretically allow me to control at least most of the pattern that gets written in the user data area (minus sector headings and the C1/C2 correction). then, according to some information i picked up from a different thread here, it seems that it will still undergo the EFM encoding and CIRC encoding with C1 and C2 protection, and then it will finally get written to the CD.

my question is this…is the EFM encoding and CIRC encoding all handled by the firmware/drivers/whatever in the reading/writing process? or are they handled by cdrecord, but we are just not given a default option to bypass them? in other words, does cdrecord send an exact pattern of 1’s and 0’s to the laser that will get written as ‘pits’ and ‘lands’, or does cdrecord send the non-encoded data, which is then encoded by firmware? from what i can tell, it handles at least some of the error correction coding for the other data modes, but if the lowest level available still leaves EFM and CIRC (which all modes seem to go through), then it seems to me like there is a good chance that is handled by some firmware that i could have no control over.

i understand there are good reasons for all of these steps in terms of data reliability and laser tracking and keeping DC out of the signal, but i am curious to know how much control i can have over the reading/writing process, even if it defies all practical wisdom. :stuck_out_tongue:


Hi, welcome amishbob.

The EFM and CIRC is not handled by the software on the PC, it is most likely handled by the chipset (hardware) or the firmware. The cdrecord software use the MMC standard commands, which you can look up in the draft pdf versions at:

The -raw96r writing is sending logical data consisting of 2352 bytes of main sector + 96 bytes of raw subchannel data. This data is after the EFM, and C1/C2 (CIRC) layer, so unfortunately you have no control of the lower level. The MMC standard has no option to do that.


thanks! that information is very helpful.


another question on this topic…

is the scrambling process also taken care of by hardware/firmware, or is this on the software end?


It depends on the selected writing mode, so yes and no:

  • raw write type - (software)
  • tao - (hardware)
  • sao - (hardware)

Raw write type is what you want, i.e. cdrecord does the scrambling when using -raw96r.