fig1 illustrates schematically the basic format of a cd - rom , as known from the relevant standard , which is often denoted to as the ‘ yellow book ’, in analogy to the ‘ red book ’ standard for the audio cd . descriptions of the physical standard of the cd - rom can be found in the public available documents iso / iec 10149 , of the audio - cd in iec 908 . the physical standard for the recordable cd , denoted as the ‘ orange book ; is disclosed in iso / iec 11172 / 1 / 2 / 3 /. the standard for the logical format of the cd - rom is described in iso - 9660 ( the high sierra standard ) and for the recordable cd in ecma 168 / iso13940 ( the frankfurter proposal ). the data carrying area of the cd - rom starts with a lead - in area , a data area is available for user data and ends with a lead - out area . the methods for defect management and formatting described in this description can be used to optimize the performance of high - speed cd - rw in a computer environment . to exploit the full capabilities of high - speed cd - rw in a computer data storage environment , several conditions should be fulfilled : 2 ) the recorded discs shall be compatible with multi - read compliant cd - rom drives , 3 ) the system needs a method of defect management that can be handled by the drive or by a dedicated device driver , 4 ) formatting shall be performed by the drive in back - ground ( no interaction with the application or operating system running on the computer ), 5 ) the disc has to be available for use immediately after insertion and the eject time shall be minimal , 6 ) recording is based on fixed packets of 32 user data blocks , in a single track , on a single - session disc . to guarantee read compatibility with multi - read cd - rom drives ( or legacy cd - r / rw recorders ), the following requirements have to be fulfilled : all program area between the lead - in area and the lead - out area shall be fully formatted , all data , including the defect management information and replacement areas have to be available inside the program area ( the logically addressable space ) of the disc . the defect management then can be handled by a dedicated device driver running under the operating system of the computer . when a disc fulfils all these conditions , we call such a disc : “ rom - compatible ”. because current cd - rom drives do not support defect management , optional device drivers , which can add this functionality to the system , could be given along in the general purpose area , e . g . during formatting . the defect management system is based on a main defect table ( mdt ) in the lead - in area of the disc , and a secondary defect table ( sdt ) and replacement packets in the general purpose area . the defect tables shall be preceded by a so - called sentinel packet ( stl ) containing all 00h bytes . the general lay - out of the disc obtained with a method according to the invention is illustrated with reference to fig2 . the general purpose area is located preferentially at the outside of the disc against the lead - out area . a cd - writer with defect management according to the invention , will report the start address of the general purpose area as the start address of the lead - out area . an udf - file system gets thus a smaller partition to use . the part not used is reserved for replacement areas and contains the defect tables . in contrast to a legacy drive that will still report the end of the original lead - out address . this trick is needed to make defect management backward compatible with legacy drives such as cd - rom . a cd - rom reader is able to read the defect management area because it will be in its data area . a device driver will perform the defect management in case of a legacy drive . future cd - rom readers should get the ability to handle the defect management themselves . this is only a firmware change in the rom firmware . a writer lead - out pointer should be added to the firmware . compatibility with cd / dvd - rom is obtained by a device driver or application that reads the defect table and handles the defect management . the operating system thus interacts with a cd - rom , a legacy cd - rw , dvd - rom or dvd - ram only by a device driver or application that handles the defect management . the cd - rw with the improved format according to the invention interacts directly with the operating system . generally the end - user of the system likes to have the disc ready for use within seconds after it has been inserted into the drive . a blank disc however has to be formatted before all it &# 39 ; s capabilities can be exploited fully . because the normal formatting process takes too much time , a back - ground formatting procedure will be defined that initializes the disc with a minimum amount of information , after which it is available for recording , and then proceeds with the formatting during the time intervals when the drive is idle . the background formatting only defines the physical formatting of the disc , which is system independent . a fully formatted disc is always in a rom - compatible state . an eject command can be executed without delay . when an eject is requested before the disc has been fully formatted , a quick finishing process shall be executed to make the disc rom - compatible before it leaves the recorder . according to the existing cd - rw recording format , data may be recorded in several distinct writing actions . this is referred to as incremental writing . in case of incremental writing , linking rules of recorded data must be taken into account . a link position is the physical location on the disc where the recording of efm signals is allowed to start and stop . in case of data recording , an efm recording sequence shall start and end with link , run - in and run - out blocks . no gap between recordings is allowed , one set of recorded link , run - in , user data and run - out blocks is called a packet . the number of user data blocks in a packet is called the packet size . the link block contains the link position . fig3 shows details of the linking in the program area according to the existing cd - rw format . the program area consists of one track with fixed packets with a size of 32 user data blocks . herein is : lnk = link block , ri 1 . . . ri 4 = run - in blocks , ro 1 , ro 2 = run - out blocks , ud 1 . . . ud 32 = user data blocks and tdb = track descriptor block fig4 shows the lay - out of the general purpose area ( gpa ) according to the invention . the general purpose area ( gpa ) consists of three parts : the gpa is located within the logically addressable space of the disc ( see fig2 ) at the end of the program area , immediately preceding the lead - out area . the defect management system shall not be active in the gpa , so there is no replacement for defective packets in the gpa . the general application area ( gaa ) can be used for storage of data that does not allow replacements by the defect management . such as application programs or device drivers that can handle defect management . or support of multiple operating systems employing udf or iso 9660 files system . or support of multiple sources like music / video play . the size of the gaa is defined during the formatting of the disc . it is allowed to specify a length = 0 for the gaa . the defect management area ( dma ) consists of n packets meant for replacement of defective packets in the data area , a sentinel packet ( stl ), and the secondary defect table ( sdt ). the number of replacement packets n is defined during the formatting of the disc . the sdt is meant for use by cd - rom drives and legacy cd recorders for defect management during read - out . it is also a back - up in cases of failures in the mdt . the sdt is contained in one packet . the sdt shall be preceded by a sentinel packet . the content of all 2k blocks of the sentinel packet shall be all zeroes . the last packet of the gpa shall be a reserved packet . this packet shall not be used for any other purpose than for file system use . the defect management system of high - speed cd - rw is based on a main defect table ( one packet ) located in the lead - in area , a secondary defect table , containing a copy of the mdt , in the general purpose area and replacement packets in the general purpose area . fig5 shows the location of the first mdt in the lead - in area . the defect management of a recorder only replaces full packets , which are found to be defective during writing or reading . detection of possible errors can be based on e . g . excessive servo signals , feedback from a “ running opc ” during writing , or error flags from the error correction system during reading . the mdt can be updated by a recorder at each occasion of a defect detection . if the mdt is wearing out because of too many overwrites ( or becomes defective for other reasons of failure ), a new stl packet is created just preceding the existing stl packet and then the old stl packet is be overwritten by a new mdt packet . fig6 shows the replacement of a defective mdt . the defective mdt packet shall be overwritten with a dt with the update count field set to ffffh , indicating that this table is no longer valid . the sdt only needs to be updated when the disc is ejected from a recorder . if the sdt is wearing out because of too many overwrites ( or becomes defective for other reasons of failure ), a new stl packet is created just preceding the existing stl packet and then the old stl packet is overwritten by a new sdt , which is illustrated with reference to fig7 . the defective sdt packet shall be overwritten with a dt with the update count field set to ffffh , indicating that this table is no longer valid . the number of replacement packets shall be decreased by one and the defect tables shall be adapted accordingly . thus , according to an embodiment of the method of the invention three defect tables are defined : the secondary defect table ( sdt ), located in the general purpose area ( gpa ) and which is an exact copy of the mdt . additionally , according to an embodiment of the method of the invention , a third defect table is defined : a temporary defect table ( tdt ). this tdt is created instead of the sdt , when an eject is requested before the back - ground formatting process has been finished , which will be discussed later . all defect tables have the same lay - out and after ejecting the disc from a recorder , they contain the same information . each defect table ( dt ) is contained in 4 consecutive blocks , which 4 blocks are repeated 8 times to fill up a complete packet . fig8 shows the composition of a defect table packet . this repetition gives a good protection against local defects in the disc ( dust , scratches , etc .). the packet shall be filled consecutively , starting with dt 0 , part 0 and ending with dt 7 , part 3 . the defect table contains a list of packets , which have been determined to be defective during verification or during use of the media , and a list of packets reserved for replacements . the defective packet shall be linearly replaced by a reserved packet as assigned in the defect table . identifying defective packets may happen either during read or write operations by a recorder . each 2k block in the defect table packet shall have the contents as defined in fig9 which shows the lay - out of the defect table . the addressing method that shall be used for the defect management is according to logical block numbering . with reference to fig9 the specific bytes have the following content : 4d4454h , representing the characters “ mdt ”, in each block of an mdt , 534454h , representing the characters “ sdt ”, in each block of an sdt , 544454h , representing the characters “ tdt ”, in each block of an tdt . these bytes shall indicate the total number of update operations on this defect table . this field shall be set to 0000h during the creation of the dt , and shall be incremented by one each time the dt is re - written . if the dt packet is defective , this packet shall be overwritten with a dt with the update count field set to ffffh , indicating that this table is no longer valid . the most significant 4 bits of this byte specify the dt number in the packet as a binary value 0 ˜ 7 . the least significant 4 bits of this byte specify the part number in the dt as a binary value 0 ˜ 3 . this byte specifies the number of parts ( 0 ˜ 4 ) of the dt that actually contain valid dt entries . these 2 bytes indicate the number of replacement entries in the dt ( total of all 4 parts ). the value shall be equal to the number of replacement packets in the defect management area . these 6 bytes are reserved and shall be set to 00h . these 3 bytes shall specify the logical block number ( lbn ) of the first user data block of the first packet in the general purpose area . byte 16 bit 7 ˜ 4 are reserved and shall be set to zero . bit 3 ˜ 0 : lbn of first user data block of gpa bit 7 ˜ 0 : lbn of first user data block of gpa bit 7 ˜ 0 : lbn of first user data block of gpa these 2 bytes shall specify the number of packets set aside for replacement of defective packets . these 3 bytes shall specify the number of packets set aside for the storage of data that is not under control of the defect management . these 2 bytes contain flags for indicating the status of the disc . they can be used for instance for tracking the back - ground formatting process . bit 4 ˜ 1 : reserved and set to zero bit 7 ˜ 0 : reserved and set to zero bit 5 is meant to be used as a “ de - icing not ready ” flag , details of which will be discussed hereinafter bit 5 = 1 : indicates that the disc has been recorded non - consecutively , and that there are blank areas between some recordings . bit 5 = 0 : indicates that all packets between the start of the program area and the last recorded user data in the data area ( see fig2 ) have been recorded or formatted . before ejecting a disc with bit 5 set to 1 , the blank area ( s ) shall be formatted . bit 0 is meant to be used as a general “ power fail flag ”. it shall be set to 1 at each write action and shall be reset to 0 when the disc is closed and ejected in a normal way . these 3 bytes shall specify the logical block number ( lbn ) of the first user data block of the last packet that has been recorded or formatted . byte 26 bit 7 ˜ 4 are reserved and shall be set to zero . bit 3 ˜ 0 : lbn of first user data block of last formatted packet bit 7 ˜ 0 : lbn of first user data block of last formatted packet bit 7 ˜ 0 : lbn of first user data block of last formatted packet these 3 bytes are reserved and shall be set to 00h . each dt entry consists of 6 bytes . the first three bytes indicate a defective packet and the last three bytes identify the replacement packet that has been assigned . the most significant bits of byte n and byte n + 3 are used to indicate the status of the replacement . unused bytes shall be set to 00h . the defective packet lbn shall be equal to the lbn of the first user data block in the defective packet to be replaced . the replacement packet lbn shall be equal to the lbn of the first user data block in the replacement packet , that is assigned to hold the replaced packet . the value of status and reserved may be as defined as following : = 01 : the entry identifies a defective packet that has not been recorded at it &# 39 ; s replacement address , = 10 : the entry identifies a replacement packet usable for future replacement , the defective packet lbn shall be set to zero , = 11 : the entry identifies a replacement packet unusable for future replacement , the defective packet lbn is unspecified . = 00 : the original location has been recorded with the same data as the replacement location , = 01 : the original location may contain different data as the replacement location , the dt entries in the tables shall be sorted in ascending order as if each dt entry were a single 48 bit unsigned binary integer . there shall be no hierarchical replacements : no replacement packet lbn shall be equal to any defective packet lbn . next the lay - out of the sentinel packets will be explained with reference to fig1 . each 2k block in the stl packet shall have the contents as shown in fig1 . herein the successive bytes have the following content : these 3 bytes shall be set to : 53544ch , representing the characters “ stl ”, in each block of an stl , these bytes shall indicate the total number of update operations on this stl packet . this field shall be set to 0000h during the creation of the stl , and shall be incremented by one each time the stl is re - written . if the stl packet is defective , this packet shall be overwritten with an stl with the update count field set to ffffh , indicating that this table is no longer valid . these 2 bytes are reserved and shall be set to 00h . these 2040 bytes are reserved and shall be set to 00h . as apparent from the above , each mdt / sdt / tdt is preceded by a sentinel packet ( also referred to a zero packet ). this packet may be used advantageously for storage of proprietary information such as copy right information . information of this kind stored in the lead - in area , is unreadable by a cd - rom reader . to the contrary , a sdt is readable . at initialization ( details of which be discussed later ) an mdt is created , containing a dt entry for each replacement packet , with status 1 = 10 , the defective packet lbn set to 00000h and status 2 = 00 . packets found to be defective during reading by a recorder , can be indicated in the defect table with status 1 set to 01 , and the defective packet lbn set equal to the lbn of the first user data block of the defective packet . if a replacement packet itself is found to be defective , it is indicated by status 1 = 11 . the defective packet lbn is undefined . if an error is detected in a packet during reading , the drive may replace the packet , mark the packet for replacement , or ignore the error . if the defective packet is to be replaced or marked for replacement , the drive shall assign the replacement packet with status 1 = 10 and the lowest lbn . if the packet is replaced , then : the data from the original packet shall be recorded in the packet identified by the replacement packet lbn . the status 1 field of the dt entry shall be set to 00 , the status 1 field of the dt entry shall be set to 01 , future read requests shall be fulfilled from the packet identified by the defective packet lbn , future write requests shall be handled by writing to the packet identified by the replacement packet lbn , changing the status 1 field to 00 , and updating the defect table sort order . optionally also the original location can be overwritten . the status 2 field shall be set accordingly . next the back - ground formatting will be explained in more detail . the disc shall be considered fully formatted if the lead - in area , the maximally possible program area and the lead - out area have been recorded . the user data bytes in the 2k blocks can contain relevant data or can be set to dummy data ( all bytes aah ). the disc shall be considered partially formatted if at least the mdt in the lead - in zone has been recorded . the status of the disc shall be indicated by the disc status and the last written address fields contained in the mdt . if compatibility with cd - rom drives is required , then the disc shall contain a lead - in area , a lead - out area , and a program area with no blank areas between the lead - in and lead - out areas . formatting is the process to reach the status of cd - rom compatibility . formatting can be done in two different ways : by pre - formatting , which is the conventional way of formatting used for many storage media . after the pre - formatting process , the disc is fully formatted . user data shall not be recorded to the disc until the pre - formatting process is complete . this process generally consists of the following steps : formatting can also be done as : back - ground formatting , which is a formatting process that runs in the background during use of the disc on a recorder . after the back - ground formatting process , the disc is fully formatted . user data may be recorded to the disc during the back - ground formatting process . the back - ground formatting process consists of the following steps : because the pre - formatting process may be rather time consuming , back - ground formatting can be a much more time - efficient solution for the user of the disc . during the back - ground formatting process only a minimum amount of data will be recorded onto the disc , after which the disc can be used by the application . a disc on which a back - ground formatting process is active , may be formatted further by the cd recorder in the background during the moments that the application is not accessing the disc . next the initialization will be explained . when a blank disc is inserted into a recorder , an initialization procedure is started by the host computer . this initialization creates an stl and mdt at the end of the lead - in area , according to a set of parameters given by the host computer , such as : start of gpa , size of replacement area , size of gaa . in general the host computer also writes some initial file system structures ( fss ) to the disc . these file system structures as well as the user data can be placed anywhere in the logically addressable space of the disc . in the following examples it is assumed that the disc is initially recorded sequentially . as a result of the initialization procedure the following disc , as shown schematically in fig1 will exist . because of the very limited amount of data to be recorded , the initialization procedure will be finished just in seconds . the disc is now ready for data storage and can be released for the application . next the de - icing will be explained , with reference to fig1 , showing the status of a disc after some de - icing and recording . de - icing is the process of recording all packets in the program area of the disc . during the de - icing phase , unrecorded areas shall be filled with packets containing 2k blocks with all aah bytes or with user data when requested . the de - icing shall be performed by the drive itself , without any support from the host computer . during the time intervals when the drive is idle , the de - icing process can proceed in the background . when the application or os requests disc access , the de - icing process is suspended and the control of the disc is returned to the os . application requested writes in blank areas shall be registered by the drive and shall not be overwritten by the de - icing process . the drive shall keep track of all areas that have been recorded or de - iced . next finalization will be discussed in more detail , with reference to fig1 , showing the status of a disc after several steps of finalization . after the full data area and the general purpose area have been recorded or de - iced , the lead - in and lead - out area are recorded . to be able to interrupt the recording of the lead - in and the lead - out area on write / read requests from the host computer , the lead - in area as well as the lead - out area are written in variable packet size . the lead - in and lead - out should be recorded continuously until the moment of the interrupt request , after which the recording shall stop by writing a packet end ( 2 run - out blocks and a partial link block ). after the action requested by the host has been finished , writing to the lead - in or lead - out is resumed with a packet start ( partial link block and 4 run - in blocks ) followed by user data blocks . to prevent too much fragmentation in the lead - in and lead - out area , each packet shall be at least of a size of 128 user blocks . at the end of the finalization process the host computer overwrites the general application area with the required files , updates the file system structures and creates additional file system structures if needed ( e . g . udf secondary avdp ). next the process of ejecting a disc from a recorder is explained , with reference to fig1 which shows an example of the final status of a disc . when the disc is ejected from the recorder the mdt packet shall be copied to the sdt packet . however , early ejecting may be feasible as explained hereinafter , with reference to fig1 , showing an early eject status of the disc . when the user pushes the eject button of the drive , he is expecting the disc to come out in the shortest possible time . however he also expects that the disc is “ rom - compatible ”. this means that the disc shall have at least a lead - in and a lead - out area and no blank areas in the program area . if the back - ground formatting process is not yet finished , the drive may decide to finish the deicing and finalization processes in the normal way . if the remaining formatting will take too much time to finish , then the drive can decide to close the disc in a temporary rom - compatible way , for which the following steps are needed ( see fig1 ): write / read requests from the computer shall be completed and the active de - icing process stops , if recordings have been made in blank areas , all blank areas up to the last recorded packet shall be de - iced , 1 ) only replacement packets that are actually in use ( indicated in the mdt with status 1 = 00 ) are copied to the location immediately following the area reserved for the temporary gaa . 2 ) an adapted copy of the mdt is placed as tdt ( temporary defect table ) next to the copied replacement packets , together with an stl and a reserved packet : the dt entries in the tdt shall point to the temporary replacement packets , while the dt entries in the mdt shall not be changed ( still pointing to the replacement packets in the final gpa ), the lwa ( last written address ) in both the mdt and tdt shall be set to the lbn of the first user data block of the temporary reserved packet , all other fields in the mdt and tdt shall be unchanged and reflect the values of the final disc after formatting has been fully completed , if the slt and / or tdt can not be written correctly at the intended location , then the next 2 packets shall be used . the tdt shall always be the last but one packet before the start of the temporary lead - out . 3 ) a lead - out area of at least 30 seconds is recorded . if this lead - out is going to overlap recorded packets in the final general purpose area , then the normal de - icing and finalization processes shall be finished instead of applying this early - eject procedure . 4 ) the lead - in area , with subcode data according to the actual situation of the disc , is recorded . 5 ) the os writes the gaa immediately following the last packet that has been de - iced or recorded , the temporary gaa shall have the same size as the final gaa . 6 ) the os updates the file system structures and writes required additional structures , 7 ) if all data to be stored in the gaa does not occupy all packets , then the remaining packets shall be de - iced . 8 ) the tdt is updated , including the reset to 0 of the dirty disc bit . 9 ) the mdt is updated , including the reset to 0 of the dirty disc bit . next re - opening and early - ejected disc will be discussed , with reference to fig1 , showing the re - opened status of the disc . when an early - ejected disc is re - inserted into a recorder , this device will detect the “ partially formatted ” status and the host computer can initiate the continuation of the back - ground formatting . de - icing shall restart from the position indicated by the lwa pointer ( see fig1 ), thus starts overwriting the temporary lead - out area . it will proceed until the full disc has been de - iced / finalized . the replacement packets already present in the final gpa shall not be overwritten . the temporary gpa is considered as being formatted . links of the file system to the temporary gaa are invalid . new write requests can overwrite the temporary gpa . before a next eject , the os shall update the file system structures . finally it is remarked that although he invention has been described with reference to preferred embodiments thereof , it is to be understood that these are not limitative examples . thus , various modifications thereof may become apparent to those skilled in the art , without departing from the scope of the invention , as defined by the claims . for instance a cd - rw may be replaced with a dvd - rw or the like . next an embodiment of a computer data system comprising a computer and a recording apparatus according to the invention will be described , with reference to fig1 . the recording apparatus 1 comprises recording medium receiving means 2 for receiving a removable recording medium 3 . the recording medium 3 may be a disc of the optically readable type such as cd - rw , dvd - ram or dvd - rw . the recording medium 3 is rotationally driven by rotation means 4 . an optical pick - up unit 5 , movable in a radial direction of the recording medium 3 , writes optically detectable marks along a spiral track 8 on the recording medium 3 employing a light beam 6 . to this purpose the recording medium 3 is provided with a suitable phase change material which has different optical properties in crystalline or amorphous states . heating with the light beam 6 may induce these states . the light beam 6 is modulated by recording means 9 according to digital information signals to be recorded . these digital information signals have been suitable encoded with encoding means 10 , employing efm modulation and circ error encoding , as prescribed by the cd - standards . inputting means 11 , which may employ suitable interface means , receive the digital information signals from a connected computer 12 . alternatively , recorded digital information signals on the recording medium 3 , may be read via the same optical pick - up unit 5 , by suitable reading means 13 . these are connected to decoding means 14 to perform efm decoding and circ error correction processing . the decoded and corrected signal are outputted , via outputting means 15 , comprising suitable interface circuitry , to the computer 12 . all units are controlled by a controlling unit 16 connected to memory means 17 , such as for example a non - volatile rom . the controlling unit 16 may comprise a processing unit which operates according to a specific program loaded in the memory means 17 , in order to perform the method according to the invention , either independent or under control of the computer 12 . the computer 12 comprises interface circuitry 18 adapted to receive digital information signals from the recording apparatus 1 or to send digital information signals to the recording apparatus 1 . the digital information signals may comprise , apart from signals read from the recording medium 3 or to be recorded thereon , control signals from the computer 12 to control the recording apparatus 1 . the interface circuitry 18 is connected to an internal data and address bus 19 in order to exchange data and control signals with a hard disk unit 20 , a ram memory unit 21 , a central processor unit 22 and a rom memory unit 22 . the computer 12 may be loaded with a suitable operating system and a device driver to operate with the recording apparatus 1 . in case of a recording apparatus according to the invention , the recording apparatus 1 will perform the major parts of the method according to the invention itself , such as back - ground formatting or defect management , without requiring excessive interaction with the computer 12 . in that case the computer 12 will only interact with the recording apparatus 1 in case of write , read or eject requests and the like . however , an other embodiment of the invention is obtained when the recording apparatus 1 is not adapted to perform independently the method of the invention , such as in case of a legacy cd - rw writer or cd - rom reader . in this case the computer 12 will have to use a dedicated device driver , loaded in the corresponding memory units of the computer 12 , to control the recording apparatus 1 in such a manner to perform at least the defect management according to the method of the invention . such a dedicated device driver may be obtained from the recording medium 3 itself or from other external means such as internet . the invention may be implemented by means of both hardware and software , and that several “ means ” may be represented by the same item of hardware . further , the invention lies in each and every novel feature or combination of features . it is also remarked that the word “ comprising ” does not exclude the presence of other elements or steps than those listed in a claim . any reference signs do not limit the scope of the claims .