Power Failure Today, Downtime

I take the somewhat unusual approach, of hosting both my site and this blog, on a PC at home. I’m not saying that everybody should do this; this is only how I do it.

What this implies is that the accessibility of my site is only as good, as the WAN connection of my personal Internet service, as well as the quality with which my PC can be kept running.

Today, my home experienced a brief power failure, from approximately 9h00 until approximately 9h10. Therefore, my server went down. Yet, because I did not get back home until noon to reset things, the site remained off-line until about 12h15. I apologize for any inconvenience to my readers.

As it happens, there have been relatively few power failures to my home, this Summer. On a typical Summer, there would have been more of them.

Dirk

 

Print Friendly, PDF & Email

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

Print Friendly, PDF & Email

Different types of music, for testing Audio Codecs – Or Maybe Not.

One of my recent activities has been, to start with Audio CDs from the 1980s and 1990s, the encoding of which was limited only by the 44.1kHz sample rate, and the bit-depth, as well as by whatever type of Sinc Filter was once used to master them, but not limited by any sort of lossy compression, and to “rip” those, but into different types of lossy compression, in order to evaluate that. The two types of compression I recently played with were ‘AAC’ (plain), and ‘OGG Opus’, at 128kbps both times.

One of the apparent facts which I learned was that Phil Collins music is not the best type to try this with. The reason is the fact that much of his music was recorded using electronic instruments of his era, the main function of which was, to emulate standard acoustical instruments, but in a way that was ‘acoustically pure’. The fact that Phil Collins started his career as a drummer, did not prevent him from releasing later, solo albums.

If somebody is listening to an entire string section of an orchestra, or to a brass section, then one factor which contributes to the nature of the sound is, that every Violin is minutely off-pitch, as would be every French Horn. But what that also means is that the sound which results, is “Thick”. Its spectral energy is spread in subtle ways, whereas if somebody mixes two sine-waves that have exactly the same frequency, then he obtains another sine-wave. If one mixes 10 sine-waves that have exactly the same frequency, then he still obtains one sine-wave.

Having sound to start from which is ‘Thick’, is a good basis to test Codecs. Phil Collins does not provide that. Therefore, if the acoustical nature of the recording is boring, I have no way to know, whether it’s the Codec that failed to bring out greater depth, or whether that was the fault of Phil Collins.

(Update 8/03/2019, 12h55 : )

Since the last time I edited this posting, I learned, that Debian / Stretch, the Linux version I have installed on the computer I name ‘Phosphene’, only ships with ‘libopus v1.2~alpha2-1′ from the package repositories. Apparently, when using this version, the best one can hope for is an equivalent, to 128kbps MP3 -quality. This was the true reason, for which I was obtaining inferior results, along with the fact that I had given the command to encode my Opus Files using a version of ‘ffmpeg’, that just happened to include marginal support for ‘Opus’, instead of using the actual ‘opus-toolkit’ package.

What I have now done was, to download and custom-compile ‘libopus v1.3.1′, as well as its associated toolkit, and just to make sure that the programs work. Rumours have it, that when this version is used at a bit-rate of 96kbps, virtual transparency will result.

And I’ve written quite a long synopsis, as to why this might be so.

(Update 8/03/2019, 15h50 : )

I have now run an altered experiment, by encoding my Opus Files at 96kbps, and discovered to my amazement, that the sound I obtained seemed better, than what I had already obtained above, using 128kbps AAC-encoded Files.


 

(Update 8/04/2019, 10h10 : )

When I use the command ‘opusenc’, which I’ve custom-compiled as written above, it defaults to a frame-size of 20 milliseconds. Given a sampling rate of 48kHz, this amounts to a frame-size – or granule – of 960 samples. This is very different from what the developers were suggesting in their article in 2010 (see posting linked to above). With that sampling interval, the spectral resolution will be approximately as good as it was with MP3 encoding, or with AAC encoding, without requiring that any “Hadamard Transforms” be used. Unfortunately, even though the resulting sound-quality was very good, it also means that support for Hadamard Transforms was not tested, and the help info in using the command-line also does not mention them.

If Hadamard Transforms are in fact used, it will be easier to adapt the granules which have been encoded that way, when the transforms are being used to increase spectral resolution, not temporal resolution, because the decoder only needs to receive the signal, that any given sub-band contains 2x, or 4x, or 8x as many coefficients, as it would normally contain. Then, in order to be able to decode a given sub-band if the transform has been applied when encoding, the decoder needs to have a separately sized ‘iDCT’ buffer running, to decode the coefficient-numbers to, the output of which would need to be added, to the output resulting from the main ‘Inverse Discrete Cosine Transform’. If the transform was used to increase temporal resolution, more would be required of the decoder, such as to split a sub-band into 2, 4, or 8 time-intervals, even though a shorter frame-size has not been set. But again, a separate ‘iDCT’ buffer would need to be running.

So it’s very possible that, because a rather long frame-size was already set, Hadamard Transforms were never used in the present exercise.

The ‘opusenc’ command that I custom-compiled allows me to shorten the frame-size to 10, 5, or 2.5 milliseconds, and then, in the last case, the frames will be 120 samples short. In that case, it would be difficult to imagine that the Codec does nothing to improve the spectral resolution. However, doing so might just ensure that my Samsung Galaxy S9 would not be able to play the resulting files anymore.


 

(Update 8/12/2019, 6h00 : )

I have now listened very carefully to the Phil Collins Music encoded with AAC at 128kbps, and the exact same songs, encoded with Opus at 96kbps. And what I’ve come to find, is that Opus seems to preserve spectral complexity better than AAC. However, the AAC encoded versions of the same music, seem to provide slightly better perception of positioning all around the listener, of instruments and voices in the lower-mid-range frequencies, as a result of Stereo. And this would be, when the listener is using a good set of headphones.

Dirk

 

Print Friendly, PDF & Email

The Recent “OGG Opus” Codec

One of the uses which I’ve had for OGG Files has been, as a container-file for music, which has been compressed using the lossy “Vorbis” Codec. This has given me superior sound to what MP3 Files once delivered, assuming that I’ve set my Vorbis-encoded streams to a higher bit-rate than what most people set, that being 256kbps, or, Quality Level 8.

But the same people who invented the Vorbis Codec, have embarked on a more recent project, which is called “OGG Opus”, which is a Codec that can switch back and forth seamlessly, between a lossy, Linear Predictive Coding mode (“SILK”), and a mode based on the Type 4 Discrete Cosine Transform (‘DCT’), the latter of which will dominate, when the Codec is used for high-fidelity music. This music-mode is defined by “The CELT Codec”, which has a detailed write-up dating in the year 2010 from its developers, that This Link points to.

I have read the write-up and offer an interpretation of it, which does not require as much technical comprehension, as the technical write-up itself requires, to be understood.

Essentially, the developers have made a radical departure from the approaches used previously, when compressing audio in the frequency domain. Only the least of the changes is, that shorter sampling windows are to be used, such as the 512-sample window which has been sketched, as well as a possible 256-sample window, which was mentioned as well. In return, both the even and odd coefficients of these sampling windows – aka Frames – are used, so that only very little overlap will exist between them. Hence, even though there will still be some overlap, these are mainly just Type 4 Discrete Cosine Transforms.

The concept has been abandoned, that the Codec should reconstruct the spectral definition of the original sound as much as possible, minus the fact that it has to be simplified, in order to be represented with far fewer bits, than the original sound was defined as having. A 44.1kHz, 16-bit, stereo, uncompressed Wave-File consumes about 1.4Mbps, while compressed sampling rates as low as 64kbps are achievable, and music will still sound decently like music. The emphasis here seems to be, that only the subjective perception of the sound is supposed to remain accurate.

(Updated 8/03/2019,16h00 … )

Continue reading The Recent “OGG Opus” Codec

Print Friendly, PDF & Email