Ripping Fails On First Pass

[Porcus]

Re: Ripping Fails On First Pass

P.S. I am getting REALLY fed up with this.

No kidding ...

OK, I'll give you a chance:

1. dBp usually works. EAC usually works. My drives usually work. My CDs usually work. But I have ripped thousands of CDs, and sometimes, somewhere, things go wrong.
2. Sometimes, the software is less than perfect. Sometimes, the firmware of the drive is less than perfect. Sometimes the CD has a pressing error even if it is new.
3. CD drives need to give a result you can listen to, and will smoothen out their errors to minimize audible effects. Secure rippers are trying to get as much information out of the CD as possible. They *want* to see errors.
4. If there is a glitch in the drive's firmware, some "secure" ripping software might provoke it and others might not -- depending on what instructions they give to the drive. Who is best -- the one which finds an error or the one which does not? Depends on whether there really is an error on the CD.

Myself I have two drives and two ripping programs -- dBp (yes I am a paying customer, no I am not Spoon's cousin) and EAC. I use a second-best (in terms of secureness) solution approximately 98% of the time because I can automate it. "Second-best" in the sense that it detects less errors than the "best" would have done, and the price I pay is that I do not get issues like you get. But if something goes wrong, I try the other drive, and/or the other program.

Oh, if you did read this long: have you tried to turn on or off the option for reading the lead-out or whatever it is called, in dBp and EAC?

[BruceH]

Re: Preventing Secure Rip Aborts

No. My specialty is in automating robots. I do have an interest in the batch ripper doing well as I sell some add-on drivers directly to folks (I can count them all on one hand so far).

The reason I'm somewhat experienced in the C2 logic and have some knowledge of this is that I have, in the past, helped zero in on a bug in the product when dealing with firewire drives. Yes, indeed, the product had bugs in the past, has bugs now and will have them in the future. That's software.

Because of the firewire issue in the past, I have studied the T10 MMC-3 spec in depth, which describes how to obtain C2 flag data from modern drives using new flags on two standard read commands. Spoon did email me (once) a very short snippet of code related to how large reads were split in half when I was trying to figure out what was going wrong.

I used his code snippet as a model for creation of some tests with the plscsi ata/scsi command-line tool and created log files which I later submitted to spoon to show evidence for my theory on why the original code (now fixed) was leading to the problems with firewire, due to firewire controllers requiring more strict buffer alignment than all other interface types.

So let me be clear: I have never completely ruled out that there's a bug in spoon's code and if I said that unconditionally, I offer an apology and I should not have. What I should have be more explicit in saying is that, in my opinion, a bug in the drive's firmware or interface bridge firmware is a more likely culprit with the symptoms you have described.

If it is the drive (or drive + interface...this is a USB device, right?), that doesn't mean spoon can't work around the problem. This wouldn't be the only drive out there that has some strange behavior of one kind or another, though.

-brendan

PS - the reason I was so focused on the firewire issue was due to having collected about 30 cd robots that all came with firewire interfaces...and I wanted C2 to work correctly with them. It was frustrating that it did not, so really, I understand how you feel... x30 or more.

Brendan,

Your statement of the situation here seems much more reasonable...particularly in light of your having experienced a similar situation. My apologies for the unreasonable accusations on my part, as I re-read my posts. I am just very frustrated with what appears to me to be a stonewall.

Your suggestion that Spoon could find a work-around is what I have been trying to get across; but he does not seem interested in pursuing such path. Your suggestion that dbpa may be handling only one of the two methods of C2 handling sounds like a logical possibility. If that is the case, then the question is what percentage of the drives out there utilize the method unsupported by dbpa. If the percentage is tiny, then I agree with Spoon's argument (below) about not tweaking for a few non-conforming drives. If the percentage is substantial (as in 10% or more, for example) then I believe that failing to disclose such non-support (if the hypothesis is even correct) is misleading and would not be remedied by a 21-day trial period.

Bruce

[BruceH]

Re: Ripping Fails On First Pass

Spoon,

Could you please answer my query at post #3, above?

Could you please elaborate on the second block of the secure mode ripping block diagram in the detailed web help page? That is, I need to know to what degree de-selecting C2 support increases the likelihood of errors getting through during an Ultra Pass. I assume that the comparison operations portion of Ultra (comparing pass 1 results to results from subsequent Ultra passes) continue to work in the absence of C2, right? I am asking this for obvious reasons, given my problems with C2 operations with this particular USB drive.

Thanks,
Bruce

[BruceH]

Re: Ripping Fails On First Pass

No kidding ...


OK, I'll give you a chance:

1. dBp usually works. EAC usually works. My drives usually work. My CDs usually work. But I have ripped thousands of CDs, and sometimes, somewhere, things go wrong.
2. Sometimes, the software is less than perfect. Sometimes, the firmware of the drive is less than perfect. Sometimes the CD has a pressing error even if it is new.
3. CD drives need to give a result you can listen to, and will smoothen out their errors to minimize audible effects. Secure rippers are trying to get as much information out of the CD as possible. They *want* to see errors.
4. If there is a glitch in the drive's firmware, some "secure" ripping software might provoke it and others might not -- depending on what instructions they give to the drive. Who is best -- the one which finds an error or the one which does not? Depends on whether there really is an error on the CD.

Myself I have two drives and two ripping programs -- dBp (yes I am a paying customer, no I am not Spoon's cousin) and EAC. I use a second-best (in terms of secureness) solution approximately 98% of the time because I can automate it. "Second-best" in the sense that it detects less errors than the "best" would have done, and the price I pay is that I do not get issues like you get. But if something goes wrong, I try the other drive, and/or the other program.

Oh, if you did read this long: have you tried to turn on or off the option for reading the lead-out or whatever it is called, in dBp and EAC?

No luck with lead-in/lead-out, Porcus; but thank you for the suggestion. I will probably just turn off C2 to rip tracks that exhibit the C2 problem, if Spoon will tell me the effect of doing so on accuracy of the rip. I can also use the 1/2 drive in my laptop to rip the problematic tracks; but disabling C2 is easier and probably better for my laptop.

Bruce

[Spoon]

Re: Ripping Fails On First Pass

If the disc is in AccurateRip and verfiies as such then it makes no difference if C2 is used or not. Obvously having c2 is better than not having it (assuming it works correctly). Not having c2 increases the risk of a consistant error getting through (an error which repeats exactly each read).

As for % of drives which exhibit this problem - this is the first time I have heard of a drive which fails as yours does.

[BruceH]

Re: Ripping Fails On First Pass

If the disc is in AccurateRip and verfiies as such then it makes no difference if C2 is used or not. Obvously having c2 is better than not having it (assuming it works correctly). Not having c2 increases the risk of a consistant error getting through (an error which repeats exactly each read).

As for % of drives which exhibit this problem - this is the first time I have heard of a drive which fails as yours does.

Ok; I understand. I will use the laptop drive to rip the failed tracks because the likelihood of a consistent error is high for a scratched disk.

Thanks Spoon; good luck with the product.

Bruce