According to This earlier posting, I was using a Debian / Jessie laptop, the first part of which is also known as Debian 8, to burn UDF-Capable Blu-ray Disks, given an external Blu-ray burner, and that version of Linux required help. Specifically, I needed to modify the way K3b behaves, by uninstalling the package ‘wodim’, which provides ‘cdrkit’, and by custom-compiling ‘cdrtools’, which is meant to act as a drop-in replacement for ‘cdrkit’, except for the fact that for the moment, ‘cdrtools’ was more powerful than ‘cdrkit’.
Under Debian / Stretch, which is also known as Debian 9, ‘wodim’ is not suggested by ‘K3b’ anymore, but rather a required dependency, for which reason to uninstall ‘wodim’, would also uninstall K3b. And so I needed to know, whether the package-provided version of K3b, and all its dependencies, could still burn Blu-rays via the GUI.
And the short answer is that Indeed, under Debian / Stretch, the packaged software has the required capabilities, so that to try to modify the behavior of K3b ( v2.0.3 ) is not only a bit risky, but totally unnecessary.
I created a Data-DVD Project – which we would also do for Blu-rays, and then burned that onto a DVD+R with 3 sets of options:
- File System = “Linux+Windows”, back-end = ‘growsiofs’
- File System = “UDF”, back-end = ‘growisofs’
- File-System = “UDF”, back-end = ‘cdrecord’
What I next did, was to run the command ‘df -T /dev/sr0′ , after mounting each disk via the GUI, both actions as a regular user. I found that options (2) and (3) both showed up as a “udf” file-system, while option (1) showed up as an “iso9660″ file-system.
This is as much, as custom-compiling ‘cdrtools’ could do for the user. Also, when going into the Programs settings of K3b, the full range of supported back-ends shows up as being available. Using burning-options (3) above, starts out the dialog with “Using Wodim” in the GUI, but all 3 settings still show me in the K3b GUI, “Burning ISO9660 File System”.
(Updated 10/23/2017 :
If this is to be used seriously for burning Blu-rays, then there is something which the user should further know.
The type of UDF File-System this creates, can in some cases be similar to what I was getting on the other machine, when I was burning UDF-enabled DVDs. This was a bridge-format, in which the disk is burned with mUDF 1.02, according to the ISO-13346 standard, while retaining backwards-compatibility with older DVD-players, that were only capable of accessing ISO9660 content. Hence, the version of UDF being offered could be as low as that. No UDF 2.01 File Systems might actually result from this.
However, my recent tests have shown, that when I burned a Data-Disk Project some time ago, set to the UDF File-System, and with ‘cdrecord’ as its back-end, no backwards-compatibility with ISO9660 was maintained, which in turn would suggest that some higher UDF version was in fact burned.
And, giving the command:
- file -s /dev/sr1
With the disk Not mounted, finally revealed that that version of ‘cdrecord’ had created a v1.50 UDF File-System. )
What UDF offers as a practical advantage over ISO9660, is an added error-correction system, which is important when very high bit-densities arise, such as when actually burning Blu-rays. But, it may also be desirable for burning DVDs.
When burning a media-disk of any kind, it is not only important that all the files be present and accounted for, but also, that the sequence with which blocks are written to the File-System Image, be the sequence in which high-data-rate streams are going to be played back.
And so while to use ‘growisofs’ as a back-end might work well for Data-DVDs, with UDF enabled, this may not be ideal for Blu-rays. I think that for an explicit Video-DVD project, K3b decides this for the user.
But when burning Blu-rays using K3b, especially if not from pre-mastered .ISO Files, I would recommend using ‘cdrecord’ as the back-end, because ‘cdrecord’ will specifically see to it, that the order with which blocks are written, corresponds to a sequential stream.
(Edit 10/23/2017 : )
I suspect the the main reason fw ‘/opt/schily/bin’ is still one of the search-paths, could be the mere possibility, that somebody forgot to remove it. In any case, if somebody was still to install a custom-compiled version of ‘cdrtools’, then K3b would find those, according to the search-paths above, which are editable.
I think that I should warn readers, that a very plausible problem can arise, if we burn Video-Blu-rays to the highest UDF-version possible, and if we then expect to preview the disks which we created, on the same computer we created them with.
The result could eventually be a Blu-ray, which our own Linux computer can no longer play back.
Before such a result gets counted as a failed project, I would recommend actually inserting the disk into a Blu-ray Playback Device, to see whether that playback device will play it. If it does, the project was not a failure.
Now, I can speculate as to why this result sometimes occurs, given the fact that my own Linux computers are sometimes able to play back commercially-recorded Blu-rays. My first guess would be, that even though the highest UDF Version which is recommended, may be v2.50 , even commercial producers may not be using that, for disks we buy in retail-stores, for playback on Standalone Players.
I appreciate that we’d like to be as advanced as possible, but sometimes, products that we take for granted and which work, which were even produced by companies, might have been made using inferior stuff. We could easily have picked up a Blu-ray in a store, which was also recorded using UDF 1.02, with backwards-compatibility with ISO9660, and simply going by the fact that our playback-device pays it, we’d never notice.
If the reader runs into the problem that his Linux computer cannot play the disk, but that his standalone playback-device does – as it once happened to me – I have advice on what he can do, to regain his ability to preview the content on the computer he used to author it.