I've noticed that CDRTFE has never been able to properly verify data discs, at least for me. Every time I burn a data disc and 'verify' is enabled, I get a message that says that CDRTFE is not able to find the disc, and thefore is not able to verify its content. To me, that seems like a very serious issue because you will never know if the data has been properly burned. This is not a new issue. It happen after discs have been burned, and after it has been ejected before verification.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very strange. I just tested it once again, and it worked for me:
> [...]
> Fixating...
> Fixating time: 42.437s
> /cygdrive/I/BURN/tools/cdrtools/cdrecord: fifo had 710 puts and 710 gets.
> /cygdrive/I/BURN/tools/cdrtools/cdrecord: fifo was 0 times empty and 610 times full, min
> fill was 78%.
>
> Execution completed.
>
> Comparing files ...
>
> Reading TOC of CD. Please wait ...
>
> Comparing 418 files with the source files ...
>
> 0 error(s) found.
Normally, the drives are specified with their SCSI ID (like 0,0,1). However, to verify the data after the burning cdrtfe needs acces to the drives using a Windows drive letter. So, a drive letter has to be assigned to the CD/DVD writer. Without a drive letter the verification won't work.
cdrtfe should be able to find the right drive automatically. After the disc has been burned and reloaded, cdrtfe will access each optical drive in your system to find the disc by searching for the first file from the pathlist. This may fail, if mkisofs has renamed files automatically when detecting too long file names.
You can tell cdrtfe about the drive letters used by Windows. Please check your cdrtfe.ini, there should be a section [Drives]:
If 'LocalDrives' is empty, then cdrtfe will search for the drive as described above. But you can specify which drive letter cdrtfe should use for which SCSI ID. Just list the drive letters in order of the SCSI IDs.
Example:
My system has two optical drives: a DVD writer from LG (drive x:) and a CD writer from Sony (drive y:). The SCSI IDs are:
Still regarding verification issues, is it possible to not have cdrtfe eject the disc in between burning and the verification process? I have my tower inside a desk, with the door closed, and it is rather annoying when burning discs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> is it possible to not have cdrtfe eject the disc
> in between burning and the verification process?
I know that this is annoying but currently I don't know how to get rid of this behaviour.
Before starting the verification Windows needs to know that there's a new disc from which it can read. Otherwise the files which just have been written are not accessible. So, if anybody has a way to do so without reloading the disc, please let me know. I would appreciate any help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do know that there are applications out there that do not require the disc to be ejected first; such as ONES and the new version of CDBurnerXP. I think CDBXP also offers source code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, at least under Win2k/XP/Vista(?) cdrtfe does not need to reload the disc before verification any longer. However, this only works, if cdrtfe knows about the drive letters assigned to the CD/DVD devices. If for some reason the (new) SCSI bus scanning routine should fail, you still can assign the drive letters manually (cdrtfe.ini, section [Drives], LocalDrives, AssingManually).
You can download the new version from the package cdrtfe test, cdrtfe file version 1.2.7.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this something that you plan to add to the 1.3 branch, or is it exclusive to 1.2? I ask because in order to test this feature I need to revert back to 1.2, which results in the loss of other features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, the new cdrtfe with file version 1.2.7 is the successor of cdrtfe 1.2.6 which has the release name 'cdrtfe 1.3pre2'.
If a version is feature complete then the minor version number is increased and the release gets the corresponding name without suffix (like pre1). If the file version 1.3.0.0 will be ready it will be named cdrtfe 1.3 (final).
Until then, the pre-releases will be made available (packages 'cdrtfe' and 'cdrtfe portable') each time one or more important features have been added or a severe bug has been fixed. These pre-release can be considered as stable as final releases. They just lack some features.
The test versions (package 'cdrtfe test') are just intermediate versions. They are released to see how people like new features or if new functions correctly work on other systems. They may still have some bugs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed that CDRTFE has never been able to properly verify data discs, at least for me. Every time I burn a data disc and 'verify' is enabled, I get a message that says that CDRTFE is not able to find the disc, and thefore is not able to verify its content. To me, that seems like a very serious issue because you will never know if the data has been properly burned. This is not a new issue. It happen after discs have been burned, and after it has been ejected before verification.
This works perfectly. I was able to verify the contents of a disc without the need for it to be ejected first. Thanks, that was bugging me.
Very strange. I just tested it once again, and it worked for me:
> [...]
> Fixating...
> Fixating time: 42.437s
> /cygdrive/I/BURN/tools/cdrtools/cdrecord: fifo had 710 puts and 710 gets.
> /cygdrive/I/BURN/tools/cdrtools/cdrecord: fifo was 0 times empty and 610 times full, min
> fill was 78%.
>
> Execution completed.
>
> Comparing files ...
>
> Reading TOC of CD. Please wait ...
>
> Comparing 418 files with the source files ...
>
> 0 error(s) found.
Normally, the drives are specified with their SCSI ID (like 0,0,1). However, to verify the data after the burning cdrtfe needs acces to the drives using a Windows drive letter. So, a drive letter has to be assigned to the CD/DVD writer. Without a drive letter the verification won't work.
cdrtfe should be able to find the right drive automatically. After the disc has been burned and reloaded, cdrtfe will access each optical drive in your system to find the disc by searching for the first file from the pathlist. This may fail, if mkisofs has renamed files automatically when detecting too long file names.
You can tell cdrtfe about the drive letters used by Windows. Please check your cdrtfe.ini, there should be a section [Drives]:
[Drives]
UseRSCSI=0
Host=
RemoteDrives=
LocalDrives=
If 'LocalDrives' is empty, then cdrtfe will search for the drive as described above. But you can specify which drive letter cdrtfe should use for which SCSI ID. Just list the drive letters in order of the SCSI IDs.
Example:
My system has two optical drives: a DVD writer from LG (drive x:) and a CD writer from Sony (drive y:). The SCSI IDs are:
0,0,0 0) 'HL-DT-ST' 'DVDRAM GSA-4163B' 'A105' Removable CD-ROM
0,1,0 1) 'SONY ' 'CD-RW CRX100E ' '1.0j' Removable CD-ROM
So, the corresponding entry in [Drives] would be:
LocalDrives=x,y
I also have two drives; G: and F:. My ini file looks like this:
[Drives]
UseRSCSI=0
Host=
RemoteDrives=
LocalDrives=
Should that not be the case? Should it be:
[Drives]
UseRSCSI=0
Host=
RemoteDrives=
LocalDrives=x,y
That might explain why I have problems.
I also have two drives; G: and F:. My ini file looks like this:
[Drives]
UseRSCSI=0
Host=
RemoteDrives=
LocalDrives=
Should that not be the case? Should it be:
[Drives]
UseRSCSI=0
Host=
RemoteDrives=
LocalDrives=x,y
That might explain why I have problems.
Well, with your ini file it should work, but obviously it doesn't. So, you could try to set the LocalDrives entry. In your case it would be
LocalDrives=g,f
or
LocalDrives=f,g
depending in which order your drives appear when the SCSI bus is scanned (see tab sheet 'CD Info', 'SCSI bus scan').
Still regarding verification issues, is it possible to not have cdrtfe eject the disc in between burning and the verification process? I have my tower inside a desk, with the door closed, and it is rather annoying when burning discs.
> is it possible to not have cdrtfe eject the disc
> in between burning and the verification process?
I know that this is annoying but currently I don't know how to get rid of this behaviour.
Before starting the verification Windows needs to know that there's a new disc from which it can read. Otherwise the files which just have been written are not accessible. So, if anybody has a way to do so without reloading the disc, please let me know. I would appreciate any help.
I do know that there are applications out there that do not require the disc to be ejected first; such as ONES and the new version of CDBurnerXP. I think CDBXP also offers source code.
Ok, at least under Win2k/XP/Vista(?) cdrtfe does not need to reload the disc before verification any longer. However, this only works, if cdrtfe knows about the drive letters assigned to the CD/DVD devices. If for some reason the (new) SCSI bus scanning routine should fail, you still can assign the drive letters manually (cdrtfe.ini, section [Drives], LocalDrives, AssingManually).
You can download the new version from the package cdrtfe test, cdrtfe file version 1.2.7.
Is this something that you plan to add to the 1.3 branch, or is it exclusive to 1.2? I ask because in order to test this feature I need to revert back to 1.2, which results in the loss of other features.
> which results in the loss of other features
It doesn't. I know that the versioning scheme could be better, but it's not that complicated. It's just important to look at the file version.
1.2.0.0 -> cdrtfe 1.2 (final)
1.2.1.0 -> 1.2.1 (test)
1.2.2.0 -> 1.2.2 (test)
1.2.3.0 -> cdrtfe 1.3pre1
1.2.4.0 -> 1.2.4 (test)
1.2.5.0 -> 1.2.5 (test)
1.2.6.0 -> cdrtfe 1.3pre2
1.2.7.0 -> 1.2.7 (test)
So, the new cdrtfe with file version 1.2.7 is the successor of cdrtfe 1.2.6 which has the release name 'cdrtfe 1.3pre2'.
If a version is feature complete then the minor version number is increased and the release gets the corresponding name without suffix (like pre1). If the file version 1.3.0.0 will be ready it will be named cdrtfe 1.3 (final).
Until then, the pre-releases will be made available (packages 'cdrtfe' and 'cdrtfe portable') each time one or more important features have been added or a severe bug has been fixed. These pre-release can be considered as stable as final releases. They just lack some features.
The test versions (package 'cdrtfe test') are just intermediate versions. They are released to see how people like new features or if new functions correctly work on other systems. They may still have some bugs.