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.

Have you been in contact with spoon. Posts on his forum indicate this is not a priority. However, maybe he would be willing to work with you to implement it in dBpoweramp? Please contact him. I would LOVE to have CTDB in dB.

Yes, its clear he reads it. My thought was if you were interested and he was willing, that you do the development of CTDB for integration with dBpoweramp. It does not seem that thats where he wants to dedicate his effort at this time, however, maybe if you were willing to do the development he would be more interested.

Even without working together, now that we're in June, it would be nice if we could have both a new version of Cuetools & an update of the AR database ... say before the 13rd of the month ! (with the cuetools update coming slightly before the AR database update, it would be perfect ) ... not that I want to force you both with anything but as it seems that if write down my wish here, it will not fall in the ears of deaf developers, (even if once again off-topic), I thought that I would authorize myself to speak aloud so that I can, maybe, be fulfilled It seems reasonnable no ? specially as there was no May AR update & even if the Cuetools update is minor. Nevermind if I ask too much (I just thought the timing was good).

I have a few thousand CDs ripped (with dBpoweramp), stored as one-.flac-per-track, one-folder-per-disc. Is there a command line way to script "submit to CTDB" based on folder without running AR verification on each track, which would take a couple of weeks on my hardware?

If so: which ones should I exclude? I can identify the following:

- discs ripped with known errors -- "insecure" in dBpoweramp (or worse, getting an unrecoverable error in Secure mode and hence burst-ripped only to get a sound file out) will only pollute the database, right?

- discs Secure (Warning), i.e. re-ripped until 10 identical hits (where the max # of re-rips is sometimes set so high as 9999) -- if I include all these, the probability of at least one error would be fairly significant. Still worth submitting, or should they be left out?

- discs Secure but Inaccurate (i.e., different pressings). I could try to verify by CueTools first, is that any good for the purpose of submitting to CTDB? Should they then be offset-corrected? What about those which fail to verify -- different pressings sometimes do differ in bits?

- discs defective-by-design? Would be good if these deficiencies could be actually fixed in the database, but I cannot imagine there is any authorative way to tell which rip is "the right" for these.

- discs with HTOA, stored as track #0 (dBpoweramp's behaviour). Would I e.g. need to pre-generate a cuesheet?

I am getting some very strange results. Most of the times there are a lot of results in AR db and I'm lucky if there is any in the CTDB, and some other times there are even more results in the AR db and almost as many in the CTDB. Can this be explained?

I have a few thousand CDs ripped (with dBpoweramp), stored as one-.flac-per-track, one-folder-per-disc. Is there a command line way to script "submit to CTDB" based on folder without running AR verification on each track, which would take a couple of weeks on my hardware?

I also have a few thousand discs I have personally ripped w/ dBpoweramp. All of them are accurate/secure. Mine are ripped as single files and all stored as FLACs (no cues, TOCs are in FLACs as metadata). A utility to scan my library and submitt to CTDB would be nice.

Gregory, would you consider creating an exe that another ripper could use to access CTDB? In the case of dbpoweramp, it has the option to run a DSP called "run external" ( http://www.dbpoweramp.com/dbpoweramp-dsp.htm ). This would allow an external exe to scan the results of the rip as well as read the log file. If the rip is accurate it could be added to the CTDB. If it needs to be repaired and its in the CTDB this option could be given. It could also add results of confirmation for accuracy to the log and possibly to the meta-data of the ripped files. It doesn't sound like spoon will be adding support any time soon, but this may be a way to get it in there.

When trying to validate a rip, I get this error: The specified path, file name, or both are too long.

QUOTE (Gregory S. Chudov @ May 7 2010, 18:59)

Maybe the output path (for the log) was too long - the default template places it somewhere like C:\Documents and settings\username\My Music\.... which can easily get too long. I'll think how to handle this case better, maybe by abbreviating artist/album names to something shorter when generating a path.

1. Was this fixed?

Even with the information about the output path, the total path still seems less than 260, so I can't figure this out.

2. Are the names for album and tracks taken from the filenames or from the tags? I ask because I shortened the filenames and folder names significantly, yet I still see the error.

Gregory, are you indicating your intention to work on/develop a DSP to bring CTDB to dBpoweramp or your willingness to help a developer do so. Its just unclear to my how to read your response. Hopefully you intend to develop the DSP as no one has the knowledge set you have re CTDB.

Gregory, there have been recent discussion regarding consistent errors from drives, rippers, or discs. What information does CTDB store about the source of its data? Is the submitting drive and/or ripper stored? What about the source (previously ripped, vs cd ripper, etc...)

Gregory, can CueTools read the CD TOC tags used by dbpoweramp? Many CDs I have are not recognized as being in the AccurateRip DB when they are. Likely, because there are no CUE files. However, the songs are tagged with the CD TOC tag and that should be enough to recognize the disc in the AR DB.

Gregory, can CueTools read the CD TOC tags used by dbpoweramp? Many CDs I have are not recognized as being in the AccurateRip DB when they are. Likely, because there are no CUE files. However, the songs are tagged with the CD TOC tag and that should be enough to recognize the disc in the AR DB.

I am not sure if CDTOC contains sufficient information, but the ACCURATERIPDISCID tag should?

Gregory, another question for you. How does CTDB identify unique discs? Pressings of the same data with different offsets are, basically the same discs. But what if a disc is remastered but has the same number of tracks with same tracks lengths, but different audio because its remastered?

Gregory, are you indicating your intention to work on/develop a DSP to bring CTDB to dBpoweramp or your willingness to help a developer do so.

The latter.

QUOTE (Eli @ Dec 21 2010, 23:32)

Gregory, there have been recent discussion regarding consistent errors from drives, rippers, or discs. What information does CTDB store about the source of its data? Is the submitting drive and/or ripper stored? What about the source (previously ripped, vs cd ripper, etc...)

It does store the submitting drive and unique user id hash. So it's possible in theory to eliminate erroneous submissions if a certain drive is found to be malfunctioning. In practice this hasn't been used yet. CTDB's purpose is not so much to tell a good rip from a bad rip, but to provide user with means to fix his copy, when he is certain that his copy is damaged and there is an undamaged one in database. It's up to user to decide on those things.

QUOTE (A_Day_Without_Me @ Dec 27 2010, 06:16)

Do you have to rip the disc using CueTools Ripper for a disc to be submitted or is disc submitted when using verify in CueTools?

Currently, apart from CUETools ripper you can submit a disc using verify in CueTools if you select 'submit' mode explicitly. By default CUETools doesn't submit anything. Also, as the number of ripper submissions grows, i will disable CueTools submissions at a certain point.

QUOTE (Eli @ Jan 6 2011, 03:56)

Gregory, can CueTools read the CD TOC tags used by dbpoweramp? Many CDs I have are not recognized as being in the AccurateRip DB when they are. Likely, because there are no CUE files. However, the songs are tagged with the CD TOC tag and that should be enough to recognize the disc in the AR DB.

CUETools doesn't support this tag currently. If CD TOC tag contains enough information, e.g. length of each track in frames including the last one, this should be enough to identify a disc, so i will keep that in mind.

QUOTE (Porcus @ Jan 6 2011, 14:17)

I am not sure if CDTOC contains sufficient information, but the ACCURATERIPDISCID tag should?

If i remember correctly, CUETools recognizes this tag.

QUOTE (Eli @ Jan 12 2011, 18:04)

Gregory, another question for you. How does CTDB identify unique discs? Pressings of the same data with different offsets are, basically the same discs. But what if a disc is remastered but has the same number of tracks with same tracks lengths, but different audio because its remastered?

So far, i've never seen remasters having the same TOC. If this happens, those discs will have the same Id, but database can handle several entries with same Id. When correcting a rip you will be presented with a list of entries with this id, but will be able to use correction only with one of them. The other entry will look like it has too many differences with your disc to be used.

There's a similar example currently in database. I seem to remember that there are two sets of pressings for original CD release of Pink Floyd's Dark Side of the Moon. Probably this: http://db.cuetools.net/index.php?tocid=Md6...IFPA3GiDVrsn5c- Those are not remasters, but differ slightly, perhaps in several hundred samples. One variant has AR confidence of 233, the second one - 530. My guess is, one of the master discs for this CD contained inaudible errors, and about 30% of all produced CDs have exactly the same errors. Using CTDB you can switch back and forth between those two variants and try to find out which one is 'right'. I wasn't able to hear any difference in the sound at the locations indicated by CTDB, but perhaps you can find out by looking at the waveshapes using Audacity or something like that.

Gregory, are you indicating your intention to work on/develop a DSP to bring CTDB to dBpoweramp or your willingness to help a developer do so.

The latter.

Thanks for the answer. Maybe if you find the time you could lay the groundwork with an open source DSP plug-in for CTDB. Honestly, I don't think anyone but you has the expertise and interest to get the project off the ground. I am very thankful spoon opened up the DSP architecture, now hopefully some developers take advantage of this.

I'm new to this forum. I have had a bug about good rips since I started about 10 years ago. I have taken Spoon's advice on hardware and software with great success. One of his recommendations was Plextor Drives. I bought the Plextor Premium which has Plextools. This program gives me the ability to analyze my discs and measure the C1, C2 and uncorrectable errors. I have ripped over 3,000 CD's. I use EAC to rip all my CD's. I predate the accurate rip DB. What I have found is about 10% of the new CD's I purchase will be a very poor pressing with High C1, C2 and uncorrectable errors. Frankly, I believe that the record companies know that they are selling garbage. I take the reports to the retailer and return defective discs all the time. I've given up on exchanging them for the same disc because every time I have, the replacement has been defective also. Some artists have even sued the record companies for putting out junk.

In a nutshell, I find that it is the individual tracks that need to be replaced. Most of the CD is acceptable except for one or two tracks. With accurate rip I add (def) to the track name so I can identify it latter.

I believe that if you have the ability to correct the errors on a given CD (to minimize size of the DB) it may be possible to address the individual tracks as a subset and correct only those tracks that need to be. Ideally we would all have tracks that are comparable to the master itself. The greatest challenge will be to have a bit perfect copy to use as the master. I am looking forward to testing all my CD's and check the quality of my rips especially for those that I ripped prior to accurate rip. BTW If you have a bad pressing even the accurate rip DB may be wrong. I have over 40,000 tracks and I am sure I will be adding to my list of defective tracks.

I am enthusiastically in favor of these efforts and I will be happy to contribute any way I can.

I ran verify and submit on my Rock Collection over 2,200 CD's. I copied the info from the results pane. It would be nice if there was a log file that organized the info and recommend a course of action to address each of the exceptions. All have been ripped with EAC secure mode and about half predate accurate rip.

Here is the letter A from my Rock Collection I am assuming that this is a representative sample of my entire Rock Collection with 74 CDís. Some discs had multiple print outs with listing 2 different songs. The key question is what to do with the info and how do I address the ones that could not be verified?

\AC DC\Let There Be Roc\AC DC\Powerage\Adams, Bryan\Bryan Adams (Remastered)\Adams, Bryan\Cuts Like A Knife\Adams, Bryan\Into The Fire\Adams, Bryan\On A Day Like Today\Adams, Bryan\Reckless\Adams, Bryan\Room Service\Adams, Bryan\You Want It You Got It\Adams, Bryan\11 (Deluxe Edition)\Adams, Bryan\Waking Up The Neighbours11