Are you sure it wasn't other way around: CD was created and pressed from files, that artist has, so CD contains pressing errors and offset?

I listen to the differences. The only obvious clicks that sounded like a typical ripping error i reported to the artist. He replaced the file witth a version fitting the AR db.The converstaion was sent from his iphone reading the signature. Isn't the typical musican maybe itunes ripper and is happy alone to have found the alac button

Is troll-adiposity coming from feederism?With 24bit music you can listen to silence much louder!

The idea of an experiment is that it can be repeated by other people, to obtain the same results.I can not know how you have obtained that entry, you have not said it. You just say "is from my files". I don't think your word can be considered a scientific proof of anything. What software did you use? What steps did you follow?

If I may return to the (original) topic at hand, I have encountered this curious problem when I rediscovered some rips I had made well over a decade ago. These rips were made using xACT, an ancient ripping utility for Mac OS. I ran these rips through CUETools to check their integrity and, just as I expected, every single one of them was shown to have zero matches for both AccurateRip and the CTDB.

Why did I expect this result? Because I know that xACT had a coding flaw that caused the channels to be swapped when its output was set to AIFF. (It did not do this if output was set to WAV; the developer's "fix" for this was to do simply do away with the AIFF option altogether.) Having foobar2000 rewrite the FLACs with channels reversed restored the rips, which AR and CTDB happily confirm.

I also remember that there were a few drives back then that were known to swap audio channels. Mind, these were early days for DAE,

Enough of the historical footnote lesson. My point is that the OP may want to try reversing the channels and check the results again with CUETools.

What about the obvious way to simply write a polite email to the artists or service that offers the files? This release looks like it comes directly from the artists homepage. Some artists are pretty good at such things.

Is troll-adiposity coming from feederism?With 24bit music you can listen to silence much louder!

Wow!!!! Just, wow!!!!So, you're saying that burning the file to CD-R, and then ripping the CD-R, doesn't count as CD rip?Wow!!!And, by "submission may indeed come from files", you mean burning the files to CD and then ripping the CD?And that you meant that all along?What a piece of troll.

Are you seriously denying that a digital album delivered as files, are files if track lengths correspond to ones in a CD TOC, which is the case at hand, for the OP's downloads? Do you seriously insist that the digital album - that carries a signal that has never ever been on a CD nor a CD-R - is a "CD rip" and not a "file"?

Do you seriously want the reader to believe that this is your honest opinion?

If you don't believe me.... Rip a CD and verify it as accurate. Then burn the resulting files to a CDr... even with perfect read and write offsets entered... the resulting CDr will have bit differences from the original CD. Load it as an image and do the same thing. There will be differences.

I have a reader that can overread with an applied offset and a burner that can overwrite with an applied offset.

Guess what that means...

Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

Different pressings affect AR database, not CT database.If the CD is found in the cuetools database, with 194 results!, and all tracks show no match, obviously those files have been modified after ripping. If it's downloaded from a web site, it's probably watermarking. If it's a download from some other site, it can be anything.The probability of ripping an original CD yourself, and get that result is null.

The album indeed has been downloaded from the web.

Poor baby.

Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

I've downloaded the album, obtaining the same results: same CTDB TOCID, "no match" in all tracks.And by that I mean that I've downloaded using a torrent. I think OP means by "downloaded from the web" downloaded with a torrent too. Anyway he can clarify this point.If the database have 194 entries, those entries are from 194 CD rips. As I said, it's not probable at all that 194 people have burn to CD-R and then rip that CD-R. So that entry in the database comes from a physical CD.

Different pressings affect AR database, not CT database.If the CD is found in the cuetools database, with 194 results!, and all tracks show no match, obviously those files have been modified after ripping. If it's downloaded from a web site, it's probably watermarking. If it's a download from some other site, it can be anything.The probability of ripping an original CD yourself, and get that result is null.

The album indeed has been downloaded from the web.

Poor baby.

If there are 194 entries in the database, there must be a CD release, because those entries come from CD rips. This doesn't mean that there's not a digital release too. There can be both.

If OP has downloaded the commercial digital release, and he has obtained the results shown in the first post, it means that the CD release and the digital release are different. These differences can be anything, watermarking, a different mastering or something else.But, I've downloaded the album without paying for it, and the verification produces identical results, so I guess that he just downloaded the album that way too.

If there are two CD releases of the same album, with the same TOC, the difference can not be watermarking, but a different remaster.I guess both CDs will generate their own entries in the database.Example: If 40 people rip CD A, and 20 people rip CD B, and then you verify the ripped files of CD B, the result will be "(20/60) accurately ripped", and not "(0/40) no match".

If there are two releases, one a CD and the other a digital download only release, with the same TOC, if the digital release is watermarked, if you verify the digital release, the result will be no match to all tracks, like OP example.I think the confussion comes because I shouldn't have defined the files as "CD-rip files" but just as "CD release files". The files are the same, but the wording is misleading.

If you don't believe me.... Rip a CD and verify it as accurate. Then burn the resulting files to a CDr... even with perfect read and write offsets entered... the resulting CDr will have bit differences from the original CD. Load it as an image and do the same thing. There will be differences.

I have a reader that can overread with an applied offset and a burner that can overwrite with an applied offset.

There are valid reasons why CUETools was designed to accept submissions from files, with no AccurateRip confidence (only an AccurateRip ID match). It does have its consequences, for example if a [watermarked lossless download with the same TOC | really bad rip or defective-by-design | rip with channels reversed] is spread on the web and the downloaders try to retro-verify them as rips. In such cases, CUETools may deliver scores that are not "trustworthy" (depending on what you mean by that). That is not to say that CUETools is wort(h)less - nobody said that but Shostakovich's strawman - but that there are certain things that CUETools by design will not do, and that may impair the information it returns.

Some of these consequences are more of a concern to pirates than to anyone else, which might very well be a reason why they were not given high priority. (Passing over unreliable information on the quality of someone's illicit download, is hardly a mortal sin.) Sometimes, they might be a nuissance to myself; is that score of 1 my submission, or do I have a verified good rip?

As I said before, you can add a submission to CT database (only the first one) if there is no entry before, if there are at least two accurate submissions in AR database. . So a confidence of two is needed.

I didn't say that the verification is worthless. I said that, if the database accepted entries that are not from CD rips, it would be flawed. But that's not the case.

The point of posting a link to a forum post, is to paraphrase something posting there. But, what you say has nothing to do with what the linked post says.

The post linked says:"Discs don't have to pass AR before being added to the CTDB, AR is used only as a kind of proof that there is a physical CD with such content when adding with CUETools.CD Rippers can add CDs to CTDB even if AR doesn't know them. There is already a number of CDs in database submitted by CUERipper, some of them have confidence 1 - that means they didn't pass AR check or weren't found in AR."

"Discs don't have to pass AR before being added to the CTDB, AR is used only as a kind of proof that there is a physical CD with such content when adding with CUETools." means that you can add a submission to Cuetools database, without the need of a preexisting AR entry of the same CD. And you get this result ripping the CD in secure mode with cueripper. This doesn't mean that you can add a submission verifying a file with cuetools without confidence in the AR database. Those are different things!

So when CUERipper has the physical CD and is ripping from the physical CD, then - and only then - does it look up AR to find proof that the physical CD it is already ripping, does in fact exist. Seriously?

Let's say you have a CD that doesn't have any submission in any database, not in CT neither in AR databases. You can generate a submission to the cuetools database, but the only way is ripping the CD in secure mode with cueripper. You won't generate any submission to the AR database. This is what "Discs don't have to pass AR before being added to the CTDB" means.

If a CD has at least two submissions to the AR database, and none in the CT database, then you can generate a submisson in the CT database verifying the CD ripped files with cuetools. This will generate one submission, the first one. Later submissions could only be added ripping CDs. But cuetools permits this, because the fact that there're already two submissions at least in the AR database, proves that a CD exists. This is what "AR is used only as a kind of proof that there is a physical CD with such content when adding with CUETools." means.

If there are no entries in the AR database, or only one, the verification won't add any submission to the CT database. Only ripping a CD, in secure mode, will add submissions. This is what "The only way to submit data that is not in AR database is to rip a CD using a ripper." means.

Because that is what you wrote. And from everything else you have been writing here (false "files have been modified after the ripping" claims for downloads that need not ever have been on CD; false "worthless"/"wortless" strawman that nobody ever said but you; claiming that the number of hits correspond to the number of physical CDs; denying that a "file" is a "file") - there is no "of course".

Because that is what you wrote. And from everything else you have been writing here (false "files have been modified after the ripping" claims for downloads that need not ever have been on CD; false "worthless"/"wortless" strawman that nobody ever said but you; claiming that the number of hits correspond to the number of physical CDs; denying that a "file" is a "file") - there is no "of course".

And of course this makes perfect sense (to anyone but you), because CTDB is a database of CD rips and not a database of random junk (including downloaded or otherwise obtained files of unknown origin).

Of course submissions are also accepted from ripped CD-Rs, because ripping programs can't tell the difference between CD and CD-R, but to call this "submissions are accepted from files" is just misleading nonsense.