Looking for advice on glacial, on/off reading pattern with secure ripping

[artisan002]

I have both a Plextor PS-891SAF PLUS and a Pioneer BDR-209D. So, a DVD and a BluRay drive respectively. And both of them have a specific problem with Secure and Ultra Secure ripping. It's not really accurate to call it a stutter or even a stammer. The drives basically read in tiny bursts. They'll spin a disc up, read a little bit, then spin down, then spin up, read a little bit, then spin down, ad nauseum. This is so severe, that simply secure ripping even a pristine, new CD will take over 12 hours. This can't possibly be good for the drive motors!

I've deleted the ATAPI driver instances from Device Manager then restarted the machine. It didn't help. I tried a purportedly common registry edit (something I hate doing and deeply distrust), only to find it didn't help either. Both are supposed to be very good optical drives. But, they are functionally worthless on anything other than Burst mode in dBpoweramp.
I'm fairly certain this is some kind of problem within Windows 10, but absolutely cannot find a way to solve this. (I don't really know how to replicate that kind of task in a Linux distro either, so I can't really offer comparison)

Anyone have any advice on the matter? Has anyone else even experienced the same thing or similar? I'll go back through the ASRock BIOS-UEFI settings and see if there's something I've missed there. But, even then, I'm at something of a loss -- I mean, I wouldn't bother everyone else if I weren't. LOL

[mville]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

How is the C2 Error Pointers for Error Detection option configured?

[Spoon]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

It is likely your interface not the drives.

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

"How is the C2 Error Pointers for Error Detection option configured?"

Well, if the drives wouldn't do this for C2 error detection -- spending over 8 hours on a 5-track CD and still not finishing -- I could answer that. :-/

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

It is likely your interface not the drives.

Interface? How do you mean?

This has been an issue since I moved up to Windows 10, btw; seems to have become worse with the May 2019 (v1903) update. Installed from that update on this current install (long story leading up to that)

[Spoon]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

The SATA interface, it might be drivers, or a setting in the bios.

[garym]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

"How is the C2 Error Pointers for Error Detection option configured?"

Well, if the drives wouldn't do this for C2 error detection -- spending over 8 hours on a 5-track CD and still not finishing -- I could answer that. :-/

I don't understand your answer. In your CD Ripper settings, under "secure ripping" options, is the option to "use C2 error detection" ticked or not? If it is ticked, untick it and try ripping a CD. Your symptom is what I see if I try to use C2 error correction setting on a drive that doesn't handle C2 very well (which is many drives these days by the way).

[mville]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

"How is the C2 Error Pointers for Error Detection option configured?"

Well, if the drives wouldn't do this for C2 error detection -- spending over 8 hours on a 5-track CD and still not finishing -- I could answer that. :-/

It is a setting configured in CD Ripper:
CD Ripper Menu > CD Ripper Options > Ripping Method > Secure Settings

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

The SATA interface, it might be drivers, or a setting in the bios.

Kind of what I thought you meant, though my activities have me conditioned to think first of audio interfaces, etc.

But, to your suggestion, I've not found anything in BIOS-UEFI that was out of order. More specifically speaking, I've not found anything I know to be a problem there. I'm still learning the differences and nuances to do with AMD X470 minutia, having been on Intel boxes for several years. I'll go look yet again.
Drivers, on the other hand, are bog standard, according to Plextor, Pioneer, and Windows. So, that leaves registry stuff, which I hate tampering with.

I do wonder about HPET (which I bugged you about once). There was apparently a compatibility/compliance issue with it (an Intel standard Microsoft enforced), that is supposed to be resolved. No BIOS version documentation I can find from ASRock ever mentions it; so, I don't know, and still live by the rule of never tampering with BIOS unless you know you have to. The point being, however, is that I hadn't thought about the possibility of it being specifically necessary for a DVD/Blu-Ray driver. But, it may be. I'll have to go look.

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

It is a setting configured in CD Ripper:
CD Ripper Menu > CD Ripper Options > Ripping Method > Secure Settings

Yes it is. And the drives both do the exact same thing I described at the start of this when running a check for C2 error detection. Hence, why I noted it was taking over 8 hours to run a mere C2 setup scan. I finally gave up when the Plextor alone (the faster of the two) cleared 9 hours reading a 5-track CD that I know has scratches over the first track. I already switched from a full album of 16 or so tracks, down to that CD single on the hope that it might at least wrap up sooner. No such luck.

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

I don't understand your answer. In your CD Ripper settings, under "secure ripping" options, is the option to "use C2 error detection" ticked or not? If it is ticked, untick it and try ripping a CD. Your symptom is what I see if I try to use C2 error correction setting on a drive that doesn't handle C2 very well (which is many drives these days by the way).

Eh. It's in the phrasing, since I hadn't fully quoted the menu button in that reply; I was trying to handle a couple other things at once and was pressed for time.

So.., to explain: I was in the settings for dBpoweramp CD Ripper: Secure Options, setting up the drive. As for the entry labeled "C2 Error Pointers for Error Detection," it's ticked. But, a checked box isn't the issue. It's the fact that when it's running a secure rip, or just following the command to "Detect C2 Support" it acts up and does the bizarre stuff I described at the top of the thread. And the "Technical" info from both drives say they handle C2 error pointers. But, I always check anyway, and stuff like this is why.

I think you're thrown off by mentioning the C2 part. That simply happened because Mville specifically asked about C2 error checking, so I answered him. The relevant action is the same between looking at a drive to rip a disc and looking at a drive to detect C2 pointers -- especially since the latter is a simulation of the former, to simply gain some data. There's also the curiosity that two unrelated drives are behaving in the same stilted, stuttering, stumbling way under equal conditions. That at least indicates, that it's a specific function that seems to be botched. But, I have no way of knowing if it's a communication problem or a control problem. Whatever it is, it's consistent and has something to do with tightly controlled scanning of the media.

Now, I don't particularly think this is an issue specifically with dBpoweramp, but it's very obviously affecting it and this is the only time I run into it. So, I was hoping to see if anyone else could shed light on the matter, since it's hurting the application's ability to do it's job.

[garym]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

I'm asking a much simpler question. In the ripper setup, if you untick the " use C2 error checking" and then try to rip a CD, does it rip much faster? Your answer above indicates that you haven't tried ripping with that setting unticked. In my own case, with some drives, ticking the C2 error checking can cause exactly the problem you describe. Unticking the setting makes all work properly. I"m just asking if you've experimented by trying that option (untick C2).

edit: And there are many drives where the technical info says they should handle C2 error pointers, but in fact they don't properly and cause problems with dbpa ripping.

[mville]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

I think you're thrown off by mentioning the C2 part. That simply happened because Mville specifically asked about C2 error checking, so I answered him.

Actually, it was a simple direct question that you didn't answer.

I was in the settings for dBpoweramp CD Ripper: Secure Options, setting up the drive. As for the entry labeled "C2 Error Pointers for Error Detection," it's ticked. But, a checked box isn't the issue.

You may be correct here, but you do not know for certain whether this is the issue.

It's the fact that when it's running a secure rip, or just following the command to "Detect C2 Support" it acts up and does the bizarre stuff I described at the top of the thread. And the "Technical" info from both drives say they handle C2 error pointers. But, I always check anyway, and stuff like this is why.

Optical drives may report that they handle C2 Error Pointers, but in reality often the firmware does not handle C2 Error Pointers correctly.

As garym has said, just un-tick the C2 Error Pointers option, try ripping a CD and report the results here. If there is still a problem we can move forward, having ruled out C2 Error Pointers.

[artisan002]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

Looking back, I really haven't explained this as well as I'd thought I had. Sorry about that. It certainly wasn't intentional... I've wound up dealing with this odd phenomenon after a perfect storm of circumstances broke my original installation of Windows; and that happened just a couple days before my girlfriend's father died; apart from being as supportive as I can with that, I've been sparring with Focusrite over a pro audio driver issue where they wasted a week before just admitting it was a known problem and they lack a fix for it, but they're fine with me beta testing for them... The point is I'm apparently stretched a bit thinner than I realize, and I need to just reel my bullsh*t in a bit. So, again, sorry for all that.

Now, if I may, I should probably just start this all over and maybe do a more thorough job of explaining...

1. Everything in this rig save for spinning platters and the PC case is new as of last September -- the Blu-Ray drive is even newer. The change was atypically large, in that I've gone from an old Intel E5 Xeon rig to an AMD Ryzen 2700X. Additionally that was going from Windows 7 Pro to Windows 10 Pro. I've not been on AMD since the original Athlon days. So, there are a couple of learning curves at play here, one being particularly steep.
1.1. I only very briefly had the Plextor drive in the old rig before the Xeon motherboard died.
1.2. The point to this bit of detail is to contextualize why I only have so much information to offer before present time. A lot has gone on, and I'm only now really succumbing to my unrelenting curiosity along with frustration over a lack of information/solutions for this phenomenon.

2. All that said, the Plextor drive worked fine in Windows 7, though I truly didn't have occasion to put it through it's paces before everything broke. Plus I still had an Asus drive as my main. (However, it was routinely foiled by DRM, particularly whatever is embedded with newer issue Orbital CDs).
2.1. I know I had C2 error checking turned on when I was running Windows 7. But, saying the Plextor drive didn't act up during this time is pretty worthless considering I just cannot remember if I even used it for secure ripping in lieu of the Asus drive that was still holding on.

3. Shortly after the new system was put together, the old remaining Asus drive failed; thus the Plextor drive became my primary. But, life and superseding computer usage priorities kept me from discovering the start-stop-start behaviour until somewhere around January/February.
3.1. To Garym's suggestion of just turning off C2 error checking, in all honesty, it was never even be a possibility. That is to say it just wasn't an available consideration in my head. My reasoning for this was likely a matter of unthinking reflex in a personal crunch and a simple lack of deeper knowledge in this area. Even across this evening my brain was still convulsively trying to argue, "It's not secure if C2 error checking is off!!!" And I know better than that -- at least when other people's gear is at stake. So, obviously I'm going to give that advice a go, once I'm through typing all this.
3.2. Seriously, I'm mad at myself that I fell into whatever kind of habit that so straightforward an idea simply could not exist. And I've done various tech work -- and was good at it -- for 15 to 20 years! But, I'm also pretty worthless when my own stuff breaks; focus and reason just tend to drift out.

4. Since all that occurred, I added the Pioneer BDR-209D Blu-Ray drive -- partly because the Plextor drive just couldn't deal with Secure Rip in a timely fashion. (Unrelated "fun" fact: Windows doesn't provide default support for playing Blu-Ray movie media. You have to buy an app from them or other vendors.)

5. I can confidently recall having checked both the Plextor and Pioneer drives for C2 support this past winter. At that time they came back with positive C2 support results. But, at that time, checking for C2 support didn't cause the drives to engage in that start-stop-start behaviour; only running Secure Rip did.
5.1. At present, I can't even get through checking for C2 support. I've ended up aborting every check attempt, because it shouldn't take upwards of 9 hours reading a disc when the first track has visible scratches over it.
5.2. The only difference between now and this past winter is the version of Windows.
5.3. Roughly 2.5 weeks ago now, the Windows May 2019 Update broke my original install on this box (it's a dumb, long-ish story amounting to a cautionary tale about hubris and using motherboard based RAID). The install image I'm running on now started current from the May 2019 (v1903) update. And that mandated new I/O rules. So, I'm wondering if the expansion of this problem is connected to that.

6. The issue I'm ultimately hung up on is the fact that both the Pioneer Blu-Ray and Plextor DVD drives have consistently exhibited the exact same start-stop-start behaviour under Secure Rip conditions -- and now even when just checking for C2 support. And when I say that, I mean they do exactly the same pattern right down to the timing. I took the time to check, this past winter. Considering the differences between the two drives, this just seems odd -- especially given Spoon's observations (in a separate thread) about inconsistency in C2 error checking quality and implementation. The odds of them doing the exact same thing seem a bit steep... But, optical drives are not a thing I've ever had to learn much about. So, I'm forced to just run on associated logic instead of any degree of experience.
6.1. Even before things got worse with this newest Windows Update, I've failed to find any credible documentation stating whether or not the Plextor drive has C2 error checking at all. Nobody seems to have answers any better than mere guesswork. I haven't spent as much time/energy looking into the Blu-Ray drive, but have so far found the same lack of certainty. I only know that neither one requires special drivers and they therefore use strictly what Microsoft supplies. Last night I updated the Plextor's firmware to current, but it also didn't help anything. That was a curious affair in it's own right as you can't get the file through Plextor, instead going through Vinpower Digital.
6.2. So, thanks to Garym pressing the idea of just turning C2 error checking off, it makes sense that an absolute lack of support on both drives could make them behave the same -- equal absences should garner equal response. But, again, simply checking for C2 support wasn't a problem before this last Windows update. So, I'm left wondering what that's about, too.
6.3. As such, the situation is now worse than it was a couple months ago. But, even then spotty C2 support might have been the cause, and Microsoft's new I/O specs may have just made it more apparent.
6.4 It's killing me that I can't confirm C2 support with either drive via official documentation. That's mostly what I need to know. The fact that both drives act the same way means either this is just how an absence of C2 support presents itself, or there's a different problem some other place I don't know to look. Either way, this is largely what I'm trying to find out, and my limited knowledge in this area is effectively as tapped out as I am in general. LOL!

7. Of curious note, if I endured the hours and hours of start-stop-start disc scanning (well, at least this past winter, that is) I could get a secure rip out of either drive. It just took as long as 24 straight hours to get through it. And Accurate Rip was okay with the results. I was even able to contend with the DRM'd Orbital CDs, though track 1 would sometimes come out silent.

8. Regarding Spoon's suggestion on interface issues, I did finally uncover some previously overlooked SATA settings in the BIOS-UEFI. I'd missed them before as they were in a sub-directory largely dedicated to RAM overclocking and ECC settings. I've since researched these newfound settings as best I could, made some adjustments, and still not seen any improvement in this particular situation here. But, now that I know I've missed stuff, I'm intent on going back through the whole of the BIOS-UEFI to see if there's still more that I've missed. The only catch is that Ryzen motherboard vendors have put in a lot of settings. This will take a while. LOL!


So, there it is. I started this entry back around 21:00 local time. It's now approaching 3:30. I've been as thorough as I can manage. I don't know what else to put in or rephrase. I hope this is better.

[garym]

Re: Looking for advice on glacial, on/off reading pattern with secure ripping

3.1. To Garym's suggestion of just turning off C2 error checking, in all honesty, it was never even be a possibility. That is to say it just wasn't an available consideration in my head. My reasoning for this was likely a matter of unthinking reflex in a personal crunch and a simple lack of deeper knowledge in this area. Even across this evening my brain was still convulsively trying to argue, "It's not secure if C2 error checking is off!!!" And I know better than that -- at least when other people's gear is at stake. So, obviously I'm going to give that advice a go, once I'm through typing all this.

@artisan002, Thanks for the clarification and mea culpa. Sounds like a hectic time and I know how frustrating it can be when something doesn't work the way it should and you can't get to the bottom of it. You have a lot of moving parts here. I always like to start with simple things in my testing. Thus the recommendation to test WITHOUT "use C2 errors checked". That may not be the problem, but it will be useful to get that simple and obvious explanation out of the way, one way or the other. I look forward to your report of this simple test.