Tag: Sinc Filter

An Observation about the Modern Application of Sinc Filters

One of the facts which I have blogged about before, was that an important type of filter, which was essentially digital, except for its first implementations, was called a ‘Sinc Filter‘. This filter was once presented as an ideal low-pass filter, that was also a brick-wall filter, meaning, that as the series was made longer, near-perfect cutoff was achieved.

Well, while the use of this filter in its original form has largely been deprecated, there is a modern version of it that has captured some popularity. The Sinc Filter is nowadays often combined with a ‘Kaiser Window‘, and doing so accomplishes two goals:

  • The Kaiser Window puts an end to the series being an infinite series, which many coders had issues with,
  • It also makes possible Sinc Filters with cutoff-frequencies, that are not negative powers of two, times the Nyquist Frequency.

It has always been possible to design a Sinc Filter with 2x or 4x over-sampling, and in some frivolous examples, with 8x over-sampling. But if a Circuit Designer ever tried to design one, that has 4.3 over-sampling, for example, thereby resulting in a cutoff-frequency which is just lower than 1/4 the Nyquist Frequency, the sticky issue would always remain, as to what would take place with the last zero-crossing of the Sinc Function, furthest from the origin. It could create a mess in the resulting signal as well.

Because the Kaiser Windowing Function actually goes to zero gradually, it suppresses the farthest zero-crossings of the Sinc Function from the origin, without impeding that the filter still works essentially, as the Math of the Sinc Function would suggest.

Further, even Linux utilities such as ‘ffmpeg’, employ a Sinc Filter by default when resampling an audio stream, but with a Kaiser Window.

(Updated 8/06/2019, 15h35 … )

Continue reading An Observation about the Modern Application of Sinc Filters

Caveats when using ‘avidemux’ (under Linux).

One of the applications available under Linux, that can help edit video / audio streams, and that has been popular for many years – if not decades – is called ‘avidemux’. But in recent years the subject has become questionable, of whether this GUI- and command-line- based application is still useful.

One of the rather opaque questions surrounding its main use, is simply highlighted in The official usage WiKi for Avidemux. The task can befall a Linux user, that he either wants to split off the audio track from a video / audio stream, or that he wants to give the stream a new audio track. What the user is expected to do is to navigate to the Menu entries ‘Audio -> Save Audio’, or to ‘Audio -> Select Track’, respectively.

Screenshot_20190314_131933

Screenshot_20190314_132014

 

 

What makes the usage of the GUI not straightforward is what the manual entries next state, and what my personal experiments confirm:

  • External Audio can only be added from ‘AC3′, ‘MP3′, or ‘WAV’ streams by default,
  • The audio track that gets Saved cannot be played back, if In the format of an ‘OGG Vorbis’, an ‘OGG Opus’, or an ‘AAC’ track, as such exported audio tracks lack any header information, which playback apps would need, to be able to play them. In those cases specifically, only the raw bit-stream is saved.

The first problem with this sort of application is that the user needs to perform a memorization exercise, about which non-matching formats he may or may not, Export To or Import From. I don’t like to have to memorize meaningless details, about every GUI-application I have, and in this case the details can only be read through detailed research on the Web. They are not hinted at anywhere within the application.

(Updated 3/23/2019, 15h35 … )

Continue reading Caveats when using ‘avidemux’ (under Linux).

There has been some confusion about the Sinc-Filter.

I have read descriptions about the Sinc-Filter somewhere, which predicted that it would become unstable, if the frequency of the input stream, happened to correspond to the spacing, between its non-zero coefficients. As far as I can tell, this prediction was based on a casual inspection of the Sinc Function, but overlooks something which is easy to overlook about it. This case also happens to correspond, to the input stream having a frequency equal to the Nyquist Frequency, of certain practical applications, such as over-sampling.

The Sinc Function has zero-crossings at regular intervals, including the center-point, where its coefficient is stated as being equal to (1.0) . This happens because the value at the center-point, is the solution to a limit equation, that corresponds to (0/0) .

This center coefficient is symmetrically flanked by two positive ones, one of which is only positive, because it forms as a division of the sine of x by the corresponding negative value of x. At frequencies below the Nyquist Frequency, the sum of their products starts to reinforce the center element. Above Nyquist, they start to cancel the product with the center coefficient.

sincplot_2

This can be complicated to plot using Computer Algebra Systems, because plotting functions are always numerical, and at (x=0), there is no numerical solution (only the Algebraic solution given lHôpitals Rule). So, a CAS typically needs to have the Sinc Function defined as a special case, to be able to plot it, otherwise requiring a complex workaround.

So it is possible that the frequency of the incoming stream aligns to the spacing between the maxima and minima of the Sinc Function. If that happens, there are two behaviors to bear in mind:

  1. The peak of the input stream could be aligned with the center-point. In that case, all the other waves will have zero-crossings, where the Sinc Function has maxima. The fact that the single input-sample seems to produce (1.0) as the output amplitude, is due to how the function is frequently normalized for practical use. According to that, maximum output should reach (2.0) at a frequency of zero…
  2. The input stream could have a zero-crossing, at the center-point of the Sinc Function, so that its product from there should equal (0.0) . In that case, the input stream will have positive peaks on one side of the center-point, that all correspond to negative peaks on the other side of the center-point. According to that, the instantaneous output should equal (0.0) .

All of this would suggest to me, that the Sinc-Filter will work properly.

sincplot_3

One way in which people can misinterpret the plot of the curve, would be to notice it has a positive peak in the center, to notice that after a zero-crossing, it forms two negative peaks, and then to conclude that those negative peaks are also the two closest non-zero coefficients to the center.

Continue reading There has been some confusion about the Sinc-Filter.

I feel that standards need to be reestablished.

When 16-bit / 44.1kHz Audio was first developed, it implied a very capable system for representing high-fidelity sound. But I think that today, we live in a pseudo-16-bit era. Manufacturers have taken 16-bit components, but designed devices which do bot deliver the full power or quality of what this format once promised.

It might be a bit of an exaggeration, but I would say that out of those indicated 16 bits of precision, the last 4 are not accurate. And one main reason this has happened, is due to compressed sound. Admittedly, signal compression – which is often a euphemism for data reduction – is necessary in some areas of signal processing. But one reason fw data-reduction was applied to sound, had more to do with dialup-modems and their lack of signal-speed, and with the need to be able to download songs onto small amounts of HD space, than it served any other purpose, when the first forms of data-reduction were devised.

Even though compressed streams caused this, I would not say that the solution lies in getting rid of compressed streams. But I think that a necessary part of the solution would be consumer awareness.

If I tell people that I own a sound device, that it uses 2x over-sampling, but that I fear the interpolated samples are simply generated as a linear interpolation of the two adjacent, original samples, and if those people answer “So what? Can anybody hear the difference?” Then this is not an example of consumer awareness. I can hear the difference between very-high-pitch sounds that are approximately correct, and ones which are greatly distorted.

Also, if we were to accept for a moment that out of the indicated 16 bits, only the first 12 are accurate, but there exist sound experts who tell us that by dithering the least-significant bit, we can extend the dynamic range of this sound beyond 96db, then I do not really believe that those experts know any less about digital sound. Those experts have just remained so entirely surrounded by their high-end equipment, that they have not yet noticed the standards slip, in other parts of the world.

Also, I do not believe that the answer to this problem lies in consumers downloading 24-bit, 192kHz sound-files, because my assumption would again be, that only a few of those indicated 24 bits will be accurate. I do not believe Humans hear ultrasound. But I think that with great effort, we may be able to hear 15-18kHz sound from our actual playback devices again – in the not-so-distant future.

Continue reading I feel that standards need to be reestablished.