Redcode

I've spent some time pondering over this, so here's my 2 cents:

1. Build your product first.

2. It's expensive. If you still believe your idea is unique[1], hire help.

3. Algorithms are not patentable. Systems and methods are.

See: http://paulgraham.com/softwarepatents.html

If you want to patent an algorithm, you have to frame it as a
computer system executing that algorithm. Then it's mechanical;
phew. The default euphemism for algorithm is "system and method."
Try a patent search for that phrase and see how many results you
get.

4. It's a long process. See PG's footnote:

[3] Applying for a patent is now very slow, but it might actually
be bad if that got fixed. At the moment the time it takes to get a
patent is conveniently just longer than the time it takes a
startup to succeed or fail.

and this: http://paulgraham.com/startupfaq.html

There are two kinds of patent suits:
1. Random people suing you in the hope of getting money.
2. Competitors suing you in order to destroy you.
Until you're successful, you won't have to worry about the first
type. And once you are successful, you'll inevitably have a lot of
them to deal with, valid or not. So fatalism is the right plan for
type 1 suits.

and the classic: http://paulgraham.com/wealth.html

One way to put up barriers to entry is through patents. But
patents may not provide much protection. Competitors commonly find
ways to work around a patent. And if they can't, they may simply
…

Update: I posted a link to some source code that implements the Shazam algorithm:

https://news.ycombinator.com/item?id=5724442

About the patent lawsuit thing:

As I understand it, Shazam sold their patent to Landmark Digital Services, which are a part of BMI the record label. They kept an exclusive license to make Shazam-like software for phones.

You can imagine BMI wanting it to make money from how a service such as Youtube fingerprints and detects copyright infringement...

And it was this BMI company that were trying to get this blog post explaining the patented algorithm removed from the internet.

One post from the BMI lawyers to Roy in the Netherlands was particularly broad bullying:

> Mr. Van Rijn,

> The two example patent numbers that I sent you are U.S. patents, but each of these patents has also been filed as patent applications in the Netherlands. Also, as I'm sure you are aware, your blogpost may be viewed internationally. As a result, you may contribute to someone infringing our patents in any part of the world.

> While we trust your good intentions, yes, we would like you to refrain from releasing the code at all and to remove the blogpost explaining the algorithm.

> Thank you for your understanding.

> Best regards,

> Darren

> P. Briggs

> Vice President &

> Chief Technical Officer

> Landmark Digital Services, LLC

Roy gave a great talk at Devox about this: http://www.redcode.nl/blog/2012/03/devoxx-2011-talk-freely-available/

I think I heard that…

Here's a starting point, how to do it with music:
http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/

You chunk a song into small segments and create a sort of "fingerprint" for each piece using Fourier analysis or similar. (So a song segment is represented by a frequency histogram, similar to this: http://www.flickr.com/photos/svartling/4229109164/ )
The fingerprints are stored in a DB.

To match a song fragment, chunk and analyze it in the same way. For each segment, find the closest match in the database. If most of the closest matches belong to the same song, and appear in the same order as in the song fragment you are trying to find, you have a match.

Creating fingerprints from a series of video segments is roughly similar, Fourier can be used for 2D images as well.

Doing it like this, you can reduce the volume of data you need to compare against with several orders of magnitude. Scaling to YouTube volumes is still hard, but that's the sort of scaling a company like Google already has plenty of experience in.

NB: Shazam is run by raging assholes who like to threaten people posting code on their site to implement the algo described in the paper [1:4]. Roy's site is still up, but you may introduce quite a lot of stress into your life by messing around with this interesting paper / technique.

In more interesting news, see [5] for a similar implementation in matlab, and [6] for Roy's java implementation.

[1] http://news.ycombinator.com/item?id=1496683

[2] http://www.redcode.nl/blog/2010/07/patent-infringement/

[3] http://www.redcode.nl/blog/2010/11/patent-infrigement-part-2/

[4] http://www.informationweek.com/news/infrastructure/management/225702757

[5] http://labrosa.ee.columbia.edu/~dpwe/resources/matlab/fingerprint/

[6] http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/

This is almost exactly the technology behind Shazam, which has a fairly extensive catalog. Shazam 'listens' to a song when you hit a button and captures microphone data from your phone. It then takes that recorded data and listens for 'key points', which it hashes and uses to compare against its catalog.

If you want to know more about how to implement it on your own, you could use this as a resource: http://www.redcode.nl/blog/2010/06/creating-shazam-in-java/

I assume the biggest drawback to be that Shazam uses a microphone, which is obviously subject to ambient noise. Shazam doesn't actually seem to have much of a problem with this, but I'm guessing a passive listener that sampled the audio output device instead of a noisy ambient microphone would work much more reliably.