作れます。

＞渋木宏明(ひどり)様
早速のご回答ありがとうございます。
プログラムの知識がある方にすれば
どの程度のレベルのものになるのでしょうか？
また、私のような初心者でも簡単に作れるものなのでしょうか？

アプリとしては、フォルダ内のファイルをより分けて表示するまでの作業であり
その先の、フォルダ分けをするとか、メディアに焼く作業というものは省きます。

> どの程度のレベルのものになるのでしょうか？
ファイルサイズの計算は、足し算・引き算ができればいいから、小学校低学年レベルの算数。
あとは、開発環境依存。

＞どの程度のレベルのものになるのでしょうか？
＞また、私のような初心者でも簡単に作れるものなのでしょうか？

UI をどう作り込むかで難易度は大きく変わります。

UI についてまったく考えなくてよいなら、主たる処理自体はそんなに難しくないです。

指定されたフォルダの、ファイル一覧と各ファイル容量が取得できれば、既にコメント
がついているように、あとは算数レベルの問題です。

> もっとも最適（焼ける容量ギリギリ）なファイルの選択
>
この部分の処理、どんなアルゴリズムを考えるかがキモだと思います。
いや、勿論作れますよ。
ただ私には、意外と結構面倒なのではないかと感じました。

＞ただ私には、意外と結構面倒なのではないかと感じました。

「最適な解を高速に得る」のは難しいでしょう。

「そこそこ最適な解を高速に得る」方が難しいかな？

とりあえず、総当りで計算するようにして、メディア容量にイチバン近いものを残すよ
うにすれば、当座の用は満たせるかと。

ナップサック問題としても解けますが、そこまでする必要はないのでしょう。
空き容量以下の最大のファイルを選ぶ処理を繰返せば、十分なのでは？

ファイルのプロパティを見ると
「サイズ」と「ディスク上のサイズ」というのがあります
http://yougo.ascii24.com/gh/71/007179.html

クラスタサイズが4096バイトですと
1～4096バイトのファイルの場合、ディスク上の4096バイトを占有します
4097～8192バイトのファイルの場合、ディスク上の8192バイトを占有します

複数ファイルがある場合ですが、
ファイルのサイズを求めるときに
コピー先のメディアのクラスタサイズに切り上げして足し算をしないと
誤差がでます

＃質問の本題とは外れますが…

そのようなアプリを、何らかの理由で作らねばならない、あるいは技術的な興味から作
ってみたい（つまり「作る」ことが重要）というのでしたら構いませんが、「使う」た
めに作ろうとしているなら、そのようなアプリは既に存在します。
名前は忘れましたが、以前どこかで見かけました。
探してみてはいかがでしょうか。