A Word Of Warning about Using tsMuxer And Certain UDF Versions

I have written numerous postings, to guide myself as well as anybody else who might be interested, on the subject of Video-DVD burning, as well as on the subject of Video-Blu-ray burning. According to advice which I gave, it’s possible to use a program named “tsMuxerGUI”, to create the Blu-ray File Structure, which a Blu-ray playback-device will play.

According to additional advice I gave, it’s possible to burn these Blu-rays using some version of ISO-13346, which is also known as ‘UDF’, as opposed to burning them with ISO-9660, as the File System with which data is encoded on the disk.

But what I have noticed, is that certain Blu-rays which were burned in this way, will not play back using the application “VLC”. Normally, the open-source player named VLC can play back Blu-rays, which were commercially produced. So, it would seem natural, that we’d want to test our Blu-rays on the computer we used to create them, with the VLC application as the playback system.

My own experience has been, that the Blu-rays which result play back fine on my Sony Blu-ray playback-device, but do not open on VLC, on my computers.

As unlikely as this may seem, I did after all return to the conclusion, that I’ve created two UDF-encoded Blu-rays, which VLC cannot read, because of the customized UDF-encoding.

Apparently, when we instruct VLC to play a disk inserted into a specific Blu-ray drive, such as perhaps ‘/dev/sr1′, VLC expects to connect directly with the drive, rather than to use the mount-point exclusively, which Linux can create for us.

This is somewhat bewildering, because by default, I need to mount the disk in question, as a regular user, which we can do from the notification tray, before VLC is capable of playing it. But then, whether VLC can in fact read the Blu-ray turns into an independent question, from whether Linux was able to mount it for the rest of the computer to use.

(Edit 10/23/2017 :

There is an even more improbable-sounding possibility, as to why this actually happens. It may be that VLC expects to be able to access the Media Key Block of an inserted Blu-ray Disk, in order to decrypt that, and to start playing back DRM-ed Blu-rays. This would require not only raw access to the disk, but also that such a Block be present on the disk.

If I translate this problem into Human Logic, I’ll get, that ‘VLC’ is only capable of playing Blu-rays that have DRM, when those Blu-rays are also ISO9660-compatible. This may be unfortunate, because even though UDF 2.50 is still not ‘the law of the land’, ISO9660-compatibility may be phased out one day, while DRM likely will not be. )

But there is a workaround. VLC includes in its menus, the ability to Play A Directory. We can choose this option, and can navigate to the mount-point, which we created when we mounted the disk from the notification tray. That mount-point should exist under the directory ‘/media’ , have ‘BDMV’ as one of its sub-folders. And when we then direct VLC to play the folder, that is the parent folder to the ‘BDMV’ sub-folder, we are in fact directing it to play the root-folder of the disk.

And in my own, recent experience, VLC is then able to play the disk. I specifically took care, not to direct VLC to play the folder on my HD, from which I created one of the Blu-rays, but rather the folder that is the mount-point of an actually-inserted disk. Because, it would be pointless to conduct a test, which physically bypasses the disk.

Continue reading A Word Of Warning about Using tsMuxer And Certain UDF Versions

Burning UDF 2.01 File Systems under Linux using a Script

In certain earlier postings, I wrote about the possibility of burning Blu-rays using the UDF File System, but using the GUI-application ‘K3b’, under Linux. One big problem with this approach was, that the version of UDF being applied was only 1.02, and that it was part of an ISO9660 / UDF bridge-format, which the earliest ISO9660-capable devices are able to read because of the ISO9660 backwards-compatibility, but which would present some of the error-correction capabilities that UDF is supposed to offer, to more-modern devices, via UDF 1.02 .

The issue with this would be, that UDF 1.02 may still not be robust enough, in its error-correction, and that we wish to burn UDF 2.01 File Systems, using open-source software, under Linux.

(Edit 10/22/2017 :

Actually, my recent findings seemed to suggest, that if we use ‘cdrecord’ to burn a Data-Disk Project, the UDF version it applies may already exceed that standard. )

This posting will describe how such a File System can be written using a script, which I have tested myself, but which does not offer any type of GUI at all.

First of all, in order for this to work, our Linux computer needs a reasonably recent Kernel version, because what the script will do is create an empty UDF File System, and then mount that as a loop-device, so that the same script can batch-copy the contents of the Present Working Directory, (the PWD, as it’s called under Linux,) to this File-System, after which the FS is unmounted, and burned onto a Disk.

If our Kernel-version is not recent, then to mount and/or to batch-copy may fail, and for no other reason. I’ve tested this to work using Kernel version ‘4.4.0-30-generic’, which is by far not the standard Kernel-version that my Debian / Jessie repositories would offer.

Another prerequisite is, the package called:

‘udftools’

Which we would use to create the empty File System, but which we won’t be using to do anything other than that. ‘udftools’ can be installed using our standard Debian package-manager, and offers support up to UDF 2.01 as its maximum. This package also contains the commands for growing a UDF File System, ‘wrudf’, but because I did not trust the package-version of UDF being offered, I chose not to use it. ‘wrudf’ is supposed to work somewhat like the ‘growisofs’ command would work, within a GUI-application such as K3b, but K3b does not recognize it out-of-the-box. In fact, I do not envy anybody, who needs to use ‘wrudf’ to grow their UDF File System.

This is the script which I have tested:

 

#!/bin/bash

if [ ! -e "/dev/sr1" ] ; then
	exit 1
fi

if [ ! -x "/usr/bin/mkudffs" ] ; then
	exit 1
fi

if [[ $UID -ne 0 ]] ; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

rm -f /tmp/image.udf

echo "Creating Sparse File..."
truncate -s 24G /tmp/image.udf

echo "Formatting File System..."
mkudffs --media-type=dvdram --spartable=2 --vid="BD_$1" /tmp/image.udf || \
	exit 1

echo "Mounting File System..."

mkdir -p /media/udfimage || exit 1

mount -t udf -o loop,rw /tmp/image.udf /media/udfimage
rm -rf /media/udfimage/lost+found
chown -R root:root /media/udfimage

echo "Writing to File System. This may take some time..."
cp -rf ./* /media/udfimage

echo "Unmounting File System..."
umount /media/udfimage

echo "Burning File System. This may take some time..."

unset SUDO_COMMAND
export GENISOIMAGE=/usr/bin/genisoimage

growisofs -dvd-compat -Z /dev/sr1=/tmp/image.udf

echo "Cleaning Up..."
rm -f /tmp/image.udf

eject
echo "Done."


 

There are a few observations about this script, which anybody would wish to know about, who might want to use it. First of all, this script will expect one command-line argument, which is going to be prefixed with the string ‘BD_’ and then applied as the volume-ID of the file-system to be created. This will appear on computers, and on some playback-devices, as the name of whatever disk we have inserted. The exact naming is not critical, just as the exact naming for ISO9660-based Volumes may not be critical. It’s a formality which should be taken care of.

Secondly, this script expects to be run while the PWD is whatever directory we wish at the root of our created File System, and expects to be run as root. This poses an obvious security gap, as anybody could use this script in order to burn a copy of a folder, which he or she never had permission to read, if he could get root privileges with this script.

I have done my best to allow this script to be run using ‘sudo’, if it was placed in my system-directory:

‘/usr/local/bin/UDF-Burn.sh’

But, I have never tested whether it can be made to run using ‘sudo’ in this way. It might not, because it consists of a shell-script, which might only cause the script-interpreter to be elevated to ‘root’, but not all the commands within the script! My readers may test this as they wish, but since I’m the only real user of my own computers, I’ve always just felt comfortable to make myself ‘root’, and then just to run this script.

In the interest of allowing this script to be run via ‘sudo’, I have set the variables ‘SUDO_COMMAND’ and ‘GENISOIMAGE’ as would be appropriate. This has to do with the behavior of ‘growisofs’ to use an external helper, in order actually to grow certain types of File Systems, and an unscrupulous user could run this as ‘sudo’, and could set this external command to be anything he wanted it to be. It would allow an unscrupulous user to execute an arbitrary program as root, if my script did not take care to re-set this variable to the correct path.


 

The reader may be reassured to know, that by default, if one of his scripted commands throws an error, the execution of the script will continue after that command, as if nothing had gone wrong. This discovery actually cost me several blank disks, until I had sprinkled a few error-checking commands into it.

Hence, the output which the user sees could be:

Error: ‘/tmp/image.udf’  Is A Directory

After which Bash will try to keep running the rest of the script… And then, the next important question becomes, whether the ‘mkudffs’ command can eventually still execute successfully, which I did bracket, If it cannot store the File-System Image it creates at that location…

I also figured, that I was more likely to uninstall the package ‘udftools’ by accident, than I was, eventually to downgrade the kernel, on a computer which I had already established, could mount a UDF 2.01 File System correctly. But, if the reader has such fears, he can also just add:

|| exit 1

To the mount command…


 

I suppose another observation I should add about how this script will behave, is that it will create an empty, 24GB File-System Image right off the bat, and start to build the data within. A possible nuisance, because this would represent the total amount of raw space that a device would hold – unformatted – and the entire 24GB will be written to the Blu-ray disk every time the script is used, regardless of how little data we might actually want written to the disk. I chose 24GB because the true amount of raw space on a single-layered Blu-ray is actually ~24.8GiB, and the format does not allow for fractional values to be put on the command-line. So for our purposes, we only have 24.0GiB of raw, unformatted space to work from.

I suppose I could have sat down with a calculator, to determine that 24.7GiB ~= 25292MiB …

(Updated 10/24/2017 : )

Continue reading Burning UDF 2.01 File Systems under Linux using a Script

UDF-Capable Disk Burning with K3b and Debian / Stretch

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:

  1. File System = “Linux+Windows”, back-end = ‘growsiofs’
  2. File System = “UDF”, back-end = ‘growisofs’
  3. 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 :

screenshot_20171023_173754

If this is to be used seriously for burning Blu-rays, then there is something which the user should further know.

Continue reading UDF-Capable Disk Burning with K3b and Debian / Stretch

A Note On Playing Back Commercially-Recorded Blu-rays

Just as it was with DVDs, when movies first started to be distributed in that format, commercially-recorded Blu-ray disks today use an encryption system, which is sometimes referred to as ‘content scrambling’, to prevent people from making unauthorized copies. It’s actually named ‘aacs’.

Experts already know about this, but I’m putting this in layman’s terms for anybody who might not.

Basically, Blu-ray playback-devices have a hidden store of public keys, which the users are not allowed to access, and this time, the company is able to update that store of keys via the Internet, because most Blu-ray players today are also online devices.

Unlike how it is with Blu-rays, the content-scrambling system of DVDs was famously hacked. This means that Linux computers are well-able to play back Movie-DVDs. OTOH, the ability to play back commercial Blu-rays, is mainly unsuccessful on Linux computers, or on any other unauthorized devices, because the content-scrambling which gets used – was never hacked. As long as the encryption continues to work, Linux users and pirates will not be able to play back or rip Blu-rays.

As it stands, the company is able to revoke public keys which it was once using.

This is a shame, because some Linux users might only be wanting to view Blu-ray movies which they purchased and paid for. But the main fear of the industry remains, that as a platform, a Linux computer is more susceptible to an unauthorized copy being made of anything, which that Linux computer would also be able to perform authorized playback of.

Therefore, when I gave instructions on how people can record Blu-rays privately, my assumption was that we would not be using any encryption. I don’t see encryption as being important in any way, for home-movies which people might shoot. But, the Blu-ray folder must nevertheless contain a sub-folder named ‘CERTIFICATES’. In the example I wrote about, this sub-folder will simply remain empty.

Further, the mere use of the Blu-ray (single-layer) disk, as a step-up from DVD+Rs, where a Blu-ray can store up to 25GB of pure data instead of 4.7GB, is unfettered for Linux users to use as they wish. All we need is an external Blu-ray burner, and we’re all set to burn pure data. But as soon as we want to burn something using ‘UDF’, which is the approved file-system of Blu-ray players, the level of difficulty already increases, even though no encryption has been used yet.

(Updated 09/19/2017 : )

Continue reading A Note On Playing Back Commercially-Recorded Blu-rays