cannam · HackerTrans

Quite right! But approximate experiments and lightweight automation are really useful in deciding where to go and then making sure you stay there. I'm all for test-first, but I'd find it very hard to argue that it's a more important tool than, well, scripting things.

cannam

4 anni fadiscuss

This is a good article, with (for me anyway) quite a twist at the end.

The author quotes a tweet expressing amazement that any company might not use TDD, 20 years after it was first popularised - and then writes

"I’d equate it to shell scripting. I spent a lot of time this spring learning shell scripting"

Wow! I feel like the person in the tweet. It's amazing to me that someone could be in a position to write an article with such solid development background without having had shell scripting in their everyday toolbox.

(I use TDD some of the time - I was slow to pick it up and a lot of my older code would have been much better if I had appreciated it back then. I like it very much when I don't really know how the algorithm is going to work yet, or what a good API looks like.)

cannam

6 anni fadiscuss

> > it’s possible that […] your work makes the world a worse place > > Always great to hear that…

Painful, but it is true.

Free Software development is awkward in this respect. Both developers and users feel as if they are doing something virtuous, but it's unclear to what extent the contributions of either party help the other (or anyone else).

Meanwhile the presence of this self-conscious feeling of virtue makes transactions difficult, as every party feels they begin by deserving something out of it. So Free Software users are more demanding and aggressive than users of proprietary software, and Free Software developers are more prickly.

Loss of ego is absolutely essential here.

(More on-topic, this series of HN posts about X and Wayland has prompted me, a long-time holdout X user, to experiment again with switching one laptop to Wayland. It's massively better than the last time I tried it, and I'll probably leave this laptop like this unless something goes awfully wrong. Thank you, unappreciated Wayland developers.)

cannam

8 anni fadiscuss

For anyone else still reading, this paper from Philips Research describes the method I think you're referring to. (It's cited in Avery Wang's 2003 Shazam paper.) http://www.ismir2002.ismir.net/proceedings/02-FP04-2.pdf

This is a really nice paper as well, but the Shazam method is more exciting because of its focus on the search part of the problem. Audio fingerprinting wasn't an entirely new field of course - the Philips paper also cites several prior publications.

The big limitation of all these methods is that they are robust to EQ and other degradations but not at all to variations in timing between frames. So they work well for identifying different instances of the same recording, but not at all for matching different performances, or for "query-by-humming".

cannam

8 anni fadiscuss

I agree with you, and I work in music audio signal processing.

Shazam was founded in 1999-2000 ish and was live by 2002, longer ago than many people realise. The fingerprinting method they used was a novel one, and they successfully deployed it in a couple of years, with a database of two million tracks, in a system that could be used by dialling a number from any phone. It's an extraordinary and rare example of taking a research method and getting it to work at scale in the face of real constraints, in the process producing something that most people would never have imagined could be done.

comments