This is an online supplement to my article "Design and Measurement of a Dipole Microphone", appearing in the June 2009 issue of audioXpress magazine. In the article I describe the simulation, development, and testing of a directional microphone based on a design of Blumlein from 1937. I also give a tutorial on gated measurement techniques, including computer source code for readers to download. Recent events have dramatically increased the availability of studio-quality microphones for general use. The article helps readers to understand and evaluate the various types that can be purchased, and compare them with home-built alternatives.
First you need to have the article itself, starting on page 34 of the June 2009 issue. An electronic copy is currently posted on the audioXpress server. Part II of the article which focuses on the gated measurement technique is not in print at this time, but you can download a draft copy here: Dipole Microphone Online Content (4.3 MB). Then scan the following list of questions to see if you need additional information to carry out the measurements in the article. This list is written in the form of an "FAQ" (Frequently Asked Questions) although I haven't actually received any questions yet. If you have a question not answered in the article or supplements which is not addressed here, please send it by email to the address given in the graphic at the bottom of this page.
The basic requirement is to be able to play back a 16-bit linear PCM stereo .WAV file at 44,100 samples per second, while simultaneously recording a new stereo .WAV file in the same format. For my offline analysis technique to work, playback and record sample clocks must be the same, and the digital audio must not be compressed or encoded. You have to able to figure out the total delay, including both recording latency and the acoustic delay from source to microphone, by looking at the recorded waveform in a visual editor.
Almost any generic sound card or motherboard sound system should be able to handle this. You'll need appropriate cables and adapters to get from the usual 3.5 mm 3-circuit mini-jacks on the computer side to your amplifier or receiver, and your mic preamp. If you have an outboard audio digitizer it will likely perform even better, and will have more flexible interface options than an internal sound card.
In the article I used Audacity for its ability to play and record in full duplex, its compatibility with a variety of sound file formats, and its visual waveform editor with sample-accurate time cursor. It's also free, and runs cross-platform. Apple's GarageBand and related programs cannot be used, because of their lossy compression algorithms which discard phase information and distort the time envelope of the tone bursts.
The command line utility programs which I wrote in C++ to generate and analyze gated measurements using harmonically shaped tone bursts can be downloaded here: DipoleMic.zip (264 KB). The .ZIP package contains both source code, and executables built for Win32 platforms.
Here are the steps I use to be sure everything is working:
tbg.exe and tba.exe without any command line parameters, to verify that the usage text appears.
This is what I would call a "Hello World." test.
tbg.exe with just one argument, the name of a wave file to be created.
While tbg.exe is running, it sends a stream of descriptive text to the console, which you can capture by redirecting it to a text file.
The captured text should look just like this: one.txt (8 KB).
Assuming you do this in a writeable directory, the result should be a wave file containing 201 shaped tone bursts at 1/2 second intervals, sweeping from 100 Hz to 10 kHz.
Total duration of the wave file should be exactly 1:41 (101 seconds), with a length of exactly 17816444 bytes.
Look at the file in a waveform editor (like Audacity) to be verify the file's contents. Play the file and listen to it, to better understand this test signal.
tba.exe with just one argument, the name of the wave file you just created.
While tba.exe is running, it sends a stream of analysis data to the console, which you can capture by redirecting it to a text file.
The captured text should look just like this: one1.txt (24KB).
The captured text files can be opened directly in Excel, as tab-delimited fields and newline-delimited records.
This represents an "Ideal Straight Wire" test, with no frequency dependence in either the gain or phase response.
Note that the background noise measurement gives a result of minus infinity "-inf" in this test which Excel can't interpret, possibly producing an error each time it appears.
tba.exe with two command line arguments. The first argument is the name of the .WAV file just recorded, while the second argument is the total delay from the start of the
.WAV file to the leading edge of the first tone burst, in units of samples. On my Intel MacBook Pro this number was 23942, which is the base delay of 22050 samples plus a recording latency of 1892 samples.
Note that the recording latency can vary each time you click the [RECORD] button. I've plotted the gain and phase response for my MacBook Pro in an Excel spreadsheet, which you can download here: one2.xls (96 KB).
Your plot will probably look similar to mine, so don't be surprised if you find (as I did) that phase response differs between the left and right channels! In my case, the phase offset amounts to half of a sample interval.
That's really beyond the scope of this web page, but I'll just mention a few hints. First you need a development environment that can build generic C++ command line utility programs. In my work, I use Apple's X-Code on the Macintosh side, and Microsoft's Visual C++ on the Windows side. The source code I provide here relies on the compiler to keep track of byte offsets into data structures, and is therefore completely dependent on targeting only processors which use Intel byte order for words and longwords. If you want to target a processor with Motorola byte order (68K or PowerPC, for instance), you should seriously consider using .AIF format instead of .WAV for your sound files. I've already done a quick port to run on an Apple G4 Cube which runs nicely. If enough readers ask for the .AIF version, I'll clean it up and post it here. There are many resources on the internet to help you sort out sound file formats, which I won't go into here.
Audacity has its quirks, and even crashes occasionally, but is generally well-supported, and has a large user base. I was a little surprised to find that the recording latency changes each time I click the [RECORD] button. You may also find that Audacity has dropouts from time to time, which ruins the measurement. While testing on old Win98 vintage PCs, I found that if I enabled DMA in the properties tab in Device Manager for the internal hard drive, dropouts basically went away. Audacity maintains a page of helpful tips for Troubleshooting Recordings. Audacity has a feature which tries to approximately remove recording latency, but it doesn't seem to know about the variations that occur between takes.
All of the SoundBlaster cards and similar interfaces I've tried were able to operate in full duplex mode, playing two channels and recording two channels all at the same time. I was surprised however to find that they don't all use the same sample clock for record and playback. My offline analysis technique only works if the record and playback sample clocks are in fact the same, but it's not documented anywhere so you have to check this before committing to a particular hardware configuration. The steps given above for verifying your hardware and software will reveal this problem. You may even have to downgrade to an older computer or sound card to find one with a common sample clock.
It will as long as you can record and playback with a common sample clock, and can import and export .WAV files. You will probably find that a DAW will give much shorter record latency, which will probably be constant to the exact sample each time you click [RECORD].
I've tried this, and found that it fails for several reasons. First, the duration and spacing of the gated tone bursts are set up to approximate free-field conditions in a relatively small space. This means that filters with a slope of more than about 6 dB per 8va won't reach steady state, so the plotted response will be full of artifacts. Second, it won't work for an analog tape deck because the time delay will be unknown and variable. I may develop a separate offline analysis technique for this in the future, but this isn't it.
In the article, I claim that sound pressure falls as 1/r, where r is the distance from an ideal point source radiating spherical waves. Readers may wonder if I checked my setup to verify this before publication, and the answer is "Yes." I placed the mic stand in Photo 1 on top of what amounts to a furniture dolly, and moved it in small increments away from the loudspeaker while recording tone bursts at a fixed frequency. In this way I obtained a series of on-axis amplitude measurements over a range of distances from 9" to 44" in 56 steps of 5/8" each, and then used Excel's "Add trendline..." utility to match the measured amplitude to a power law curve. The fitted exponent turned out to be -1.06 at 300 Hz, which is very close to -1. So practically speaking, my Auratone 5C Super Sound Cube does behave as a point source emanating spherical waves.
Obviously the acoustic time delay was steadily changing while carrying out this measurement, so I had to modify the analysis program tba.exe
to add a fixed delay before each burst. This is easier than it sounds, and the results were pretty good.
The time shift added by moving the microphone 5/8" is almost exactly 2 samples at 44.1k samples/second, so I just added an extra 2 samples of offset
before measuring each tone burst. Actual measurement data is available in an Excel spreadsheet here: powerLaw.xls (80 KB).
In the article, I claim that the dipole length (as measured by phase or time delay) is approximately equal to the distance between the center lines of the two capsules. Readers may wonder if I checked this before publication, and the answer is "Yes." I was able to make very precise measurements of relative phase shift between the two capsules while rotating the dipole microphone on a turntable. Note that this technique cancels out the unavoidable phase shift due to small motions of the whole dipole towards or away from the loudspeaker. The following table gives the results at three different frequencies.
| Frequency | Dipole Length |
|---|---|
| 300 Hz | 13.6 mm |
| 1000 Hz | 12.25 mm |
| 3000 Hz | 12.5 mm |
The actual distance between the center lines of the two capsules in my prototype microphone is 7/16", or 11.1 mm. So the acoustic dipole length is only approximately equal to the center line spacing. This is not a surprise, since the presence of the capsules certainly affects the sound arriving at each diaphragm. The actual response to incident sound must be integrated over the surface of the diaphragm to account for such effects. Actual measurement data is available in an Excel spreadsheet here: dipoleLength.xls (184 KB).
The command line utility programs available here only support 16-bit linear PCM stereo .WAV files at 44,100 samples per second. Further, they expect the file header chunks to always appear in the same order, with no unknown chunks inserted in between. Luckily, this seems to work fairly well with the various audio recording and playback programs that I have access to. You can always try different file formats by changing the source code available here and recompiling the executables. This is not difficult, but implies a level of commitment that many readers may not share. As mentioned above, I might post an .AIF version here if readers start asking for it.
Readers may wonder if I've tried my dipole microphone design in a boundary layer configuration. The answer is "No," but I would very much like to. I believe it would work exactly as expected, producing the desired Fig-8 and cardioid patterns in a hemispherical 2π space. This would be very useful for recording stage productions where you would place the dipole on the floor at the lip of the stage. Handling noise coupled through the floor might be an issue, but one that can be dealt with. If I do get around to trying it, I may post the results here.
For reader's convenience, I list here the references given in the article, with URL's linked as available:
Here are some additional links not cited in my article. These may be of some assistance for those who want to dig deeper:
This error appears when the Analysis ToolPak add-in is not enabled in legacy versions of Excel. The Excel Help pages for IMSUM and IMPRODUCT have a link showing how to correct this issue.
In the article I made all the polar plots linear with respect to the radial axis, while I made the frequency sweeps logarithmic in the vertical axis. Readers may wonder how I decided on that combination, and how it compares with published curves for store-bought microphones. It is very common to show the amplitude response in units of decibels (dB) in the vertical axis. This lets you tell at a glance how much side and rear rejection you have at any given frequency. I took the further step of setting major divisions vertically to 6 dB increments, to make it easier to tell if the side response is exactly 6 dB down, as required for an ideal cardioid microphone. Most manufacturers seem to plot amplitude response with major divisions of 5 dB or 10 dB, probably because they've already done the work of evaluating the side and rear rejection so you don't have to.
Manufacturers usually plot polar response in units of decibels (dB) in the radial axis, but I chose to make it linear so I wouldn't have to deal with increasingly negative values when the rear rejection reaches a null. I normalized the polar plots to the on-axis response so I could just look at the shapes without having to think too much about absolute levels. Note that manufacturers typically don't publish a specific curve for a specific microphone. Rather, they measure a half dozen or more units of the same type and then take an average which is then used in all their literature for that type. This is reasonable given the constraints of time and money available in manufacturing. One of the luxuries we enjoy as hobbyists is that we don't have to follow such constraints.
