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: CUERipper 2.2.5 Plextor gap detection problem (Read 1879 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUERipper 2.2.5 Plextor gap detection problem

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!

Re: CUERipper 2.2.5 Plextor gap detection problem

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

korth

Re: CUERipper 2.2.5 Plextor gap detection problem

Reply #2
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

Re: CUERipper 2.2.5 Plextor gap detection problem

Reply #3
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
Code: [Select]
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.
korth

Re: CUERipper 2.2.5 Plextor gap detection problem

Reply #4
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.