Forgive me, but how does a larger db increase server load? This clearly is an area that I know nothing about.
Forgive me, but how does a larger db increase server load? This clearly is an area that I know nothing about.
Pretty standard stuff for database performance tuning. See the Microsoft SQLServer page two screens down:
http://technet.microsoft.com/en-us/l.../bb508963.aspx
Hi,
While you are thinking of improving AccurateRip, I have a few suggestions.
I think it would be interesting to tell if the AccurateRip match is composed only of drives of the same type, or if there is a diversity of drive types.
This would help in two way :
1) If I re-rip the same disk on the same drive, I would know if I match my previous result or not.
2) If you assume that drives could have repeatable firmware bug, one would be able to gauge the confidence of his rip with more certitude, as more drive diversity is better.
For example, I can assume that Plextor is pretty popular for ripping. If I rip with a Plextor and I match with confidence 4, if all those 4 other match are also done on Plextor, I get less confidence than if all 4 are on different drives.
One quick way to implement that. For each AR record, you associate an offset field. For the first rip, when the AR record is created, you set the record offset to the offset of the drive that did the rip. For subsequent rip, if the offset is the same, you don't change anything. If the offset of the new rip differ from the record offset, you invalidate the offset. Then, when checking the AR record, I can compare the AR record offset with my own offset.
In a similar vein, you could keep in the record some idea of the diversity of ripping program used and ripping mode used. As we know, some program in some mode may introduce repeatable errors. Again, a greater diversity gives a greater confidence.
Thanks again for AccurateRip, and good luck with the new version...
Jean
What is the current status of AR2? With the revelation that AR is not as 100% fullproof as we thought I think AR2 needs to be a very high priority as well as an option to force secure ripping in dBpoweramp.
I am taking my time, no point in rushing into a decision which you cannot change for 5 years...
Spoon
www.dbpoweramp.com
Nothing in life is 100% perfect....
That is why I'm using a drive that was not in the Accurate Rip database (a B900A) for those 30% of the discs in my collection that are actually in accuraterip. No "false positives" yet.
For those that aren't in accuraterip (or don't match), I'm doing my own rip compares using at least two different drives (three or four different drives if there were re-rips). I don't doubt the existence for these errors as I've read the various threads. However, except for the last track read in/out business, I have not found a repeatable error (after 1500 discs), when dbpoweramp returns "secure". Maybe I will in the next few thousand.
I will be curious after AR2 gets implemented, what the incidence of any "false positives" actually was in AR1. "False negatives" don't bother me since most of my collection isn't in accurate rip. Different concerns of course for a commercial ripping business but these may be impossible to meet from the perspective of validated statistical process control.
Phil
Trivial. Setting -> Secure Setting. You can disable the check for AccurateRip. In that case, dBpoweramp will do the secure ripping.
But you will have to ask yourself if that is enough diversity. You are still using the same drive and same reading method. To me, that's not enough diversity.
I personally agree with Spoon, he should consider all aspect of the issue and not move too fast.
Jean
I dont want to disable AR, but nor do I want to rely on it as much as it currently is.
An accurate match in AR, plus a matching re-read on no C2 errors would be good enough, I think.
The B900A uses a Panasonic chipset. Many LG drive do use a Panasonic chipset. I think the ripping behaviour of your drive would be very close to other drive based on the Panasonic chipset, if not exactly the same. When Panasonic do a new chipset, they just cut'n'paste from the old chipset.
I personally would not worry so much about this AccurateRip "flaw". Most errors are clustered and affect both channels, so very unlikely to not be detected. And I would use a cheaper drive for ripping ;-)
Are they different chipset ? If I remember, you do, so you should be good. Note that when ripping on the second drive, you could use only a single pass.
My experience is that some of the errors did not happen the way I was expected. I was expecting only random errors, I've seen random errors on scratched disks, but I'm also seeing consistent errors on pristine CDs. Those errors are actually harder to detect, and I feel most people would overlook them.
Actually, I'm much more interested in how AR2 will address the new type of consistent errors that seems to be reported. This, I believe, is more crucial.
Have fun...
Jean
Anyway, I believe that re-reading on the same drive using the same method is totally useless to detect some class of consistent errors (not enough diversity). You'd be much better off to do your second pass on another drive with the different chipset. Or to use EAC in secure mode for the second pass (not as good IMHO).
So, you leave AR on. If the confidence is too low, just put the CD in the other drive and try again. dBamp will show if the CRC matches or not (or check the logs). This is effectively what I do with EAC.
Of course, now the trouble is that you have to find two good ripping drives instead of only one ;-)
Jean
I've tried to find that elusive diversity and have looked up the chipsets (as well as opinions that offsets matter as much or more). So I've got my primary two models which are common Plextor branded Drives that are definitely different chipsets:
PX750/760
PX230
I do only use a single pass for confirmation and have three varieties of confirming drives: the B900, various Samsungs (same chipsets I believe), and the PX-40TS.
As far as I can, tell this gives me five drives that actually are different, all of which are at least decent. Any other specific suggestions on drives would be welcome.
Phil
Phil
Will AR ID and Disc TOC be enough to look up current rips in AR2? Can a utility to confirm already ripped files be a priority with AR2?
Yes
Spoon
www.dbpoweramp.com
Just wondering were AR2 development stands?
Copyright © illustrate 2024, All rights reserved