An observation about some purchased FLAC Files.

One of the ideas which I’ve blogged about often – a pet peeve of mine – is how lossy compression is not inaudible, although some people have claimed it is, and how its use degrades the final quality of modern, streamed or downloaded music.

And so if this is taken to be real for the moment, a question can rise as to what the modern methods are, to purchase High-Fidelity, Classical Music after all. One method could be, only to purchase Audio CDs that were mastered in the 1990s. But then, the eventual problem becomes, that even the best producers may not be mastering new recordings in that format anymore, in the year 2019. We may be able to purchase famous recordings made in the 1990s, but none from later, depending on what, exactly, our needs are. But, an alternative method exists to acquire such music today, especially to acquire the highest quality of Classical music recorded recently.

What people can do is to purchase and download the music in 16-bit, FLAC-compressed format. Ideally, this form of compression should not insert any flaws into the sound on its own. The sound could still be lacking in certain ways, but if it is, then this will be because the raw audio was flawed, before it was even compressed. By definition, lossless compression decompresses exactly to what was present, before the sound was compressed.

I have just taken part in such a transaction, and downloaded Gershwin’s Rhapsody In Blue, in 16-bit FLAC Format. But I made an interesting observation. The raw 16-bit audio at a sample-rate of 44.1kHz, would take up just over 1.4mbps. When I’ve undertaken to Flac-compress such recordings myself, I’ve never been able to achieve a ratio much better than 2:1. Hence, I should not be able to achieve bit-rates much lower than 700kbps. But the recording of Gershwin which I just downloaded, achieves 561kbps. This is a piece in which a piano and a clarinet feature most prominently, and, in this version, also some muted horns. And yet, the overall sound quality of the recording seems good. So what magic might be employed by the producers, to result in smaller FLAC Files?

(Updated 8/19/2019, 17h00 … )

Continue reading An observation about some purchased FLAC Files.

Can a VPN carry out a Man-In-The-Middle Attack?

If the reader needs to ask this question, then I’d suggest that the question should first be translated into a similar question, which the reader more-probably needs the answer to:

‘Can software which claims to be a VPN, intercept the user’s data or carry out a MITM attack?’ A way in which some software can attack its user is by misleading him or her, about what its nature is. In order to assess this question quickly, I’d ask two more questions about the software:

  • We know that Windows, Mac and Linux computers have a large variety of installed libraries, that make up the core of how each O/S works, which under Windows are .DLL-Files, and which under Linux consist finally of .SO-Files. Does this software replace any of those existing libraries with its own versions?
  • Does this software install anything, such as Browser Extensions, which may change the way the browser behaves?

If the answer to either of these two questions was ‘Yes’, then in fact, this software has an opportunity to perform a MITM.

If the answer to both questions was firmly ‘No’, then the possibility is more likely, that this software really is ‘just a VPN’, in which case it should not be able to perform a MITM.


 

Why? Because, as long as we are connecting to a Website the URL of which begins with ‘httpS://’, and not ‘http://’, what a healthy browser will do is to encrypt its traffic to and from the site, using a public key, for which only the intended site has the private key, needed for decrypting the exchanged data. This is already being done by mainstream browsers, on the assumption that one or more of the connecting pieces of the Internet are insecure or untrustworthy. In the case where a link in this chain actually performs its own encryption, well that’s just another insecure link according to the way data is secured.

Data can be encrypted more than once, and, assuming that different encryption keys are being used each time, taking data which was already encrypted, and encrypting it again, does not by itself compromise the security of the data. The resulting stream just needs to be decrypted twice again, each time using the appropriate keys, each of which is held by a different party, to translate the data back into its clear-text form, in this case finally on the Web-server.

Therefore, VPN software operating as it should, ends up passing through any data that has been encrypted using a shared secret between the browser and the server, as though this data just consisted of random bytes. But, a VPN will add a layer of encryption to it. It can also be said conversely, that, given the encryption of the VPN, the browser adds its layer of encryption.

But what of software that confuses its users into installing special browser extensions, or library-overrides? Well, such software could have as its special behaviour, to cause the client to bypass its own encryption, only applying whatever encryption the so-called VPN may apply, and also doing what any client could do, which is, to connect to the server using encryption that exists between the VPN and the server, as a proxy. A computer which has been modified in this way is essentially hacked.

Dirk

 

VDPAU Playback Issue (Problem Solved).

One of the facts which apply to Linux computing is, that NVIDIA created an API, which allows for certain video-streams to be played back in a way accelerated by the GPU, instead of all the video decoding taking place on the CPU. And, users don’t necessarily need to have an NVIDIA graphics card, in order for certain graphics drivers to offer this feature, which is called ‘VDPAU’, an acronym that stands for “Video Decode and Playback API for Unix”. Simultaneously, what some Linux users can do, is to experiment with shell-scripts that allow us to click on a specific Application Window, in order to perform screen-capture on that Window for a specified number of seconds, ad then to compress the resulting stream into MP4, AVI, or MPG -Files, once the screen-capture has finished. This latter piece of magic can be performed using elaborate ‘ffmpeg’ commands, which would need to be a part of the script in question. And in recent days, I’ve been tweaking such scripts.

But then an odd behaviour crept up. My NVIDIA graphics card supports the real-time playback of MPEG-1, MPEG-2, DIVX and H.264 -encoded streams, with GPU-acceleration. Yet, when I clicked on the resulting animations, depending on which player I chose to play those with, I’d either obtain the video stream, or I’d just obtain a grey rectangle, replacing the captured video stream. And what I do know, is that which of these results I obtain, depends on whether I’m playing back the video stream using a software decoder purely, or whether I’m choosing to have the stream played back with GPU-acceleration.

I’ve run in to the same problem before, but this time, the cause was elsewhere.

Basically, this result will often mean that the player application first asks the graphics card, whether the latter can decode the stream in question, and when the VDPAU API responds ‘Yes’, hands over the relevant processing to the GPU, but for some unknown reason, the GPU fails to decode the stream. This result can sometimes have a different meaning, but I knew I needed to focus my attention on this interpretation.

Linux users will often need to have some sort of file-format, in which they can store arbitrary video-clips, that do not need to conform to strict broadcasting and distribution standards, even when the goal is ‘just to monkey around with video clips’.

I finally found what the culprit was…

(Updated 8/15/2019, 22h15 … )

Continue reading VDPAU Playback Issue (Problem Solved).

Unattended-Upgrades fails to install any updates (Solved).

All my desktop and laptop computers are Linux-based, more specifically, being Debian-based, but I enjoy having some of the simplifications which Windows offers, including either to notify me of pending updates, so that I can use point-and-click methods to install those, or even, in some cases, to install updates automatically. The package which I use, to install updates automatically, as I sleep, is called ‘unattended-upgrades’, which is a package which cannot simply be installed and forgotten. If the user has installed this package, he or she must also configure it. And the following Web-article explains, how to do so under Debian:

https://wiki.debian.org/UnattendedUpgrades

A situation I was having for some time was, that ‘unattended-upgrades’ was installed and working fine, on my Debian / Jessie – aka Debian 8 computer named ‘Phoenix’, but that even though I had followed all the instructions for how to install and configure it on my Debian / Stretch – aka Debian 9 computer named ‘Phosphene’, the same package did not seem to work on that one. I had often found that if there did exist updates which the automated process was supposed to install, then the log file on ‘Phosphene’ would break off, just before indicating which packages were going to be installed, and no updates would take place. This would happen every time that some updates were to be installed, and required each time, that I install the updates in question manually. Also, the ‘normal’ logging output did not include any error messages; it would simply stop in mid-process.

What I finally needed to do in order to troubleshoot this process, was to wait until there were going to be pending updates, and then, instead of installing those manually, to run the following command from the command-line, as root, and to observe the output:

 


# unattended-upgrades -d

 

Running this command when there were no updates pending was rather useless, because the malfunction would not take place, unless there were updates pending. Also, this process should not be interrupted if it’s in the middle of installing updates, because doing so can and will cause package-corruption and / or software corruption. If the process is going to install multiple packages, the user needs to wait until that process has finished, before doing anything else from the same command-line. What I finally found was, that the article linked to above omits a very important piece of information.

Continue reading Unattended-Upgrades fails to install any updates (Solved).