Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools DB (Read 292803 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

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 #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 ...)




Re: CUETools DB

Reply #292
the cuetoolsDB plugin for exactaudiocopy does not work in windows 10 Version 10.0.18362.356 What can I do for fix it?

Re: CUETools DB

Reply #293
Works for me on the same Windows version. What exactly do you mean by doesn't work? If you go to EAC Options->Audio Plugins, is it in the list? If you click "Show the options...", does a window pop up? When you do a CD rip, are there any messages from CTDB plugin in the log? Any error messages pop up?
CUETools 2.1.6

Re: CUETools DB

Reply #294
on older windows 10 the plugin worked. And now it doesn't even appear in the Audio Plugins list in settings
no error messages. The same EAC on Windows 7 has been tested and everything works

Re: CUETools DB

Reply #295
Sorry, problem solved. Net Framework 3.5 was needed!

Re: CUETools DB

Reply #296
Hello everybody!
I only discovered CUETools DB very recently, I know, I am a late bloomer on this :)
But the thing is, until today I could browse through the recent additions, and now of a sudden I am stuck at the first page and I can only see the last 10 additions. The arrows at the bottom are both greyed out. Is it me or is it an issue on the site? Thank you!

Re: CUETools DB

Reply #297
Yes, buttons don't work here. No idea if they did before.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: CUETools DB

Reply #298
Yes, buttons don't work here. No idea if they did before.

Ok Wombat, thank you for the reply!

Those buttons did work. I used to scroll sideways using those buttons when an artist had more than 10 entries, and it used to work very well until now.
db.cuetools.net/?artist="the_name_of_the_artist" without the quotes.

Re: CUETools DB

Reply #299
Discs on Musicbrainz with HTOA have tracks listed incorrectly on the database page.

http://db.cue.tools/cd/936811

When using the "SaGa Frontier Original Soundtrack" Musicbrainz tracklist, "Theme of Coon" appears as track 1 but it should be "ムスペルニブル" instead.