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: Secure Ripper Test (part 2 concise results) (Read 145749 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Secure Ripper Test (part 2 concise results)

Reply #75
@jarsonic

It has to be lowercase for infile and outfile, ie:

-if [infile] -of [outfile]


And spoon, what would the correct parameter be for my oggenc2.exe?  (See my post above)

Secure Ripper Test (part 2 concise results)

Reply #76
even when i use [infile] and [outfile], i'm only getting files with names like this:

Andrew Peterson - Behold the Lamb of God; The True Tall Tale of the Coming of Christ - 01 - Gather 'Round. Ye Children. Come.ext

what's with the .ext extension?  it's a zero-byte file, too.  where do i specify the extension for the file?  should it be, like, (for nero aac) [outfile].mp4    ?

Secure Ripper Test (part 2 concise results)

Reply #77
Not having oggenc2.exe on this system I cannot look it up, but perhaps:

-Q -q5.0 - -o [outfile]

See the help file for CLI Encoder, there is a file you have to edit to set the extension.

 

Secure Ripper Test (part 2 concise results)

Reply #78
If every track is inaccurate (as your log shows) and the CD is not overly scratched then it is pretty certain the CD being reported as Confidence of 2 is a different pressing to yours, so AccurateRip can be dis-counted in this instance (although in the log it is supposed to suggest different pressing, but is not I will look into that).


How about a "try second drive" option/feature for an internal AR, so that when errors are not detected but no tracks are matching the ripper would suggest the user (if a 2nd drive is detected and option is active) to try the disc in a second drive.

Secure Ripper Test (part 2 concise results)

Reply #79


If every track is inaccurate (as your log shows) and the CD is not overly scratched then it is pretty certain the CD being reported as Confidence of 2 is a different pressing to yours, so AccurateRip can be dis-counted in this instance (although in the log it is supposed to suggest different pressing, but is not I will look into that).


How about a "try second drive" option/feature for an internal AR, so that when errors are not detected but no tracks are matching the ripper would suggest the user (if a 2nd drive is detected and option is active) to try the disc in a second drive.



i doubt that is worth the effort because i know with my drives, if it doesn't read on my good one it is definitely not reading on the worse one.  And you usually can find out which is worst.

Secure Ripper Test (part 2 concise results)

Reply #80
I found a new(er) drive to use for ripping, so far it rips as good using burst, as my other drives do with secure mode.

But alas it doesn't support C2 (BenQ DW1620)

So I understood the settings for C2 drives, but now I'm wondering again.

Will 34 re-reads get me the best possible rip?

I understand the risk of errors increasing with the # of rereads, so is 34 the highest possibility that's still safe?

I've been using 6 minumun passes, finish after 3, and 18 max, just to be safe

Secure Ripper Test (part 2 concise results)

Reply #81
Depends on the drive, I have tested drives (with c2 off) that could happily go to 50. Obviously with c2 you can go much higher (x20) and get better results from that.

Secure Ripper Test (part 2 concise results)

Reply #82
I understand the risk of errors increasing with the # of rereads, so is 34 the highest possibility that's still safe?

No, the risk of errors does not necessarily increase with the number of re-reads,
it depends on the disc. Therefore there's not one particular number of re-reads
values which will give best results on all discs.

Secure Ripper Test (part 2 concise results)

Reply #83
>No, the risk of errors does not necessarily increase with the number of re-reads

You could re-phrase it to "the risk of errors in a frame matching across re-rips is proportional to the number of re-reads done", for example 1,000,000 re-reads would have a match even if that match was an error **

** when c2 is not used.

That is where c2 can be a real help, you can disregard the errors with a certainty so they cannot be become a false match, today I re-ran the test on a new NEC DVD-RW ND-2510a (rather than the old tired 2510a), this drive shows more than any other drive tested the need for c2 (and the phenomenal results when using c2 with high re-reads, this drive can only manage to rip 1 track without error in burst, and all but one with c2):

http://www.dbpoweramp.com/secure-ripper.htm

I have come to regard c2 as the difference as driving at night with the lights on, or lights off, without them on you are just guessing. Ironically, all the talk for EAC is to disable c2, in all my tests with EAC, c2 on gave better results than off...

Secure Ripper Test (part 2 concise results)

Reply #84
Well, turns out the BENQ is worse then my LG drive

If only I could get my usb enclosure to work with R12

The only time I have trouble with it is when I enable C2

C2 works fine in EAC and all other software, but with R12 I get a "Buffer too big" error using ASPI. SCSI PT gives me a vauge cannot read disk error.

I know you mentioned a bad chipset, and I managed to find out today it's a NEC chipset in my enclosure.

I'm tempted to buy another enclosure, but I want to see if anyone else is having trouble w/ USB and R12, or any other ideas.

Secure Ripper Test (part 2 concise results)

Reply #85
I remember when I was running tests (I had a usb enclosure also) that all advanced calls (such as FUA disable) did no work on the USB enclosure. The only certaintiy would be a drive built specifically for USB, ie one of the USB plextors.

Secure Ripper Test (part 2 concise results)

Reply #86
If I can find a cheap USB enclosure somewhere, I'll try it out. I'd like to have 2 anyways.

I also have weird issues accessing cds in Foobar, that no one else apparently has, so I won't rule out it being a piece of junk enclosure.

Secure Ripper Test (part 2 concise results)

Reply #87
Well the issue I'm having doesn't really have to do with the ripping stage, it's the program in general

it's a Lite-On LTR-24102B in a USB enclosure, my interal LG drive works fine

using scsi pass through, it'll give me an error about not being able to read the cd when i rip in burst mode. When I try to detect the cache for secure mode, it finds the cache, but when it tries to test the size of the cash it keeps saying there's no cd in the drive.

Now if i switch to Nero ASPI, it rips in burst mode fine, but once again, when I try to detect the cache (I know this drive caches for a fact) it sees the cache but the program completely locks up upon detecing the cache size.

I have the same problem with same Lite-On drive. I have two Lite-On drives on my computer using IDE bus. SHW-1635S (DVD-RW) drive works well, but LTR-24102B (CD-RW with latest firmware) does not. Sympton is just like you described.
I have removed the daemon-tools SPTD driver and I've been using alpha6 version of the DBPower AMP CD Ripper.

Secure Ripper Test (part 2 concise results)

Reply #88
I've decided the Lite-On is just a piece of junk

Even in an actual desktop w/ a fresh install of Win2k3, it'll lock up when detecting the exact cache size, exactly the same way as it does in the USB enclosure, no matter what is used (Cache Explorer, Feurio, dMC R12)

I did manage to figure out the size using Feurio! and a few reboots, seems to be 863KB.

The drive also attains a 5/5 rating for FUA support, but it hardly works, the drive just locks up after a few minutes with FUA enabled.

Secure Ripper Test (part 2 concise results)

Reply #89
You could re-phrase it to "the risk of errors in a frame matching across re-rips is proportional to the number of re-reads done", for example 1,000,000 re-reads would have a match even if that match was an error **

The *number* of possible matching errors increase with re-reads, not the
risk of error (i.e. not the probability of getting a bad match as final rip).
Indeed, if the number of possible wrong matches increases with re-reads,
so does the number of possible good matches. Which one will stop the
algorithm first depends on the probability of consistent wrong values,
which itself depends on the disc (and possibly on the drive).

Secure Ripper Test (part 2 concise results)

Reply #90
I've decided the Lite-On is just a piece of junk

Even in an actual desktop w/ a fresh install of Win2k3, it'll lock up when detecting the exact cache size, exactly the same way as it does in the USB enclosure, no matter what is used (Cache Explorer, Feurio, dMC R12)

I did manage to figure out the size using Feurio! and a few reboots, seems to be 863KB.

The drive also attains a 5/5 rating for FUA support, but it hardly works, the drive just locks up after a few minutes with FUA enabled.

Well the particulal Lite-On drive is old but it isn't so bad, although it doesn't work with dBpowerAMP CD Ripper (Alpha). It work's very well with EAC so it also might be a bug in dBpowerAMP. My newer Lite-On drive work's without problem in dBpAMP though.

Secure Ripper Test (part 2 concise results)

Reply #91

I've decided the Lite-On is just a piece of junk

Even in an actual desktop w/ a fresh install of Win2k3, it'll lock up when detecting the exact cache size, exactly the same way as it does in the USB enclosure, no matter what is used (Cache Explorer, Feurio, dMC R12)

I did manage to figure out the size using Feurio! and a few reboots, seems to be 863KB.

The drive also attains a 5/5 rating for FUA support, but it hardly works, the drive just locks up after a few minutes with FUA enabled.

Well the particulal Lite-On drive is old but it isn't so bad, although it doesn't work with dBpowerAMP CD Ripper (Alpha). It work's very well with EAC so it also might be a bug in dBpowerAMP. My newer Lite-On drive work's without problem in dBpAMP though.


The drive is rather good for it's age, but too slow for my tastes with it's cache.

It works fine for me in dMC R12, you just have to manually enter the cache size, the detection doesn't work.

Secure Ripper Test (part 2 concise results)

Reply #92
There is no reason why the cache detection should freeze or require re-boots (all it does is normal drive reads and times the time taken, no special calls, no c2, nothing).

Secure Ripper Test (part 2 concise results)

Reply #93
There is no reason why the cache detection should freeze or require re-boots (all it does is normal drive reads and times the time taken, no special calls, no c2, nothing).

Fortunately it doesn't require re-boots. Do you know if EAC does the same cache detection or does it differ?

Secure Ripper Test (part 2 concise results)

Reply #94
If I get the plexor 230A (any reason i shouldn't? or better for that price range?) will it give that error the same as my qsi 242 does now? that the cd can't be read.  I understand if it finds the errors, and i want it to if there are there but shouldn't it still be able to read all cd's???


I had a Plextor PX-230A and it is not a "real" Plextor, it is a re-badged version.

Secure Ripper Test (part 2 concise results)

Reply #95
and ironically it is one of, if not the best Plextor at ripping CDs (not talking features, just ripping ability), also one of the cheapest.

Secure Ripper Test (part 2 concise results)

Reply #96
I just tried to run R12 on my old PC (Celeron (Coppermine) 566Mhz running Win98se) and the CD-Ripper crashes at startup (program performed an illegal operation). R11.5 works fine.

Secure Ripper Test (part 2 concise results)

Reply #97
We have not done any testing on Win98, it should be compatible but until we are ready for release then every operating system will be tested against it.