Closed dhouck closed 1 year ago
Its closed source, hasn't got specifications, it's badly executed, and there are dubious legal aspects to holding recovery data on a server and distributing it for free (these days even publicizing a checksum of copyrighted data is enough to get in trouble). Not happening.
I’ve also been looking at using CUETools (the software not just the database) so I find some of that alarming.
What part of it is closed source? It looks like the client and even the server are open source, although yeah there doesn’t seem to be a spec (not that I can find a spec or source code for AccurateRip either).
More importantly, I’m curious what’s badly executed about it; as I said I’m not familiar with the technical side of this. I saw a reference somewhere to a weird checksum algorithm but it sounds like you mean more than that?
If you're going to write a piece of code to correct errors, you don't start by rolling your own. Not when so many error correction codes already approach the Shannon limit. And generally, you won't find anything better than Raptor(Q), since 2011/5, which is also an IETF standard. Either way, I'm leaving it for someone else to implement. Generally, drives leave very little for programs to correct, and often, they simply won't output anything and freeze if they find something truly unreadable, at which point the entire rip is gone. If you're going to be downloading dubiously legal error code data, may as well download dubiously legal rips too.
Having CTDB support would IMO mainly be interesting as another layer of verification (especially as it often takes quite a while for data to get into AR).
AFAICS, the code is fully open?
As for the concerns about copyright issues. According to their website they store 180KB of recovery data. If that would already be enough for copyright infringement is questionable (but I'm no lawyer).
But shouldn't one be on the safe side if one simple doesn't implement that part of functionality and never download the recovery data? All what's then left is checksums, like with AR.
CTDB has some advantages over AccurateRip, including the potential for repairing bad rips. It’d be nice if cyanrip could optionally support CTDB
I don’t really understand the technical side of this; it might or might not be possible without also doing the majority of the work required for ripping the whole disc as one file instead of one-file-per-track.