Hacker News Reader

Comment by eli | Hacker News Reader

The fact of the matter is, there is absolutely no way Google could determine if your tracks were illegally downloaded or simply ripped from your own physical discs.

Well that's simply false. If I ripped a CD myself, it wouldn't be byte-for-byte identical as the copy on Pirate Bay. In fact, if I rip it myself and don't share that rip with anyone it should probably be unique within the system.

And how hard would it be to figure out who has illegal copies of an unreleased album?

View on HN

Not true. If you ripped a CD using the same software and settings as someone else, your files would be identical, byte for byte. There is no magic fingerprinting, however, a lot of pirated tracks could be determined by looking at ID3 tag information since most warez crews like to brag about their releases.

That's simply not true when talking about audio CDs. You can even get non-identical rips from the same machine with the same CD-ROM drive, software and settings.

The issue is that the audio CD standard ("Red book") does not require block-accurate addressing during seeking[1]. This allows you to still be able to play scratched up CDs, with the trade off being that even discs that aren't scratched up that bad may not give you a byte-for-byte copy on different reads.

To try and account for this, CD ripping programs like EAC have to make multiple read passes and apply certain algorithms to determine where jitters occur and only take the "good parts."

[1]: http://en.wikipedia.org/wiki/Jitter#Compact_disc_seek_jitter

I thought the point of Accurate Stream was to provide the ability to do sample-accurate streaming, along with C2 error detection to know when there was a problem. EAC only does multiple jittered read passes if your drive doesn't support Accurate Stream. How else can it do hash checks for accurate rips?

EDIT: I confused C2 error pointers and Accurate Stream. Mea culpa.

You're talking about read errors. Run a ripper that fixes/retries/etc the read errors, and you'll have an identical rip.

Would it not be possible for you to rip with super standard settings thus making it pretty much like every other rip?

I don't see how ripping could be so different if people use the same settings.

From what I understand--

The "lossy" part of MP3 is that the encoder decides to throw away frequency bands to reduce the information size.

This is more than just choosing a bitrate and being done with it - different encoders treat different bands as important or unimportant, attempting to make a smaller sized file still sound better.

Indeed but really, how many encoders does one use? That is, it's not like there are dozens of them that are widely used. If there are only 2 or 3 (say, LAME, some Apple one and some Microsoft one) and people usually use 2 or 3 bitrates... well that leaves quite the space for overlapping.

Right, but the music pirates don't write their own encoders. They are likely using software like LAME, EAC, and FLAC when ripping. Therefore, as long as someone uses the same settings, they could end up with an exact duplicate rip.

If two users were using a ripper that uses Accurate Rip, and both were using lossless compression, then you could end up with identical decompressed wav files.

Fair enough. There probably isn't a 100% perfect way of detecting unlicensed content in every case. But that wasn't the question. (The methods for detecting copyrighted content in YouTube videos are obviously quite far from 100% and yet they routinely ruin people's day.)

Yeah, like the guy who was uploading the birdsongs that got flagged as copyrighted.

Encoding software for most lossy formats rely on some form of prediction and realtime analysis. That can't be the same for every repeated encode. Some randomness has to appear so that bit for bit, separate encodes are not alike.

Why speculate when you can test?

   $ ls -l KDE_Startup_new.wav
   -rw-r--r-- 1 jerf jerf 970882 Feb 27 21:42 KDE_Startup_new.wav
   $ lame KDE_Startup_new.wav 1.mp3
   $ lame KDE_Startup_new.wav 2.mp3
   $ md5sum *mp3
   0bc5fee9b5d67ca2d6f1bf61a186067a  1.mp3
   0bc5fee9b5d67ca2d6f1bf61a186067a  2.mp3

Interesting. I know in x264 there's a non-deterministic option when using multithreading that can speed up encoding and quality sometimes, otherwise it always produces the same output.

Whether a format is lossy or not plays no part in whether the algorithm for transcoding is deterministic or not. The input (a CD) is digital and provided whole; there is no "realtime analysis" needed, and no reason why "prediction" would produce non-determinism.

Some multi-threaded encoders may be non-deterministic (from using concurrency), but encoding MP3s (or nearest equivalent) on modern hardware is generally fast enough for casual use even on a single thread, and parallelizing the operation would be better done at the level of tracks rather than within a track.

It's not quite "realtime analysis", but...

MP3 compression works by FFT-ing the audio stream, which is something that has to be ingested sequentially. It's not realtime since the encoder does it much faster than realtime, but it is doing sequential analysis of the file.

Usually a high quality encoder does multiple passes of the file to better fit it's FFT with the source material.

Reply on news.ycombinator.com