CD ripping rules and archiving

[connor17]

One of the great things about piratebay in the almost complete absence of rules, anybody can upload anything.

Other sites have "higher standards", implemented by an extensive set of rules. Basically, its purpose is to achieve an uniformity in the "archive".

The problem with that approach is that those rules are not about quality, and only achieve a mere uniformity in the presentation of the files, that makes easier the hoarding of the files, what seems to be the ultimate goal.

If a certain rip doesn't follow the rules, it will be deleted, or let at the expense of being "trumped" by another that do follow the rules.
These rules are extensive and forbid a lot of things: using software other than the approved ones with certain parameters, burst mode, CD-Rs, virtual drives, etc.
The problem with all these rules is that they have nothing to do with anything, and show a lack of understanding on how a FLAC file is verified.
A FLAC file is verified using a database of CD rip checksums. If the checksum of your rip is identical to the one in the database, then the rip is accurate, period. It doesn't matter what software did you use, of if it was a CD-R, or if you ripped it on a wednesday. It doesn't matter, at all.

If the one who wrote that rules thinks that CD-R, or burst mode, or whatever, are more prone to give errors, first, it's wrong, and second, it has nothing to do with anything, becuase the flac file is checked against the database afterwards.

You can download a cd rip flac, and verify it yourself with cuetools. It will be accurate, or not, and that would have nothing to do with any of those rules.

If this is so simple, why all that hassle? I think is more of a control and hoarding thing.

Rutracker labels cuetools rips as "doubtful", even if the rip is accurate, just because the rules state the EAC is mandatory.
Other sites use "log checkers" that returns a percentage for a certain log, so they can check the rip. It takes cuetools around 20 seconds to verify a flac. The output of cuetools would be identical to the one written in the log file.
The prohibition of cd images files is just arbitrary.
And all those digressions about the fucking offset, something that was solved years ago with cuetools.

[connor17]

[RobertX]

I'll say this, it does simplify a lot of things. I like TPB's way of being devoid of standards, but you do learn a thing or two about ripping.

Everything starts with an idea, albeit the good ones aren't forced, and, like a snowball, it gets bigger as it goes downhill.

[Q91]

ofc, i dont think alot of people wish to have 64kb/s mp3s

[Aaron.Walkhouse]

…unless it's voice, with which you can pack weeks of clearly audible courses and stories into a thumb drive… ‌ ‌

[connor17]

The problem is not that good rips are labelled as bad, that's just annoying. The real problem are bad rips labelled as good.

For example, rutracker labels as "verified" if its rules are followed. There are a lot of rules, and I mean a lot. But all those rules refer to the ripping process: mandatory software, forbidden practices ( CD-R, virtual drives, burst mode, etc), etc.

But, as I said before, all that rules are pointless, because the FLAC files must be verified afterwards. If a FLAC file, being verified with cuetools (checking the checksums with two databases), shows "accurately ripped", then the rip is perfect. But, on the other hand, in the result is "no match", the rip is erroneous.

And now the question is, how rutracker labels rips with "no match" as result?
If the rules have been followed, the label will be "verified".

This means that all that rules don't mean nothing regarding quality, and that all those labels only show the level of obedience of their users. Rutracker was a private tracker and old habits die hard I guess.

Just an example (not an exception, it's generalized):
http://rutracker.org/forum/viewtopic.php?t=3980089

Cuetools results:

Rutracker one

Rutracker one

My own rip of the same CD

My own rip of the same CD

The only way to verify a FLAC is ... verifying the FLAC, not the ripping process.

The implications of this go beyond CD rips, or better said, can not go beyond them. You can only verify something, if there is something to verify it with, and there are only databases for CD rips. So all that WEB downloaded FLACs can only be verified if they are CD rips, so all 24 bit FLAC can not be verified.

In order to solve this impossibility, rutracker goes deeper down the rabbit hole asking for spectrograms, or dynamic range measurements that are as idiotic as the ripping rules for CDs.

The real problem with WEB downloads, the real nastiness, is watermarking (that is generalized), and no beautifully coloured spectrogram can show that.

[bubanee]

Very well written this article

[joew771]

What is your point? That TPB is bad? Or good? Or that private sites are good? Or bad? WTF.

You just seem to be babbling about trackers and verifying and so what?

And also, I'll ask this, who cares?

I don't care about who ripped what or if it was verified by some program or another or some website or another.

I think you need to calm down.

[RobertX]

Agreed, joew771.

Music is good no matter the bitrate or whether it's ripped by a beer tap or a cocktail waitress.

If it's good music, it's good music no matter how it's ripped.

[Q91]

ofc, i dont think alot of people wish to have 64kb/s mp3s

Still, this post is still relevant