IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
Call for capable people to do a comparison of rippers
spoon
post Jul 27 2010, 22:06
Post #26


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2749
Joined: 24-March 02
Member No.: 1615



A bad collision is like playing the lottery, the more tickets you purchase (other crcs checked) the greater the chance of winning (or loosing if talking of a bad collision). It is all unlikely, but if there is a way of strengthening the process then it should be done.

This does not effect valid offsets, only possible invalid ones.

This post has been edited by spoon: Jul 27 2010, 22:07


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 23:37
Post #27





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Duh, I get it now. Thanks spoon!

CUETools does now check the offset checksum, at least when the track checksum doesn't match. I wonder if it still does anyway and what it would do if the track checksum matches and the offset checksum doesn't.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 23:51
Post #28





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I'm starting to think that just specifying Windows in the OS is not adequate. Many people are having quite a bit of difficulty getting EAC to work properly with 64-bit versions of Windows specifically and post-XP Windows in general. While some people are finding solutions, more and different problems are being reported regularly. There seem to be more and more drive-based or interface-based issues as well.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Jul 28 2010, 00:34
Post #29





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Noting a recent addition made by Eli, I'd like to quote myself:

QUOTE (greynol @ Jul 26 2010, 16:36) *
I also don't think we should create a chart that is heavily skewed based on a list of features belonging to just one ripping program. Still, any type of feature/technology that makes a clear difference in performance should be listed.

Perhaps we have some objective 3rd-party statistics demonstrating how often someone is expected to derive a benefit from PerfectMeta?

Unless there are some objections, I'd like to remove the row and add a footnote to the metadata entry for dBpoweramp. I think the same should be done for the CUETool DB with a footnote added to its entry in the AccurateRip row. Perhaps the row be renamed to something that describes what the two services do.

I also think that the (natively) part be removed from the artwork and that the entries be done in a similar fashion as the metadata. Entries designed in such a way as to limit information should be avoided.

This post has been edited by greynol: Jul 28 2010, 00:44


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Jul 28 2010, 00:37
Post #30





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I have an objection with footnote 4 since it implies that dBpoweramp is the only current ripper that can check your rips against different pressings, especially considering that it isn't even the first ripper to be able to do this.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Eli
post Jul 28 2010, 01:16
Post #31





Group: Members
Posts: 1056
Joined: 16-October 03
Member No.: 9337



QUOTE (greynol @ Jul 26 2010, 16:36) *
I also don't think we should create a chart that is heavily skewed based on a list of features belonging to just one ripping program. Still, any type of feature/technology that makes a clear difference in performance should be listed.


How many rippers have to support a feature? 2+, 3+? What about using C2 in re-reads? Only 2 rippers?

The feature of CTDB is exclusive to one ripper. I wish it wasn't. Its open to any other rippers to add support. Its an important enough feature in my mind (no other feature can actually correct unrecoverable data) to warrant its own row. Other developers should add support and get a yes in their row as well.

Comparison of meta-data is exclusive to one ripper, I wish it wasn't. Any developer could implement a version of PerfectMeta (under a non-TM name). I don't have any statistics and no one would consider me objective anyway, but I argue that its important enough of a feature to warrant its own row. Its current implementation in dBpoweramp is to skewed to AMG results, however it is still very useful, and much better then anything else anyone is offering.


QUOTE (greynol)
I have an objection with footnote 4 since it implies that dBpoweramp is the only current ripper that can check your rips against different pressings, especially considering that it isn't even the first ripper to be able to do this.

Footnote 4 is correct in that dBpoweramp is the only current ripper to support AR2. But you are also correct in that others support checking against different pressings. Does it warrant 3 rows; accuraterip support, cross pressing checks, and accuraterip 2 support? That would be most accurate, but also somewhat combersome.

This post has been edited by Eli: Jul 28 2010, 01:18


--------------------
http://forum.dbpoweramp.com/showthread.php?t=21072
Go to the top of the page
+Quote Post
greynol
post Jul 28 2010, 02:45
Post #32





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I think there is a way to generalize rows that and still show definite benefits between rippers. I also think that it is possible to add extra information as needed through the use of footnotes.

dBpoweramp is the best ripper for Windows, in terms of features and performance, hands down. Whichever way the chart is sliced and diced this will be reflected, Eli, I assure you. Still, the chart doesn't need to look like dBpoweramp marketing material.

FWIW, I considered making mention of PerfectMeta, but figured that it already took the crown in that row. I still feel it should be included, BTW, though perhaps is should be noted that some of those options cost $$$(?).

QUOTE (Eli @ Jul 27 2010, 17:16) *
I argue that its important enough of a feature to warrant its own row.
Only after the fact.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Eli
post Jul 28 2010, 04:03
Post #33





Group: Members
Posts: 1056
Joined: 16-October 03
Member No.: 9337



QUOTE (greynol @ Jul 27 2010, 21:45) *
dBpoweramp is the best ripper for Windows, in terms of features and performance, hands down. Whichever way the chart is sliced and diced this will be reflected, Eli, I assure you. Still, the chart doesn't need to look like dBpoweramp marketing material.


I'm certainly not trying to market for dBpoweramp. It certainly has the lead, but I would say right now that CueTools has the momentum. CT is being more innovative and pushing things more (CTDB, cross pressing checks). PerfectMeta is an advanced feature with great, though under-utilized, benefits. Its the only row with a dbpoweramp only feature and its deserved, just like CT deserves a row for CTDB.

I don't want the chart to reflect anything but what is the truth. Hopefully every developer strives to improve their software.


QUOTE (greynol @ Jul 27 2010, 21:45) *
QUOTE (Eli @ Jul 27 2010, 17:16) *
I argue that its important enough of a feature to warrant its own row.
Only after the fact.


Sorry, a request was made to help build the chart. I actually spent an hour making changes last night. However, when I saved they were lost. I think someone else was editing at the same time. Wasn't aware I needed to make the argument before making the change, but feel I can support it.




--------------------
http://forum.dbpoweramp.com/showthread.php?t=21072
Go to the top of the page
+Quote Post
greynol
post Jul 28 2010, 04:18
Post #34





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Maybe Jan feels differently, but I thought it a good idea to reduce the number of line items in this category rather than increase them.

Perhaps a dedicated article on metadata with an obvious link?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Jul 28 2010, 04:19
Post #35





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Eli @ Jul 27 2010, 20:03) *
I'm certainly not trying to market for dBpoweramp.

Please don't make me count posts, let alone point to your signature.

This post has been edited by greynol: Jul 28 2010, 04:19


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Eli
post Jul 28 2010, 22:33
Post #36





Group: Members
Posts: 1056
Joined: 16-October 03
Member No.: 9337



QUOTE (greynol @ Jul 27 2010, 23:19) *
QUOTE (Eli @ Jul 27 2010, 20:03) *
I'm certainly not trying to market for dBpoweramp.

Please don't make me count posts, let alone point to your signature.


My self interest is in promoting the advancement of the features that I think would best improve the ripping experience. If I was promoting dBpoweramp I would point to a page to buy it, not a list of features I wish it had. Yes, I have posted more regarding dbpoweramp then any other topic. Before R12 I used EAC. Maybe one day I will transition to CueTools or something else. I will use the best software as I see it.


--------------------
http://forum.dbpoweramp.com/showthread.php?t=21072
Go to the top of the page
+Quote Post
Jan S.
post Jul 29 2010, 00:15
Post #37





Group: Admin
Posts: 2550
Joined: 26-September 01
From: Denmark
Member No.: 21



  • Why is over-reading in the cache column?
  • Why does "no" have a different color for C2?
  • I think some explanation of the C2 pointers is needed. The general user will have no idea significance "initial pass" and "on re-reads" has.


QUOTE (greynol @ Jul 27 2010, 17:14) *
Careful about post-processing. With at least dBpoweramp and Rip, AR is more integrated into the ripping process; decisions are made based on its results. In the case of dBpoweramp, any combination of results from multiple passes that differ are checked against the database.
"Ripping process" can be renamed to "data acquisition" and "Post processing etc." just to "Additional features". This will suffice?

QUOTE (greynol @ Jul 28 2010, 00:51) *
I'm starting to think that just specifying Windows in the OS is not adequate. Many people are having quite a bit of difficulty getting EAC to work properly with 64-bit versions of Windows specifically and post-XP Windows in general. While some people are finding solutions, more and different problems are being reported regularly. There seem to be more and more drive-based or interface-based issues as well.
QUOTE (spoon @ Jul 27 2010, 17:20) *
All good, CD-Text might be listed under the metadata for rippers which support it.

........

The AR column, instead of Yes / No could be the version of AR, ie 1 or 2, or No.
Added to todo list.

QUOTE (greynol @ Jul 28 2010, 01:34) *
Unless there are some objections, I'd like to remove the row and add a footnote to the metadata entry for dBpoweramp. I think the same should be done for the CUETool DB with a footnote added to its entry in the AccurateRip row. Perhaps the row be renamed to something that describes what the two services do.

QUOTE (greynol @ Jul 28 2010, 03:45) *
FWIW, I considered making mention of PerfectMeta, but figured that it already took the crown in that row. I still feel it should be included, BTW, though perhaps is should be noted that some of those options cost $$$(?).
I suggest "Compare Meta-Data from multiple sources" is removed, "Metadata lookup" renamed to "Metadata" and a footnote added saying: "Dbpoweramp is unique in being able to compare metadata from several sources automatically to eliminate erroneous data. This function is bought as a subscription service called PerfectMeta™".
I think CUETools_db should be a separate feature from AR. To me it adds completely different functionality.

QUOTE (greynol @ Jul 28 2010, 01:34) *
I also think that the (natively) part be removed from the artwork and that the entries be done in a similar fashion as the metadata. Entries designed in such a way as to limit information should be avoided.
I think "Download Album Art (natively)" should just be "Album Art". If there is a plugin it should show in the table.

QUOTE (greynol @ Jul 28 2010, 01:37) *
I have an objection with footnote 4 since it implies that dBpoweramp is the only current ripper that can check your rips against different pressings, especially considering that it isn't even the first ripper to be able to do this.

QUOTE (Eli @ Jul 28 2010, 02:16) *
Footnote 4 is correct in that dBpoweramp is the only current ripper to support AR2. But you are also correct in that others support checking against different pressings. Does it warrant 3 rows; accuraterip support, cross pressing checks, and accuraterip 2 support? That would be most accurate, but also somewhat combersome.

Two rows. AR row can state the version number instead of yes/no; checking for different pressings/offsets another. I'm personally not so concerned about limiting the number of rows. To me there is some way to go before it becomes too much.

QUOTE (Eli @ Jul 28 2010, 05:03) *
Sorry, a request was made to help build the chart. I actually spent an hour making changes last night. However, when I saved they were lost. I think someone else was editing at the same time. Wasn't aware I needed to make the argument before making the change, but feel I can support it.
I'm sorry to hear work was lost. It really shouldn't be possible. As far as I know the wiki is suppose to warn in case someone else is editing. And in either case your version should have been saved in the history. Any help is greatly appreciated. If someone disagrees it can always be discussed and changed
Go to the top of the page
+Quote Post
greynol
post Jul 29 2010, 01:57
Post #38





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Jan S. @ Jul 28 2010, 16:15) *
Why is over-reading in the cache column?
It is the mechanism by which the audio cache is cleared. I decided to cite specific methods available in order to remove an unnecessary row.

QUOTE (Jan S. @ Jul 28 2010, 16:15) *
Why does "no" have a different color for C2?
Some C2 pointer implementations aren't much better than not having C2 pointer support at all, especially when used with drives that do not provide them or aren't accurate and thorough when reporting errors that could not be corrected, so not having that feature isn't necessarily a bad thing.

QUOTE (Jan S. @ Jul 28 2010, 16:15) *
I think some explanation of the C2 pointers is needed.
I agree completely and think this should be done for many of the categories. The same problem exists with the lossless comparison table as well. I'm not sure how it should be structured in the wiki, but I'd be more than happy to add the information once the structure is in place.

QUOTE (Jan S. @ Jul 28 2010, 16:15) *
QUOTE (greynol @ Jul 27 2010, 17:14) *
Careful about post-processing. With at least dBpoweramp and Rip, AR is more integrated into the ripping process; decisions are made based on its results. In the case of dBpoweramp, any combination of results from multiple passes that differ are checked against the database.
"Ripping process" can be renamed to "data acquisition" and "Post processing etc." just to "Additional features". This will suffice?
Sure.

We also need to do something about gaps and CUE sheets since the two really go hand in hand. Saying that EAC provides different types only tells half the story.

QUOTE (Jan S. @ Jul 28 2010, 16:15) *
Any help is greatly appreciated. If someone disagrees it can always be discussed and changed
I fully agree and feel that I overreacted and have been hypocritical. My apologies to Eli.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Jan S.
post Jul 29 2010, 23:56
Post #39





Group: Admin
Posts: 2550
Joined: 26-September 01
From: Denmark
Member No.: 21



QUOTE (greynol @ Jul 29 2010, 02:57) *
QUOTE (Jan S. @ Jul 28 2010, 16:15) *
Why is over-reading in the cache column?
It is the mechanism by which the audio cache is cleared. I decided to cite specific methods available in order to remove an unnecessary row.
Hmm. So we need another row for the overreading (leadin/leadout) feature or am I lost?


QUOTE (greynol @ Jul 29 2010, 02:57) *
QUOTE (Jan S. @ Jul 28 2010, 16:15) *
I think some explanation of the C2 pointers is needed.
I agree completely and think this should be done for many of the categories. The same problem exists with the lossless comparison table as well. I'm not sure how it should be structured in the wiki, but I'd be more than happy to add the information once the structure is in place.
I have tried to organize all the pages related to cd ripping. We have a big big big mess IMO. A lot if information is hidden in program specific pages fx. offset. I think things like this is a major problem for the table we are trying to create and will have to be sorted out before we can figure what needs to be explained specifically in the comparison page. Ideas for structuring the categorization is more than welcome. And people that would like to split things like the offset and C2 pointers are also in want. IMO the page on secure ripping should be much more limited with references to separate pages explaining the different features/technologies.
Go to the top of the page
+Quote Post
greynol
post Jul 30 2010, 01:06
Post #40





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Jan S. @ Jul 29 2010, 15:56) *
So we need another row for the overreading (leadin/leadout) feature[...]?
I don't think it's something worth bothering over, but we could if there are rippers which offer offset correction that don't offer this option.

QUOTE (Jan S. @ Jul 29 2010, 15:56) *
IMO the page on secure ripping should be much more limited with references to separate pages explaining the different features/technologies.
I think relevant information should be merged into the table and the article removed, or turned into a CD-Ripping glossary page containing information linked from other articles.

QUOTE (Jan S. @ Jul 29 2010, 15:56) *
I also feel that this article should be removed unless its contents are approved by the original author(s) since it was completely plagiarized from the EAC website.

This post has been edited by greynol: Jul 30 2010, 01:07


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Jul 30 2010, 01:13
Post #41





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Jan S. @ Jul 29 2010, 15:56) *

Very little of the information written in that link is correct. After finishing this post I will be removing the offending parts.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
mjb2006
post Jul 30 2010, 10:41
Post #42





Group: Members
Posts: 816
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (greynol @ Jul 29 2010, 18:06) *
QUOTE (Jan S. @ Jul 29 2010, 15:56) *
I also feel that this article should be removed unless its contents are approved by the original author(s) since it was completely plagiarized from the EAC website.

...plagiarized and subjected to some minor copy edits (spelling mostly). AFAIK, the only thing actually different is the part I added about a feature which was removed.
Go to the top of the page
+Quote Post
Jan S.
post Jul 30 2010, 14:16
Post #43





Group: Admin
Posts: 2550
Joined: 26-September 01
From: Denmark
Member No.: 21



I have implemented some of suggested changes. Before I go ahead I would like to know what people think of splitting the table in windows only programs and others. We could use some space in the width of the table. Of course I am open to other suggestions for a less cluttered table.
Go to the top of the page
+Quote Post
greynol
post Jul 30 2010, 19:07
Post #44





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I think adding a row about AR results across multiple pressings and continuing to specify AR1, AR2 is redundant. A stronger checksum is the only other difference and IMO does not warrant so much visibility in the table. There has never been any evidence (and will likely never be any evidence) presented showing that the checksums as calculated in AR1 have ever given someone a false positive.

This post has been edited by greynol: Jul 30 2010, 19:20


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Jan S.
post Jul 30 2010, 19:11
Post #45





Group: Admin
Posts: 2550
Joined: 26-September 01
From: Denmark
Member No.: 21



FYI I found this in XLD changelog:
QUOTE
Added option to use C2 error pointers
When the option is turned on, XLD first read a sector in burst mode, and check the occurrence of C2 error. If C2 error occurs, then XLD re-read the sector with cdparanoia. This accelerates ripping extremely for the drive with C2 error support (Plextor, NEC, etc), without losing safety. If you use this option, please make sure that your drive supports reporting C2 errors.
Go to the top of the page
+Quote Post
greynol
post Jul 30 2010, 19:21
Post #46





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Thanks Jan. I will edit the table accordingly to reflect this information.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Jan S.
post Jul 30 2010, 19:24
Post #47





Group: Admin
Posts: 2550
Joined: 26-September 01
From: Denmark
Member No.: 21



QUOTE (greynol @ Jul 30 2010, 20:07) *
I think adding a row about AR results across multiple pressings and continuing to specify AR1, AR2 is redundant. A stronger checksum is the only other difference and IMO does not warrant so much visibility in the table. There has never been any evidence (and will likely never be any evidence) presented showing that the checksums as calculated in AR1 have ever given someone a false positive.
OK. Changed it back and emphasized that the added security is theoretical. If this is discussed somewhere a link would be good. And maybe some sharper wording instead of "security" is in order.
Go to the top of the page
+Quote Post
greynol
post Jul 30 2010, 19:51
Post #48





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



The argument boils down to how likely a ripping error will only affect the accuracy of a single sample in the right channel only, which gets into the messy business of scrutinizing CIRC. The probability of this happening then needs to be divided by 65536, since this is how often the AR1 hash drops coverage. There are also more complicated situations regarding the lack of coverage of only select bits of the right channel every so many samples.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
greynol
post Jul 30 2010, 21:28
Post #49





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



fb2k entry updated and other minor edits. I put N/A for iTunes and WMP under cache defeating because they aren't secure. I guess we need to revisit this, but I'm happy kicking the can down the road for now.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Jul 30 2010, 22:00
Post #50


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2749
Joined: 24-March 02
Member No.: 1615



CDex should be added to the table, it is still widely used.

The designation of 'AccurateRip 2' is there to stop confusion, it is a minimum feature set required to obtain such a branding.

>AccurateRip 2 which will theoretically ad

'Theoretically', not a theory it is a fact.

Why is foobar just 'freeware' whilst EAC is 'proprietary, freeware', they are the same?

If you ask me <and in somewhat jest> the GPL column colour should be orange, programs/libs which are GPL tend to be the least developed over time as proven by CD-Paranoia and CDex.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 1st October 2014 - 17:32