Skip to main content
Topic: CUETools DB (Read 188934 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.)

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.

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

 
SimplePortal 1.0.0 RC1 © 2008-2018