Sunday 22 February 2015

Moving to

I announced a while back that I was moving my blog to Well I’ve been double posting on both blogs for a while, but the transition is now complete, and no new posts will be added here.

If you’re subscribed with feedburner, then you should already be getting content via the new blog. But otherwise, please check at for all future content.

To see what you’ve missed since I’ve moved, check out my archives page.

Sunday 8 February 2015

Week Two - Bugs and Sales

Last week I told the story of how the "entreprogrammers" podcast inspired me to turn one of my ideas for an application into an actual product and make it available for sale. Of course I had no idea how it would actually do, and in the first week I only made one sale. That was pleasing in the sense that I knew that one or two sales a month would effectively cover my costs for web hosting, and also proved that that my shopping cart and license generator both worked. But I was hoping I could improve things. So in this (rather long) post, I'll tell you what happened in my second week.

Attracting Visitors

First, I needed to get some more traffic to my site and thankfully I had one quite good way of doing that. I had made a similar but limited open source application which continues to be extremely popular (still don't really know how!). I simply updated this application to suggest to users that if they wanted to record their calls they should check out the "pro" version, and directed them to my site. The traffic from this route is currently about 75% of my total traffic.

Secondly, I tried to generate a bit of buzz about the application on twitter. I don’t have a particularly big following (about 400 followers) and programmers aren't really my target market, but probably the best thing I did was to give a shout-out to the entreprogrammers. They seemed glad to re-tweet it to their many followers, and it resulted in me reaching the heady heights of about 6 concurrent visitors to the site! Takeaway: a bit of flattery can really pay off if you want people to spread awareness of your product!


The Mailing List

My third idea for getting some traffic was to leverage my mailing list. I had made a bit of a mistake in harvesting emails in the year preceding my launch. I didn't do a "double opt-in" (where you get people to verify their email by clicking a link). This meant I couldn't import the 1400 email addresses I had on the list into MailChimp.

So instead I wrote my own script in the awesome LinqPad application to send mails to this list using my own SMTP server. This revealed that just over 10% of the emails in the list were invalid, and I created a special script on my website to serve up an image in the email so I could track open rate. I was sending out in batches of 50 for fear of getting blocked as a spammer, and so I could try alternative ideas as I worked my way through the list. But 300 emails in, and I've not really seen much of a response so far.

I also emailed out to my MailChimp mailing list (the one with proper double opt in subscribers!), which is slowly growing, but currently only at 40 subscribers. Again the open rate wasn't exactly impressive, and I don't think it led to any sales, but at least this list I am allowed to keep emailing, so I have the chance to keep the product in their mind.

Tracking Errors

Another thing I did during the week, was to actually allow customers to submit the details of any unhandled exceptions they encountered during the running of the application. I needed to know if all the people who were downloading my app were actually having any success running it. The results were interesting (read about what I did here) and I discovered many problems my users were having that could be relatively easily resolved. In fact there are still several issues I need to get fixes out for next week. I suspect that users who see the app crash are much less likely to shell out for a license, so the sooner I can eliminate common causes of error the better.

A Customer Support Case

My heart sank when only my third customer since the site went live contacted the support email to say she couldn’t install the application. Turns out she was getting some kind of weird ClickOnce error (yes I know, I'm supposedly an expert in that now). Thankfully she was very patient while we tried a few troubleshooting steps and eventually we got it working for her. But I suspect I was close to having to issue my first refund.

Getting More Subscribers

One of the entreprogrammers, Derick Bailey kindly gave me some advice on my site. He particularly pointed out that visitors could simply download my application without giving their email address. He suggested I should change that, and only offer them the download if they subscribed to my list.

To do that required a bit of learning about the MailChimp API. Unfortunately because I am not on one of their paid tiers yet, I can't create an email that gets auto-sent to new subscribers. So I had to set up a webhook and send out the email with the download link myself when a subscriber was confirmed.

In fact, I currently allow users through to the download page even before they click the confirmation from MailChimp, so technically it is still possible for people to install the app without subscribing to my newsletter. I'm going to see what percentage of people do that, and if it is too high, I'll force everyone to complete the cycle and subscribe before they get the download link.

Website Redesign

The second thing I did was a complete website redesign. This was a painful process as HTML and CSS is not my strong suit. I had paid for a nice looking landing page called Ultima from Wrap Bootstrap. The challenge was working out what bits of the gigantic 3000 line CSS file and the dozen or so JavaScript libraries it came with I actually needed.


I suspect it has left my site a little bloated in terms of download size, and I'm really hoping it actually still works in all browsers, but I do feel that the site now looks a lot more professional and engaging and hopefully I'll still get a lot of people downloading and installing despite the need to enter your email address.

Social Media

I also decided that I needed to give Skype Voice Changer a presence on social media. So I created a facebook page, a Google plus page, and a YouTube channel (no videos yet). I've not yet got round to a twitter account. Of course, these are currently virtual ghost towns, but I've added some social media icons to my website, and maybe if I decide to spend some money on advertising at some point I can drive some traffic through facebook, youtube or twitter.



With only one sale in the first week, I was concerned that I had overpriced my app. I was charging $50/£30 and asking for VAT on top. Other similar Skype utilities seemed to be priced at around $30. So I decided to make the quoted price inclusive of VAT, and run a month long "launch sale" at 40% off. I thought that this might allow me to create a sense of "urgency", particularly towards the end of the month, by encouraging people to buy before the sale ends. As it is, it is rather too easy for them just to try the app out and then forget about it. What difference did my new pricing strategy make to sales? Well nearly there, read on to find out.

The Numbers - Visitors

I've had Google Analytics running in the background for much of the last week. It's fascinating how much information this tool gathers. The number of "sessions" has been artificially bloated by the number of times I've visited the site myself during development, but according to Google Analytics, I have nearly 100 different people visiting the site a day, which I'm hoping isn’t too bad for a two week old product (not really sure what I'm supposed to be expecting at this stage).


The Numbers - Sales

Finally, we're onto the bit we've been waiting for. How many did I sell in my second week? Well, I did improve on the one sale from the first week. There was a moment of excitement early in the week when I made two sales in quick succession. But sales came in at a rate of just under one a day and by the end of the week I had sold six. This was a fairly encouraging rate, and if I can keep it up will mean I comfortably cover my costs. Interestingly, including VAT in the price has not impacted my earnings at all, since all my customers so far have been from outside the EU (mostly USA, with one sale each in Canada, Australia and Brazil).


What's Next

Well although one sale a day isn’t too shoddy, I don’t think it's quite time to put my feet up and abandon this project as a source of "passive income". First of all I need to fix more of the bugs that my users are reporting. This should mean more people have a smooth first experience with the product.

I know I also need to improve the nag screen within the app, so that people who keep using it get regularly promoted to purchase a license, rather than the current half-hearted attempt that is in there.

I'm fairly happy with the overall content on my website now, but I do think I need to create at least one video, to show off the application's features and teach how to use it.

And finally, I'm a little paranoid now that with all the extra JavaScript in the site from the template I bought, maybe some visitors are getting JavaScript errors that are preventing them from being able to use the payment form. So I'd like to investigate a way of making that part of the site bullet-proof, so that whatever happens in the page load, the purchase link will always work.

Well done if you managed to read all that to the end! My goal for next week is to improve on the six sales I achieved last week. I'll let you know how I get on, and do let me know in the comments how you're getting on with your own personal entrepreneurial projects!

Tuesday 3 February 2015

How to Encode MP3s with NAudio MediaFoundationEncoder

In this post I am going to explain how the NAudio MediaFoundationEncoder class can be used to convert WAV files into other formats such as WMA, AAC and MP3. And to do so, I'll walk you through a real-world example of some code I created recently that uses it.

The application is my new Skype Voice Changer utility, and I wanted to allow users to save their Skype conversations in a variety of different formats. The WavFormat that Skype uses is 16kHz 16 bit mono PCM, and I capture the audio directly in this format, before converting it to the target format when the call finishes.

The input to the MediaFoundationEncoder doesn't actually have to be a WAV file. It can be any IWaveProvider, so there is no need to create a temporary WAV file before the encoding takes place.

Initialising Media Foundation

The first step is to make sure Media Foundation is initialised. This requires a call to MediaFoundation.Startup(). You only need to do this once in your application, but it doesn’t matter if you call it more than once. Note that Media Foundation is only supported on Windows Vista and above. This means that if you need to support Windows XP, you will not be able to use Media Foundation.

Determining Codec Availability

Since I planned to make use of whatever encoders are available on the user’s machine, I don't need to ship any codecs with my application. However, not all codecs are present on all versions of Windows. The Windows Media Audio (and the Windows Media Voice) codec, are unsurprisingly present on all the desktop editions of Windows from Vista and above. Windows 7 introduced an AAC encoder, and it was only with Windows 8 that we finally got an MP3 encoder (although MP3 decoding has been present in Windows for a long time). There are rumours that a FLAC encoder will be present in Windows 10.

For server versions of Windows, the story is a bit more complicated. Basically, you may find you have to install the "Desktop Experience" before you have any codecs available.

But the best way to find out whether the codec you want is available is simply to ask the Media Foundation APIs whether there are any encoders that can target your desired format for the given input format.

MediaFoundationEncoder includes a useful helper function called SelectMediaType which can help you do this. You pass in the MediaSubtype (basically a GUID indicating whether you want AAC, WMA, MP3 etc), the input PCM format, and a desired bitrate. NAudio will return the "MediaType" that most closely matches your bitrate. This is because many of these codecs offer you a choice of bitrates so you can choose your own trade-off between file size and audio quality. For the lowest bitrate available, just pass in 0. For the highest bitrate, pass in a suitably large number.

So for example, if I wanted to see if I can encode to WMA, I would pass in an audio subtype of WMAudioV8 (this selects the right encoder), a WaveFormat that matches my input format (this is important as it includes what sample rate my input audio is at - encoders don't always support all sample rates), and my desired bitrate. I passed in 16kbps to get a nice compact file size.

var mediaType = MediaFoundationEncoder.SelectMediaType(
                    new WaveFormat(16000, 1), 

if (mediaType != null) // we can encode… 

What about MP3 and AAC? Well you might think that the code would be the same. Just pass in MFAudioFormat_MP3 or MFAudioFormat_AAC as the first parameter. The trouble is, if we do this, we get no media type returned, even on Windows 8 which has both an MP3 encoder and an AAC encoder. Why is this? Well it's because the MP3 and AAC encoders supplied with Windows don't support 16kHz as an input sample rate. So we will need to upsample to 44.1kHz before passing it into the encoder. So now let's ask Windows if there is an MP3 encoder available that can encode mono 44.1kHz audio, and just request the lowest bitrate available:

mediaType = MediaFoundationEncoder.SelectMediaType(
            new WaveFormat(44100,1), 

Now (on Windows 8 at least) we do get back a media type, and it has a bitrate of 48kbps. The same applies to AAC - we need to upsample to 44.1kHz first, and the AAC encoder provided with Windows 7 and above has a minimum bitrate of 96kbps.

Performing the Encoding

So, assuming that we've successfully got a MediaType, how do we go about the encoding? Well thankfully, that's the easy bit. So for example, if we had selected a WMA media type, we could encode to a file like this:

using (var enc = new MediaFoundationEncoder(mediaType)) 
    enc.Encode("output.wma"), myWaveProvider) 

In fact, to make things even simpler, MediaFoundationEncoder includes some helper methods for encoding to WMA, AAC and MP3 in a single line. You specify the wave provider, the output filename and the desired bitrate:

                        "output.mp3", 48000); 


Creating your Pipeline

But of course the bit I haven't explained is how to set up the input stream to the encoder. This will need to be PCM (or IEEE float), and as we mentioned, it should be at a sample rate that the encoder supports. Here's an example of encoding a WAV file to MP3, but remember that the input WAV file will need to be 44.1kHz or 48kHz for this to work.

using (var reader = new WaveFileReader("input.wav")) 
            "output.mp3", 48000); 

But that was a trivial example. In a real world example, such as my Skype Voice Changer application, we have a more complicated setup. First, we open the inbound and outbound recording files with WaveFileReader. Then we mix them together using a MixingSampleProvider. Then, since I limit unregistered users to 30 seconds of recording, we optionally need to truncate the length of the file (I do this with the OffsetSampleProvider, and using the Take property). Then, if they selected MP3 or AAC we need to resample up to 44.1kHz. Since we’re already working with Media Foundation, we’ll use the MediaFoundationResampler for this. And finally, I go back down to 16 bit before encoding using a SampleToWaveProvider16 (although this is not strictly necessary for most Media Foundation encoders).

// open the separate recordings 
var incoming = new WaveFileReader("incoming.wav"); 
var outgoing = new WaveFileReader("outgoing.wav"); 

// create a mixer (for 16kHz mono) 
var mixer = new MixingSampleProvider(

// add the inputs - they will automatically be turned into ISampleProviders 

// optionally truncate to 30 second for unlicensed users 
var truncated = truncateAudio ? 
                new OffsetSampleProvider(mixer) 
                    { Take = TimeSpan.FromSeconds(30) } : 
                (ISampleProvider) mixer; 

// go back down to 16 bit PCM 
var converted16Bit = new SampleToWaveProvider16(truncated); 

// now for MP3, we need to upsample to 44.1kHz. Use MediaFoundationResampler 
using (var resampled = new MediaFoundationResampler(
            converted16Bit, new WaveFormat(44100, 1))) 
    var desiredBitRate = 0; // ask for lowest available bitrate 
                    "mixed.mp3", desiredBitRate); 

Hopefully that gives you a feel for the power of chaining together IWaveProvider’s and ISampleProvider’s in NAudio to construct complex and interesting signal chains. You should now be able to encode your audio with any Media Foundation encoder present on the user’s system.

Footnote: Encoding to Streams

One question you may have is "can I encode to a stream"? Unfortunately, this is a little tricky to do, since NAudio takes advantage of various "sink writers" that Media Foundation provides, which know how to correctly create various audio container file formats such as WMA, MP3 and AAC. It means that the MediaFoundationEncoder class for simplicity only offers encoding to file. To encode to a stream, you'd need to work at a lower level with Media Foundation transforms directly, which is quite a complicated and involved process. Hopefully this is something we can add support for in a future NAudio.

Monday 2 February 2015

Are you feeling your customers’ pain?

I blogged recently about finally getting the first version of my Skype Voice Changer application out the door. In order to get something into the hands of users, I had to take a few shortcuts and make a few compromises. One of those was error handling. Basically, for the first version, if something went wrong I would pop up an apologetic dialog, and suggested that they emailed my support address with details of the problem (I included the stack trace in the dialog).

Of course, I got no reported errors at all via email, which meant that no one was having any problems with my app, right?

Automated Error Reporting

Well I knew that probably there were some issues, and so in the next version I added a button on my error dialog to offer the user the chance to submit an error report to a web API. Then my web server could simply drop the error report into Azure blob storage as a text file. Nice and simple (and VS2013 makes it really easy to check a blob container for new entries and look inside them).

Well, within an hour of going live with the new version, I saw three errors reported. And they kept on coming at a rate of about one or two an hour. Some of these were clearly the same user submitting the same problem multiple times, but it revealed that people were using my app, and it wasn't going smoothly for all of them.

Analysing the Errors

By analysing the errors it became apparent that I had some recurring faults. Several users failed to start up with a SocketException - clearly something was blocking them from opening the necessary ports. One user's soundcard refused to open. Some users could connect to Skype, but not determine which version of Skype they were connected to. One user couldn't initialise Media Foundation. One user's installation was bizarrely missing some of the included data files. Without automating error reporting from my app, I would have had no idea that these problems were occurring.

Improving Error Logging

So with error reports now flooding in thanks to my automated submit, I set to work about addressing them. In fact the first thing I did was to improve the error messages I was submitting to myself. They only included the stack trace, and so I upgraded them to include details of what version of Windows and Skype the user was running, and what operation they had been attempting.

Handling Anticipated Exceptions

It also meant I had the opportunity to write some more "defensive code" to handle "anticipated exceptions". In other words there are now several places in my code where I know things might go wrong. Thanks to the stack traces, I know what lines can blow up and with what exceptions. This allows me to specifically write code that anticipates those problems and either works around them, or presents the user with a much more friendly and meaningful message, allowing them to continue if at all possible. However, I still let them report these errors if they wanted, since I don't want to mask an ongoing problem.

Quick Bugfix Turnaround

So I quickly released another version, and sat there refreshing my error blob container to see if my fixes had worked. This time things were a bit more encouraging. In the next 24 hours I had just three errors reported. The improvements I made to error logging also proved extremely useful in helping me diagnose the cause of these issues. This is another benefit of automated error reporting - it allows me to have an extremely quick bugfix turnaround - I can resolve an issue a user is seeing and get an updated version of the app released within hours of the original problem.

Obviously I still don't have any information on how many people are successfully using my application - I'll need to ask my users permission to submit usage statistics in order to do that. But automated submitting of errors with good diagnostic information is an excellent starting point. What about your users? Are they suffering in silence, or are you feeling their pain?