Facts about Sound you Probably didn’t Know

The other day I kept hearing this noise from my neighbor.  I couldn’t quite figure it out, and naturally it was annoying.  I didn’t do anything about it, but it got me thinking about some random facts about sound and noise.

• Sound travels faster through concrete than air
• Sound travels faster through most materials faster than air
• Below is a list of common materials and how fast sound travels through them (Values found at http://www.engineeringtoolbox.com/sound-speed-solids-d_713.html)

• The range of human hearing is 20 Hz – 20,000 Hz, however most people can only hear between 40 Hz – 16,000 Hz
• All frequencies are not equal.  Our ears perceive certain frequencies to be louder than others (found at Wikipedia http://en.wikipedia.org/wiki/Equal-loudness_contour):

• Sound travels a smidge less than 1 foot per second at standard temperature and pressure.  Therefore if you need to place speakers in front of other speakers, you need to delay them based on distance… 40 feet = ~40ms of delay.
• If a speaker is placed in front of another without a delay, the sound from the speaker farthest from you will sound similar to an echo.  This is called the Haas effect.  However, most people don’t notice this until there is a 40ms gap between sounds, or roughly 40 feet.  After about 40ms of delay, the intelligibility of the sound also decreases.  I.e. it starts to degrade the quality, and you start having trouble understanding what you hear.

Mostly useless facts, but they are fun to know.

Balanced Audio Connections

Someone once told me that a balanced audio connection works because of polarity. I wish I had a rolled up newspaper so I could swat him with it on the nose. Balanced systems are used to keep noise and interference out of systems. It is a common myth that balancing a system involves polarity. It does not. Polarity plays a part in keeping interference out, but the real reason balanced systems work has to do with impedance.

This type of connection is known as an unbalanced system. There is only one connection leaving the Op-Amp in device A. The second connection is ground. In device B the signal is brought in on one leg of the Op-Amp and the the second leg is a replica signal sourced to ground (or reference). In other words the signal is the same except opposite (polarity). There is absolutely nothing preventing noise and interference from entering this system.

This is a balanced input. Notice how the input connector has 3 connections instead of 2.

This a balanced output. Notice the 2 Op-Amps and 3 connections. The balanced system has both connections equally referenced to ground. How this prevents interference is an idea called Common-Mode Rejection (CMR). Because interference hits all three wires in a cable at once, they will all have an equal level of extra noise. It is voltage essentially. When the signal enters the Op-Amp at the input it looks at the ground line and sees what’s on it. It then compares what it sees on the two signal lines. It kicks out what all three have in common. Hence Common-Mode Rejection.

This is theory though. Not all inputs are perfect, and because all cables have something called cable capacitance, voltages differ minutely on each wire within the cable and the rejection doesn’t work as well as the theory states it should. But it still works pretty darn well. There is a whole science devoted to developing a standard for getting better CMR. One of my favorite resources is Jensen Transformers’ Bill Whitlock. He is a freakin genius. Here is his seminar handbook on balanced and unbalanced connections. This is where it all started making sense to me.

Enjoy!

Proper Podcasting Equipment

I am not a podcaster.  I do not think I have the voice for continued listening.  However, I am a sound guy, and I am anal about it.  I did a search online to find out what equipment is necessary for podcasting and every time I came back with:

• Microphone
• Pre-amp
• Digital Recorder
• PC Editing Software

For each item on this list I have heard some very disturbing suggestions for what type/brand to use.  I thought I would dispel some myths about each piece of hardware.

Microphone

Behringer is not a professional product line.  They say they are; they are NOT.  I said it, and I will say it again: Behringer does not make professional equipment.  No way, no how.  They market the products as professional equipment that all the big stars use, but in actual fact the equipment would never make it on a tour.  It can’t.  It’s not stable enough, and it’s not reliable enough.  It WILL break.

Enough ranting about that.  There are two main types of Microphones you will be dealing with when podcasting.  Dynamic and Condenser.  They both have their merits.  Dynamic microphones are usually cheaper because they are easier to make.  The sound quality is theoretically lesser than a Condenser Mic.  And a Dynamic Mic does not need an external power source.

Sound quality is always an issue when recording.  However, a podcast is 99% vocal.  At least on the recording side it is.  On the frequency spectrum vocals range between 80 Hz and 1100Hz.  You do not need a super-ultra-fantastic microphone for this job.  In some cases you do, but generally if that were the case you wouldn’t be reading this article – you would be talking to an audio recording professional.

You also have your choice between a Cardioid and an Omni-directional Mic.  An Omni-directional microphone will pick up sound from 360 degrees.  It’s great for dealing with multiple people talking at once, but horrible if you are talking in a loud environment.  A Cardioid (pronounced: car-dee-oid) microphone is directional.  It will pick up sound from a single direction, and is excellent if you are the only person talking in a very noisy environment.

My two cents: go talk to a sound guy directly and tell them what you are doing.  They will understand.  Brand-wise I like Shure and Sennheisser.  By all means contact me if you want more help.

Pre-amp

A pre-amp will do one of two things, but first I need to explain how a microphone works.  Essentially a microphone works by producing a very small electrical signal that is a representation of the sound hitting a membrane within the microphone capsule.  Different types of microphones (electret, condenser, dynamic, piezoelectric etc) capture and translate the frequency patterns differently.  The important thing to know is that the electrical signal coming out of the microphone is extremely low.

The voltage is so low that most recorders cannot handle the voltage.  They need more.  A pre-amp takes care of this problem.  It amplifies the signal just enough so the recorder can use it properly.  In some cases microphones need voltage going to them before they can actually produce a signal.  Condenser microphones are notorious for this.  The required voltage is called Phantom Power.  It’s a long winded explanation of what actually happens with the phantom power, but for all intensive purposes, the pre-amp will usually take care of the phantom power too.  This is definitely something you need to talk to a sound guy directly about.

Digital Recorder

I never got into digital recording, but just from basic analog to digital conversion theory, here are some thoughts:

1. Get a recorder that converts to a lossless format.  .Wav files are the most standard.  When recording you want the highest possible quality available.
2. Get a recorder that has a balanced audio input.  XLR is balanced.  Get a microphone that outputs through XLR, and a pre-amp that takes XLR and outputs XLR.  You will end up with better quality.  Balanced connections do wonders for interference.  It won’t remove interference already in the system, but it will prevent any other from getting in.
3. Get one that is durable.  You will drop it.  You just will.

PC Editing Software

For editing the podcast you want a piece of software that can handle multiple tracks.  This allows you to layer chunks of audio without losing data.  It also gives you more wiggle room to move parts around.  I like Adobe Audition.  There are many others out there though.

Zune Player

At first I was a little skeptical at the quality of the Zune Player, as it’s basically in direct competition with Windows Media Player.  In retrospect, that’s probably what made it what is today.  It’s designed to sync the Zune media player, and it works very well as an alternative to Media Player.  There are a couple problems that I have with it though:

• It’s a resource hog
• It requires a good video card to show effects
• It sorts things in weird ways when meta data is missing

The Zune Player is built on .NET.  It has a very big initial memory footprint.  It gets better as it settles into place.  My assumption is that it’s using WPF to make itself look pretty, and that’s where all the effects come from.  As a result some video cards aren’t capable of handling the effects renderings.  For instance, my laptop’s video card just dies when the effects are on.  Zune will turn them off if need be.  If the Album Artist meta tag is empty, Zune sticks “Various Artists” in place thereof.  Zune sorts based on Album Artist in the default view, so when I loaded my library into it, a whole whack of songs where under Various Artists, which isn’t all that useful.  With that being said, all the (legally) downloaded content had proper meta tags and were sorted perfectly.

However, with all the negatives, comes a few gems.  Sorting is a breeze.  Playlists are extremely easy to build.  Filtering works.  And it’s a really slick UI.

I’m a little miffed the band image is pixilated, but all the extra info brought with it makes up completely.  Talk about slick.

It also makes decent random playlist decisions.  On the UI and UX side of things it gets the job done.  It’s pretty stable.  It hasn’t blown up on me yet.  I give it my approval.  Check it out: www.microsoft.com/zune.

What Makes us Want to Program? Part 2

In my previous post I started talking about part of my personal history with software development, and when QBasic got me hooked.  I ended the post talking about the move to Canada.  We arrived in Canada literally a week (7 days exactly) before Grade 9 started.  After getting enrolled in school, I tried to find something to keep my mind occupied.  It was either that or contemplate what Grade 9 would be like for someone who used to live 3000 miles away in another country.  And winter.  Still 4 months away, but definitely something I didn’t want to think about.  Being that we moved to a house in the country, I couldn’t just walk around town either.  Mental occupation was harder than I thought.

So what does a 14 year old boy, new to the country, living in the middle of nowhere, do to keep himself from going crazy?  Install Linux of course!  I needed something to keep my interest, as well as to keep the gears in my head moving.  If memory serves, I started out with a vanilla copy of Red Hat Linux.  It was pretty easy to install, but being new to the OS architecture, the device mapping was a little confusing.  After a couple months of studying the Linux architecture, I started writing shell scripts, and even delved into the source code.  After testing some minor modifications to different components I started to learn the basis for the C/C++ languages.  Imagine that, a 14 year old kid understanding the basis for C++.

While trying to keep my mind still occupied, I came across an interesting find: The National Security Agency’s Security Enhanced Linux Kernel.  If compiled and installed wrong, you will destroy the build.  Learned that the hard way…  And seeing as I couldn’t find a proper driver for my modem anyway, I gave up on Linux and moved back to XP.  Not that the internet was all that useful anyway; I was connecting at 28.8 half the time.

Going back to the image in Part 1, I met an interesting character in school.  He turned out to be one of my best friends, and fellow developers, Greg. We started working on some odd projects here and there in VB, until I was tasked with building a web store.  Since I had never actually brought HTML and Dev together, I was a little nervous about what I was getting myself into.  Going with what I knew well, I started in ASP with VB code.  This was not ASP.NET.  Earlier, I had said I never found VB all that intuitive as a language.  The syntax never really made sense to me.  So my friend suggested I take a look at PHP as an alternative.  I liked it.

PHP had the flow of C, and the usefulness of VB.  With PHP I got the store finished and launched.  The site worked great.  I was 15.

Once the first spring of my existence in Canada rolled around, a couple friends and I decided to start a band.  We sucked.  But seeing as one of the other members was Greg, we had an awesome website.  We had media streaming, custom modified forums, and full site statistics.  The statistics were built around the forum.  The site pulled data from recent posts, recent events, and recent user logins, and compared the data to the media streams.  We could see who was doing what.  Mind you, there was only about 50 people who loitered around the site, but the site was a great proof of concept for what we could do.

Following the demise of the band, Greg and I were invited to a Microsoft hosted event.  It was here that I fell in love with ASP.NET.  Which I will discuss in Part 3.

The Tragically Hip Media Player

More of Silverlight sound implementation for multimedia app