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 1893880 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 #2750
In theory, there's a lot. Not sure how probable some of them are.

Code: [Select]
[ec2-user@ip-10-226-89-162 cuetoolsnet-code]$ fgrep "new Exception" CUETools.Codecs.FLAKE/FlakeReader.cs
...
throw new Exception("invalid frame");
throw new Exception("unsupported bps coding");
throw new Exception("unsupported frame coding");
throw new Exception("invalid sample rate mode");
throw new Exception("invalid channel mode");
throw new Exception("header crc mismatch");
throw new Exception("unsupported residual coding");
throw new Exception("invalid partition order");
throw new Exception("cbits >= 16");
throw new Exception("negative shift");
throw new Exception("unsupported subframe coding (ch == x)");
throw new Exception("invalid subframe type");
throw new Exception("frame crc mismatch");
throw new Exception("FLAC stream not found");
throw new Exception("headerless file unsupported");
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2751
Thanks. "unsupported" is evidently not what metalheads want to use in a song title, so these were pretty quickly checked ;-)

Feature suggestion: CUETools could report e.g. "###DECODING ERROR### -" in front of the message.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2752
Hi there, I have been trying to use CueTools for a while but at times the results are not as they should supposed to be.

For example if I am ripping a double cd I just end up with disc 2 only because the program will just overwrite disc 1 even if it did state disc 1 and 2 when retrieving the titles via the database.
I have to remember every time to modify the name of disc 1 and there seems not to be any option to fix that.

At times I might get different AccurateRip results like that:

Quote
CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov

Joel Xavier & Andy Lekker / Whoop! Records

Used drive  : HL-DT-ST DVD-RAM GH22NP20  Adapter: 1  ID: 0

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

Read offset correction                      : 102
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

    Peak level 98.8 %
    Range quality 100.0 %
    Copy CRC EE4CE234
    Copy OK

No errors occurred

AccurateRip summary

Track  1  accurately ripped (confidence 3)  [D7E7D661]
Track  2  accurately ripped (confidence 3)  [B7BE380B]
Track  3  accurately ripped (confidence 3)  [E06C08AC]
Track  4  accurately ripped (confidence 3)  [DDBB47DD]
Track  5  accurately ripped (confidence 3)  [3A0B3CD1]
Track  6  accurately ripped (confidence 3)  [37851E71]
Track  7  accurately ripped (confidence 3)  [5E502743]
Track  8  accurately ripped (confidence 3)  [EE66FB22]
Track  9  cannot be verified as accurate (confidence 3)  [589E7CB8], AccurateRip returned [4B6FBBC2]



Quote
Exact Audio Copy V1.0 beta 6 from 9. April 2015

Various / Andy Lekker & Joel Xavier - Whoop! Records

Used drive  : HL-DT-STDVD-RAM GH22NP20  Adapter: 1  ID: 0

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

Read offset correction                      : 102
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


Range status and errors

Selected range

    Peak level 98.8 %
    Extraction speed 4.1 X
    Range quality 100.0 %
    Copy CRC EE4CE234
    Copy OK

No errors occurred

AccurateRip summary

Track  1  accurately ripped (confidence 3)  [7A743493]  (AR v2)
Track  2  accurately ripped (confidence 3)  [42FE6D49]  (AR v2)
Track  3  accurately ripped (confidence 3)  [1D1C4DA1]  (AR v2)
Track  4  accurately ripped (confidence 3)  [12A6A005]  (AR v2)
Track  5  accurately ripped (confidence 3)  [1FC98BC3]  (AR v2)
Track  6  accurately ripped (confidence 3)  [6795CB85]  (AR v2)
Track  7  accurately ripped (confidence 3)  [06DAE983]  (AR v2)
Track  8  accurately ripped (confidence 3)  [A4EC8B1D]  (AR v2)
Track  9  cannot be verified as accurate (confidence 1)  [57EE6EBA], AccurateRip returned [4B6FBBC2]  (AR v2)

8 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.6

[CTDB TOCID: 7iyjmsPsuL9DStBu_cJgCjiM01Y-] found


Same cd... different values. How can it be?

The last track is giving me headaches since every copy I tracked down does have issues on the very last minutes though it does sound fine with the EAC [57EE6EBA] value being confirmed by other 8 different rips also using different softwares.

Also when I try to rip any cd with a data track the program freezes and I am back to EAC to do the job.

On top of that today I came across another issue. Vangelis - Opera Sauvage (which I know it should have pre-emphasis) does not show on CueRipper 2.1.5 while it does show with EAC 0.99pb5.

Quote
REM GENRE Electronic
REM DATE 1979
REM DISCID 650A1907
REM COMMENT "ExactAudioCopy v0.99pb5"
CATALOG 0042282966322
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
FILE "Vangelis - Opera Sauvage.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Hymne"
    PERFORMER "Vangelis"
    ISRC FRF067900070
    FLAGS PRE
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    TITLE "Rêve"
    PERFORMER "Vangelis"
    ISRC FRF067900080
    FLAGS PRE
    INDEX 00 02:42:02
    INDEX 01 02:46:35


Quote
REM DISCID 650A1907
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
CATALOG 0042282966322
REM DATE 1979
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov"
FILE "Vangelis - Opera Sauvage.wav" WAVE
  TRACK 01 AUDIO
    PERFORMER "Vangelis"
    TITLE "Hymne"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    PERFORMER "Vangelis"
    TITLE "Rêve"
    INDEX 01 02:46:35


I seem to recollect from another thread that the weird indexes 00 on the EAC cuesheet are a result of EAC getting confused or something and are wrong.

So I guess I will just add the FLAG PRE to the CueRipper rip though I had to do the job twice to get a more accurate result using the best of both worlds.

I like the ease of use of CueRipper. It is generally faster in getting the same results of EAC, but when it comes to the aforementioned issues and with scratched cd's I need to go back to the slower error recovery routines of EAC.

I hope this will be fixed in the next builds.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2753
Quote
For example if I am ripping a double cd I just end up with disc 2 only because the program will just overwrite disc 1 even if it did state disc 1 and 2 when retrieving the titles via the database.
I have to remember every time to modify the name of disc 1 and there seems not to be any option to fix that.

You can change the Output Path Template. Adding [%unique%] before the .cue will prevent overwriting. Adding something like  $ifgreater($max(%discnumber%,%totaldiscs%),1, '('CD%discnumber% of %totaldiscs%')',) before the .cue will add " (CD1 of 2)" (without the quotes) when TotalDiscs > 1.
[ '('CD%discnumberandname%')'] should give a similar result.
 
Quote
At times I might get different AccurateRip results...Same cd... different values. How can it be?

What does the *.accurip file show?

Quote
Also when I try to rip any cd with a data track the program freezes

There was a problem with 2.1.4 related to the 'Detailed log' setting but you shouldn't still have a problem in 2.1.5.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2754
Same drive same cd

CueRipper
Quote
Track 1 accurately ripped (confidence 3) [D7E7D661]
Track 2 accurately ripped (confidence 3) [B7BE380B]
Track 3 accurately ripped (confidence 3) [E06C08AC]
Track 4 accurately ripped (confidence 3) [DDBB47DD]
Track 5 accurately ripped (confidence 3) [3A0B3CD1]
Track 6 accurately ripped (confidence 3) [37851E71]
Track 7 accurately ripped (confidence 3) [5E502743]
Track 8 accurately ripped (confidence 3) [EE66FB22]
Track 9 cannot be verified as accurate (confidence 3) [589E7CB8], AccurateRip returned [4B6FBBC2]


EAC
Quote
Track 1 accurately ripped (confidence 3) [7A743493] (AR v2)
Track 2 accurately ripped (confidence 3) [42FE6D49] (AR v2)
Track 3 accurately ripped (confidence 3) [1D1C4DA1] (AR v2)
Track 4 accurately ripped (confidence 3) [12A6A005] (AR v2)
Track 5 accurately ripped (confidence 3) [1FC98BC3] (AR v2)
Track 6 accurately ripped (confidence 3) [6795CB85] (AR v2)
Track 7 accurately ripped (confidence 3) [06DAE983] (AR v2)
Track 8 accurately ripped (confidence 3) [A4EC8B1D] (AR v2)
Track 9 cannot be verified as accurate (confidence 1) [57EE6EBA], AccurateRip returned [4B6FBBC2] (AR v2)


Accurip

Quote
[CUETools log; Date: 24/09/2015 19.47.56; Version: 2.1.5]
[CTDB TOCID: 7iyjmsPsuL9DStBu_cJgCjiM01Y-] found.
Track | CTDB Status
  1  | (6/6) Accurately ripped
  2  | (6/6) Accurately ripped
  3  | (6/6) Accurately ripped
  4  | (6/6) Accurately ripped
  5  | (6/6) Accurately ripped
  6  | (6/6) Accurately ripped
  7  | (6/6) Accurately ripped
  8  | (6/6) Accurately ripped
  9  | (5/6) Accurately ripped
[AccurateRip ID: 0014cc8b-00989ece-750e8409] found.
Track  [  CRC  |  V2  ] Status
01    [d7e7d661|7a743493] (0+3/3) Accurately ripped
02    [b7be380b|42fe6d49] (0+3/3) Accurately ripped
03    [e06c08ac|1d1c4da1] (0+3/3) Accurately ripped
04    [ddbb47dd|12a6a005] (0+3/3) Accurately ripped
05    [3a0b3cd1|1fc98bc3] (0+3/3) Accurately ripped
06    [37851e71|6795cb85] (0+3/3) Accurately ripped
07    [5e502743|06dae983] (0+3/3) Accurately ripped
08    [ee66fb22|a4ec8b1d] (0+3/3) Accurately ripped
09    [589e7cb8|57ee6eba] (0+0/3) No match

Track Peak [ CRC32  ] [W/O NULL]
--  98,8 [EE4CE234] [CEE895AF]         
01  98,8 [A221583D] [9992DF6D]         
02  98,8 [5CC78955] [84F97CB5]         
03  98,8 [8965A6C9] [25D4BD73]         
04  98,8 [EE8D99AE] [7073213C]         
05  98,8 [006A4937] [47C9342E]         
06  98,8 [B0FB5684] [904B1008]         
07  98,8 [A5E4F7AB] [214EB42F]         
08  98,8 [BCB386BD] [45269E9F]         
09  98,8 [D2C4DF7F] [1108173C]


If I am comparing the resulting wav files in WaveLab they are identical.
Not on all cd's I am getting the different values though the waveform content is exactly the same. Most of the times the values for both EAC and CueRipper are the same.
I take EAC and CueRipper "sometimes" have a different behaviour when approaching the AccurateRip database.
On this cd CueRipper is using the CRC column values while EAC is using the V2 column values.

Now I know at least.

I believe that [%unique%] string [It did add 1 to the ripped files so that this time did not overwrite the previous rip] or better the %music%\%artist%\[%year% - ]%album%\%artist% - %album%[ '('disc %discnumberandname%')'].cue should be "by default" if anyone ripping double cd's or boxsets might be having the very same issue just out of the box after installing the software and ripping a double cd for the very first time.
Thanks for the tip.

And yes. Unfortunately also 2.1.5 seems to be having the same issue you pointed out for 2.1.4 when it comes to cd's including an extra data track, videos or anything.
It looks like the cdextra type is causing some conflicts.
If this is related to (some) LG drives (I am having 4 at the moment) I cannot tell.

Also if the cd has some scratches it tends to give an error message box on some drives. If I select quit the program will close without saving. If i click on Continue it will carry on writing.
Maybe I don't need to be scared by those menacing messages when dealing with a scratched cd that will be eventually ripped with other software without the "menacing" boxes with one option meaning the end of the whole process.

That's why I go back to EAC/dbPowerAmp/sometimes also iTunes when dealing with problematic cd's until I collect the right samples (if I can and if the AccurateRip database has a reliable amount of submissions). Not all of them though.

Is the FLAGS PRE of the older cd's will get fixed it will be an extra step into perfection at this point.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2755
Quote
Is the FLAGS PRE of the older cd's will get fixed it will be an extra step into perfection at this point.
Do you have Detect Indexes set to False?

Note: This is a different version of the CD [DISCID 650A1907 <> DISCID 620A1807] (it took me a while to dig it out).
Used drive  : LG HL-DT-ST DVDRAM GH24NS95

Set to True
Code: [Select]
REM DISCID 620A1807
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
CATALOG 0042282966322
REM DATE 1979
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov"
FILE "Vangelis - Opera Sauvage.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Vangelis"
    TITLE "Hymne"
    FLAGS PRE
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    PERFORMER "Vangelis"
    TITLE "Rêve"
    FLAGS PRE
    INDEX 00 02:41:27
    INDEX 01 02:45:72
  TRACK 03 AUDIO
    PERFORMER "Vangelis"
    TITLE "L'enfant"
    FLAGS PRE
    INDEX 00 15:12:62
    INDEX 01 15:18:22
...
Set to False
Code: [Select]
REM DISCID 620A1807
PERFORMER "Vangelis"
TITLE "Opera Sauvage"
CATALOG 0042282966322
REM DATE 1979
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.5 Copyright © 2008-13 Grigory Chudov"
FILE "Vangelis - Opera Sauvage.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "Vangelis"
    TITLE "Hymne"
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    PERFORMER "Vangelis"
    TITLE "Rêve"
    INDEX 01 02:45:72
  TRACK 03 AUDIO
    PERFORMER "Vangelis"
    TITLE "L'enfant"
    INDEX 01 15:18:22
...
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2756
Detect Indexes is set to True (as for defaults when I installed CueTools). Something I have left untouched as advised.
Your version is a different pressing of course but if it did detect the pre-emphasis using the same settings I am also using.
Perhaps the FLAGS PRE is written in a different place...

Quote
A pre-emphasis flag for each track is normally stored in the subcode along with the audio data. It's also supposed to be stored in the table of contents (TOC), but many CDs have TOCs that say there's no pre-emphasis when in fact the subcode says there is. There are also some CDs which people believe were mastered with pre-emphasis, but which have no pre-emphasis flags set at all.


... and this might be the case... and the reason why I hate buying represses...

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2757
Maybe korth will provide a snippet of audio from his CD. You can compare it to the same section on yours.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2758
A quick question regarding tagging:



I'm encoding a soundtrack album. Movie has been released in 1952, while this album has been released in 2007.

My questions are:

1) What exactly is the meaning of "Date" and "Release Date"?
2) Would be correct to set Date to 1952 and Release Date to 2007?

What about foobar:



What would be the meaning of Date tag, in that case?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2759
Release date is for the actual CD release date - for example, every remaster has a different one, so you can tell them apart. So it's probably 2007.
Date is usually the earliest release date for this material. Which is kind of ambiguous in this case, because the movie doesn't quite count as a release, so strictly speaking this would have to be 2001, but in the end it's your choice and if 1952 makes more sense for you, go with it.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2760
Thank you Gregory. Do you know if, talking about movie soundtracks, the majority of people use the movie date as Date (Year) tag?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2761
I'd say it's whatever you make it to be. I usually just tag the date as yyyy/mm/dd of the release for all my archives.

@Gregory: any chance you could look at this issue?

I'm currently running CUETools on WINE and it somewhat works (did not try CUERipper yet), but it's full of weird side effects. For example mounting /tmp as R:\ then attempting to access R:\ via CUETools results in  "The given path's format is not supported". Going via the internal Z: drive gives something similar: "Z:\tmp - the given path's format is not supported". foobar2000 can access the same folder on WINE just fine.


Regarding this issue, I was able to pinpoint what is causing it: if any of the files in the folder you are trying to browse contain invalid characters by NTFS definition (in my case, ':' in socket file names in /tmp), then CUETools cannot list anything and just spits out that message.
I would be eternally grateful if CUETools could ignore and simply not show (=filter out) invalid filenames instead.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2762
Hello, I am trying to convert my CD collection in flac files, but I would like to do from the command line through a batch file. where can I find a guide? thanks and sorry for my terrible English!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2763
Sorry, no guide.
Are you converting image+cue to tracks?
Example: image.flac + image.cue to track1.flac + track2.flac + track3.flac ...
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2764
Sorry, no guide.
Are you converting image+cue to tracks?
Example: image.flac + image.cue to track1.flac + track2.flac + track3.flac ...

yes, I would like to rip CDs into folders with track.flac, track2.flac etc. via command line, as I could do? thank

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2765
Do you have file(s) + .cue you are trying to 'convert'? Or are you trying to 'rip' CDs?
'convert' and 'rip' are different things.
You can 'convert' existing audio files (already ripped from CD) to FLAC via command-line using CUETools.exe if you have a CUE file. I could write a quick guide for that.
The command-line CUETools.ConsoleRipper.exe is a very basic program for testing so it won't 'rip' the way you want.
As far as I know CUERipper.exe does not have command-line options.
korth


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2767
It is a CUE sheet command to add silence after a track.
http://digitalx.org/cue-sheet/syntax/#postgap
cdrwin supports the command but I'm not sure if other programs do also.
korth


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2769
It's relevant to checking against alternate structures which is useful if you have a rare pressing.  So, yes, it is just as relevant to "ripping" as any other instruction.

FWIW, Alcohol 120% supports postgap lines (in response to korth's comment).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2770
Yes that should've been 'which other programs' instead of 'if'.
ImgBurn supports postgap as well.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2771
Do you have file(s) + .cue you are trying to 'convert'? Or are you trying to 'rip' CDs?
'convert' and 'rip' are different things.
You can 'convert' existing audio files (already ripped from CD) to FLAC via command-line using CUETools.exe if you have a CUE file. I could write a quick guide for that.
The command-line CUETools.ConsoleRipper.exe is a very basic program for testing so it won't 'rip' the way you want.
As far as I know CUERipper.exe does not have command-line options.

using cue console ripper get a .wav file and .cue file, then I would get from these .flac files via the command line. guide would be welcome !!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2772
I have a couple of feature requests for CUERipper. Hopefully this is the right spot for them.

Unfortunately, this thread has gotten a bit long, so if these are repeats, I apologize. In that case consider it a vote for the feature. 


The first should be, I think, relatively simple:

A lot of times when reading a damaged disc, I will get spurious errors, such as "medium error" or "ioctl failed". I say spurious because these errors don't always happen for a given disc, usually aren't at the same spot, and often happen after several retries have already been performed on the same location.

Unfortunately, when one of these errors occurs, CUERipper just aborts the rip. It would be very nice if there were an option to retry the operation instead of aborting, since in my experience, it would be very likely to succeed given a second attempt. If no progress is made after many retries, it might be nice if there were additionally an option to skip the problem-causing sector, using the best guess from any retries that have been completed, and continue on ripping the rest of the disc.


The second is more complex, and may be beyond the scope of CUERipper:

For extra-problematic discs, it would be nice if there were functionality akin to that found it ddrescue. The idea would be for CUERipper to record which samples were not read correctly, and allow retrying just the failed samples at a later date to try to get as much data as possible from the CD (possibly crossing the threshold from not repairable to repairable). The idea would be that I could rip a CD on one drive, and then retry the failed samples on one or more other drives to try to get as much valid data as possible from the CD.


Finally, I had one disc with very slight damage that was such that the drive would kind of get lost when it got to a certain track, and keep returning read failures after that point. I discovered (using a different tool) that if I read some data from the track afterword and then went back and tried again (so the drive was seeking backward and not forward), it read the track just fine. I'm not sure if this is common enough to be useful as a strategy for error correction, but I thought I'd mention it.

Thanks!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2773
New user attempting to use CUERipper ... This thread seems current, but someone please let me know if I should put this elsewhere.  I'm encountering:
[blockquote]Exception: Error Reading CD: IoctlFailed[/blockquote]in a fashion which seems different from what I've been able to find by searching.

I've been an EAC user on an old machine at home that is failing, so I've brought up a new platform and wanted to try CUERipper at the same time.  The new platform is:
  • A virtual machine running Win7 Home Premium x64 SP1, 6GB of RAM
  • The VM is hosted on a QNAP TS-451 NAS (x86 dual-core CPU, host OS is "QTS 4.1.4")
  • Lite-On eTDU108 external DVD-ROM, USB 2 connection to the TS-451 (no outboard hub), drive assigned to the VM
  • CUETools 2.1.5, downloaded this morning. Stock configuration except for: Option changes for metadata search - extensive, detailed log - true; changed from image to tracks mode; set Test & Copy; and changed output path template
my discs for testing are Pink Floyd, The Wall (Columbia, C2K 36183).  Previously ripped years ago via EAC, sitting on an indoor shelf ever since. I recently learned that these discs were recorded with pre-emphasis that is only indicated in the track data, which EAC didn't detect and indicate in my log.  Wanted to see CUERipper report it (and then experiment with fixing it).

So I launched CUERipper, and loaded a disc once the window was up.  CUERipper identified the read offset (matching what I had seen in a web site search for this drive), read the disc metadata and track titles, and finds 30 CUETools DB matches and 78 AccurateRip matches.  This is looking very promising!

Hit the "Go" button ... Status bar shows Detecting drive features ... followed by Detecting gaps ...  After gap detection completes I see Ripping @nn.mm ..., then Ripping @nn.mm (retry 1)... (if I understand correctly, retry because I'm in "Secure" mode?), then shortly after it switches back to another Ripping @nn.mm ... (Track #2?) the rip fails with the Error reading CD.  Checking the folder I see only the .CUE file.  This seems to be deterministic behavior on both discs.

Switched off Test & Copy, repeated the experiment.  This gets me further into the rip before encountering the error.  The alternation between Ripping and Ripping (retry 1) was still happening, 4-8 times (across multiple tests), but when I check the target folder I see only the .CUE file and sometimes 01. In the Flesh_.flac (note that CUERipper shows the track title as In the Flesh?, so the file name in the folder differs slightly from the %tracknumber%. %title% template in the options).  When it fails only 4-5 alternations (tracks?) into the rip I see just the .CUE file, if it goes further I see the .CUE and a single FLAC.  Haven't ever seen more than the first track's FLAC file.

Similar results on the other disc in the set.  The behavior isn't deterministic, how deep into the rip I get varies (as long as Test & Copy is not selected).  Changing to either Burst or Paranoid mode seems to make the failure happen sooner.

So I'm hoping this is a known problem with known solutions to try, and my "Google-fu" just isn't good enough to find them.  Failing that, if anyone involved in CUERipper development can tell me how to enable more logging or debug information to get some traction on the problem, I'll certainly willing to give it a go.  I'll also do an EAC installation on the VM and give it a try this evening, to see if the drive fails to work with any ripping software.

Thanks in advance for any advice or pointers,
Alan

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2774
Indeed, secure mode involves a minimum of 2 reads of each block of sectors, and for the 2nd pass, the "retry" message is an unfortunate word choice since it implies there was something wrong with the first pass. Nothing to worry about, though.

The filename thing is not a bug. Windows APIs don't support "?" in filenames, so if constructing a filename from a string with "?" in it, the app must decide what to write instead. EAC makes a decision as well, with some degree of configurability.

Secure mode is already doing at least 2 reads, so Test & Copy is putting unnecessary wear & tear on your drive. I would only use it when using burst mode on CDs which are not in AccurateRip or CTDB.

The rips should not be aborting unless there's a communication problem with the drive.