Skip to main content
Topic: CUETools DB (Read 190461 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: CUETools DB

Reply #275
All I need to pay attention to is that the mention "accurately ripped" and a large number initially like: 3/5, 40/52 180/220?
Basically, yes.

Alright this is all need to know. In other term I can ignore message like I got "(205/1486) differs in 1362 samples @03:06:66-03:06:67" as long as this number is lower (205/1486) than (1263/1486) because the majority has ripped the same pressing (presumably?) like mine.

Plus I can consider than my track is OK because there is  an previous verification from Accuraterip "Track  5  accurately ripped (confidence 200)  [B143B820]  (AR v2)" (confidence 200 means at least 200 people got the same checksum?)

Re: CUETools DB

Reply #276
(Edit)
as long as this number is lower (205/1486) than (1263/1486) because the majority has ripped the same pressing (presumably?) like mine

The majority 1263 vs 205 means nothing to the rip itself: even the 205 would have been perfectly ripped. Most likely even if it had been 5 and not 205.
Now you could argue that an idiosyncratic error at some pressing plant is less likely to show up in larger numbers, but what if the defective was pressed for a different market? If you don't hear anything wrong, then yours is good enough, don't worry about the others.

(Sometimes a mispress is recalled and replaced - if serious, it is likely to be noticed early and get a lower number.)
“It sounded bad to me. Digital. They have digital. What is digital? And it’s very complicated, you have to be Albert Einstein to figure it out.”
- Donald Trump, May 2017

Re: CUETools DB

Reply #277
It was a example from http://cue.tools/wiki/CUETools_log : CTDB (CUETools Database) Section
OK, a rip as one.  Look at this, track by track:
  9   | (74/76) Accurately ripped, or (1/76) differs in 78 samples @01:41:24,04:01:51
 10   | (74/76) Accurately ripped
 11   | (71/76) Accurately ripped, or (1/76) differs in 4879 samples @07:43:59-07:43:60, [...]


Such a result would mean that it matches 74 others. (Or "73" if you retro-verify later and your own is one of the 74.)
The (1/76) is likely a bad rip.
“It sounded bad to me. Digital. They have digital. What is digital? And it’s very complicated, you have to be Albert Einstein to figure it out.”
- Donald Trump, May 2017

Re: CUETools DB

Reply #278
It was a example from http://cue.tools/wiki/CUETools_log : CTDB (CUETools Database) Section
That part is from an optional detailed log. It shows you everything the database knows about other people's rips and how they relate to you. It's hard to understand, that's why it's disabled by default.

Alright this is all need to know. In other term I can ignore message like I got "(205/1486) differs in 1362 samples @03:06:66-03:06:67" as long as this number is lower (205/1486) than (1263/1486) because the majority has ripped the same pressing (presumably?) like mine.
Like Porcus said, majority is not terribly important. As long as the number of people who have the same result as you is "high enough". For example, if your CD was the minority version, it would say 'Accurately ripped (205/1486) or differs ... (1263/1486)", and you could still be confident you copied the CD correctly - 205 is definitely "high enough". If there's a problem, it was not with your rip, but with your CD, so no point in copying it again.

Plus I can consider than my track is OK because there is  an previous verification from Accuraterip "Track  5  accurately ripped (confidence 200)  [B143B820]  (AR v2)" (confidence 200 means at least 200 people got the same checksum?)
Yes.
CUETools 2.1.6

Re: CUETools DB

Reply #279
Ok thank you guys

Re: CUETools DB

Reply #280
Is it possible to get a list of fields aka tags that are stored in the database, but more specifically returned to EAC via the plug-in.
thanks

Re: CUETools DB

Reply #281
You can see the XML for yourself, for example here.
CUETools 2.1.6

 

Re: CUETools DB

Reply #283
Well... yeah. The metadata part is a simplified interface to freedb/discogs/musicbrainz, that loses some details in favor of unified fast interface.
CUETools 2.1.6

Re: CUETools DB

Reply #284
Are the CRCs in the web database (db.cuetools.net) supposed to match the CRCs from EAC and CUETools (program)?
I noticed that EAC and CUETools show the same CRCs for all tracks, but the web database shows different CRCs for the first and last track of a CD.

Re: CUETools DB

Reply #285

The database excludes the first 10 sectors of the first track and the last 10 sectors of the last track to allow for read offset and pressing offset differences.
http://cue.tools/wiki/CUETools_Database

but going up to 10 is overkill.
You are forgetting that CTDB stores only one record for all pressings. Pressing offset adds to drive offset, and pressing offsets can be quite large. Even if drive offsets are limited to 4 sectors, pressing offsets of 6 sectors are not uncommon.
korth

Re: CUETools DB

Reply #286
Just curious: retro-verifying one of my CDs gives
CTDB: verified OK, confidence 158, or verified OK, confidence 124.

Why?
“It sounded bad to me. Digital. They have digital. What is digital? And it’s very complicated, you have to be Albert Einstein to figure it out.”
- Donald Trump, May 2017

Re: CUETools DB

Reply #287
Verify log please or at least provide the CTDB TOCID so I can look it up.

(without the opportunity to have a look) Sometimes a submission has a pressing offset greater than 10 sectors (10×588 samples) from the original submission. The data is still the same but it is out-of-range. When this happens a new CTDBID is created. If you have a rip of a pressing that is within 5880 samples (10 sectors) of both records, you receive results from both.
korth

Re: CUETools DB

Reply #288
Looks like that. One example: http://db.cuetools.net/?tocid=WVtAckpKyOMYNcgIVL0PcPgKIcs-

The two matches are each less than 5880 away from mine, but more than 5880 apart from each other:
Code: [Select]
        [03be4ad4] (159/313) Accurately ripped
        [fbdb1263] (007/313) No match
        [f1381a20] (125/313) Accurately ripped
        [cc70dfce] (001/313) No match
        [5e23b55e] (001/313) No match
        [47894b5a] (018/313) No match
        [f8313530] (001/313) No match
        [556da365] (001/313) No match

(AccurateRip hits are with offsets within +910 and -709 ...)
“It sounded bad to me. Digital. They have digital. What is digital? And it’s very complicated, you have to be Albert Einstein to figure it out.”
- Donald Trump, May 2017

 
SimplePortal 1.0.0 RC1 © 2008-2018