#1 Burning Software

In a previous topic ("Disc Free Space and Image Size") there was some discussion about how to tell whether a specific set of files would fit on a given disc or not, based on things like "lead-out" and "border-out".

If it helps answer my questions, I am insisting on an empty disc when I start my burning (and erase the disc if it isn't empty). It is absolutely necessary that all of the data fits on a single disc, and I don't need or want to leave the disc "open" to having additional sessions or tracks added to it after I'm done. If my data isn't going to fit, then my program needs to work with the user to decide which files to include and which files to exclude. Creating multiple discs isn't an option for my requirement. I would like to support whatever kind of disc the user sticks in their drive.

A couple questions on this subject.

1) Anton mentioned "disabling multisession during the current burn" as a way of maximizing the space available on a disc. I'm not quite sure how to do that.

2) The TRACK_INFORMATION structure contains the # of free logical blocks, are blocks always UDF_LOGICAL_BLOCK_SIZE_IN_UCHARS bytes long?

3) Is there a clever function like ISO9660JolietFileTree_WillFit() that lets me quickly determine whether the Joliet tree I've constructed will fit onto a single disc? Or maybe ISO9660JolietFileTree_GetSizeInUCHARSIncludingLeadOutAndBorderOut()? If not, how hard is it for you to create such a function?

Thanks again!

1) Just pass FALSE as IsNextSessionAllowed parameter when using burning API subset functions.

2) Yes. When recording data discs only 2048 bytes from each 2352 byte sector of the CD would be used (DVDs have ALWAYS 2048 byte sectors visible to user). When recording video or audio single sector size would be different to 2048 bytes.

3) Not so... When you're adding files to the tree you need to process callbacks updating total file content size (not to get complete tree size after BuildImage(...) call - you can do nothing with the tree after this point). Just add file system overhead itself (around 2 megabytes) and lead-out overhead for CD (let it be 15 megabytes) and 30 megabytes for DVD (if recording with "next session" set to FALSE) and you'll have whole "physical image" size stored on the media.

Your "would fit?" API call sounds like a good idea and I think we'll be adding it as feature request.

Just to make sure I understand your answer to (3) ...

The reason I would need to update the total size during the callbacks is so I know when I've added too many files ... but if I do that update during callbacks, and then compare it with the value I get back from GetSize() (after calling Build), they should give the same answer?

The thing is, I don't need to know when I've added too many files (to fit on the disc), all I need to know is, given the options the user has selected in my program, will their files fit or not? So for me, I think I can build my whole tree, call GetSize(), add 2M and either 15M or 30M, and then if the answer is too large, tell the user they gotta pick different options, and then go back and re-create the tree.

Thinking more about (3) ...

If I add a whole bunch of really small files to the disc, will the file system overhead still be only 2M? It seems like to be careful, I would need to use a more complicated calculation, one that included # of files and # of folders?

No, the reason is - when you add too many files you can ask user to stop doing this (I'm talking about something like "green-yellow-red" slider at the bottom of "disc compilation" f.e. Nero shows to the user). So user would be asked to remove some files himself from compilation. I'd recommend you doing the same.

Yes, you're correct. Files would be padded to the sector size (2KB) each so true size would be a bit larger then just file size itself. You can easily hovever padd file size yourself after receiving "file add" callback.

For my application, it doesn't make a lot of sense for the user to pick which files to include - the CD that my program is creating contains an application and the data files necessary for the application to function, so if not all of the data files will fit, the user needs to either use a different disc (DVD instead of CD) or they need to pick some different application options (which would result in a different set of data files being required).

So just to make sure I've got it right, if I round each file up to the nearest 2k, I should still add the 2M "file system overhead"?

Thanks!

1) Round file sizes to 2K (make sense if you use a lot of small files, in the other case just skip it)

2) Add file system overhead (2MB not more)

3) Add lead-out overhead (could be skipped if you use Disc-At-Once recording and thus you can "overburn")

Since you know better what content you're recording you can pick the steps really required for you. That's all!