Recommended Ultra Secure Ripping Settings?

[Spoon]

Re: Recommended Ultra Secure Ripping Settings?

With dBpoweramp you use c2 pointers if supported, unless it is very obvious they are not working well (for example on a unscratched disc it gives lots of frames to re-rip, such as 2000 and this goes away if c2 is disabled).

[Sapagrino]

Re: Recommended Ultra Secure Ripping Settings?

I would like to know the answer to this as well?

[sredmyer]

Re: Recommended Ultra Secure Ripping Settings?

2 passes for C2 pointer which are supported well should be enough.

I see alot of comments here regarding how well a drive does (or does not) support C2 pointers. Comments that seem to indicate that for a drive that supports C2 pointers well, Batch Ripper/CD Ripper should be configured to use them. On the other hand those same comments seem to indicate that if the drive does not support C2 well (or at all) they should not be used. I also know that the configuration allows us to test if our drive is reporting C2 pointers.

Question is, how do we know just how well C2 pointers are implemented by our drive. To further confuse this issue (for me anyway) is the fact that although the drive may support C2 pointers well (according to the both the manufactures documentation and Spoon), dbp may say it does not. I understand that this is usually due, not the drive, but the IDE/firewire or IDE/USB bridge being used. So a drive that supports C2 pointer very well (ie. an older "real" plextor) attached to a USB/IDE or Firewire/IDE bridge which does not may result in sub-standard support of the C2 pointers.

So again I ask the question how do we know how well our particular setup (drive and any interface hardware) handles C2 pointers. Then once we know that, what level of support for C2 is sufficent to make them worthwhile to use and below what level of support do they cause more harm than good?

[Spoon]

Re: Recommended Ultra Secure Ripping Settings?

2 passes for C2 pointer which are supported well should be enough.

[twostar]

Re: Recommended Ultra Secure Ripping Settings?

Hi Everyone. Just a quick question. (I hope.)

This guide recommends the ultra secure settings to be:

If your drive supports C2 pointers, set as Minimum Ultra Passes: 1 Maximum Ultra Passes: 2 End After Clean Passes: 1

But the help file recommends:

* Drive Supports c2 error pointers well enable Ultra Secure with Minimum 1, Maximum 6 and End after 1.
* Drive Supports c2, but badly enable Ultra Secure with Minimum 2, Maximum 6 and End after 2.
* Drive does not support c2 enable Ultra Secure with Minimum 3, Maximum 6 and End after 2.

Which one should I follow?

My drive by the way is: Drive: TSSTcorp - CDDVDW TS-L632H (68 users): 495 Accurate Submissions 4 InAccurate Submissions 99.1984 % Percentage Accuracy.

[chileboy]

Re: Recommended Ultra Secure Ripping Settings?

If you used secure rip and it says the first track is inaccurate it is. The case above is when a track is listed as SECURE but all other tracks are accurate with a high degree. That makes me believe that the track is NOT secure.

I meant that, as I recalled, everything ripped as Secure, but only the one track showed as Inaccurate (according to AR), which is what I took that to mean.

I was apparently wrong anyway, I went and re-ripped the CD and it was both Accurate and Secure. Sorry.

- Mark

[EliC]

Re: Recommended Ultra Secure Ripping Settings?

If you used secure rip and it says the first track is inaccurate it is. The case above is when a track is listed as SECURE but all other tracks are accurate with a high degree. That makes me believe that the track is NOT secure.

[chileboy]

Re: Recommended Ultra Secure Ripping Settings?

I have seen weird pressings where 10 tracks match AR and one does not, so these would be incorrectly flagged as having errors when they do not.

This happened to me with James Blunt - Back to Bedlam. The first track rips as Inaccurate, every other track is fine. This with 50+ Confidence on all tracks.

I was guessing that it was due to the fact that there is a single occurrence of a certain four-letter word in the first track, which is over-dubbed on the non-explicit pressing. Not sure how AR handles that sort of thing, where folks are ripping two nearly-identical versions of the same CD.

- Mark

[EliC]

Re: Recommended Ultra Secure Ripping Settings?

I would just like to see them flagged as possibly insecure or something that indicates a higher level of suspicion, especially if there were C2 errors on the track in question, or not every re-rip matched, ect...

[Spoon]

Re: Recommended Ultra Secure Ripping Settings?

I have seen weird pressings where 10 tracks match AR and one does not, so these would be incorrectly flagged as having errors when they do not.

[EliC]

Re: Recommended Ultra Secure Ripping Settings?

I would think that there should be some sort of algorithm that would be reasonable. The more songs with AR matches, and the higher the number of matches for each of these, the less likely that any songs with just secure are actually secure. I would imagine that the number of C2 errors occurring in these "secure" tracks could also be considered.

[bhoar]

Re: Recommended Ultra Secure Ripping Settings?

Either way, if 9/10 songs match AR with 5+ matches, and 1 song is listed as secure, I seriously doubt that song is secure, and would like to have the option to flag it that way, especially when using the batch ripper and not watching every rip myself.

If the AR matches on the other songs are over 2, I agree.

If the AR matches on the other songs are only 1 (maybe even 2, if the original computer equipment submitted it twice, say after a window reinstall) and one track is listed as secure, then the original submitter might have a badly configured cd ripper and told it to trust dodgy equipment more than the operator should have. In which case, maybe your track was actually accurate...

Can something like the above happen?

-brendan

[EliC]

Re: Recommended Ultra Secure Ripping Settings?

A possible additional factor would be that you have either configured the cd ripper with incorrect secure-related settings for your drive (fua, cache size, c2 support) or the drive's implementation of these is not reliable and yet you turned on the features (perhaps the device passed the feature tests?). That could potentially result in a mix of AR and "Secure" results, when really the "secure" results were incorrect.

-brendan

Either way, if 9/10 songs match AR with 5+ matches, and 1 song is listed as secure, I seriously doubt that song is secure, and would like to have the option to flag it that way, especially when using the batch ripper and not watching every rip myself.

[Spoon]

Re: Recommended Ultra Secure Ripping Settings?

A track can be labelled as secure and still have errors, depends on drive (c2 helps reduce this), it is called a consistant error, which do happen.

>The issue I have is finding out how inaccurate a particular rip is. ....And at what
> level do noticeable errors such as pops and clicks occur?

Many drives will interpolate errors, so if there was an error it is silenced out, you will never hear a pop, but you might hear silence on a badly damged cd.

If you enable c2, that will catch most errors, a badly damaged cd is going to take a long time to rip (in comparison to a lightly damged cd), that would be the basis for determining quality.

[bhoar]

Re: Recommended Ultra Secure Ripping Settings?

The only time I really do not trust this is if the rest of the disc is listed as accurate with AR>1. I wish spoon would add a bit of extra power in the decision making tree. While accuraterip is done on a track basis, it does not make any sense that every other track on a CD would have an AR confidence of 5 and one track would be secure. Note, I have never had this problem with dbpoweramp, but have with EAC.

A possible additional factor would be that you have either configured the cd ripper with incorrect secure-related settings for your drive (fua, cache size, c2 support) or the drive's implementation of these is not reliable and yet you turned on the features (perhaps the device passed the feature tests?). That could potentially result in a mix of AR and "Secure" results, when really the "secure" results were incorrect.

(is that a good description of the issue, spoon?)

-brendan