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 versions 1.9.5 through 2.1.6 (Read 1894059 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1775
With EAC I found this drive can overread.  Perhaps I made a mistake, or does CueRipper always set this to 'No'?
Similar question [a href='index.php?act=findpost&pid=707779']asked[/a] and [a href='index.php?act=findpost&pid=707857']answered[/a]. I have a Plextor CDR capable of Overread into Lead-In and Lead-Out. Also No in CUERipper.
More testing of Cueripper.

When I compare against EAC (with overread) some CDs have identical test CRC32 for the last track.  This will be because CueRipper is filling up the offset with zeroes, and the missed part contained zeros anyway.  My offset is +30. Other CDs do appear to have data to the end.

Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

I suppose it might even be a good feature here for those people correcting offsets if you could check that you are only moving zeroes around (although I understand that correcting offsets has no real benefits, I only enter the offset in the main window to alter the offset for a verify to get the ARv2 result if it wasn't corrected properly at rip)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1776
Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

mkdir tmp9 && shntool.exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9

(would be simpler if shntool had a "don't write any files" option)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1777
Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?
mkdir tmp9 && shntool.exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9

(would be simpler if shntool had a "don't write any files" option)
Clever, but I wasn't thinking straight this morning. "Fill up missing offset samples with silence : Yes" will stop me from testing this way.

I'm testing CueRipper results against EAC. EAC overreads into the lead out with my PLEXTOR DVDR PX-716A (+30 offset)

Am I just being picky wanting my last track CRC32 to match what I get when I run EAC test in burst mode?  It usually does because the last 30 samples are usually digital silence.

I'm just regarding the CRC32 as being superior to the (flawed) AR CRC (and even the v2 has flaws right?). Isn't this why Gregory uses CRC32? Am I wrong here?

Coming soon: How I Learned to Stop Worrying and Love the Rip 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1778
I thought you already figured out that a [a href='index.php?act=findpost&pid=747535']few leading and trailing samples were removed from the CTDB CRC because drives with different offsets and no overread capability will produce different data in those areas[/a]. The link points to a discussion about the localDB but the two are similar.
AR CRCs are also calculated with a few leading samples from the first track and a few trailing samples from the last track removed.
I guess I don't have the same obsession for a possible 30 samples (0.00068 seconds) of inaudible digital noise at the end of the disc if the rest of the disc verifies.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1779
Yes, I know about how AR and CTDB drop the start and end (5 and 10 sectors).  I'm not really worried about those last few samples in my rips.  What I am doing is testing my CueRipper rips against EAC results.  The only way I have to do this is to use the full CRC32 from the EAC log.  As I understand it CRC is less robust (hence why Gregory uses CRC32), and ARv1 is further flawed (hence ARv2).

I guess I'm trying to check if I have one of these errors in EAC, or drive bugs, that I keep hearing about. Greynol might be able to point me in the right direction here. I figured that using two drives and two bits of software would flush any problems out.

It's the scientific training.....just a few more checks and then I'll be happy 

I do think that checking for digital silence could be implemented when people are correcting offsets in CueTools.  I know it has no real benefit to correct the offset and the downside is losing more samples.  But if you check for zeroes, then the downside vanishes.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1780
Just finished ripping 80 cds to discover:

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 1  ID: 0
Gap handling: Not detected, thus appended to previous track



Now, I understand that this does not affect the FLACs, but means my cuesheet will have no Index 00.  Other than the negative numbers on a burnt CD there are no bad consequences are there? I read this guide to gaps years ago

I do think the program should warn if it fails gap detection

A couple of other issues.
1) I had a problem where unique didn't work (may have been my fault as I had manually renamed the directory to remove an extraneous 'disc1') and the program simply overwrote the files without asking.  Is this the expected behaviour?
2) I'm trying my other drive in the light of the gap detection.  I see a changed CTDB confidence.  Should I get this increase as a result of my own re-rip? Is it the change of drive?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1781
Just finished ripping 80 cds to discover:

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 1  ID: 0
Gap handling: Not detected, thus appended to previous track
Strange, this is not consistent. Out of 80 cds, 4 were not detected (consistently, with several retries) although one has just had the gaps detected where they weren't before.

This may not be CueRipper though.  I think I recall problems with EAC, although my recollection is that EAC would hang during detection.  This was a long time ago though, so I could be wrong.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1782
Other than the negative numbers on a burnt CD there are no bad consequences are there?


This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1783
Other than the negative numbers on a burnt CD there are no bad consequences are there?
This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
I always think you need to be careful.  Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1784
Other than the negative numbers on a burnt CD there are no bad consequences are there?
This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).
I always think you need to be careful.  Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.


HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1785
HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.
Yes, of course I agree.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1786
Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection
That is how the program notifies you [a href='index.php?act=findpost&pid=706347'][link][/a]
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1787
Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection
That is how the program notifies you [a href='index.php?act=findpost&pid=706347'][link][/a]
Cheers korth. It is no problem now that I know this. I looked once I got to that post.

Again, this is a documentation issue. I think I'll make an account for the Cuetools wiki.

And I'm happier now that I see it wasn't all the rips I had completed.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1788
I hope this is the right place to ask - I have the following problem: I ripped a CD (The Lion King OST) in EAC, resulting in a few errors in one track, every other track was verified OK by AccurateRip:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 23. February 2012, 20:09

Various / The Lion King OST

Used drive  : HL-DT-STDVD-ROM GDR-H30N  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  3:59.67 |        0    |    17991 
        2  |  3:59.67 |  2:50.73 |    17992    |    30814 
        3  |  6:50.65 |  3:40.15 |    30815    |    47329 
        4  | 10:31.05 |  3:33.50 |    47330    |    63354 
        5  | 14:04.55 |  2:57.52 |    63355    |    76681 
        6  | 17:02.32 |  2:55.33 |    76682    |    89839 
        7  | 19:57.65 |  4:17.50 |    89840    |  109164 
        8  | 24:15.40 |  3:45.17 |    109165    |  126056 
        9  | 28:00.57 |  5:59.05 |    126057    |  152986 
      10  | 33:59.62 |  4:51.50 |    152987    |  174861 
      11  | 38:51.37 |  3:36.73 |    174862    |  191134 
      12  | 42:28.35 |  3:59.45 |    191135    |  209104 


Range status and errors

Selected range

    Filename Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.wav

    Suspicious position 0:41:22
    Suspicious position 0:41:26

    Peak level 98.3 %
    Extraction speed 9.3 X
    Range quality 99.6 %
    Copy CRC 201635C8
    Copy finished

There were errors

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 5)  [8F75F0CE]  (AR v2)
Track  2  accurately ripped (confidence 5)  [B94FCBF7]  (AR v2)
Track  3  accurately ripped (confidence 5)  [057830A9]  (AR v2)
Track  4  accurately ripped (confidence 5)  [9072E0B2]  (AR v2)
Track  5  accurately ripped (confidence 5)  [45BC209F]  (AR v2)
Track  6  accurately ripped (confidence 5)  [69A80D86]  (AR v2)
Track  7  accurately ripped (confidence 5)  [CEFBBEB7]  (AR v2)
Track  8  accurately ripped (confidence 5)  [54A17B6F]  (AR v2)
Track  9  accurately ripped (confidence 5)  [377CD6A5]  (AR v2)
Track 10  accurately ripped (confidence 5)  [5942A28C]  (AR v2)
Track 11  cannot be verified as accurate (confidence 94)  [AC42013C], AccurateRip returned [47CF4212]  (AR v2)
Track 12  accurately ripped (confidence 5)  [B2C61F12]  (AR v2)
 
11 track(s) accurately ripped
 1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: V1WRWT9HKBEErwwrV9RGpqqiZP8-] found, Submit result: V1WRWT9HKBEErwwrV9RGpqqiZP8- has been submitted
[fc6cb270] (162/168) Differs in 9300 samples @41:20:11-41:20:12,41:20:28-41:20:29,41:20:44-41:20:45,41:20:61-41:20:62,41:21:02-41:21:03,41:21:19-41:21:20,41:21:35-41:21:36,41:21:52-41:21:53,41:21:68-41:21:69,41:22:10-41:22:11,41:22:26-41:22:27,41:22:43-41:22:44,41:22:59-41:22:60,41:23:01-41:23:02,41:23:17-41:23:18,41:23:34-41:23:35,41:23:50-41:23:51,41:23:67-41:23:68,41:24:08-41:24:09,41:24:25-41:24:26,41:24:41-41:24:42,41:24:58-41:24:59,41:24:74-41:25:00,41:25:16-41:25:17,41:25:32-41:25:33,41:25:49-41:25:50,41:25:65-41:25:66,41:26:07-41:26:08,41:26:23-41:26:24,41:26:40-41:26:41,41:26:56-41:26:57,41:26:73-41:26:74,41:27:15,41:27:31-41:27:32,41:27:48,41:27:64-41:27:65,41:28:06,41:28:22-41:28:23
[d03a4fda] (001/168) No match
[557785fe] (001/168) No match
[8036c248] (001/168) No match
[e23534ca] (001/168) No match
[523a016f] (001/168) No match
[9d808615] (001/168) No match
You can use CUETools to repair this rip.


I've never used CUETools before, but i wanted to give it a try to repair the rip. When i load the cue file, and run the encode mode with the repair script selected it verifies the tracks and then stops with the message

Code: [Select]
Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.cue: differs in 9300 samples, confidence 163, or verified OK, confidence 1.

Sounds like there are multiple entries in the CTDB database, i might even have uploaded the incorrect one myself, as EAC states "has been submitted" in the log. Is there a possibility to repair the rip?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1789
Is there a possibility to repair the rip?

It looks like you are getting the batch mode log, select the cue sheet before you click go.  Cuetools should then ask you which entries in CTDB you want to use for the repair.

I've also had a few issues where I've had to ask it to repair several times.  Initially it goes through the verify and stops, then the next time it works and I'm not sure why.  Someone else might be able to shine some light on this.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1790
Ah thank you, i was using the batch mode, it worked now.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1791
Ah thank you, i was using the batch mode, it worked now.
Glad to help.  I've only been using CueTools for a week and I've been doing all the asking until now.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1792
I'm using the latest version of CUETools 2.1.2a for verifying my rips and populating the CTDB. I found a problem with multi-disc albums that have 5 or more discs if each disc is ripped into multiple tracks. CUETools nicely detects the individual discs if the files are propperly tagged - but only to a maximum of 5 discs. If there are more than 5 disc for that album, all the remaining tracks are grouped in one big disc - the 5th one. Is there a parameter that I can set (max. discs) or is this a bug? Of course if each disc is ripped into a single flac file then there is no problem with the multi-disc albums.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1793
You can switch Input to Multiselect Browser and select cues for more than 5 discs. Detection (as you put it) does max out at 5.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1794
Thanks for your help korth. Can you be a bit more specific - I didn't really understand and see where I can switch to Multiselect Browser.

Also why is this magic number 5 hardcoded? There are many album box-sets out there with definitely more than 5 discs. Maybe that could be a parameter in a future version that one could set under the options. :-)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1795
See the down arrow after Input:? Click on it.
Quote
Also why is this magic number 5 hardcoded?
That I can't answer. Only know it from my own usage. Gregory seems quite busy the past few months so I just help out when I can answer a question.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1796
I know I am replying to some > 3 year old post [a href="index.php?act=findpost&pid=593800"][{POST_SNAPBACK}][/a], but, concerning AccurateRip retro-verification:

i'm still quite pessimistic about the possibility of recovering an album structure, when tracks were split. Ok, we can sacrifice that split track and focus on verifying other tracks, but for that we have to know for sure it's length.


A suggestion for the case where a cuesheet is absent:
(I) Check files for ACCURATERIPID tags. Then users who use CUERipper, will be able to retro-check AR status later, without the cuesheet (and users who read this forum, could very often get the impression that cuesheets are only useful for writing back a copy ...)
(II) Check files for AccurateRipDISCId tags (my emph.). dBpoweramp writes those. CUERipper and dBpoweramp users are a minority compared to EAC users, but if you consider (I) to be worthwile support for CUERipper users, it should be hardly much effort to do dBpoweramp's tag as well.
(III) Could CDTOC be used the same way? MusicBrainz IDs?


(... 72 pages and counting ... if you could even find information in this thread, you wouldn't know if it is up-to-date :-o )

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1797
I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1798
I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?
Because of the way accuraterip works, I would rip the whole CD in track mode then just grab the tracks I wanted.  Or you could use EAC.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1799
Whenever I try to rip a CD using CueRipper, I always get an error stating that there were 15 suspicious sectors, although the rip has been confirmed with Accurip; for an example, the CD I've just tried produced the following Accurip file:

Code: [Select]
[CUETools log; Date: 10/03/2012 11:30:36; Version: 2.1.2a]
[CTDB TOCID: _uGvLH10IxqfR4ZETg_p5mkWEpw-] found.
        [ CTDBID ] Status
        [215e14c2] (1/2) Differs in 710 samples @58:26:43-58:26:44
        [9e9c6c34] (1/2) Accurately ripped
[AccurateRip ID: 001f4d67-016255cf-c70db20f] found.
Track  [ CRC    ] Status
 01    [0729a137] (04/32) Accurately ripped
 02    [6dc2ef07] (04/32) Accurately ripped
 03    [942a1c47] (04/32) Accurately ripped
 04    [3e9c91b6] (04/32) Accurately ripped
 05    [00f5b2e0] (04/32) Accurately ripped
 06    [8ec50bcd] (04/32) Accurately ripped
 07    [228a631f] (04/32) Accurately ripped
 08    [084ab80e] (04/32) Accurately ripped
 09    [ba9a8ed6] (04/31) Accurately ripped
 10    [b4faabe6] (04/32) Accurately ripped
 11    [4c61993f] (04/32) Accurately ripped
 12    [980f5e20] (04/32) Accurately ripped
 13    [51070d0f] (04/31) Accurately ripped
 14    [ce9d5a83] (04/31) Accurately ripped
 15    [1f5281df] (04/29) Accurately ripped
Offsetted by 1879:
 01    [1321ed77] (02/32) Accurately ripped
 02    [2a4a5c4e] (02/32) Accurately ripped
 03    [5a28826a] (02/32) Accurately ripped
 04    [3f160e1d] (02/32) Accurately ripped
 05    [592e74cf] (02/32) Accurately ripped
 06    [388dbbda] (02/32) Accurately ripped
 07    [124d08a5] (02/32) Accurately ripped
 08    [4edeb39b] (02/32) Accurately ripped
 09    [408366d0] (02/31) Accurately ripped
 10    [8ebca252] (02/32) Accurately ripped
 11    [06f884e7] (02/32) Accurately ripped
 12    [cc92ee8c] (02/32) Accurately ripped
 13    [0552cee7] (02/31) Accurately ripped
 14    [13c98641] (02/31) Accurately ripped
 15    [e1889663] (02/29) Accurately ripped
Offsetted by 2713:
 01    [e03f2aff] (16/32) Accurately ripped
 02    [40038405] (16/32) Accurately ripped
 03    [3ecee28a] (16/32) Accurately ripped
 04    [88447f34] (16/32) Accurately ripped
 05    [0cfba08e] (16/32) Accurately ripped
 06    [d058da0d] (16/32) Accurately ripped
 07    [fd5ff960] (16/32) Accurately ripped
 08    [63891968] (16/32) Accurately ripped
 09    [721e03c5] (15/31) Accurately ripped
 10    [b1f79bc8] (16/32) Accurately ripped
 11    [ab29209d] (16/32) Accurately ripped
 12    [cfbabb8f] (16/32) Accurately ripped
 13    [c8cb2ec1] (15/31) Accurately ripped
 14    [8e80b899] (15/31) Accurately ripped
 15    [d0512438] (00/29) No match but offset

Track Peak [ CRC32  ] [W/O NULL]
 --  99.9 [0EDAF71A] [3E355924]         
 01  93.2 [88F41CD8] [D57DC7E0]         
 02  72.5 [C64A2F25] [A6B1C7EA]         
 03  95.4 [BBA16AB2] [3FD6FC02]         
 04  87.3 [236D2E8E] [103E0353]         
 05  80.7 [038E3D95] [1A09CAB9]         
 06  94.6 [DF0DF23F] [4DFC12DD]         
 07  84.2 [6A17FA2E] [BDC00B01]         
 08  99.9 [3A5BA7CD] [D07AC925]         
 09  90.9 [2E4D3AE1] [E8914DFB]         
 10  88.0 [9AC6C7C8] [BD3FF92A]         
 11  74.9 [023E329B] [4CBE857B]         
 12  87.1 [A3F378CF] [E5B9B1CC]         
 13  92.4 [DE103A96] [7A326BE4]         
 14  75.0 [52A4E116] [5B5BFA5A]         
 15  69.6 [2391AED3] [0C0A645C]         

The CueRipper log shows:

Code: [Select]
CUERipper v2.1.2 Copyright © 2008-10 Gregory S. Chudov

EAC extraction logfile from 10. March 2012, 11:30

Motörhead / All the Aces: The Best of Motörhead

Used drive  : HL-DT-ST DVDRAM GH20NS15  Adapter: 1  ID: 0

Read mode              : Burst
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:48.30 |        0    |    12629 
        2  |  2:48.30 |  4:34.72 |    12630    |    33251 
        3  |  7:23.27 |  4:43.50 |    33252    |    54526 
        4  | 12:07.02 |  2:52.60 |    54527    |    67486 
        5  | 14:59.62 |  5:22.53 |    67487    |    91689 
        6  | 20:22.40 |  3:21.62 |    91690    |  106826 
        7  | 23:44.27 |  3:09.20 |    106827    |  121021 
        8  | 26:53.47 |  3:40.15 |    121022    |  137536 
        9  | 30:33.62 |  4:16.53 |    137537    |  156789 
      10  | 34:50.40 |  2:46.02 |    156790    |  169241 
      11  | 37:36.42 |  2:39.03 |    169242    |  181169 
      12  | 40:15.45 |  4:27.02 |    181170    |  201196 
      13  | 44:42.47 |  3:15.28 |    201197    |  215849 
      14  | 47:58.00 |  5:11.35 |    215850    |  239209 
      15  | 53:09.35 |  5:17.15 |    239210    |  262999 


Range status and errors

Selected range

    Filename D:\Rip\Motörhead\1993 - All the Aces_ The Best of Motörhead\Motörhead - All the Aces_ The Best of Motörhead.wav

    Suspicious position 0:57:54

    Peak level 99.9 %
    Range quality 100.0 %
    Test CRC 0EDAF71A
    Copy CRC 0EDAF71A
    Copy OK

There were errors


AccurateRip summary

Track  1  accurately ripped (confidence 4)  [0729A137]
Track  2  accurately ripped (confidence 4)  [6DC2EF07]
Track  3  accurately ripped (confidence 4)  [942A1C47]
Track  4  accurately ripped (confidence 4)  [3E9C91B6]
Track  5  accurately ripped (confidence 4)  [00F5B2E0]
Track  6  accurately ripped (confidence 4)  [8EC50BCD]
Track  7  accurately ripped (confidence 4)  [228A631F]
Track  8  accurately ripped (confidence 4)  [084AB80E]
Track  9  accurately ripped (confidence 4)  [BA9A8ED6]
Track 10  accurately ripped (confidence 4)  [B4FAABE6]
Track 11  accurately ripped (confidence 4)  [4C61993F]
Track 12  accurately ripped (confidence 4)  [980F5E20]
Track 13  accurately ripped (confidence 4)  [51070D0F]
Track 14  accurately ripped (confidence 4)  [CE9D5A83]
Track 15  accurately ripped (confidence 4)  [1F5281DF]

All tracks accurately ripped

End of status report

Any ideas why CueRipper should be reporting an error? Is it something to do with my drive?

When ripping with EAC + CTDB, I get the following:

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 10. March 2012, 12:02

Motörhead / All the Aces: The Best of Motörhead

Used drive  : HL-DT-STDVDRAM GH20NS15  Adapter: 4  ID: 1

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 667
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format              : User Defined Encoder
Selected bitrate                : 896 kBit/s
Quality                        : High
Add ID3 tag                    : Yes
Command line compressor        : C:\Program Files (x86)\Exact Audio Copy\FLAC\FLAC.EXE
Additional command line options : -6 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "ALBUMARTIST=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" %hascover%--picture="%coverfile%"%hascover% %source% -o %dest%


TOC of the extracted CD

    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.00 |  2:48.30 |        0    |    12629 
        2  |  2:48.30 |  4:34.72 |    12630    |    33251 
        3  |  7:23.27 |  4:43.50 |    33252    |    54526 
        4  | 12:07.02 |  2:52.60 |    54527    |    67486 
        5  | 14:59.62 |  5:22.53 |    67487    |    91689 
        6  | 20:22.40 |  3:21.62 |    91690    |  106826 
        7  | 23:44.27 |  3:09.20 |    106827    |  121021 
        8  | 26:53.47 |  3:40.15 |    121022    |  137536 
        9  | 30:33.62 |  4:16.53 |    137537    |  156789 
      10  | 34:50.40 |  2:46.02 |    156790    |  169241 
      11  | 37:36.42 |  2:39.03 |    169242    |  181169 
      12  | 40:15.45 |  4:27.02 |    181170    |  201196 
      13  | 44:42.47 |  3:15.28 |    201197    |  215849 
      14  | 47:58.00 |  5:11.35 |    215850    |  239209 
      15  | 53:09.35 |  5:17.15 |    239210    |  262999 


Range status and errors

Selected range

    Filename D:\Rip\Motorhead - All The Aces\Motörhead - All the Aces- The Best of Motörhead.wav

    Peak level 99.9 %
    Extraction speed 28.2 X
    Range quality 100.0 %
    Copy CRC 0EDAF71A
    Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 4)  [0729A137]  (AR v1)
Track  2  accurately ripped (confidence 4)  [6DC2EF07]  (AR v1)
Track  3  accurately ripped (confidence 4)  [942A1C47]  (AR v1)
Track  4  accurately ripped (confidence 4)  [3E9C91B6]  (AR v1)
Track  5  accurately ripped (confidence 4)  [00F5B2E0]  (AR v1)
Track  6  accurately ripped (confidence 4)  [8EC50BCD]  (AR v1)
Track  7  accurately ripped (confidence 4)  [228A631F]  (AR v1)
Track  8  accurately ripped (confidence 4)  [084AB80E]  (AR v1)
Track  9  accurately ripped (confidence 4)  [BA9A8ED6]  (AR v1)
Track 10  accurately ripped (confidence 4)  [B4FAABE6]  (AR v1)
Track 11  accurately ripped (confidence 4)  [4C61993F]  (AR v1)
Track 12  accurately ripped (confidence 4)  [980F5E20]  (AR v1)
Track 13  accurately ripped (confidence 4)  [51070D0F]  (AR v1)
Track 14  accurately ripped (confidence 4)  [CE9D5A83]  (AR v1)
Track 15  accurately ripped (confidence 4)  [1F5281DF]  (AR v1)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: _uGvLH10IxqfR4ZETg_p5mkWEpw-] found, Submit result: _uGvLH10IxqfR4ZETg_p5mkWEpw- has been confirmed
[215e14c2] (1/3) Differs in 710 samples @58:26:43-58:26:44
[9e9c6c34] (2/3) Accurately ripped
You can use CUETools to repair this rip.


==== Log checksum B86A826E81C4C480ECB0ED5FE371F678BA6921EE19A4E62D0D7B5754B5A01B10 ====