Hacker News Reader

Comment by mdasen | Hacker News Reader

I'm guessing that they're going to use an audio hash to look at the file and determine what song it is. It's probably more reliable than using ID3 tags which might get mixed up (especially around remixes, live versions, or just generally missing information).

http://en.wikipedia.org/wiki/Hash_function#Finding_similar_r...

View on HN

If the audio hash & protocol gets reverse-engineered, though, it'll make filesharing very quick--- instead of having to trade mp3s, you can just email your friend a list of hashes.

I'm not sure how that would work, for the hash to be the same you would need the original song right? If they use sha1 or something like that how are you going to go from hash to song?

I was thinking of the case where iTunes computes hashes of your mp3s locally, then uses those to tell Apple which songs you have. You're right that if Apple requires you to upload the actual files, and then computes the hashes on the server-side, it'd make it much more difficult (you'd have to either have the original file, or generate a hash collision).

I doubt they would use an exact hash like SHA-1 though. It wouldn't allow for variations in bitrate, slight length differences due to cutting off beginning/end of the song's fade out/fade in, etc.

I could imagine people figuring out the minimal bitrate that would produce a matching fingerprint (perhaps 64 kbps or even smaller) and sharing music that way.

This could get exploited so hard. I'm sure there must be a catch somewhere in the service.

I think the real point here is that won't really matter, because those friends will be Match subscribers so the royalties will be attributed when they're either added to match or streamed/downloaded (I'm guessing the latter).

Ah, right, that makes sense. Well then someone should put together a rainbow table of collisions with actual songs, haha.

Reply on news.ycombinator.com