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.

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.

In the thread title question, you're asking about a possible "inaccurate rip". But that result show that the files have been modified after the ripping. The ripping itself could have been perfect, not that it matters now.

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.

Using ARDB/CTDB verification on downloaded files only makes sense when you can be 100% sure that it's actually an unmodified CD rip.

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.

Using ARDB/CTDB verification on downloaded files only makes sense when you can be 100% sure that it's actually an unmodified CD rip.

That doesn't make much sense.The only way of knowing that the files have not been modified is verifying them. How can you possibly know that the files have not been modified before that?If cuetools gives "accurately ripped" on all tracks, then you know those files are from a perfect rip of a CD.

The only way to verify an accurate rip on downloaded content is by looking at the EAC log file that you downloaded with the music.

You cannot recreate a bit for bit identical copy of the original CD using downloaded content. Even if you load it as an image file and rip from a virtual drive, there will be differences.

Therefore....there is no way to take the downloaded content and compare it to rips made off of the original CD.

This entire discussion is pointless once you factor that in.JXL

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.

The only way to verify an accurate rip on downloaded content is by looking at the EAC log file that you downloaded with the music.

You cannot recreate a bit for bit identical copy of the original CD using downloaded content. Even if you load it as an image file and rip from a virtual drive, there will be differences.

Therefore....there is no way to take the downloaded content and compare it to rips made off of the original CD.

This entire discussion is pointless once you factor that in.JXL

Everything you say is false, and I mean everything.

Who says that you download a log file? "The only way to verify an accurate rip on downloaded content is by looking at the EAC log file that you downloaded with the music."That's just idiotic. Then, what do you think cuetools verification function does? Nothing? It's just a fraud?

Of course you can recreate a CD, what "differences" are you talking about? If you download a FLAC file, and when you verify it shows "accurately ripped", there will be zero differences.

I repaired more than one download with CUEtools i purchased at bandcamp. Artists over there obviously offer files they ripped themself from former cd releases including non corrected offsets and ripping errors. CUEtools nicely identifies them without any cue or log.

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

The only way to verify an accurate rip on downloaded content is by looking at the EAC log file that you downloaded with the music.

You cannot recreate a bit for bit identical copy of the original CD using downloaded content. Even if you load it as an image file and rip from a virtual drive, there will be differences.

Therefore....there is no way to take the downloaded content and compare it to rips made off of the original CD.

This entire discussion is pointless once you factor that in.JXL

Everything you say is false, and I mean everything.

Who says that you download a log file? "The only way to verify an accurate rip on downloaded content is by looking at the EAC log file that you downloaded with the music."That's just idiotic. Then, what do you think cuetools verification function does? Nothing? It's just a fraud?

Of course you can recreate a CD, what "differences" are you talking about? If you download a FLAC file, and when you verify it shows "accurately ripped", there will be zero differences.

Have you ever burned a CDr from accurately ripped lossless content and then tried to rip the resulting CDr to see if it was accurate? I have...

Once you actually test the BS you are spouting, then you can post again.Thanks... bye.JXL

Have you ever burned a CDr from accurately ripped lossless content and then tried to rip the resulting CDr to see if it was accurate?

I used to do that a lot when I was younger. The burned contents are absolutely bit-identical if you use the correct write offset with your drive. Only potential difference one might encounter is if the clipped milliseconds of audio weren't silence. I don't think I had any such discs.

Oh, the bleeding obvious once more: The CUETools database accepts uploads from files, and not only upon ripping. If you downloaded the file - legally or not - you have no guarantee that a match is not to a copy of the file. Thus, the observation that it matches a CTDB entry verifies nothing about the original rip (if there ever was any original rip!). And multiple exclamation marks verify something completely different.

The AR database tries to guard against this (not the "!!!!") by accepting submissions only upon ripping, but it cannot guard against a burned CD-ROM being ripped and on a different computer and then compared to the rip it was burned from.

I repaired more than one download with CUEtools i purchased at bandcamp. Artists over there obviously offer files they ripped themself from former cd releases including non corrected offsets and ripping errors. CUEtools nicely identifies them without any cue or log.

Yeah, in some way it is a good sign when there is actually something to repair; most likely your Bandcamp purchase can be compared to a CD, and that the artist did not decode a lossy for upload. I have never got from Bandcamp any FLAC with AccurateRip tags or log tags though - but this purchase had such.

In the first post of the thread, there are 194 entries on the database. And the result is "no match". You can infer from that that the files have been modified after the ripping.

As for if the coutools verification tool is worthless or not, I disagree.

"The CUETools database accepts uploads from files, and not only upon ripping"That's just not true. If you verify a file, not present in cuetools database, and has two or more accurate result in AR database, then it's added to cuetools database, but only once. Further verifications won't add more results to CT database.You can only add more entries ripping it, being CD-R or virtual, ripping in secure mode. Burst mode doesn't add entries.So you are saying that the verification is wortless because maybe some people is ripping CD-Rs or virtual images, originated from downloaded files, in secure mode, just for the sake of it. That's just against probability, common sense, and any interest on what's actually real, just for the sake of trolling.

"The CUETools database accepts uploads from files, and not only upon ripping"That's just not true. If you verify a file, not present in cuetools database, and has two or more accurate result in AR database, then it's added to cuetools database, but only once.

"but only once"? Right. If I claim that you were born, would you then reply "just not true" because you were only born once? You do not even contradict what you claim is "not true", you support it.

"The files need not ever have been on CD. There need not be any "after the ripping". "That's not true. There are 194 entries in the database. If there's no CD, there would be zero entries.If you try to verify a file, and it's not in both databases, then nothing is added to the database.If you try to verify a file, and there are no entries in the CT database, but there are at least two accurate entries in the AR database, then one entry is added to the CT database. But that's because there were several entries, from CD rips, to the AR database. So in fact there was a CD rip.But, from the 194 entries, only 1, at most, can be from a non CD rip, all the rest, the 193, must come from CD rips. Being that original or CD-R.

It makes no sense that some people are burning to CD-R and then rip that CD-R to obtain just a duplicate of the file they already have. At least not 193 people, that just absurd.

The original question was about if you can infer something about the result of cuetools verification from that example. And you say that no, you can't. When in fact you can infer quite a lot. So you are implying that cuetools can not do things that it can do.

"The files need not ever have been on CD. There need not be any "after the ripping". "That's not true. There are 194 entries in the database. If there's no CD, there would be zero entries.

And so all files must be from the CD - and not the CD have been created from a file? If you read this thread, you may even notice that "someone" mentioned that the file may have been watermarked. That "someone" has forgotten about this - most likely "forgotten" on purpose, out of dishonesty.

Will that "someone" now claim that record labels - who possess files from which the CDs are created - rip a CD in order to supply to online vendors?

Of course you can create a CD from a file. But, if you actually read what I posted, the probability of 193 people doing that and ripping that CD-R, is null. So yes, it must be from an original CD.

Do you mean me, by someone forgetting watermarking? What has that to do with anything?

The result of the first post is in fact pretty common, but for stuff downloaded from the web, not for rips that you made. The fact that the database identify the files as a CD rip, is because it's in fact a CD rip, go figure! And the fact that all tracks show "no match", is not due to a bad rip, because as I said, you don't find such a result ripping a CD, but due to a later manipulation of the files.This manipulation can be anything, so it's just a guess work.In the case of a commercial download, with such a result (identified as a CD rip by the database and with "no match" in all tracks), the guess can be about a watermarking, of course. I don't know shit about the suply line of any vendor.Anyway, I've downloaded the file and I've obtained the same result. So it can be anything.

As for you trolling, you said :"Oh, the bleeding obvious once more: The CUETools database accepts uploads from files, and not only upon ripping. If you downloaded the file - legally or not - you have no guarantee that a match is not to a copy of the file. Thus, the observation that it matches a CTDB entry verifies nothing about the original rip (if there ever was any original rip!). "And that's just a lie. Cuetools doesn't accept uploads from files, as I said before.

the probability of 193 people doing that and ripping that CD-R, is null. So yes, it must be from an original CD.

Wrong. It could be generated from the files that were used to create the CD. Files sent (I) to the mastering plant for pressing - and (II) through watermarking and then to online vendors. Files (II) need not have been on a CD ever.I also have different masterings with precisely the same CDTOC. I have CDs that have the same CDTOC, but differ in the LSB throughout the disc - most likely, a second pressing with dither applied once more, not only offset.

The fact that the database identify the files as a CD rip, is because it's in fact a CD rip, go figure!

It is because lengths match those of a CD. That does not mean the files were ever on a CD. In this case, the artist released is as download before the CD was out. As "super digital edition", whatever that means. It could very well be that dither or peak-normalization was applied when the files were sent to CD mastering, what do you know about that?

Show me how can you create an entry in the cuetools database using only files. Select some FLAC tracks from different CDs, like a mixtape, and then show me the steps to generate an entry in the database. Of course, without burning to CD-R.

I'm all for science. Show me how can you do something that I don't think can be done.