Skip to main content

Topic: Questions About CTDB Plugin in EAC (Read 4693 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Questions About CTDB Plugin in EAC

With the CTDB plugin installed and enabled, does EAC check both CTDB and AccurateRip after a rip, or does it only check one database?  Is there a way to get EAC to check both?  (Though as I understand it, one match in any database should be enough verification as long as it is not a previous submission from when you ripped the same CD in the past.)

After I ripped one of my tracks, the EAC log says "Accurately ripped (confidence 5)  [6489E204]  (AR v2)".
I assume "AR v2" is AccurateRip, but how will I know whether CTDB has been checked?

If CTDB finds an error, will I be prompted to use its error-correction feature, or do I have to do something manually in EAC?

Thanks.

  • korth
  • [*][*][*][*][*]
Questions About CTDB Plugin in EAC
Reply #1
Quote
With the CTDB plugin installed and enabled, does EAC check both CTDB and AccurateRip after a rip, or does it only check one database? Is there a way to get EAC to check both?With
With AccurateRip enabled and the CTDB EAC plugin installed you will get results from both.
Quote
but how will I know whether CTDB has been checked?
CTDB results appear at the bottom of the log.
Quote
If CTDB finds an error, will I be prompted to use its error-correction feature, or do I have to do something manually in EAC?
You would need to manually repair with CUETools.

EAC includes v2.1.3 of the plugin. The current plugin is v2.1.4 which includes fixes to work better with the latest version of CTDB. You can get it here, you can read a little more about the CTDB EAC plugin here and CTDB here.
  • Last Edit: 22 December, 2012, 02:15:22 PM by korth
korth

Questions About CTDB Plugin in EAC
Reply #2

Thanks.  I'm trying to deduce which part of the log is the CTDB results.  Here is the end of the log from my previous rip:

[...]

Track 15

    [...]
    Accurately ripped (confidence 5)  [2045F36A]  (AR v2)
    Copy OK


All tracks accurately ripped                <--- IS THIS BASED ON CTDB OR ACCURATERIP?

No errors occurred

End of status report

  • korth
  • [*][*][*][*][*]
Questions About CTDB Plugin in EAC
Reply #3
Quote
All tracks accurately ripped <--- IS THIS BASED ON CTDB OR ACCURATERIP?
AccurateRip. CTDB results would come after like this:
Code: [Select]
All tracks accurately ripped

No errors occurred

End of status report

---- CUETools DB Plugin V2.1.4

[CTDB TOCID: C8BYPUqGce7nqTyd1e6JwfA0_cE-] found
Submit result: C8BYPUqGce7nqTyd1e6JwfA0_cE- has been confirmed
Track | CTDB Status
  1  | (1/2) Accurately ripped
  2  | (1/2) Accurately ripped
  3  | (1/2) Accurately ripped
  4  | (1/2) Accurately ripped
  5  | (1/2) Accurately ripped
  6  | (1/2) Accurately ripped
  7  | (1/2) Accurately ripped
  8  | (1/2) Accurately ripped
  9  | (1/2) Accurately ripped
 10  | (1/2) Accurately ripped
 11  | (1/2) Accurately ripped
  • Last Edit: 22 December, 2012, 03:13:31 PM by korth
korth

Questions About CTDB Plugin in EAC
Reply #4

Weird, I have "CUETools DB Metadata Plugin V2.1.3" selected in EAC's Metadata Options, and I have the plugin activated on the Audio Plugins tab of the EAC options, but I'm still not getting feedback from CTDB when I rip.  I will try updating to V2.1.4.

Questions About CTDB Plugin in EAC
Reply #5

I'm still having the issue after installing the newer version of the plugin.  (I just replaced the old plugin .dll files in the EAC folder with the ones from the archive you linked to.)

  • Surfi
  • [*][*][*]
Questions About CTDB Plugin in EAC
Reply #6
::

What OS?

::

  • korth
  • [*][*][*][*][*]
Questions About CTDB Plugin in EAC
Reply #7
Quote
I'm still having the issue after installing the newer version of the plugin
The plugin only processes 'whole disc' rips so you won't see the CTDB results if you only rip one or a few tracks.
korth

Questions About CTDB Plugin in EAC
Reply #8

!!!!  I bet that's why it didn't work.  I will let you know if I have any problem after ripping a whole disc.  Thanks a lot!

OS is Windows 7.

  • Surfi
  • [*][*][*]
Questions About CTDB Plugin in EAC
Reply #9
OS is Windows 7.
::

That should work OOTB.

::

Questions About CTDB Plugin in EAC
Reply #10

I got the CTDB verification results in my log, but worryingly only some of the tracks were "Accurately ripped" and many had "No match".  I read that "No match" means "Too many samples differ".  Yet the ripped tracks all sound like they are supposed to (at least the first couple seconds of each that I listened to).

So does this really mean that those tracks just aren't in the database at all, even some of the tracks from the album are, or are my rips too inaccurate?  The CD isn't in that bad of shape.

This CD contains tracks that may be identical to tracks from a previously released album by the same artist, so could CTDB be comparing them to the tracks from the other album, which might be in the database, and that is why only some tracks could be verified?  Or does CTDB not compare tracks from different albums?

All tracks were verified by AccurateRip with confidence 5.  I worry that 5 could be from when I ripped the same CD in EAC years ago, but I never previously clicked "Send AccurateRip Results..." in EAC.  So:
A)  Does "Send AccurateRip Results..." send the CRCs of my rips to EAC?
B)  If so, then the other entries in the database probably are not mine unless previous versions of EAC would automatically submit CRCs, because I never clicked "Send AccurateRip Results..." in the past.


From my log:

---- CUETools DB Plugin V2.1.4

[CTDB TOCID: FIR2mkbR8UXsDT6lGL1fzKyd.BM-] found
Submit result: FIR2mkbR8UXsDT6lGL1fzKyd.BM- has been uploaded
Track | CTDB Status
  1  | (1/1) Accurately ripped
  2  | (0/1) No match
  3  | (1/1) Accurately ripped
  4  | (1/1) Accurately ripped
  5  | (1/1) Accurately ripped
  6  | (1/1) Accurately ripped
  7  | (0/1) No match
  8  | (0/1) No match
  9  | (0/1) No match
10  | (0/1) No match
11  | (0/1) No match
12  | (0/1) No match
13  | (0/1) No match
14  | (0/1) No match
15  | (0/1) No match

  • korth
  • [*][*][*][*][*]
Questions About CTDB Plugin in EAC
Reply #11
Quote
So does this really mean that those tracks just aren't in the database at all
Not possible. CTDB records are of complete discs.
Quote
or are my rips too inaccurate? The CD isn't in that bad of shape.
You're comparing your rip to a low confidence record (x/1). Confidence levels below 2 should not be considered reliable.
Quote
This CD contains tracks that may be identical to tracks from a previously released album by the same artist, so could CTDB be comparing them to the tracks from the other album, which might be in the database, and that is why only some tracks could be verified? Or does CTDB not compare tracks from different albums?
Only if the disc layout is the same from the actual start of track 1 through end of the last track. For example, your rip [link] has a 32 frame pregap but the previous record in the database [link] did not. The layout was identical otherwise.
Quote
All tracks were verified by AccurateRip with confidence 5. I worry that 5 could be from when I ripped the same CD in EAC years ago, but I never previously clicked "Send AccurateRip Results..." in EAC. So:
A) Does "Send AccurateRip Results..." send the CRCs of my rips to EAC?
B) If so, then the other entries in the database probably are not mine unless previous versions of EAC would automatically submit CRCs, because I never clicked "Send AccurateRip Results..." in the past.
Both AccurateRip and CTDB have some protection in place to prevent multiple submissions from a single user on a single machine. So your rip should be good. AccurateRip results should be sent every 30 days or so. The CTDB plugin sends results immediately.
  • Last Edit: 23 December, 2012, 04:41:13 PM by korth
korth

Questions About CTDB Plugin in EAC
Reply #12
Thanks for looking into that for me.  I just want to make sure I understand what you said about the pregap.  Is the only difference (or only apparent difference) between my rip and the previous rip simply in the way EAC appended the gaps, and there just aren't any other records yet for people who ripped the same album and handled the gaps the same way as I did?  That would make sense, because I have EAC set to append gaps at the end of the previous track, so the missing gap at the beginning of the first track would explain the difference between my rip and the other record.

To clarify things for me: do the "Start" and "End" columns in the database records refer to the positions on the CD where the ripped tracks begin/end?

Based on the understanding I explained above, I am confused about a few things.  First:  Why is the length of Track 1 the same in both records?  Track 1 starts 32 frames later in my rip, which makes sense if the pregap was omitted, but why does it also end 32 frames later?
My initial explanation (which I now don't think is right) was that it is because the gap of the next track is appended on the end, adding to the length, and the gaps for all the tracks happen to be exactly 32 frames.

But that leads me to my next question:  Why is the length of the last track the same in both records?  Wouldn't the last track be shorter due to not having any gap appended to it?  I expected the last track to end on the same frame in both records, regardless of how the gaps were appended.


BUT, to confuse me even more:  I ended up reading this CD's cue sheet, and after reading this page ( http://wiki.hydrogenaudio.org/index.php?ti..._and_Cue_Sheets ) and learning how to interpret EAC cue sheets, I came to believe that this particular CD actually has NO gaps except for the pregap in Track 1.  In the cue sheet: the first track has a "PREGAP 00:00:32" line which would cause silence to be written for 32 frames to account for the missing Track 1 pregap, but none of the other tracks have any "PREGAP" or "INDEX 00" lines, which I interpret to mean they just didn't have any gaps on the CD.


This raises a couple more questions:

--  So we know that my rip starts 32 frames later due to the omitted pregap; but how is it possible that all of the tracks other than Track 1 start and end on different frames if there really are no gaps between any of the tracks?  Is there something technical about the way CTDB works that I'm not aware of?

--  If none of them had any gaps to speak of, why weren't all the tracks other than Track 1 "Accurately ripped"?  And some of them were "Accurately ripped", so....  is it possible that the other guy actually had a bunch of badly ripped tracks?  Mine were all verified by AccurateRip.


(....Or, from an entirely different angle:  Could the difference between the two rips have something to do with the fact that I didn't configure EAC to overread into the lead-in and lead-out?  My drive is supposedly only 6 frames off, though, not 32.)


Oy.  Sorry to ask a bunch of possibly dumb questions.  Thanks, korth, for your very informative help thus far.
  • Last Edit: 24 December, 2012, 12:55:57 AM by heyo_speaker

  • korth
  • [*][*][*][*][*]
Questions About CTDB Plugin in EAC
Reply #13
Sorry [!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]{and my apologies to mr. greynol}[/size]. My original text said 'disc pregap' but got lost in the edit. Another term for this would be HTOA. This is found in the disc TOC (Table of Contents located in the lead-in area of the disc that describes the layout of the tracks on the disc), not the gaps EAC detected between tracks. When present, the start position of all tracks are shifted back by the length in frames of the HTOA (as with your rip).
Quote
To clarify things for me: do the "Start" and "End" columns in the database records refer to the positions on the CD where the ripped tracks begin/end?
Per the disc TOC. The "Start" and "End" positions in CTDB also include the 2 second lead-in so all positions are shifted back by 150 frames when compared against the TOC info found in the EAC log. Musicbrainz and freedb also include the 2 second lead-in in their records.
Quote
If none of them had any gaps to speak of, why weren't all the tracks other than Track 1 "Accurately ripped"? And some of them were "Accurately ripped", so.... is it possible that the other guy actually had a bunch of badly ripped tracks? Mine were all verified by AccurateRip.
The other rip could just be a different pressing from another region (a pressing without the HTOA). It could also be from a CDR created from tracks and the HTOA was omitted. Though it is possible the other rip had errors too. Confidence levels below 2 should not be considered reliable.
Quote
(....Or, from an entirely different angle: Could the difference between the two rips have something to do with the fact that I didn't configure EAC to overread into the lead-in and lead-out? My drive is supposedly only 6 frames off, though, not 32.)
No. BTW, drive offset is in samples, not frames.
korth

  • korth
  • [*][*][*][*][*]
Questions About CTDB Plugin in EAC
Reply #14
'shifted back' was admittedly a poor phrase. Maybe just 'shifted'
  • Last Edit: 24 December, 2012, 07:07:43 PM by korth
korth

Questions About CTDB Plugin in EAC
Reply #15

Thanks!  I wasn't aware of the "disc pregap" / HTOA.  So I shouldn't worry about the non-matching rip in CTDB and I can probably just be confident in my rip's accuracy based on the results from AccurateRip.