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: Call for capable people to do a comparison of rippers (Read 54072 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Call for capable people to do a comparison of rippers

Reply #25
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.

Call for capable people to do a comparison of rippers

Reply #26
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.

Call for capable people to do a comparison of rippers

Reply #27
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.

Call for capable people to do a comparison of rippers

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

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.

Call for capable people to do a comparison of rippers

Reply #29
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.

Call for capable people to do a comparison of rippers

Reply #30
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 from: greynol link=msg=0 date=
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.

Call for capable people to do a comparison of rippers

Reply #31
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 $$$(?).

I argue that its important enough of a feature to warrant its own row.
Only after the fact.

Call for capable people to do a comparison of rippers

Reply #32
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.


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.



Call for capable people to do a comparison of rippers

Reply #33
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?

Call for capable people to do a comparison of rippers

Reply #34
I'm certainly not trying to market for dBpoweramp.

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

Call for capable people to do a comparison of rippers

Reply #35
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.

Call for capable people to do a comparison of rippers

Reply #36
  • 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.


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?

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.
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.

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.

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.

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.

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.

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.

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

Call for capable people to do a comparison of rippers

Reply #37
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.

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.

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.

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.

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.

Call for capable people to do a comparison of rippers

Reply #38
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?


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.

Call for capable people to do a comparison of rippers

Reply #39
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.

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.

http://wiki.hydrogenaudio.org/index.php?ti...xact_Audio_Copy
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.

Call for capable people to do a comparison of rippers

Reply #40
C2 pointers

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

Call for capable people to do a comparison of rippers

Reply #41
http://wiki.hydrogenaudio.org/index.php?ti...xact_Audio_Copy
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.

Call for capable people to do a comparison of rippers

Reply #42
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.

Call for capable people to do a comparison of rippers

Reply #43
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.

Call for capable people to do a comparison of rippers

Reply #44
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.


Call for capable people to do a comparison of rippers

Reply #46
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.

Call for capable people to do a comparison of rippers

Reply #47
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.

Call for capable people to do a comparison of rippers

Reply #48
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.

 

Call for capable people to do a comparison of rippers

Reply #49
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.