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: "dBpoweramp. Its as secure as EAC" (Read 7678 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"dBpoweramp. Its as secure as EAC"

Quote from: Eli on
Its as secure as EAC

Not necessarily.

FWIW, I'm still waiting for a response from this guy from all the previous times he's made this sweeping and provably untrue claim.

"dBpoweramp. Its as secure as EAC"

Reply #1 –
Quote from: Eli on
I you want the security of ripping with EAC, then no, no one has created an all in one, especially not an easy to use one.

My recs
Check out dBpoweramp. Its as secure as EAC and gets better album art. IMHO, its much more user friendly then EAC.
Check out MediaMonkey for managing your music and putting it on your MP3 player.


When you say "security" of ripping with EAC, do you mean accuracy?  I think of security as meaning viruses and stuff.  I will check out mediamonkey, I just hate having to install the stuff only to find out it's worse than WMP.  I hope they have good screenshots and user guide w/o having to install it.

Thanks!

"dBpoweramp. Its as secure as EAC"

Reply #3 –
FWIW - For what it's worth

"dBpoweramp. Its as secure as EAC"

Reply #4 –
While a cursory search will show that Eli misses very few opportunities to plug dBpoweramp, his wording in this latest instance has not been as blatantly incorrect as it has been in the past.

The fact of the matter is that with drives that report C2 error information, the reference version of dBpoweramp has a better chance of getting accurate rips with discs that produce errors than EAC.  With drives that don't report C2 error information, however, dBpoweramp can much more easily be (mis)configured to allow errant data to be passed off as secure than EAC.  Regardless of the number of re-reads allowed, dBpoweramp requires only 10 matches for each sector re-read to deem the track secure.  In the case of EAC, at least half the data of any given set of 16 re-reads must match in order for the the track to be deemed ok.  Whether you allow EAC to perform only 16 re-reads or 80 re-reads, the minimum number of matches will still remain at roughly about half when a track is labeled ok.  If you allow dBpoweramp to perform 80 re-reads, the number of matches required to deem a rip secure drops to 12.5%.  Furthermore, dBpoweramp re-reads errors one sector at a time.  In the case of EAC, re-reads are performed over 27 sectors.  While my intuition for probability is not as good as others around here, I believe that if more than one sector in the group gives errors, it is likely that the amount re-reads that that result in match for any individual sector in the group will be higher than 50% in order to EAC to report the whole set as ok.  Now beyond C2 pointers, dBpoweramp does have some extra coding to attempt to spot consistent errors, though it has not been demonstrated to work with a wide variety of drives that are currently available on the market today.  So is this "every bit as secure as EAC" as has often been claimed? Of course it isn't. 

What does security mean?
I'm not sure there's any official definition that will work equally well with all ripping programs, but I'll make an attempt.  Some people feel that it is synonymous with accuracy; it is not.  Rather, it is simply a reasonable assurance that the program has made an effort to provide data that is error-free.  However. it is not a guarantee that the program has actually provided data that is error-free.

"dBpoweramp. Its as secure as EAC"

Reply #5 –
Quote from: greynol on
While a cursory search will show that Eli misses very few opportunities to plug dBpoweramp, his wording in this latest instance has not been as blatantly incorrect as it has been in the past.

The fact of the matter is that with drives that report C2 error information, the reference version of dBpoweramp has a better chance of getting accurate rips with discs that produce errors than EAC.  With drives that don't report C2 error information, however, dBpoweramp can much more easily be (mis)configured to allow errant data to be passed off as secure than EAC.  Regardless of the number of re-reads allowed, dBpoweramp requires only 10 matches for each sector re-read to deem the track secure.  In the case of EAC, at least half the data of any given set of 16 re-reads must match in order for the the track to be deemed ok.  Whether you allow EAC to perform only 16 re-reads or 80 re-reads, the minimum number of matches will still remain at roughly about half when a track is labeled ok.  If you allow dBpoweramp to perform 80 re-reads, the number of matches required to deem a rip secure drops to 12.5%.  Furthermore, dBpoweramp re-reads errors one sector at a time.  In the case of EAC, re-reads are performed over 27 sectors.  While my intuition for probability is not as good as others around here, I believe that if more than one sector in the group gives errors, it is likely that the amount re-reads that that result in match for any individual sector in the group will be higher than 50% in order to EAC to report the whole set as ok.  Now beyond C2 pointers, dBpoweramp does have some extra coding to attempt to spot consistent errors, though it has not been demonstrated to work with a wide variety of drives that are currently available on the market today.  So is this "every bit as secure as EAC" as has often been claimed? Of course it isn't.


[PS as this is getting technical, it is probably best splitting to a 2nd post]

I stand by the implemention of re-reads in dBpoweramp, for R13 there was the option of changing the code (it would be trivial to do a half match in 12 frames), but IMHO this leads to less recoverability - in that it was observed on damaged cds frames could recover sporadically, getting 50% recover rate on a damaged CD is quite an assumption. There is a trade off with consistent errors, but again EAC will re-read the same 27 sector block again and again, we shift the block being read around its starting frame - giving the drive again potentially more chance of recovering (it was proven on my tests, but see below for believability). On modern drives interpolation and its subsequent leading to consistent errors is a major issue when AccurateRip is not there to help, if Accurate rip is there to help then dBpoweramp will out recover EAC on basis that dBpoweramp will try different lookups whilst ripping, potentially querying AccurateRip 200 times for one track, this is immune to consistent errors, where as 50% recover rate is not immune to consistent errors being present more than 50% of the time. Our ripping strategy is all based around AccurateRip and maximum recoverability of the data.

>So is this "every bit as secure as EAC" as has often been claimed? Of course it isn't. 

I do not necessarily agree with Eli's promotional methods, but you as a moderator are not putting your own claims (that EAC is more secure with non-c2) to the same standards. Until a real life test was done (10 drives - a broad spectrum of popular drives, x100 damaged discs across all 10 drives **) there is nothing to back up either claims (I have done that test, during the year of development for R12, but I am biased so there is no reason for anyone to believe me). Theories are just that, theories.

** the likely out come would be:
  c2 pointers: no contest dbpoweramp recovers more discs
  non-c2 and disc in accurate rip: with at least 4 passes dbpoweramp would recover from consistent errors present 75% or more were as eac would be at 50%
  non-c2 and disc not in accurate rip: dbpoweramp would suffer more from consistent errors (if the drive was suffering from this)

As I have mentioned there are 3 levels to detecting errors: Accurate rip, c2 pointers then re-reading, base all assumptions only on re-reading is flawed imho.



"dBpoweramp. Its as secure as EAC"

Reply #6 –
Quote from: greynol on
FWIW, I'm still waiting for a response from this guy from all the previous times he's made this sweeping and provably untrue claim.
.
.
.
While a cursory search will show that Eli misses very few opportunities to plug dBpoweramp, his wording in this latest instance has not been as blatantly incorrect as it has been in the past.


I am not aware of any other instances where you have questioned/challenged my claims about EAC.

While everyone else plugs EAC. Yes, you can configure dBpoweramp to be insecure in its ripping. That doesn't make dBpoweramp insecure. As you probably know I was a huge fan of EAC. I wrote an extensive guide for EAC. Then came dBpoweramp with secure ripping. I gave it a fair try and it won me over. IMHO it beats EAC hands down. In my tests it securely ripped many discs EAC couldn't and is much faster. In addition it is very actively developed. Spoon, dBpoweramp's developer is an active member here (anyone ever seen Andre?), and he (spoon) is very responsive both here and on his forums. dBpoweramp is not perfect. It still needs gap detection, cue sheet implementation needs to be finished and perfectmeta could use some more tweaking, but IMHO, its the best cd ripper out there hands down.

So yes, when someone asks for advice on which CD ripper to use I have no problem suggesting dBpoweramp.

"dBpoweramp. Its as secure as EAC"

Reply #7 –
Quote from: spoon on
(it would be trivial to do a half match in 12 frames), but IMHO this leads to less recoverability
There's absolutely no reason why one couldn't alter the interface to make the ripper more selective about what it deems secure and continue to allow it to recover the most consistent data.

Quote from: spoon on
- in that it was observed on damaged cds frames could recover sporadically, getting 50% recover rate on a damaged CD is quite an assumption.
Yet EAC has worked this way for years.

Quote from: spoon on
There is a trade off with consistent errors, but again EAC will re-read the same 27 sector block again and again, we shift the block being read around its starting frame - giving the drive again potentially more chance of recovering (it was proven on my tests, but see below for believability).
I don't see any proof, but are you suggesting that shifing the starting address around a frame reduces the risk that your program will pass off errant data as secure and that this will always make your program at least as judicious as EAC if not more so when it comes to labeling data as secure as Eli has been claiming?

Quote from: spoon on
dBpoweramp will try different lookups whilst ripping, potentially querying AccurateRip 200 times for one track,
So if a track has more than one block with error your program will step through each combination?  What about tracks for which AR data is not present?

Quote from: spoon on
you as a moderator are not putting your own claims (that EAC is more secure with non-c2) to the same standards
Straw man!  Calling a guy out for making a sweeping generalization that can easily be shown as false (it only takes one example) is not the same as claiming the opposite.  Nice try, though.

Quote from: spoon on
non-c2 and disc not in accurate rip: dbpoweramp would suffer more from consistent errors (if the drive was suffering from this)
You've validated the very reason why I've expressed a concern, thank you! Now that you've said it, perhaps Eli will stop suggesting that dBpoweramp can never be less secure than EAC.

Quote from: Eli on
I am not aware of any other instances where you have questioned/challenged my claims about EAC.
Not all of these instances were challenged, but here you go:
http://www.hydrogenaudio.org/forums/index....st&p=647341
http://www.hydrogenaudio.org/forums/index....st&p=639126
http://www.hydrogenaudio.org/forums/index....st&p=638284
http://www.hydrogenaudio.org/forums/index....st&p=572944
http://www.hydrogenaudio.org/forums/index....st&p=561711

"dBpoweramp. Its as secure as EAC"

Reply #8 –
Quote from: greynol on
Quote from: spoon on
non-c2 and disc not in accurate rip: dbpoweramp would suffer more from consistent errors (if the drive was suffering from this)
You've validated the very reason why I've expressed a concern, thank you! Now that you've said it, perhaps Eli will stop suggesting that dBpoweramp can never be less secure than EAC.



I believe there some significant symantic differences in what we are saying. I have always argued that dBpoweram is as secure as EAC. In some situations EAC is more secure. In some situation dBpoweramp is more secure. They are both secure rippers, and in terms of their level of "security" are probably on par with eachother. dBpoweramp is faster if there is an accuraterip match. If there are C2 pointers dBpoweramp outperforms EAC. Yes, I am a dBpoweramp "fanboy." However, this is a forum full of EAC fanboys. I speak up when ever I see someone asking for advice on which ripper to use. Its usually a newbie, interested in something like EAC, which is why they found there way here. I speak up in support of what I believe to be the better overall option. In terms of security, I believe they are on par. But in virtually every other field, IMHO, dBpoweramp outshines EAC, meta-data being formost among those.

Maybe spoon will change the read routines for non-C2 ripping when the disc is not in AR to overcome this shortcoming. However, without C2 and AR both dBpoweramp suffer from the possibility of missing consistent errors.

"dBpoweramp. Its as secure as EAC"

Reply #10 –
As I said earlier, your wording has been toned-down.  In the past you've used terms like "at least as" and "every bit as" which do not make room for the possibility that EAC can in some instances be more secure than dBpoweramp.

If your mission is to help spoon sell copies of dBpoweramp, you'd be better served focusing on situations where dBpoweramp has the clear upper hand (drives that provide C2 pointers) when talking about ripping and not make foolish attempts to broad-brush the subject opening each program up to areas where they fall short.  Be careful when touting superior ability with C2 pointers as well since there will be (perhaps freak) exceptions where EAC will get good data and dBpoweramp won't.

Regarding advocacy please understand that we have rules about this.  While you've been a long time member of HA and have a high post count, your recent posting history here has been more about pitching dBpoweramp than anything else.  I do not know any other regular member here who spends the amount of time suggesting other software like you do with dBpoweramp.  Of course we hear a lot about foobar2000, but considering that a huge portion of people are here for the foobar2000 forum, this is understandable.  We do not see such rabid advocacy for EAC (IOW, posts promoting it above other secure ripping software).  Personally I prefer giving choices over advocacy and I think my record here reflects this.  I have offered dBpoweramp as a choice on many occasions probably more so than EAC, at least since it was re-written.

"dBpoweramp. Its as secure as EAC"

Reply #11 –
Quote
"getting 50% recover rate on a damaged CD is quite an assumption." Yet EAC has worked this way for years.


Often a secure ripper only has to recover a couple of frames, those frames might self recover on the very next read (with only 3 or 4 errors there is a chance that burst ripping could recover the errors given enough trys). That is not to say which ever ripping method (dBpoweramp, EAC, CD paranoia) are not without inherent flaws which can be improved, even if they have appeared to work for years.

Quote
I don't see any proof, but are you suggesting that shifing the starting address around a frame reduces the risk that your program will pass off errant data as secure and that this will always make your program at least as judicious as EAC if not more so when it comes to labeling data as secure as Eli has been claiming?


On the secure ripper test we ran one of those drives Matshita - UJDA757 improved with the starting address shifting around, it could be for many reasons (such as drive being at a different speed on the 'bad' sector, or how the drive was interpolating), how wide spread this drives chipset base implementation is, who knows.

Quote
So if a track has more than one block with error your program will step through each combination?


Yes

Quote
What about tracks for which AR data is not present?


Nothing to compare against, so is not done.

Real results are often different to theorized results. Also single drive testing is just that, specific to one drive - or to put another way, often a question might come up 'What drive should I purchase for use with EAC?', the answer to that is simple - what ever drive Andre uses , it is possible EAC performs outstanding on that exact drive model, unless he does most of his work on specifically chosen 'poor' drives. That is the risk of secure rippers to focus too much on one specific drive, to the exclusion of most other drives - the key is getting an average quality across most drives (there is probably 1 drive which rips better in iTunes than EAC or dBpoweramp  ).

I hold a belief that many Ripping results would be improved in EAC if c2 were used, on the basis that consistent errors through interpolation are now more wide spread than drives of 4 years ago. C2 can spot these consistent errors, AccurateRip can also, where as re-reading cannot (read, re-read: got a consistent error - let it through).