It doesn't submit in Burst mode or when there were suspicious positions with many retries.

Thks for the link Greynol ... I missed it. This reduces even more the probability of bad submissions.Sorry but as there are no real FAQ or tutorial for AR & CTDB, the information is splitted everywhere.Even if I am faulty, it is hard to follow all AR & CTDB subtilities. Sorry if I made you waste some time, but it was once again usefull to me to have an "unfriendly" discussion with you

It seems that it means that you possibly admit entries to CDTB that might be damaged.

Yes, of course, and there's no way around it. Same goes for AccurateRip - when the first submission for a CD is made, there's nothing to compare it with, and no way to make sure it's really accurate.

QUOTE (sauvage78 @ May 27 2010, 21:34)

I don't like idea that such non accurate CTDB entries will appear in my .accurip.

I don't like it either. If e.g. AccurateRip log would show all non-matching entries, it would be very long and unreadable. CTDB verification log is much shorter because it doesn't have separate entries for pressings with different offsets, but still at some point we will probably have to ignore entries that don't match and have low confidence (1?). For now it shows all the entries and it's up to user to interpret this information.

QUOTE (sauvage78 @ May 27 2010, 21:34)

I don't understand the logic of being AR(2) dependent if the rip comes from EAC or dbpoweramp & in the same time not dependent of the accuracy at all if the rip comes from cueripper.

Not that it's entirely logical, but there are reasons.

In ideal world CTDB shouldn't depend on AR at all and only accept submissions from rippers. You asked if i consider CUERipper submissions a hack - well no, it's the other way around. I had to add another way to submit data because 1) Only one ripper supports CTDB so far, 2) It doesn't even work on some drives, 3) I needed to jump-start the database, because noone would have taken it seriously if it only had a dozen CDs. So it's CUETools' submit feature that is a hack, although a necessary one.

The absolute minimum requirement for CUETools submissions is some evidence that the submitted files really come from a CD and were not modified since they were ripped. CUETools could in theory submit any rip that passes AR check with confidence of 1, or even as someone suggested, a rip that doesn't pass AR check, but has a log and matches CRCs from that log. I still hesitate whether i should do this or not. On one hand, this would speed up database growth. On the other hand, this would reduce data quality.

CTDB submissions use much more disk space/traffic, which demands higher data quality than in AR. As i said, in the end there's no way around it - there will be bad rips in the database, but we must minimize the number of those bad rips. So CUERipper for example doesn't submit a rip to CTDB if it had problems reading some sectors. EAC submits to AR anyway.

QUOTE (sauvage78 @ May 27 2010, 21:34)

Have you stored any additionnal informations that would allow you to re-check the accuracy of these suspicious submissions later ? (& purge them ...)

I store the drive model and ripper version so that i could purge entries from virtual drives or ripper versions with known bugs. By the way, another reason to trust CUETools submissions less than CUERipper submissions is that there's no way i can find out drive model and ripper version (at least if there's no EAC log). Spoon might purge submissions from that drive later, but the erroneous entry would already be in CTDB.

Sorry but as there are no real FAQ or tutorial for AR & CTDB, the information is splitted everywhere.Even if I am faulty, it is hard to follow all AR & CTDB subtilities. Sorry if I made you waste some time, but it was once again usefull to me to have an "unfriendly" discussion with you

Search for information before making claims and you should be ok. If you are unsure it is better to ask a question rather than speculate. It will result in far fewer incidents of being told you are not correct. This is advice I try to follow myself.

A while back I tried to split the discussions between CUERipper and CUETools. Now with CTDB, I feel more justified than ever with that decision. Even though they are linked to one another and are bundled together (which I think is a mistake), they each serve a specific purpose. Discussions are easier to follow when they are primarily focused on only one specific purpose. I don't think there are a lot of people who want to search through a discussion with hundreds of posts in order get information about something that doesn't show up until far into the discussion. If it weren't for this thread a lot of people would be asking, "WTF is CTDB? Where did this come from?". In fact this is exactly how this discussion got started. Wading through tons of logs with requests for clarification, requests for assistance with batch processing, feature requests, etc. with CUETools in order to find technical information about a ripping program is a nightmare. Anyhow, sorry for ranting.

By the way, another reason to trust CUETools submissions less than CUERipper submissions is that there's no way i can find out drive model and ripper version (at least if there's no EAC log).

Let's also accept the cold hard reality that many people use CUETools to check their illegal downloadz. The initial rip could easily have been in error but still submitted to AR. It could have easily been solidified in the database through a subsequent submission from CD-R burned from a CUE sheet and a drive with a write offset of zero or one that is compensated if not zero. If it's the only entry for that particular disc ID, it doesn't even need solidification [AR (1)]. (EDIT: thankfully AR(1) results are not submitted.)

With CTDB, there is a very real risk that a good rip from an honest person ripping a factory-pressed CD may be altered to match an illegal upload with an error that has been propagated through file sharing and made exponentially worse by this new system. I think the term viral is a fitting description.

Thks for the answers. I am reassured that the issue is much smaller than I feared.

Greg:

QUOTE

even as someone suggested, a rip that doesn't pass AR check, but has a log and matches CRCs from that log. I still hesitate whether i should do this or not.

This is definitely not a good idea. Logs are too easy to edit to be reliable, this is the exact reason why I delete logs. There is even insane developpers around which codes log generators... The only logs you can trust are your own, & most of the time (if perfect) your own logs are useless to you (except for enhanced CD). If you do this, the database will instantly be spoiled by guys uploading to CTDB rips they grabbed from P2P & some of those will have fake/edited logs. You would be surprised by how some people are able to lie to themselves to make them look important to their P2P communities. (specially teenagers...)

Greg:

QUOTE

In ideal world CTDB shouldn't depend on AR at all

In my ideal world CTDB should rely entirely on AR(2) I guess it's a question of point of view. I understand that you trust your own software & that you want to be independent from Spoon.But I have seen so many non-burst EAC log without re-reads with "no error occured" that I hardly trust even ultra paranoid rip anymore as long I don't have an AR match. On the one hand, I think that relying on parameters no matter how good is not perfect & on the other hand I agree that the idea of having a "pure" database is insane, so I guess lowering the risk is, in a way, a fair deal.I think I can live with the way it works now, even if I was at first suprised by your choice.

I understand that you trust your own software & that you want to be independent from Spoon.

It's not that. I think that users would benefit from my cooperation with Mr. Spoon, and if he decides to work together on CTDB and add CTDB support to dbPoweramp that would be great. But databases should be separate, because they are too different to depend on each other.

I rely 100% on AR(2). My collection is organized from AR results.:AR(2), Silent Track, Data Track, AR(1), Not in Database, not AR(2) ... I re-check non AR(2) every month, hence the reason why I care a lot about .accurip & not at all about .log.I wouldn't be so vocal in AR/CTDB/Cuetools threads, if I wasn't so dependent on Spoon & Greg's work.Even if very thanksfull to Andree, I am slowly leaving the EAC sect & their log fanatism.

Fuki:If I were Greynol I would say that "this sound like an admission that you use the program to check material that is not distributed through legal legal means." because your TOC says it is an enhanced CD, which you seem unaware. But hopefully I am not Greynol ! lol

Edit:More seriously if this is an old EAC rip of yours without TOC in the log, you can try to manually add the data length in order to find it in the AR database. Try all length between 02:13:73 & 02:14:72, good luck. CTDB is actually useless to you because there is non-enhanced entry that doesn't match your enhanced pressing. Once you find the exact data length if it happens to be not accurate, then you will have to wait for your enhanced pressing to be submitted to CTDB by someone else before you can try to fix yours.

Tnx sauvage78!Like a lot of the rips I have on my hard drive, unfortunately I don't have the original any more so I cannot be sure if it had had the CD-Extra data track or not, but as I can remember there wasn't any.

Unfortunately a percentage (around 5% of virtual drive users) set the virtual drive name to a real drive name...

So I guess AR.dll analyses the device directly. How do you do it? Or is it security by obscurity... I mean I doubt any virtual drive software developer would want to re-write their software to beat AccurateRip's detection, would they? If at all they care more about game DRM systems than about audio rippers I guess, so I believe there's no loss for the safety of the AR database when you disclose how you do it.

As you point out the way CUE Ripper does it is not enough, since anyone who's able to read and follow a tutorial is able to beat it. Not that it should be a concern for people who only rip or check rips of valid retail CDs they have physical access to...

More seriously if this is an old EAC rip of yours without TOC in the log, you can try to manually add the data length in order to find it in the AR database. Try all length between 02:13:73 & 02:14:72, good luck.

Heh, even at the risk of being accused to be from the "use the program to check material that is not distributed through legal legal means"-camp, there is something that I thought of recently. Would it be somehow possible for CueTools to try all the various data track lenghts to see if there is one that matches? Or would that be too time/processing-intensive?

Even if very thanksfull to Andree, I am slowly leaving the EAC sect & their log fanatism.

I totally agree ! Also, EAC has too much options that could f*** up your rip. I'm also VERY thankful to that German guy since we won't be at this point in accurate rip without him, but I think CUERipper is the future

Goratrix:I already asked Greg for such a feature before the creation of CTDB, but now with CTDB as time goes by it will become less interesting because when populated CTDB should store the majority of possible data lengths. What is more interesting IMHO is the support of .TOC to actually store this data somewhere on your HDD for old EAC rips with no TOC or rips with no log.

Edit:I just noticed a misstake in my post #91 that I cannot edit anymore:Sauvage78

QUOTE

because your TOC says it is an enhanced CD

should be read "because your cuesheet says it is an enhanced CD" you have no TOC as you don't know your data length.

Saxo:Actually I still use EAC, so what I am critisizing is more some users of EAC believing that there would be some magic in their logs because some biased EAC guide told them so. An AR(2) .accurip being IMHO more trustworthy than logs informations, it pretty much kills their use (As soon as you get an AR match). The people which over-trusted EAC logs may have some surprise when they'll check their AR accuracy. A small proportion (1-2%) of their rips will not be accurate despite their so-called "perfect logs" & they might discover that AR is right. The proportion is tied to the settings they used for their drive, but even with good settings a small chance of error seems to remains. I have already found faulty logs with settings that I supposed to be right (with listenable scratches in tracks pointed out by AR) but I have never found an AR(2) rip with listenable scratches. Hence my disenchantment for logs. I am not beating EAC or all use of logs, I am only pointing out the limit of EAC logs & the fact that AR can make people independent from EAC. EAC has ruled for so long that some people seems to think that only EAC can achieve accurate rips. This is not true, AR(2) proves it. Now maybe I trust AR(2) too much & maybe being dependent from AR is not much better than being dependent from EAC, only time will tell. My only fear is Spoon neglecting its database, then I would (maybe) regret having deleted my EAC logs. But even is this nightmare case, actually I don't see why my AR(2) .accurip would suddenly be less valuable. The right use of .log is not to keep them as an evidence that your rip is "perfect" (this is more the use of .accurip), the right use of .log is to keep record of the used settings in case something went wrong, as nothing can be wrong if your rip is AR(2), .log becomes useless. My conclusion is that .log are only usefull when something is wrong (& in special cases like keeping the TOC for enhanced CD). So the problem is not EAC & with or without logs, but how you use it.

Even if very thanksfull to Andree, I am slowly leaving the EAC sect & their log fanatism.

I totally agree ! Also, EAC has too much options that could f*** up your rip. I'm also VERY thankful to that German guy since we won't be at this point in accurate rip without him, but I think CUERipper is the future

I tried the CUERipper, and it looks nice & simple (which is good), but I'm missing the option for controlling the additional command line options when ripping to MP3. I miss this because I would like to encode MP3s with 0 quality (-q 0), and would like to include replygain (--replaygain-accurate). Is there a chance for implementing this?