Earglasses*

By sampablokuper | 10th Jun 2008 | Filed under Life is language, Poor man's patents, hacking, music

Mel Chua’s recent post about communication reminded me that I’m lagging on something I started many months ago: trying to find a filter chain in Wavelab that would let her hear things - music in particular - in a manner closer to that of someone with normal hearing.** A while ago she blogged about her auditory response being like that of a low-pass filter, and that made me think about what the most practical way to mitigate that response would be.

I don’t know what the audio-processing algorithms hearing aids use are, but it’s fairly clear that:

  • the user doesn’t have much ability to modify them, except perhaps in the case of highly expensive models.
  • they probably aren’t terribly powerful, because - judging by digital hearing aids’ power consumption - the processing power available to them is very small.
  • although amplification is one of the primary components of a hearing aid’s processing chain, amplification alone won’t combat most hearing difficulties (certainly not Mel’s).
  • they are optimised for speech, rather than music.

So I set about trying a different approach: CPU-intensive audio-processing using the best algorithms I could lay my hands on (i.e. Wavelab’s plugins), optimised for music. I set up an EQ stage at the end of the chain, modelled on the graph of Mel’s auditory response, and started applying filters before it in an attempt to make the end result sound as natural as possible. I had a hunch that multiband compression might be more effective for this than EQ - certainly more effective than EQ alone - and so it proved. Partly this is because multiple stages of EQ filtering can induce “ringing” (they become resonant - an unwanted side-effect). Although multi-band compressors include EQ filters to split the signal into bands, these filters didn’t seem to suffer from the same side effects, perhaps because the compression was attenuating any resonances that might have otherwise been present.

Anyhow, a few months ago - long after my first experiment, I was blessed with a few minutes of the Mel’s time, and we tried some of the filter chains, with The Decline as the test track (because it was the only CD I had to hand with a mix that I was familiar with). We were somewhat successful, but I haven’t had time to do much more with the algorithms since then.

I mentioned to Mel that I thought it would be cool to make portable Sharc DSP devices so people could carry their audio processors around with them, set up so that they could select and edit the algorithms. This isn’t very far-fetched. There are lots of battery-powered, pocket sized audio processors on the market at affordable prices (for instance, the Korg Pandora). I don’t know if they use Sharcs, but I do know that many price-breakthrough audio processors with pluggable algorithms that I’ve seen hit the market in recent years have used Sharcs, so they seemed like a good bet. (Mel knew the same company’s devices by a different name, Blackfin, and suggested those. Then we worked out we were talking about essentially the same thing :-] The Blackfin is a sibling product to the Sharc.)

And this is how I come to be writing a blog post called Earglasses. Sunglasses - filters for your eyes - are easy to get hold of, and not even very hard to make, but filters for your ears aren’t so straightforward. I doubt Mel and I can’t make earfilters possible by ourselves because we’re both too busy with other things, so this is where a community effort might come in handy. I’d love to see a bunch of people working to make earfilters - affordable, portable devices with an audio input and a headphone output and ton of helpful, user-programmable algorithms running in between - a reality. So making this an open hardware, open software project seems like the way forward.

I’ve registered earfilter.org and will set up a wiki there shortly. It will be a place that people can post their filter chains (from Wavelab, Audacity, etc), links to useful plug-ins, suggestions for hardware architecture, and anything else that’s relevant.

* * *

*It turns out there actually is a company manufacturing what they call Earglasses, a kind of latter-day ear trumpet. Whaddya know. Their engineering reminds me of Big Ears, which I’ve known about ever since I took up the dubious habit of reading Canford Audio catalogues as a teenager. (Actually, I learned a lot from those catalogues - and from CA’s competitors’ catalogues - which included pinouts, specs, regulations, construction diagrams and all sorts of other nutritious information for enquiring minds.)

**Mel’s post was, of course, not just about hearing. I’ve focused on that aspect of it here because of the earfilter.org idea, which I wanted to let the world know about. Mel’s underlying point is about communication, and I couldn’t agree with her more: any barrier to communication or comprehension can be frustrating. One of the greatest joys, for me, of living in the information age, is that we’re better placed than any previous generation to reduce or eliminate those barriers. Another great joy is that there are so many people working passionately and enthusiastically to do just that.

3 Comments »


Grep the web from the web

By sampablokuper | 11th May 2008 | Filed under Poor man's patents

I like grep. Grep lets you search within files, using regular expressions. Usually, you can even use wildcards to specify which files grep should search within. This means that when you ask grep to find something, you can give it just about as much information as you know, reducing the chances that it will spend a long time looking in the wrong place(s) or that it will return the wrong result(s).

But why can’t I do this on the web? Well, maybe it is possible, but I haven’t yet found a web site that offers to search the web in a way that lets me use wildcards while specifying which URLs to search at and that lets me use regular expression syntax to specify what to search for. (If you know of such a site, please post it here.)

In the absence of such a site, I’d like to propose creating one. So I’ve registered www.greptheweb.com and I’d like the community’s help to build a site to put there.

The site should, I think:

  • Have a front page with a form that has two fields:
    • Where to search. Here users can enter URLs with Perl regex syntax.
    • What to search for. Here users can specify strings they’re looking for, also using Perl’s regex syntax.
    • User’s should perhaps be assisted in entering their queries by means of a RegexBuddy-style helper, maybe implemented with AJAX techniques.
  • Have a help or FAQ page.
  • Have results pages that are dynamically generated with GET requests. These would be returned in response to a form submission, but would also be generated in response to a direct request, e.g. from a bookmark.

The back end of the site is the hardest part, of course. Web search engines are difficult to implement well. Scaling is an issue. I’ve never built a search engine; I’ve never written a grep-like program. Still, I have some ideas about how the back end should work.

  • It could just use the Alexa Web Search’s “grep the web” service, templating the results in HTML and returning them to the user; or
  • It could be built from scratch. If the latter, then:
  • It should, to begin with, index pages in a simplistic fashion. That is, it should include a robot that can find pages with straightforward URLs like http://www.python.org . Eventually the robot should be made sophisticated enough to find all publicly-accessible web pages.

2 Comments »