Serving the Acoustics Community Since 1994
Cross-Spectrum Labs offers Sound & Vibration Consulting Services
A man in Santa Fe has sued his neighbor because he claims that the neighbor’s use of wireless electronics is causing health problems. These types of stories appear on the internet every few months, complete with commentary about how crazy the alleged victims are.
In reading stories like these, I admit that I tend to come down on the side of “the victim is crazy” but it does remind me of a certain type of project that comes my way about once a month or so: I get a call from someone complaining that excessive noise or vibration from a nearby source is extremely disruptive to their quality of life - sleep disruption, nausea, inability to concentrate, etc. I rush over with my equipment, prepared to measure noise and/or vibration levels in exceedance of the relevant criteria.
In these types of projects, the first question I tend to ask when I show up on site is “is the source operating right now” - when the response is “yes” my heart sinks, because I can’t hear or feel anything, and my instruments show nothing above typical background levels.
When I show up on site to investigate a noise or vibration complaint, there are four ways things can go:
The first are the easy projects - I have data and my own subjective impressions to analyze and document the problem. The second are still straightforward projects and I can let the objective numbers do the talking for me. The third are some somewhat more difficult since I have only my subjective impressions to go on, but as an expert, my impressions carry weight.
The fourth are the worst - I have no data and no subjective descriptions of my own that I can use to describe or analyze the problem. It’s tempting to want to write the complainants off as kooks or people who are imagining things, but I’m usually convinced that the complainants do sincerely experience a disruption. It may be that the source is acoustical in nature but beyond the limits of my equipment and ears to detect. It could be that the source isn’t acoustical - for instance, the negative effects attributed to low-frequency noise from wind turbines may be caused by shadow flicker rather than airborne noise and similar things may be happening with other sources.
In the end, there’s little I can do. But the one thing I won’t do is laugh or poke fun, because to those folks, it’s no laughing matter.
Researchers from the Dresden University of Technology have developed SweetSpotter, a Windows program that uses a webcam to track the position of a single listener and adjusts the response of stereo loudpseakers to ensure that the listener always remains in the audio “sweet spot”.
The research behind the program is presented in two papers available on the SweetSpotter website. I haven’t had a chance to read them yet (or use the program since I don’t have a webcam), but on the face of it, this is a technology with a lot of potential.
CNet demonstrates a method to skip those “unskippable” trailers and piracy warnings that are common on DVD’s. Unfortunately it doesn’t seem to work on a few DVD’s I tried (Toshiba DVD player) but maybe you’ll have more luck.
Ethan Winer’s Audio Myths Workshop from AES NYC 2009. I haven’t had a chance to watch the whole thing, but what little I have seen is great stuff.
The calibrated microphones that I sell each come with a CD that includes the frequency response files for each individual microphone. The file format is a space-delimited text file with a frequency [Hz] , level [dB], and phase [degrees] triplet on each line as follows:
5 -14.04 0
6.3 -9.90 0
8 -6.933 0
10 -4.732 0
12.5 -3.16 0
16 -2.06 0
(Slight digression about microphone phase: I add a value of “0” for phase for compatibility with the file format, but I don’t actually measure microphone phase - in fact there’s really not a good way to measure absolute microphone phase, but that’s another blog entry.)
This text-based file format is understood by most any PC & Mac-based acoustic measurement package that I’ve come across (SMAART being the notable exception). But customers do tend to come across one compatibility problem: I chose to use the Frequency Response Data (.FRD) extension because it is a documented format. The problem is that although many software packages can handle the file format itself, they don’t like the “.FRD” extension - instead many of those programs use a variety of extensions such as “.txt”, “.mic”, “.cal” and others. The problem can be resolved by changing the “.FRD” extension to something that the program recognizes and usually everything will be fine, but this has been confusing for people. Despite the inclusion of a “Read Me” file on the discs that include this explanation, I spend a lot of time taking phone calls and responding to emails to help customers with this problem.
I really don’t want to go down the road of including files with every possible extension under the sun as that’s sure to be more troublesome then it’s worth. Given that most acoustic software packages can handle the basic format, I think it would really be better for the industry as a whole if we would just settle on a common format for calibration data.
To that end, I’ve reached out to the authors of serveral popular packages to see if we can agree on a common file extensions for calibration data. As of now, REW, Speaker Workshop, and SoundEasy currently support “.FRD”. The authors of True RTA and ARTA inform me that their next versions will include support for the “.FRD” extension. I have unfortunately not heard back from the authors of FuzzMeasure, WinMLS or Aurora. But I am hopeful we can move foward on standardizing on a file extension for calibration data. It’s a small thing, but it’s the type of thing that has tripped people up and we need to get on the same page.
Update, Mar 29, 2010:
I heard back from Chris Liscio of SuperMegaUltraGroovy - he informed me that FuzzMeasure does have support for the ".FRD" extension, but it has a bug where it won't recognize it if the extension is in upper case. I've changed my workflow to produce files with lower-case extensions and hopefully this will improve compatibility.
Two AV podcast-related items of note :
The HT Guys and AVRant podcasts are two of my favorite podcasts and I’m grateful for the mentions on these shows.
The Boston Globe ran a story about a death at Massachusetts General Hospital which was traced to a heat monitor alarm that was switched off. An investigation showed that medical equipment alarms could often not be heard by hospital staff. The proposed solution: “[turn] up the volume on all the alarms, [install] new speakers, and [assess] whether these changes solve the problem.”
As a sleep researcher who has been studying noise in health care facilities, I would urge hospital decision makers and health technology innovators to find a better solution to hospital alarm errors than turning up the volume on all the alarms. When alarms are not heard, a better solution may be to lower the background noise levels.
Don’t raise the volume of the alarms, reduce the background noise level. Makes perfect sense and I’m glad Dr. Solet spoke up.