Earglasses*

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.

Juicy TLDs not being eaten

I often think of web services I’d like to be able to use. Often these services don’t exist (yet) or aren’t easy to find if they do. While trying to find these services, I ask myself what I would call the service if I had created it - or if I were to create it. The reasoning behind this is, of course, that if the service exists and has an obvious name, which I have guessed correctly, I will find it quickly.

Thinking along these lines yesterday, I realised that several obvious domains for these services could make good use of TLDs other than the usual .com, .org, .net, and so on. Specifically, they could have benefitted from .ly or .ng . So I looked into registering domains with these and discovered that in the first case it wouldn’t be affordable for me and in the second it wouldn’t be straightforward.

.ng is the Nigerian ccTLD, and although there exists a Nigeria Internet Registration Association with a form to help potential registrants register their “domains”, it in fact only allows the registration of subdomains below .com.ng, .edu.ng, .gov.ng, .net.ng and .org.ng . So even if I had the most interesting site in the world, I couldn’t do something cool like host it at http://interesti.ng .

I think that’s a little crazy, because Nigeria could start making quite a healthy income from registrants who would be willing to pay for domains like that.

There’s another snag too: .ng is what’s known as a “closed” ccTLD, meaning that it’s supposed to only be used by organisations based in, or with a presence in, Nigeria. There has been high level criticism of the concept of “closed” ccTLDs for some time now, and I think much of it is valid. After all, what counts as a “presence in Nigeria” - or in any other country, for that matter? The registrar and hosting provider Web4Africa gives some guidance, and so do other sites, but it’s very vague. If I use a DNS server in Nigeria to host my domain, does that count as my having a physical presence there? I think it should, just as if I were renting an office there. But it’s not clear if it does. What is clear is that checking whether or not I have a physical presence in Nigeria is done manually. This means that Nigerian domain registration can’t happen quickly. That in turn means that there won’t be a Nigerian Go Daddy any time soon. Go Daddy is the largest domain registrar in the world by some margin, at the time of writing. It has built its business in large part, if I’m not mistaken, on its ability to perform automated domain registration. This is an opportunity that’s effectively denied to Nigerian registrars because of .ng’s closed status.

I should note at this point that I’m not a fan of all Go Daddy’s moral principles - here’s why - and for this reason, I avoid using Go Daddy (currently, I use Dreamhost and 123-reg for domain registration, but there are plenty of other good registrars about). But I do not believe that those ethics were necessary for the success of the business. What was necessary was a legal and technological infrastructure that permitted the automated registration of domains. This, and the ability to register whateveryoulike.ng, is all I am proposing herein that Nigeria should provide.

Another name I had in mind for a web service ended in .ly - the Libyan TLD. Here, the state of affairs is more promising, but still not quite ideal. There seems to be only one .ly registrar with a working web site in English: the intriguingly-named Libyan Spider Network. It seems that I could register whateverIwant.ly without too much trouble. The biggest snag is the price tag: $150 per year (for comparison, a .com typically costs $5-$15 per year). Clearly, what’s needed here is some competition. With a few more registrars in the marketplace, that price would likely fall to something a pauper like me could afford for a fledgling, unfunded web service.

Is there, you ask, a ray of sunshine in the ccTLD domain business? Well, yes. ccTLDs like .us, .uk, .jp, etc, are available through vast numbers of registrars. Competition keeps the prices low and the service reasonable (although there are opportunities to be fleeced if you’re foolish). But there are some great success stories from non-developed economies too. Tuvalu’s .tv ccTLD is wildly popular and widely available. Another island state with a thriving domain name business is São Tomé, whose .st TLD is modestly priced and available through a very efficient-looking site.

These cases highlight the shortcomings of Nigeria’s system. I don’t know why Nigeria doesn’t follow these other countries’ examples, and I wish it would.

How many humanities scholars does it take to change a professional paradigm?

There are some tech-savvy humanities scholars, there are some who try to grok modern IT but don’t quite manage, and there are some who wish information technology had never progressed beyond the invention of the book (for the extremists, even the printing press was a step too far: bound manuscripts are the height of IT for these folks*). I recently had a conversation with an eminent Cambridge humanities professor who said to me, in the context of a longer conversation about information management, “It’s like when Windows [by which he meant Word] will run on Microsoft [by which he meant a PC running Windows] but won’t work on a Mac [by which he meant... who knows? Word and Windows will both run on Macs].”

This sort of comment bothers me for three reasons. One is that it is baldly nonsensical: one must interpret it - with little guidance except one’s own background knowledge and a few of the antagonist’s preceding slip-ups - in order to make sense of it. Another is that it shows a lack of concern about accuracy; a dangerous lack of concern, in fact, for someone who has responsibility for one of Cambridge’s extensive, unique, and breathtakingly expensive digital datasets (furthermore, the scholarly accuracy of the input to the system matters little if your data is being corrupted by both its storage and its delivery mechanisms, which it was being). The third reason, which is the one of greatest personal concern to me, is that somebody like this - and he really is a brilliant scholar - might not be able to use Interpreader. Without people like that using Interpreader, or something like it, the paradigm of keeping annotations private and interpretations informal will remain among at least some of the best (in a traditional sense) scholars. That is not what I want.

My usability hat just swivelled itself onto my head a little more firmly.

* I’ve nothing against bound manuscripts per se, but they are not an efficient means of mass-communication.

So, SPK, is Symfony still doing it for you?

For the most part, yes.

It’s not flawless, but so far, for my purposes, it beats or equals the other web frameworks I’ve tried out, except possibly web2py, which I’m just starting to get to grips with. I won’t go into much detail here (I’m busy!) but here are symfony’s most noteworthy pros and cons as I see them.

Pros:

• Uses latest major release of PHP, meaning it should be deployable with just about any hosting service.
• End-to-end documentation (from download to deployment), with additional tutorials for newbies.
• Fairly comprehensive API.
• Mature enough to have addressed all the normal requirements: authentication, caching, admin generation, etc.
• Last but certainly not least: a forum and IRC channel full of very helpful people who respond quickly.

Cons:

• Uses PHP, so some of the syntax is less easy to read than Python or Ruby code would be (PHP’s a double-edged sword; see the “pro” above).
• A handful of parts of the documentation aren’t up-to-date, notably in the Askeet tutorial (the documentation is still more comprehensive and up-to-date than that of most recent open-source web frameworks, however).
• The sync script for deployment behaves weirdly on Vista (though this can be overcome by using cygwin - more on how to do this here).

Symfony on Dreamhost

So, I’ve had a bit more time to continue ambling up Symfony’s learning curve, and deployed a test app on Dreamhost.

I followed the instructions on Chatteren’s blog here, and they worked like a charm, although they omit to mention the need to ensure, on the Dreamhost panel, that the version of PHP for your domain is set to 5.x.x. Mine was set to 4 point something, presumably because I’ve had my account for a while, and this meant that although the PHP CLI was using version 5 point something, and was outputting perfect HTML to the command line when I executed the site’s pages, viewing the same pages through my browser gave me an ugly error instead. See my comments (#17 and #18) on Chatteren’s post for more details.

Also not mentioned in Chatteren’s post is the need to be careful with your MySQL settings (that is, if you’re using MySQL - which, if you’re on Dreamhost, you probably are). Be sure to read the Symfony documentation on the databases.yml and propel.ini files, and remember that once you’re hosting your site on Dreamhost (rather than on your workstation, which I’m guessing is where you started developing it), your database isn’t at “localhost” any more, Toto.

À bientôt.

Learning to play symfonies

Symfony is a PHP web application framework. It has a lot going for it, like comprehensive documentation, active development, reasonable maturity and the security that - at least in principle - comes with that (seen by many eyes, etc). I’m learning to use it, for various reasons, and in considered preference to CakePHP, CodeIgniter or any of the other PHP frameworks I’ve assessed.

And so far, I like it. No horror stories yet