A new feature in 1.3.2 displays the about of data to be burned compared to the totaol space available. The problem is that that ratio never changes to allow for discs with higher captivity. The indicator only seems to work for CDs and not DVDs or DVD DL. That is a major problem; obviously there is more available space on a DVD DL than on a CD when 80 meg is in the queue to be written.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may be right. However, the autotmatic disc recognition, which is already partially implemented (detecting available speeds), has caused some trouble. So, it should be completely rewritten. Any help is much appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right. But that shuold be automatic. There should be no user intervention required. Why would you want the listing for the CD when the disc you are using is a DVD DL?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree, this should be detected from info given by cdrecord -mediainfo
it gives remaining writeable size. for my taiyo yuden/jvc DVD's, it's 2295104, which I multiply by 2048 bytes per sector to get 4,700,372,992
if you can capture/redirect the output to a file, in C++ it's quite doable if you use something like:
cdrtfe indeed gets the actual size of a disc via the cdrecord -minfo command, as you can see in cl_diskinfo.pas. Of course this information is used to check, if there is enough free space on the disc for the data the user wants to write.
As mkisofs is used to generate the filesystem of the disc, cdrtfe does not know the total size of the data. cdrtfe only knows the size of each file the user wants to write to the disc, but the filesystem itself and some meta data need space, too. cdrtfe gets the total amount of data when the user starts the burning process by clicking the 'Start' button with one call of mkisofs -print-size. Then it compares this value with the free space of the disc from the cdrecord -minfo command. According to the result of comparison the program starts the writing or aborts with an error message.
Knowing this, it should be clear why the space meter is only intended to show a rough estimation of the space used. The total size value just sums up the sizes of the files added to the project, however, it does not include the filesystem overhead. So the real value will always be higher. The difference depends on how many files are included and which file system is used.
In other words, the settings of the space meter are completely irrelevant for the actual burning process. You may even switch off the space meter by setting SpaceMeter=0 in the cdrtfe.ini, section [General]. Due to performance reasons the total size of the data to be written and the medium size are only retrieved just before the burning process is started (as explained above). So, only the last confirmation dialog shows 100% accurate values.
I am not going to change this behaviour. As cdrtfe is open source, feel free to implement an automatic disc recognition and a better size calculation depending on the filesystem settings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a cdr disc with 1529856bytes/2048=747 sectors used.
that's what's reported for the last line under the size column (the 5th number or 6th token if you use spaces to separate)
learned something else. if you do cdrecord -v -minfo dev=0,0,0 you get a bigger dump with BOTH the total disc size on the line " ATIP start of lead out: 359847 (79:59/72)" (359847 sectors*2048=736,966,656 the size of my taiyo yuden cd-r)
AND the disc size (there's an extra column with no label, not sure what it's for)
80896*2048=165,675,008 which is the size of my gparted disc data. it is a mini disc (business card disc or 150MiB).
interesting? all the info in one dump.
I have to indent the above last pasted size stuff because markdown requires this. so sorry if the leading spaces mislead. there ARE spaces in front of the ATIP line.
do you think you could rework cdrtfe so it does this? I might be able to work up a patch, but I haven't done pascal in years, so I am a bit rusty at it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a "refresh size" button could be added in case the user ejects and reinserts another disc.
if it's multisession (4 tracks in one of my test cases), I have found on that dump that you will get 2+ tracks (1..n) with the additional line at the bottom "Remaining writable size: 274851"
my multisession disc with cdrecord -v -minfo looks like this:
the cdr media dumps from cdrecord -v -minfo dev=0,0,0 attached. I deleted the old ones because the filename was wrong, they were not dvds, they were cds.
point me to the source code, I may be able to provide some working source, but I don't have delphi and probably have no reference material (web site ref could be useful, but I would be a beginner on that language). I do c++ and basic and used to do assembler.
what file(s) handle the disc size graph? I assume it's a progress bar of some sort.
again, the ATIP start of lead out should contain the total number of 2048-byte sectors of the disc. the total size.
after the line of ='s, you can look for a group of lines that has the word Data in it, if they exist. if it's the only thing there (no lines with the word Blank), it is a finalized disc. the next-to-last (Size) column contains the 2048-byte size of each track of data, whether TAO or DAO. sum these Data lines' Size column to obtain the disc space used.
after the Data which may or may not be there, you can look for lines which contain the word Blank, this line may or may not be there, and there's only 1 to my knowledge, at the end of the track list. the next to last (Size) column contains the number of 2048-byte sectors that are the free space of the disc.
this is the tested version.
includes unit-testing program that calls the function that grabs the data from cdrecord. because there were even more types of
cdrecord -v -minfo dev=0,0,0>0-0-0.txt
dumps I had to work with due to differences in content, I had to work with more
test cases. my test cases were:
cdrw formatted (I don't have a blank cdrw)
cdrw formatted with data
cd-r with single-session
cd-r with multisession (TAO)
cd-r blank
dvd-r blank
dvd+r iso-burnt (DAO) (because -v -minfo reports no "full disc size" info,
I can't report it either, so TotDiscSize is really UsedSpace.)
I appreciate your help, but you seem to think that cdrtfe doesn't check the disc size or type. In fact, it does. These functions are already implemented and used in cdrtfe. See the file cl_diskinfo.pas. The relevant object or class is TDiskInfoM (functions TDiskInfoM.GetMediumInfo and TDiskInfoM.GetCDInfo, line 1251). It can handle all your test cases. It should even work with BDs, which I can't test as I don't own a Blu-ray writer.
JFTR, the topic starter complained, that the space meter doesn't adjust automatically to the medium inserted by the user. This is just a cosmetic problem as the space meter is completely irrelevant for the burning process. cdrtfe only checks the available space with the TDiskInfoM class just before the writing process is about to start. Only at this point, after calling mkisofs -print-size and cdrecord -minfo, cdrtfe knows about the total amount of data to be written, the disc type and available space.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A new feature in 1.3.2 displays the about of data to be burned compared to the totaol space available. The problem is that that ratio never changes to allow for discs with higher captivity. The indicator only seems to work for CDs and not DVDs or DVD DL. That is a major problem; obviously there is more available space on a DVD DL than on a CD when 80 meg is in the queue to be written.
You may be right. However, the autotmatic disc recognition, which is already partially implemented (detecting available speeds), has caused some trouble. So, it should be completely rewritten. Any help is much appreciated.
From the cdrtfe help:
Spacemeter
The size of the used space is shown here. Clicking right on this control opens a context menu which allows to select the disc size.
Right. But that shuold be automatic. There should be no user intervention required. Why would you want the listing for the CD when the disc you are using is a DVD DL?
I agree, this should be detected from info given by cdrecord -mediainfo
it gives remaining writeable size. for my taiyo yuden/jvc DVD's, it's 2295104, which I multiply by 2048 bytes per sector to get 4,700,372,992
if you can capture/redirect the output to a file, in C++ it's quite doable if you use something like:
cdrtfe indeed gets the actual size of a disc via the cdrecord -minfo command, as you can see in cl_diskinfo.pas. Of course this information is used to check, if there is enough free space on the disc for the data the user wants to write.
As mkisofs is used to generate the filesystem of the disc, cdrtfe does not know the total size of the data. cdrtfe only knows the size of each file the user wants to write to the disc, but the filesystem itself and some meta data need space, too. cdrtfe gets the total amount of data when the user starts the burning process by clicking the 'Start' button with one call of mkisofs -print-size. Then it compares this value with the free space of the disc from the cdrecord -minfo command. According to the result of comparison the program starts the writing or aborts with an error message.
Knowing this, it should be clear why the space meter is only intended to show a rough estimation of the space used. The total size value just sums up the sizes of the files added to the project, however, it does not include the filesystem overhead. So the real value will always be higher. The difference depends on how many files are included and which file system is used.
In other words, the settings of the space meter are completely irrelevant for the actual burning process. You may even switch off the space meter by setting SpaceMeter=0 in the cdrtfe.ini, section [General]. Due to performance reasons the total size of the data to be written and the medium size are only retrieved just before the burning process is started (as explained above). So, only the last confirmation dialog shows 100% accurate values.
I am not going to change this behaviour. As cdrtfe is open source, feel free to implement an automatic disc recognition and a better size calculation depending on the filesystem settings.
I have a cdr disc with 1529856bytes/2048=747 sectors used.
that's what's reported for the last line under the size column (the 5th number or 6th token if you use spaces to separate)
learned something else. if you do cdrecord -v -minfo dev=0,0,0 you get a bigger dump with BOTH the total disc size on the line " ATIP start of lead out: 359847 (79:59/72)" (359847 sectors*2048=736,966,656 the size of my taiyo yuden cd-r)
AND the disc size (there's an extra column with no label, not sure what it's for)
80896*2048=165,675,008 which is the size of my gparted disc data. it is a mini disc (business card disc or 150MiB).
interesting? all the info in one dump.
I have to indent the above last pasted size stuff because markdown requires this. so sorry if the leading spaces mislead. there ARE spaces in front of the ATIP line.
do you think you could rework cdrtfe so it does this? I might be able to work up a patch, but I haven't done pascal in years, so I am a bit rusty at it.
a "refresh size" button could be added in case the user ejects and reinserts another disc.
if it's multisession (4 tracks in one of my test cases), I have found on that dump that you will get 2+ tracks (1..n) with the additional line at the bottom "Remaining writable size: 274851"
my multisession disc with cdrecord -v -minfo looks like this:
hmm. I am seeing this, which has more accurate info about the capacity of the disc.
I will post a replacement function for the code I made if you can make use of c++ functions. it was buggy.
the cdr media dumps from cdrecord -v -minfo dev=0,0,0 attached. I deleted the old ones because the filename was wrong, they were not dvds, they were cds.
point me to the source code, I may be able to provide some working source, but I don't have delphi and probably have no reference material (web site ref could be useful, but I would be a beginner on that language). I do c++ and basic and used to do assembler.
what file(s) handle the disc size graph? I assume it's a progress bar of some sort.
updated code. extracts all the needed info from the dump.
more samples attached
I fixed my code so it compiles now and prettified it.
this is the tested version.
includes unit-testing program that calls the function that grabs the data from cdrecord. because there were even more types of
dumps I had to work with due to differences in content, I had to work with more
test cases. my test cases were:
I can't report it either, so TotDiscSize is really UsedSpace.)
CHANGELOG didn't get updated.
I appreciate your help, but you seem to think that cdrtfe doesn't check the disc size or type. In fact, it does. These functions are already implemented and used in cdrtfe. See the file cl_diskinfo.pas. The relevant object or class is TDiskInfoM (functions TDiskInfoM.GetMediumInfo and TDiskInfoM.GetCDInfo, line 1251). It can handle all your test cases. It should even work with BDs, which I can't test as I don't own a Blu-ray writer.
JFTR, the topic starter complained, that the space meter doesn't adjust automatically to the medium inserted by the user. This is just a cosmetic problem as the space meter is completely irrelevant for the burning process. cdrtfe only checks the available space with the TDiskInfoM class just before the writing process is about to start. Only at this point, after calling mkisofs -print-size and cdrecord -minfo, cdrtfe knows about the total amount of data to be written, the disc type and available space.