Golden Eyes: Experiments with Audio - Part 2 (are you shaved?)

Continuing from the Part 1, let's look at the waveform for track C:

Track C

If you are familiar with waveforms, you may recognize the apparent shaved-ness of the data here. I have to point out that all of the processes/artifacts has been applied to each instrument part separately and then they are glued together. Because of that, the flatness is at different amplitudes for each part as can be seen above. If we zoom into the orchestra part, it is obvious that the flat shaving is amplitude dependent and the quiet parts are not affected:

Orchestra part

Let's compare it with the original (select both audio clips in Cubase and then select 'events to part' from the Audio menu then press Enter):

Comparison of the orchestra part

Now the effect is clear! Remember to compare the left channels and right channels with each other. There are two main ways to do this effect to an audio: 1) clipping 2) limiting/maximizing. Of course clipping can also be considered as a crude type of limiting/maximizing. In clipping, the digital audio signal has become above the maximum representation capacity of the digital audio format and become cut-off abruptly. In limiting/maximizing, the audio has been similarly prevented to go above some limit but the transition to the cut-off is more gentle to prevent audio artifacts and degeneration. To make it clear, clipping is 'bad' and you don't want it to happen unless going for that specific effect. On the other hand limiting (which is a form of compression) and maximization are very common processes in the audio world but their specific usage is outside the scope of this post.

So, which has been applied here? We need to zoom in further:

Zoomed in to orchestra part

...and further:

I see waves itself!

..and further:

Shaving in plain sight

Now we see the individual waves and it looks like digital clipping more and more. If we zoom in further in the audio part editor in Cubase, the display changes to lines:

Really zoomed in

Here, the cut-off parts look flat with some exceptions. For a sound wave flatness is usually audible as pops and clicks if separated out in time, but if they are really frequent in a small time period (as in here, look at the timecode) then it sounds cracked and unpleasantly distorted (clipping distortion). (If you remember that sound is essentially a continuous or smooth change of air pressure as a function of time, the musical content will be essentially removed from these flat parts).

Even further...

I produced this effect by turning up the volume fader of the main output in Cubase allowing it to clip and then bouncing the result into the project. Let's overlay the differences showing the clipping line:

Overlay of the effect

It is interesting that the clipped parts are not actually completely flat as expected; but instead almost dips or bounces back as the clipped data goes higher. It is really weird and if anyone knows why this is happening please share it in the comments. I think this may be the result of how Cubase or my audio interface are handling the clipping data.

As another example, let's look at the drum kick clipping. Here the longer wavelength low frequency part of the kick drives the data over the clipping point. Since the higher frequencies 'live' on the lower frequency waveform, they are also gone forever (apart from that interesting dipping effect).

Overlay of the effect in the drum kick

This will provide a reference point when we compare the results with the more gentle maximizing and compression effects. In the next part I will look into phase inversion and difference of two tracks which will come really handy for our analysis.

Take care until then,
Cagil

Continue with Part 3

Golden Eyes: Experiments with Audio..uhm... part 1!

Hello everybody,

I am starting a new series of mini articles/musings under the title: "Golden Eyes". It is derived from "Golden Ears" which is a comprehensive free hearing/listening test by Philips and I strongly recommend you to take it if you record, mix any music or you are an audiophile. As of now, 1798 people completed the last level. It begins simple but becomes incrementally difficult as you approach to the latest sections and I was literally trying to hold on to the fringe of my hearing to finish it :).

Golden Ears Quiz Last Level

I have been tutoring about recording, audio engineering, mixing, and physics of audio for a while. During those sessions I have come up with my version of Golden Ears as a fun quiz for my students. I cut out some sections of instrument tracks from one of my mixing projects and then applied various effects and artifacts/distortions on it and then bounced the results on separate tracks. Then, I asked the students to identify the process involved for each track.

A Fine Selection of Vintage Waveforms!

It was tons of fun to watch their reasoning and descriptions of the effects/artifacts they hear or see. Sometimes they tried to identify the process just by listening, and sometimes by doing A/B comparisons with the original recording. But other times they were identifying the process just by looking at the waveform and/or comparing it without any listening involved. Another approach we have tried is to subtract the original from the altered tracks and listen/see the differences only (that proved to be reeaaally helpful). So that gave me the idea of Golden Eyes and hence this post (the tracks used are copyrighted anyway, so doing this without any sound upload is also highly practical :D).

Let The Games Begin!

I won't be giving out the list of processes applied beforehand since trying to guess is part of the game! Another reason for writing about this is that I am introduced to the captivating glitch art / databending world by a friend of mine and as a start I want to explore applying audio processing on other types of data to create art (or world domination haha!).

Till next time,
Cagil

Continue with part 2 here!

Readability !== Comprehension: CoffeeScript Case

I am not exactly a Javascript guy, though I acknowledge the power and need for JS in today's web environment. It seems that the CoffeeScript (CS) language, which acts as a pre-processor to JS, gains some popularity in the industry.

CS removes most of the symbols like the braces and semicolons and adds whitespaces like Python; so much that it is possible to write almost complete English sentences (long one-liners) which will be processed into tens of lines of JS code.

While searching for information on CS, I've stumbled upon an interesting criticism here by Ryan Florence, which got me thinking.

While I am a fan of syntactic-sugars in my languages and powerful data operators like the generators and list-comprehensions, I found myself agreeing with many of the criticisms int the article. Especially the ideas that readability and comprehension are different things; and the fact that the symbols are faster than words.

I wouldn't declare CoffeeScript as a bad language to use based on this criticism though since most of the criticized points are optional in it; and I like coding in Python which shares many of those features. But the general idea of the power of the symbols seems to be a good one to meditate on. Maybe Python had got rid of its 'readable' syntax in favor of more symbolism while keeping its great syntactic-sugaring and crazy data operations, it would be an even better language for me :).

Alright, so this example is from the article....Which is more comprehensible?

JavaScript:

if (five && six && seven) doStuff();

CoffeeScript:

doSomething() if five and six and seven

Another one:

wash plate, brush, sink for key, plate of dishes when plate.dirty if meal.status is 'done'

That backwards 'if' statements and the use of 'and's 'or's etc. cannot be good for fast comprehension and debugging.

One of the comments (by James Treworgy) made total sense for me:

"Actually this is the thing that has kept me away from CS more than anything else. Comparison operators are at the root of mathematical equations which are the essence of computer programming: if x = y then .... Removing the visual cue seems pointless as best. It's less terse, and it confuses literals, variables, operators, and reserved words. 

Serious programmers go to a great deal of effort to identify and implement consistent patterns in their code to make it easily comprehensible. We use capital letters to mean specific things, and we use operators and braces and parenthesis to clearly define the intent of a given expression. At the essence of CS is a desire to make code read like English. 

But English is not code. It lacks adequate syntax to clearly express the kinds of things we express in code. Would a mathematician want his integral symbols replaced with the words "integral of" or his ^ notation replaced with "to the power of "? 

Doing that would only benefit people who aren't mathematicians. Likewise, I think trying to make computer code "readable" really means "make it readable to people who aren't comfortable with the language of computers." What is more readable to someone who doesn't feel comfortable with "!==" is less readable to someone who works with it every minute of every day."

Hmmm, interesting food for thought for me concerning the meaning of coding and the relationship of the coder with the code itself.

What is Your Personal Software Development Process?

It seems that, we software developers are always on the hunt for the ultimate process to follow for our 'profession'. We are almost obssessed about the latest methodologies, life-cycles, X-driven developments, agile and heavy-weight approaches; even more so than any other similar industries out there (as far as I know).

Why is it so? I think, it is because of the nature of our field:

Boo Language Gotchas for Python Users

Recently, I have involved in a game development project that uses Unity3D engine which I had no prior experience. I'm trying to get comfortable with it now which maybe a topic for another post. This quick post is about the Boo language which is supported by the Unity game engine for scripting work. Other alternatives are C# and Javascript. I don't fancy the idea of learning C# coming from a Java and a slight no-MS background :), and I know Javascript well enough for this project. But the thing is, coding in Javascript is not much fun.... like coding in Python (for me anyways).

Another programming language popularity contest

If you are interested in the relative popularity of programming languages and the related trends, you may find TIOBE Programmıng Community Index useful. This site holds monthly popularity contests through the use of search data by Google.

How to construct a makefile on Windows and make life easier for a QGIS Python Plugin

Development of a Python plugin for QGIS is a fun experience and I plan to share my relevant adventures in a future post. But for now, I want to focus on the deployment aspect of it, which can be frustrating if done manually.

Visibility Analysis Plugin (VAP) for QGIS in the repository

Hi folks!

My humble visibility analysis python plugin for Quantum GIS can be downloaded from the User Contributed Repository. It is currently experimental software (version 0.0.9), but new features will be added soon according to my thesis work.

Updated Ash Spread Maps of Icelandic Volcano Eyjafjallajökull

I am back for a quick informative post...

Effects of Precision in Viewshed Analysis

I have added high-precision calculation option to my viewshed analysis plugin for QGIS as promised. After spending the last couple of days sick, I am back here at last :)