## File System Corruption !

I use a home-computer as my Web-host, which I named ‘Phoenix’. This was actually a computer built in 2008, and is one of the oldest still working for me. So far it has continued to work reliably.

Until several years ago, this computer was actually named ‘Thunderbox’, and was running Kanotix / Thorhammer. But I when I wiped it completely and installed Kanotix / Spitfire on it, I not only renamed it, but rebuilt its software from zero.

What just happened to me today on ‘Phoenix’, is that I fired up a routine K3b -session, in order to back up some music from Audio CDs which I had actually purchased in the 1980s, and that the GUI application showed me a message saying that it could not locate the utility named ‘dvd+rw-tools’ ; I should try installing the package (even though it’s a dependency and was installed.) After I reinstalled that package, K3b told me that it could not locate ‘cdrdao’ (even though it’s a dependency and was installed). I needed to reinstall that as well, after which I explicitly needed to tell K3b to rescan the hard-drive, to find all its back-end utilities again.

Because on this computer I had never customized the back-end utilities which K3b uses – unlike what I had done on ‘Klystron’ – and, because I had never changed the variables in question, this actually points to file-system corruption. I had last used K3b on ‘Phoenix’ several months ago, and with no error messages or warnings. Further, those utilities were among the first packages I ever installed, when I resurrected this computer as ‘Phoenix’, and the idea that the oldest data on the hard drive, would be the first data forgotten, even though never deleted, is also consistent with file-system corruption.

Usually, I’d expect FS corruption to stem from power outages. But we haven’t had a power-outage in a long time, and the last time we did, the Extension 4 File-System on the machine just seemed to repair itself correctly. Because Ext4 is such a tightly-meshed file-system, the report that it has been repaired, can be believed. If it was not repaired on boot, the computer would refuse to boot.

And so, even though this is not typical, I’d say that in this case, the FS corruption is actually secondary, to the fact that the actual Hard-Drive is aging, and has caused some I/O errors. We only get to see I/O error messages, if we’re running something from the command-line; I believe that when we’re running a GUI application, those just stay buried in a system log somewhere.

But what this seems to spell, is that eventually – sooner than later – ‘Phoenix’ will die completely, and this time, there will be no resurrecting her, because the problem will be in the hardware and not in the software.

(Update 1/16/2018 : But. there’s another possible explanation… )

## 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 :

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

## How To Burn Blu-ray Movies using Linux – via the GUI

One project which I had half-installed on my laptop named ‘Klystron’ some time ago, but which was not working, was software that would make the task straightforward to carry out, to burn Blu-ray movies from a Linux computer. Because I finally wanted to get that working, I spent time on this in-depth today.

One fact which many people understand, but few people know how to manage, is that Blu-ray movies are not supposed to be burned using the ISO9660 File-System, nor, with the .ISO-Files typically associated with that FS, that store its images. Technically, Blu-ray movies are supposed to be burned using a File-System called ‘UDF’, and version 2.50 of that preferably. Under certain circumstances, v2.01 of UDF may have to suffice, since Linux support for v2.50 is still lagging.

(Edit 10/19/2017 :

I suppose that one detail which I should have included all along, is that I was doing this on a Debian / Jessie system, which is also known as Debian 8. This is also known as the ‘oldstable’ version of Debian now, just because of technological progress. Therefore, Debian 8 was unable to do certain things, which Debian 9 can do out-of-the-box.

I will explain below, why The patch which I described in this posting, should not be undertaken on a Debian / Stretch system, which is also known as Debian 9, and which would be the up-to-date version of Debian as I’m writing this. )

I will spare the reader a lengthy account of what did not work. In order for this to work, I needed to have the Debian Multimedia Repository installed in my /etc/apt/sources.list , which should be straightforward for other people to duplicate. And my main purpose in having this repository, was to get the package ‘tsmuxergui’, version 2.6.11 . In addition, I was working with ‘K3b’ , v2.0.2 .

‘tsmuxergui’ is a GUI-front-end for ‘tsMuxer’, which is a program that can be used to set up Chapters and other playback details, as well as the 1920×1080, H.264-compressed video files of course, that are supposed to make up the program on the final Blu-ray.

As my burner, I used the external ‘Pioneer BDR-XD05′, that connects via USB 3.

There is one additional component which I needed, before K3b was willing and able to burn the UDF File System required, which it is not able to do out-of-the-box:

An out-of-tree version of ‘cdrecord’ , v3.02a7

According to its authors, the versions of cdrecord that have been placed in the standard repositories belongs to ‘cdrkit’, not ‘cdrtools’, and cdrkit fails to provide the back-end, which K3b would need to burn UDF. Yet, to try to perform a binary install of the out-of-tree version, would have been very dangerous to my system. So what I did, and what I would urge other people to do, is to use one of the source-code (tarballs) from above.

First, if the reader has ‘wodim’ installed from the package-manager, I would recommend uninstalling that, just to make sure that package-version-binaries are not overwritten by the out-of-tree versions. Then, I used the above source-code, to custom-compile ‘cdrtools’.

(Edit 10/19/2017 :

If the reader is using Debian / Stretch. aka Debian 9, then the above precaution should fail. The reason for this is the fact, that under Debian / Stretch, K3b depends on ‘wodim’. Therefore, telling the package-manager to uninstall ‘wodim’, will most probably also cause the uninstallation of ‘K3b’.

Now, I can think of several reasons for which Debian Maintainers might have made K3b to depend on ‘wodim’ in Debian Stretch. One possibility, is that they might just not like this patch being applied.

But it seems to be confirmed to me – according to this test – that under Debian / Stretch, K3b is able to burn UDF / Blu-ray File-Systems out-of-the-box. And what that would mean is that to apply this patch is neither required nor desired. )

The nice feature about this version, is that it does not even install itself to ‘/usr/local/bin’. Instead, it installs its binaries to ‘/opt/schily/bin’ , when we finally give the command ‘make install’ with root privileges, so that the ultimate risk of messing up the system is small.

(Updated 10/23/2017 : )

## Audio Disks Disk-At-Once

I have been taking a trip down memory lane, into the subject of Audio CDs, which some people today do not even recognize. And one type of Audio CD which users were once able to record, were ‘DAO’, or, “Disk-At-Once” recordings.

I should just explain what that means. Similarly to the old vinyl records, the first Audio CDs produced by big companies, had a single track from beginning to end. This track wound in a dense coil, in the middle of each Music Track, producing a surface on the CD that was noticeably matte. But between music tracks, this optical track was much less densely-wound. There would be a gap on the surface of the disk, which was less than a millimeter wide, which was more reflective, and which the early CD players used, when commanded by the listener to ‘skip in’ to Track 5, let us say. But, if playback was already underway on Track 4, near the end of Track 4, there would be ‘pre-gap’ audio played, as the playback continued into Track 5. Skipping in to Track 5 would bypass this introductory, pre-gap audio.

The first CD-Rs burned by PC users, were not Disk-At-Once, but rather had lasers which would switch off between tracks, thus leaving those non-continuous. This is now referred to as ‘TAO’. But the modern hardware and software seeks to mimic, what the big companies were able to do, by providing DAO Audio Disks.

I am exploring how I would need to use K3b to do all this.

There has been some misconception on public forums, as evidenced by users asking, ‘Why K3b does not insert silence, if’ on earlier versions of this application, ‘they had set the pre-gap time to 2 seconds.’ ( :1 )

That pre-gap time was never meant to insert any silence. In the above example, all it meant was that the first 2 seconds of Track 5 were supposed to hold the pre-gap, as supplied by the user who is acting as artist. It would also tell the CD Player, to start the counter at -2 seconds, instead of at 0, when playing through. If the artist wanted for there to be 2 seconds of silence, the responsibility would still have been his, to make sure each of his Audio Tracks began with 2 seconds of silence.

The first 2 seconds of any Audio Track so programmed, would again be skipped by the CD player, when the player was instructed to skip ahead to said track.

What the developers of K3b soon realized, was that most people have Audio Tracks, on which the songs start immediately. And so in some later version, they designed K3b so that the ‘post-gap‘ of the current Track could be be set to something other than 0, if there was a following Track.

Thus, instead of having a pre-gap timing on Track 5 set to -2 seconds, it is now possible to have a post-gap timing for Track 4, set to 2 seconds, which does the same thing which an assumed pre-gap on Track 5 used to do.

The post-gap setting on Track 4 will now tell the timer of the CD player to stop counting time belonging to Track 4, and to jump back to -2 seconds, as continuous playback continues, within the last 2 seconds of Track 4, and also to continue at the beginning of Track 5, by which time the timer should have reached 0.

So now, if the artist wants for there to be an actual 2 seconds of silence, he would need to edit into the last 2 seconds of Track 4, before adding Track 4 to his project. Also, with a post-gap timing set for Track 4, if the listener decides to skip in to Track 5 on his player, he will no longer be directed to 2 seconds, inside Track 5. (Never was.) Instead, his player will now take him directly to the exact beginning of Track 5, because the logical pre-gap of Track 5, is now the post-gap of Track 4, according to the new system. (Always was.)

The purpose in doing this, is that the gap between the tracks could be something other than silence. For example, specifically between Track 4 and 5, it could be the intention of the artist, to put a 10-second effect, which will not play if the CD player is advanced directly to Track 5. In this case, the artist would need to edit this effect into the ending of Track 4, and set the ‘post-gap’ of Track 4 to 10 seconds

Dirk

(Edit 08/07/2016 : ) If it is honestly the intention of the author, to have a sound-effect acting as an intro to the following Audio Track, that plays for more than ?4 seconds? , There would be nothing preventing him from editing that into the ending of the preceding track, but still to leave the post-gap set to 2 seconds.

Also, authors have run in to the problem from time to time, that they hear a popping or crackling sound when they try to create a DAO Disk. This could be due to some malfunction of their disk-authoring software, or of their CD-R drive. But there can also be a more innocent cause for this.

The fact that the audio streams supplied to the authoring software are digital, does not preclude the possibility that they could be storing some type of DC (Direct-Current) Offset. Most disk-authoring software makes no attempt to smooth the transition from one Track to the Next. I.e., we might be tempted to think, that because the amplitude of the signal could be zero at the moment of transition, the last sample of Track 4 in my example, should also be exactly equal to the first sample of Track 5. Well they may not be equal, and if they are not, this will also produce a crackling or popping effect.

In the case of silence, audio editing software that computes DC offset, which is nothing but the average of all the samples of a Track, may offer to zero that, let us say as part of a normalization step (Audacity example shown).

In case music or sound should play continuously over the transition / gap, the only way really to make sure that 2 successive samples match, is to start with a single Track, and to Split that, and to do no further editing of the resulting, shorter Tracks.

And yet, this is also a possible situation where either the software or the CD-R drive may not cooperate.

(Note : ) If all you are looking for is an easy way to insert 2 extra seconds of silence between your songs, the best suggestion I would come up with, would be to use a sound editor such as ‘Audacity‘, to create a single 2-second sound track, which has been formatted correctly, and which contains silence.

Then, within ‘K3b’, If for example you had 10 Audio Tracks to start with, you could insert your silence Track as the even-numbered Tracks 2-18, such that the original music Tracks become the odd numbered ones from 1-19. Then, you can use the context menus within K3b itself, to merge each of these odd-numbered tracks with the even-numbered one which follows it, so that you have 10 Audio Tracks again. Tada.

1: ) ( 06/12/2016 ) I should really not be so presumptive. There can easily be other disk-burning applications, which do insert those 2 seconds of silence. Further, ‘K3b’ versions earlier than 0.12 also used to do so. K3b version 0.12 started to change the behavior of the ‘pre-gap’, but it was still referred to as a pre-gap. The version of K3b which I now have, which I am basing this posting on, is version 2.0.2 . And it was one of the more recent versions such as 2.0.2 , which started to reorganize the pre-gap as the ‘post-gap’.

(Edit 08/07/2016 : ) I mentioned the earliest CD Players, which needed an actual gap on the disk which was more reflective, to recognize a track-switch in commercially-made CDs. Well, one reason for which the earliest DAO disks had a pre-gap, pertained to the fact that the medium itself had grooves, with a constant spacing. Users might imagine that their disk-burners are able to work very autonomously, but in fact they require that the surfaces have depressions – or other patterns – manufactured into them, into which they burn their tracks.

I think that with the earliest software, TAO disks may have actually been recorded in such a way, that the player would still see them as being ‘more reflective’, but this would be because the disk had spent numerous revolutions, with no content in that groove.

What any more recent player will do, when instructed to skip ahead to ‘Track 5′, is compute approximately how many turns into the disk this will be found, and then start reading the track…

A certain bit encoded into the track actually signifies that it belongs to the pre-gap, and that as such it still belongs to the track preceding the one sought (belonging to #4). Playback will then not start, until this bit becomes zeroes.

But when playing through from ‘Track 4′ in such a case, the other bits are still allowed to contain audio, assuming modern players.