Archive for September, 2009

First impressions of F#

Monday, September 28th, 2009

I’ve just read through Foundations of F# and written one or two trivial scripts in F#, so it’s too early to make a proper balanced assessment of it as a language. However, I wanted to record my immediate reactions to it so far while they are still fresh in my mind.

I don’t have a strong background in functional programming, but I’ve dabbled with Common Lisp, Haskell, Clojure and Scala. I’m excited by the new trend of functional languages targetting the JVM and .Net CLR, since this seems to solve the major problem with functional languages of the past in not having library code in sufficient quantity and quality.

Targetting either of the widely available virtual machines seems to be a double-edged sword, however. From what I can tell neither the JVM nor the CLR are well suited to functional languages. Clojure, Scala and F# all seem to have (and I’m being polite here) idiosyncracies forced upon them by the underlying runtime.

My immediate reaction to F# is that it seems to work hard to make it easy to interact with OO languages on the CLR, at the expense of being a great functional language in its own right. Haskell and Clojure both have strong (and different) concepts of lazy evaluation that permeate the language and let you program in a whole new way. If F# has this, it’s not been obvious to me in the first couple of hours using it.

Nor (as far as I can tell) does F# have particularly good support for parallelisation, which is one of the key advantages of functional programming for me. In my opinion Clojure has the strongest claim here, having been built from the ground up to be parallelised safely. Haskell apparently has very strong tool support in the form of ghc. What does F# offer in this direction? It’s not at all clear to me, but with the ability to create mutable fields with a single keyword, and no support for inferring immutability via the type system, it doesn’t fill me with confidence.

Why (some) people are missing the point about Twitter

Sunday, September 27th, 2009

Old curmudgeon that I am, I’ve spent a lot of time grumbling about Twitter, but having got used to using it I’m forced to admit that there are some things to like. However, I still take issue with some of the dizzier admirers: two that come to mind are Tim O’Reilly for calling it “the most important communications tool … since e-mail” and whoever it was who (apparently seriously) called for the creators of Twitter to be awarded the Nobel prize for the effect Twitter had during the Iran elections. I don’t think these fans of Twitter are wrong so much as missing the point.

Usefulness of social networks

Usefulness of social networks

Good social networks aren’t really about technology, they’re about who you can connect to with that technology. Obviously there is such a thing as “better” social networking technology; such a thing might give you

  • more flexibility to choose how you communicate
  • more power to express ideas
  • more media types available (video, audio)

But far more important than these are the qualities of the community:

  • more people to communicate with
  • access to people with appropriate experience
  • people who are more engaged with and attuned to the purpose of the community
  • people with time to spend on the community

New technology by definition attracts early adopters, and these tend to be the right sort of people to build a good community: they take an interest in new things, they have a positive vision of the future and are willing and able to invest time in making something work.

By contrast, as a technology matures and crosses the chasm into the mass market a much wider variety of people comes on board. Technologies therefore tend to slide down the vertical axis on the above graph over time.

Not every change to the community is another eternal September, since some networks adapt better than others to this change. Technology can be part of the solution here, so the correlation between good technology and good community is weak but positive. New networks can draw on lessons learned from fading networks of the past, and become stronger for it.

I think there’s even a chance that there can be a positive uplift on the trailing edge of a trend: now that some of the cranks and spammers have moved on, usenet seems to be home to a proportionally higher number of wise old hands who make for stimulating discussion.

Whatever the details of the matter, it seems to me far too early to be prognosticating the position Twitter will hold in the history of human experience, even if its place in technological history may be confirmed.

Mistakes not to make when decoding MPEG audio

Saturday, September 26th, 2009

I recently had to write my own code for parsing MP3 files into frames and data. Ordinarily, I would have relied on third party code for something like this, but the libraries I could find were either under unacceptable licenses or focussed on playing the audio, not manipulating the data. I was interested in extracting the data frame by frame to produce a cut-down sample of the audio.

I made a couple of mistakes in implementing the spec, which I’m recording here in the vague hope that they might be useful to someone at some point.

Frame sync marker

This is 12 bits of all-bits set, except when it isn’t, in which case it’s 11. Lots of documentation seems to be internally inconsistent on this point, often describing it as 11 bits and showing 12 bits on a diagram.

As far as I can understand it, the point here is that the ISO standards only describe MPEG 1 and 2, which both have a 1 as the first bit of the following field (the version number). Since the first bit of the version field is a 1, it doesn’t matter for ISO compliance whether you treat this as 12 bits of marker and a 1-bit version field, or 11 bits of marker and a 2-bit version field. I don’t know what the official ISO stance is on that since I’ve not been able to justify the cost of buying the original standards documents.

In practice if you are interested in writing the most generally applicable code you will have to take account of MPEG 2.5, which is an unofficial standard. In this case the first bit of the version field is zero, meaning that it makes sense to regard it as 11 bits of frame marker and a 2-bit version field.

Frame length

Lots of people provide a simple formula for calculating the frame length from the frame attributes, but some of them play a bit fast and loose, and most gloss over rounding. Worse, the version published in O’Reilly’s MP3: The Definitive Guide is entirely wrong, as far as I can tell (the padding value should not occur within the denominator).

One problem is that a lot of quoted formulae refer to MP3 specifically (i.e. layer-3 audio) and not the more general standard of MPEG audio that shares the same frame format. Beware of any formula that contains the magic number 144. To generalise this you’ll have to find the number of samples per frame, which can be found using the lookup table available here. The formula for frame length is then:

Frame Size = ( (Samples Per Frame / 8 * Bitrate) / Sampling Rate) + Padding Size

However, this isn’t quite the full story. In order to get the rounding right, you’ll need to pay attention to the “slot size”. Slot size is the number of bytes per “slot”, being the smallest unit of data in the file. Slot size is 1 for layers 2 and 3, but 4 for layer 1. Therefore if you’re dealing with layer 1, you need to round down to the nearest multiple of 4.