Calculating size of a corresponding ISO9660+UDF image?

[Ronald F. Guilmette]

I just got my first BluRay burner & a ton of blank single-sided BD-R
media, so I want to start using these for making backups of most or
all of the stuff I have on hard drives, which is a lot.  But efficiently
splitting up all of my stuff into nice neat little <25GB bundles seems
like it might be a bit of tricky problem for two reasons.  (See below.)

(If I can't find anything off-the-shelf that will do this job for me,
then I plan to roll my own, either in Perl or C.)

The burning itself is no problem.  I plan to use Imgburn.  It is well
regarded, and it's always worked well for me.

The real problem is one that I have arguably created for myself...  I
never want to have to read multiple burnt optical disks in order to
retrieve a single desired file from my backups.  So I never want to
split any individual input file across multiple backup volumes.

Given that small limitation, I am faced with these two modest technical
problems:

1)  How to perform "bin packing" to get as many files onto each blank BD-R
disk as possible without exceeding the 25GB limit.  (This "bin packing" is
said to be an NP-hard problem, but I'll muddle through this part somehow,
even if I end up having my program just try all possible packings. I wasn't
in a hurry anyway. :-)

2) How to calculate exactly how much space in the proposed ISO9660+UDF image
the files that have so far selected for inclusion will actually occupy.

Really, it is just this second problem that I care about at the moment.

So, can anybody tell me the magic formula which, when given a set of
on-harddisk files and directories, will calculate exactly how big that
set of input files/directories will be, once they are all rendered into
a single  corresponding ISO9660+UDF image?

If anybody can tell me how to do this calculation, please proceed.  I'd
really rather not have to get down on my hands and knees and spend time
groveling around in the bowels of the FreeBSD optical disk drivers in
order to find this information if I can avoid it.

I mean it can't be THAT complex, now can it?


Regards,
rfg


P.S.  This whole problem... especially the "bin packing" part... feels like
something that somebody else... or maybe a lot of somebody elses... must
have already solved a long long long time ago, and probably many times.
So maybe I just need to find and resuscitate some of those old solutions.
I mean we've been making backups to finite and predictable length tapes
for at least 50 years now, and I can't be the first guy to have ever said
that I don't want to split files across multiple backup volumes.  So where's
the off-the-shelf open source freeware to solve the bin packing problem
for backup tapes?  I'm not proud.  I'll just re-use that code, thank you
very much.