Which of my articles might paraphrase frequency-domain-based sound compression best.

I have written numerous postings about sound-compression, in which I did acknowledge that certain forms of it are based on time-domain signal-processing, but where several important sound-compression techniques are based in the frequency-domain. Given numerous postings from me, a reader might ask, ‘Which posting summarizes the blogger’s understanding of the concept best?’

And while many people directly pull up a posting, which I explicitly stated, describes something which will not work, but displays that concept as a point-of-view, to compare working concepts to, instead of recommending that posting again, I would recommend this posting.

Dirk

 

About +90⁰ Phase-Shifting

I have run into people, who believe that a signal cannot be phase-advanced in real-time, only phase-delayed. And as far as I can tell, this idea stems from the misconception, that in order for a signal to be given a phase-advance, some form of prediction would be needed. The fact that this is not true can best be visualized, when we take an analog signal, and derive another signal from it, which would be the short-term derivative of the first signal. ( :1 ) Because the derivative would be most-positive at points in its waveform where the input had the most-positive slope, and zero where the input was at its peak, we would already have derived a sine-wave for example, that will be phase-advanced 90⁰ with respect to an input sine-wave.

90-deg-phase-y

But the main reason this is not done, is the fact that a short-term derivative also acts as a high-pass filter, which progressively doubles in output amplitude, for every octave of frequencies.

What can be done in the analog domain however, is that a signal can be phase-delayed 90⁰, and the frequency-response kept uniform, and then simply inverted. The phase-diagram of each of the signal’s frequency-components will then show, the entire signal has been phase-advanced 90⁰.

90-deg-phase

(Updated 11/24/2017 : )

Continue reading About +90⁰ Phase-Shifting

PrintFriendly Button

In the bottom left-hand corner of each of my postings, the reader will see a little icon that has a printer-symbol on it, and the word “Print”. This icon can be used either to print the posting in question, or to save it to a PDF File, on the reader’s computer. In fact, the reader can even delete specific paragraphs from his local copy of my posting – since plausibly, the reader might find some of my postings too long to be printed in their entirety.

Some time ago, I had encountered a situation where Not code belonging to this plug-in, but Rather the URL which hosts the service, was showing me a warning in my browser, that ‘unknown URLs’ were trying to run scripts.

My own Web-browser has a script-blocker, which will display scripts to me which a page is trying to display, but which I did not authorize.

Certain features which I use on my blog, are actually hosted by the Web-site of 3rd parties, whose scripts may run, just because my page includes their widget.

The first time I noticed this I went into an alarm-mode, and removed the button from my blog quickly, thinking that maybe it was malware. But some time after that, I installed an additional extension to my blogging engine, called “WordFence”. This is an extension that can not only scan the (PHP-) code present on my own server for viruses and other malware, but that can also just scan whatever HTML my blogging engine outputs, for the possible presence of URLs to sites that are black-listed, regardless of how those URLs ended up being generated by my blogging engine.

Once I had WordFence installed, I decided that a more-Scientific way to test the PrintFriendly plug-in, would be to reactivate it, while WordFence is scanning my site. If any of the URLs produced by this plug-in were malicious, surely WordFence would catch this.

As it stands, the PrintFriendly button again displays URLs which belong to parties unknown to me. But as it stands, none of those URLs seem to suggest the presence of malware. I suppose, that the hosts of PrintFriendly rely on some of those scripts, to generate income? Since I’m not required to pay, to use their button.

Dirk

 

Three types of Constants that exist in C++

In a previous posting, I explained that I am able to write C++ programs, that test some aspect of how the CPU performs simplistic computations, even though C++ is a high-level language, which its compiler tries to optimize, before generating a machine-language program, the latter of which is called the run-time.

As I pointed out in that posting, there exists a danger that the computation may not take place the way in which the code reads to plain inspection, more specifically, in the fact that certain computations will be performed at compile-time, instead of at run-time. In reality, both the compile-time and the run-time computations as such still take place on the CPU, but in addition, a compiler can parse and then examine larger pieces of code, while a CPU needs to produce output, usually just based on the contents of a few registers – in that case, based on the content of up to two input-registers.

I feel that in contrast with the example which I wrote will work, I should actually provide an example, which will not work as expected. The following example is based on the fact that in C++, there exist three basic types of constants:

  1. Literals,
  2. Declared constants,
  3. Constant Expressions.

Constant expressions are any expressions, the parameters of which are never variables, always operators, functions, or other constants. While they can increase the efficiency with which the program works, the fact about constant expressions which needs to be remembered, is that by definition, the compiler will compute their values at compile-time, so that the run-time can make use of them. The example below is an example in which this happens, and which exists as an antithesis of the earlier example:

 


// This code exemplifies how certain types of
// computations will be performed by the compiler,
// and not by the compiled program at run-time.

// It uses 3 types of constants that exist in C++ .

#include <cstdio>

int main () {
	
	// A variable, initialized with a literal
	double x = 0;
	
	// A declared constant
	const double Pi = 3.141592653589;
	
	// A constant expression, being assigned to the variable
	x = ( Pi / 6 );
	
	printf("This is approximately Pi / 6 : %1.12f\n", x);
	
	return 0;
}


 


dirk@Plato:~/Programs$ ./simp_const
This is approximately Pi / 6 : 0.523598775598
dirk@Plato:~/Programs$


 

If this was practical code, there would be no problem with it, purely because it outputs the correct result. But if this example was used to test anything about how the run-time behaves, its innocent Math will suffer from one main problem:

When finally assigning a computed value to the double-precision floating-point variable ‘x’ , the value on the right-hand side of the assignment operator, the ‘=’ , is computed by the compiler, before a machine-language program has been generated, because all of its terms are either literals or declared constants.

This program really only tests, how well the ‘printf()’ function is able to print a double-precision value, when instructed exactly in what format to do so. That value is contained in the machine-code of the run-time, and not computed by it.

BTW, There exists a type of object in C, called a Compound Literal, which is written as an Initializer List, preceded by a data-type, as if to type-cast that initializer list to that data-type. But, because all manner of syntax that involves initializer lists is distinctly C and not C++ , I’ve never given much attention to compound literals.

(Edit 11/13/2017 : )

In other words, if the code above contained a term of the form

( 1 / ( 1 / Pi ))

Then chances are high, that because this also involves a constant expression, the compiler may simplify it to

( Pi )

Without giving the programmer any opportunity, to test the ability of the CPU, to compute any reciprocals.

Dirk