Hello all,
I own 2 Plextor drives, a 5224TA and a recently purchased 708A that I am using on Windows 11. Both of these drives, when detecting indexes on any CD, get about 2/3 of the way through the detection process, then start ripping without preserving indexes. I bought the 708A because I attributed the issue to the age and heavy use of the 5224, but it behaves in the same fashion. I also tried an older version of CUERipper with the same result. I just wondered if anyone else was experiencing this issue or if there was a potential fix that I overlooked when searching. (I do have a couple of non-Plextor drives that behave as they should in CUERipper) Thanks for any help!
Ignoring the green status bar for the moment, how did you determine the CD in question had detectable gaps?
Did you rip a CD with all 4 drives noting that the 2 non-plextor drives detected/stored gaps but for the same CD the 2 plextor drives did not?
Did you try alternate software (e.g. EAC) and note that the same CD in the plextor drive had gaps detected?
I'm asking because zero of my last 15 CD rips had gaps detected. I have 4 new CDs on my desk now and just used EAC to detect gaps using 3 different drives. No gaps detected.
I just want to make sure you don't think that all CDs must have detectable gaps.
I do have a PX-W5224TA and an untested IDE/SATA adapter. I dug out a couple of CDs that have detectable gaps. I'm still looking if I have a 4-pin Molex f/f cable to power the drive (I have a sata jack and 4-pin male Molex power on a front panel).
Thank you for your reply, Korth. I did make sure the disc had detectable gaps, and gap detection on both drives works fine in EAC. I think I have figured out the problem. I know next to nothing in command line, but I was able to use CUERipper console to force the D8 read command and the resulting rip detected indexes properly. Unfortunately, I don't know
You could set 'EAC log style' to 'False' to see what read commands CUERipper 'detected'. (Probably 'BE'). Unfortunately that log doesn't show until after the ripping process and it won't help your issue right now, but it would provide more information to the development/collaborators.
sample
CUERipper v2.2.2 Copyright (C) 2008-2022 Grigory Chudov
Extraction logfile from : 12/22/2022 07:09:49
Used drive : TSSTcorp - CDDVDW SH-224DB
Read offset correction : 6
Read command : BEh, 10h, BEh, 16 blocks at a time
Secure mode : 0
Disk length : 52:54:09
AccurateRip : ok
The PX-W5224TA drive tray mechanism is (broken | jammed | stripped) so I won't be able to test anything here right now.
You are correct, Korth, the GUI log does show the BEh command. Oddly enough, the first disc I grabbed to produce the log actually completed detection successfully, which sent me back to square one for a while. I ran through another 20-30 discs, but only 1 other disc completed index detection successfully. What they had in common was they were relatively short...7 tracks on one; 8 on the other.
I don't know if the Plextor drives are supposed to support BEh in addition to D8, or if CUERipper should be switching to D8 during drive feature detection, but in Console the BEh command does fail with a gap detection error. I have attempted to submit an issue on github regarding my problem. Thanks again for all your help.
@jgreene5 please have a look at this PR, which contains a test build:
[CUERipper] Add setting to force ReadCDCommandhttps://github.com/gchudov/cuetools.net/pull/319