
 New in 0.6
 ----------

 ** Destination path Dialog **
 
 In CDIrip 0.5 I added an Open File dialog when you launched CDIrip by a
 double-clic or specified no source image filename in the command-line. CDIrip
 then loaded the selected image and proceed to extract it in current directory
 (usually the same directory where CDIrip is located). This behaviour,
 however, prevented using CDIrip from a fixed directory through a Start Menu
 or Desktop shortcut, since image would be always extracted to CDIrip's own
 directory.
 
 Now in 0.6 when you open CDIrip by double-clic, just after the Open File
 dialog a new Destination Path dialog will appear, letting you to choose a
 destination path other than current directory. Hope this allow using CDIrip
 from Start Menu or Desktop own-made shortcuts.
 
 However, when specifying a source image filename in the command-line, program
 behaviour will remain the same as always (i.e. it will extract it to the
 current directory) to mantain compatibility with some CDIrip GUI frontends
 which have appeared so far.
 

 ** Optional Destination path in command-line **

 Now you can enter an (optional) destination path just after source image 
 filename. A quick example of this would be:

 cdirip image.cdi d:\

 As you can see, CDIrip will extract the contents of "image.cdi" into 
 specified destination path "d:\". CDIrip will change to the directory 
 specified before saving any track. This means that specified path MUST EXIST
 already in order to work. If CDIrip can't change to the specified directory
 it will simply report an error message. So if you type:

 cdirip myimage.cdi d:\rippedimages

 The directory "rippedimages" must already exist in D: drive.
 
 Of course you can still specify any option switch just after destination
 path, such as:
 
 cdirip image.cdi d:\ /cutall /iso
 

 ** New "/pregap" option **

 Until now, CDIrip always discarded pregap data when extracting tracks from  
 CDI image. I choose to do this because most recording software adds these 
 pregaps (2 second pauses between tracks) by default when loading them from, 
 disk, so it would mess up things if I did not remove them. CUE file also 
 contains PREGAP entries between each track to force adding these pauses with 
 CDR-Win.

 In this version, I've added the new "/pregap" option which tells CDIrip to  
 extract these pregaps and append to the end of each track (this is where it's 
 supposed to be). PREGAP entries will be removed from CUE files, too. This 
 way, when you load the tracks again in your favorite recording app you can 
 manually remove these 2 seconds pauses between tracks (in fact you MUST do so 
 for it to work!) so all audio tracks are "continuous". Please note that a 2 
 seconds pause *before* 1st track is still needed, as stated by CD-ROM 
 standard.
 
 This is the original CDI image track/pregap layout:
 
 +------------+-----------+------------------------+------------------------+
 | 1st pregap | 1st track | 2nd pregap + 2nd track | 3rd pregap + 3rd track |
 | (mandatory)|           |                        |                        |
 +------------+-----------+------------------------+------------------------+
 
 This is the new CDIrip extracted track layout (with "/pregap" option):
 
              +------------------------+------------------------+-----------+
      (not    | 1st track + 2nd pregap | 2nd track + 3rd pregap | 3rd track |
   extracted) |                        |                        |           |
              +------------------------+------------------------+-----------+
 
 This is the old (no "/pregap" option) extracted track layout:
 
              +-----------+            +-----------+            +-----------+
              | 1st track |            | 2nd track |            | 3rd track |
              |           |            |           |            |           |
              +-----------+            +-----------+            +-----------+
 
 The missing pregaps are re-contructed by CD recording app when burning back.
 Similarly, last 2 secs of each track are used as pregap for next track when
 burning in "continuous" mode (i.e. no pauses between tracks) so burned CD
 layout is exactly the same as original CDI image.
 
 As I've noted above, you *MUST* tell your recording app NOT to add pregaps
 (i.e. not adding 2 secs pauses) if you choose to extract with "/pregap"
 option. Not doing so, you will end with a useless CD. Because of this,
 this option is not active by default, as users using it must know what
 they are doing. Of course, since 1st track pregap is mandatory for CD-ROM
 standard, you should not remove it from the recording app's track layout.
 
 Note also that this option is needed when dealing with special CDI images
 with negative (!) track sizes.

 
 ** New "/speed" option **

 This new option will show you an estimated WRITTING speed expressed in Kb/s.
 This means that since current hard disk controller bandwidth is shared 
 between reading and writting you only will see about 1/2 of REAL throughput,
 so don't worry if you get relatively low numbers here. In my development 
 equipment (P2 266, Intel 440LX, Seagate 10 Gb ATA33 - yes I know, a bit old,
 isn't it? :) and with new buffering system, I get about 2500-3000 Kb/s
 (remember, writting only) which is not bad at all, I think.
 
 Speed will start showing only after first 2000 sectors of data from current
 track have been saved to disk. This is needed to get a good figure of real
 throughput. Since calculation is started again for every track, tracks below
 2000 sectors in size (approx. 26 seconds) won't show any speed data.
 
 The reason of putting this as an option is because speed calculation adds
 some (little) extra overhead and could affect ripping speed.
 
 
 ** Options can now start with "-" character **
 
 UN*X users will enjoy this, since they are more used to that command-line
 usage style instead of the old DOS "/" character for options. So from 0.6 you
 can now enter:
 
 cdirip image.cdi -cutall -iso -speed
 
 And CDIrip will do its job just as expected.
 
 (Note: seems even M$ is going this way, too. If you don't believe me, just
 take a look at the new Windows Media 8 Encoder command-line options ;)
 
 
 ** MAJOR speedup (two 1024 Kb buffers for read and write) **
 
 Until now, all CDIrip versions didn't implement any buffering technique other
 that the one provided by the runtime itself (64 Kb) and all disk operations
 where performed in blocks of 2 Kb in size. This added a significant overhead
 in ripping time and system speed.
 
 Now in this version I've implemented my own buffering routines for reading
 and writting, which creates two big buffers (1 Mb each) used to speedup all
 disk access. After measuring new performance, I was surprised of getting up
 to 25-33 % global speedup in total image ripping time!
 
 Using "speed" option, old CDIrip throughput was about 1500-2000 Kb/s and now
 I get 2500-3000 Kb/s on the same machine! This is a great improvement, not
 only in final ripping time but also in system overhead while doing a ripping
 job. Previous versions almost freezed entire operating system while ripping
 but now you'll experience a less-overloaded system, while getting shorter
 ripping times!
 
 
 ** DiscJuggler 3.00.780 (and up) CDI image support **
 
 The guys at Padus did it again... they changed the internal CDI image format,
 so new CDI images are no more compatible with previous DJ versions and so
 with CDIrip/CDI2nero. I've added a quick hack to detect and support these,
 plus maintaining the existing support for old 2.0 and 3.0 images. Currently,
 this is the only tool capable of this. Since I am not very satisfied with
 the current source status, which is a pure hack, I plan redoing again the
 CDI parsing routine, with special care put on new image format, and possible
 future modifications.
 
 
 ** Other enhancements/fixes **
 
 Three bugs have been fixed in this release, the first one dealing with 
 default track cutting which caused last data track being always cutted unless 
 "/full" option was specified (anyways this is a harmless bug since all data 
 tracks gets increased again 2 sectors in size when burning, so those sectors 
 being cutted were totally blank). Second bug was a more serious one and 
 affected data track conversion from Mode1/2352 (raw) to 2048 (ISO), hopefully 
 these tracks are very rare to find (this did not affect Mode2/2352 (raw) data 
 tracks which are by far more common). Finally, there was a "bug" (really a
 missing feature) when dealing with some special CDI images with negative (!)
 track sizes. These are now correctly handled, althought the use of /pregap
 option is mandatory for these (CDIrip will notify you if it is not active).
 
 Finally CDIrip now uses Bloodshed Dev-C++ v4.0 compiler which is totally free
 and also will make tiny executables (only 14 Kb in this release, with no
 compression at all!) - so don't think it's a virus or so :)
 
 
 That's all. Enjoy it!
 