HydrogenAudio

Knowledgebase Project => Wiki Discussion => Topic started by: Jan S. on 2010-07-26 00:13:02

Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-26 00:13:02
Hi.

Over the years and recently (here (http://www.hydrogenaudio.org/forums/index.php?showtopic=37313&hl=) and here (http://www.hydrogenaudio.org/forums/index.php?showtopic=80863&hl=)) there have been many discussions and questions about the differences between different cd rippers. New rippers with secure ripping facilities (dbpoweramp, CUEtools, foobar etc) have emerged in recent years and it is now difficult to judge compared to some years ago when the only answer was EAC.

For this reason I thought it could be very good to have a page at the wiki trying to explain in a concise form what the differences are. I was imagining a table with features like we have done for the Lossless format comparison (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison) but probably also additional text is required.

I do not consider myself close to competent to try to do this but I have tried to setup a starting point for such a page here: http://wiki.hydrogenaudio.org/index.php?ti...n_of_CD_rippers (http://wiki.hydrogenaudio.org/index.php?title=Comparison_of_CD_rippers)
I hope the capable people here will invest some time into this so as to save time repeating these points. Please post your thoughts on this idea: how best to organize?, what to put in the table?, which programs are relevant?, what other issues need to be explain in text?, etc.

Some more links:
wikipedias list of rippers: http://en.wikipedia.org/wiki/CD_ripper (http://en.wikipedia.org/wiki/CD_ripper)
Kind of comparison here for secure ripping features: http://wiki.hydrogenaudio.org/index.php?title=Secure_ripping (http://wiki.hydrogenaudio.org/index.php?title=Secure_ripping)
Title: Call for capable people to do a comparison of rippers
Post by: willow on 2010-07-26 12:38:30
I'm having the impression that novadays CD drives are that much self aware that it make no difference what settings or software to use. Different drives return the different results with the same software and settings. I had the unpleasant experience to choose drive i trust more. No matter the software i used (few EAC's too) the result was the same for unit but unique for each drive. They are simply self evident black boxes, back in the days there was the possibility to retrieve the raw data on reading operation by diskette and i did actually saved a few unreadable files. What the raw reading is seems to be the weak semi-random pattern of unstable sector that depends on physical damage and can be analized in manual manner. Within a few spinning iterations there was even a chance for controller to catch up and return the absolutely correct pattern but erroneous by the dumb controller standpoint. I'm not sure the modern devices are that much handsome.

Would be glad to every find outs about best rippers but keeping not much hope for them.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-26 13:26:05
Did you account for offset (http://wiki.hydrogenaudio.org/index.php?title=Exact_Audio_Copy#Offset_technology) and difference in headers when you did this comparison? My guess is no.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-27 00:22:03
I have filled some of the table but at this point we need some of the experts to step in... hint hint!
Else this idea will die fast..
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 00:36:32
"Capable of disabling C2" needs to be removed.

"Use of C2" needs to be reworded as "C2 pointers used to detect errors" and "C2 pointers used during re-reads" needs to be added; or wording to that effect.

AccurateRip1 and AccurateRip2 should just be merged to be AccurateRip, unless spoon suggests otherwise.

There's also a distinction to be made between supporting CUE sheets and gap detection (foobar2000 does not support CUE sheets to the level that EAC/CUETools does).

You might want to get rid of secure ripping features, unless you better define what you expect to have placed there.

FUA support should be added.

dBpoweramp has some other ripping features, such as an attempt to detect interpolation in order to help drop consistent errors, though I don't feel it has been demonstrated as being useful for a wide enough range of drives (one could make the same argument for FUA as well).  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.

We should also consider if something like "Accurate Stream" is worth mentioning.  If it is mentioned, I would prefer more generic terminology.  "Accurate Stream" seems more like a marketing catch phrase which I have never seen anywhere but on EAC.  If anyone actually knows the history of this phrase, please share.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-27 01:01:32
* AR2 dropped and footnote added
* dropped dppoweramp R14
* "C2 pointers used to detect errors" and "C2 pointers used during re-reads" added. Rest dropped.
* gap detection
* FUA added
* secure ripping features dropped

Maybe something like "Uses sector re-reads" should be added to indicate that the software tries to do "secure ripping"?

Edit: maybe something like "circumvents non-constant offset" could be used in place of accurate stream?
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 01:10:56
I would think that anything hitting that chart should provide the ability to perform re-reads, though this puts iTunes into an awkward category, since no one has ever come forth with definitive information as to what the "error correction" feature does exactly, let alone demonstrate that it provides any measurable benefit.

This has me thinking that any ripper with two columns of CRCs or some other method of indicating the results of test and copy can be classified as secure, even if there is no mechanism to do anything special in the event that two passes over the same range of data yields different results (such as performing additional re-reads in order to uncover consistent data).

EDIT: Oops, I didn't realize that the chart was geared for any ripper, not just secure ones.  I took a closer look when I realized that I had beaten up on just iTunes for misleading people into thinking they provide any sort of reasonable assurance of accurate ripping when WMP is equally deserving.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 01:18:22
When you tell EAC that your drive has Accurate Stream, it will no longer aggressively check for synchronization problems.  This is a situation where the ripper relies more heavily on the capabilities of the drive.  In the case of dBpoweramp, it is not recommended for drives that don't have this feature.  In the case of Cdparanoia, Accurate Stream drives have essentially made a large portion of its litany of error detection categories obsolete, at least this is my understanding.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 07:22:20
I've made quite a few updates.  Please review my work.
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 10:14:43
HTOA has been supported since dBpoweramp R13 (it is automatically detected and presented as a track which can be checked to rip).

R13 does support CueSheet writing and image as single file, but without gaps & index detection which R14 has recently added.

AccurateRip2 is an important enhancement to the usefulness of AccurateRip - it comprises of the new CRC and the program being able to check across pressings. You might find in the short term EAC supports half (new CRC) and foobar and cuetool support the other half (checking across pressings).
Title: Call for capable people to do a comparison of rippers
Post by: stevenmmm on 2010-07-27 11:42:16
MusicBee supports many of the ripping features listed:
OS: Windows
HTOA: no
Offset correction: yes
C2 pointers detect: yes
C2 pointers re-read: no
Defeat cache: yes
Support FUA: no
Accrurate Rip: yes
CUEtools db: no
gap detection: no
CUE sheet support: limited
log file: no
One track per file: yes
Image as single file: yes
Metadata lookup: freedb, MusicBrainz
Cost: free
License: freeware
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-27 14:36:35
I have reorganized the table and added info.

MusicBee supports many of the ripping features listed:
MusicBee added

HTOA has been supported since dBpoweramp R13 (it is automatically detected and presented as a track which can be checked to rip).

R13 does support CueSheet writing and image as single file, but without gaps & index detection which R14 has recently added.

AccurateRip2 is an important enhancement to the usefulness of AccurateRip - it comprises of the new CRC and the program being able to check across pressings. You might find in the short term EAC supports half (new CRC) and foobar and cuetool support the other half (checking across pressings).
Is the table correct now with regards to dbpoweramp?
Is the footnote regarding AR2 correct or do you have suggestions for improvements or more short info to add?


I've made quite a few updates.  Please review my work.
Looks very good to me. You did a lot of work. Thank you.
XLD uses cdparanoia but you added more features for XLD than for cdparanoia. They independently added features?




edit: Do you have a link for "rip"? I can't find it and it is kind of difficult to search for.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 16:07:10
AccurateRip2 is an important enhancement to the usefulness of AccurateRip - it comprises of the new CRC and the program being able to check across pressings.

People have been able to use  to check multiple pressings without AR2 for a while now.  Despite the problem with the old CRC, there have been no reported cases of collision.  I don't think we need the extra row unless there will be problems with compatibility.

Thank you for correcting the information about R13.  I briefly searched your forum for the relevant terms and looked over change logs and couldn't find the information.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 16:09:43
you added more features for XLD than for cdparanoia. They independently added features?
Yes.

You or someone else have an idea how to handle programs that use cdparanoid? There are quite a lot so I don't know if we add a sample of those, none at all or only those that have extra features like apparently XLD.
I was wondering the same thing.

Do you have a link for "rip"? I can't find it and it is kind of difficult to search for.
http://sbooth.org/Rip/ (http://sbooth.org/Rip/)
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 16:14:06
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.
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 16:20:53
Quote
Is the table correct now with regards to dbpoweramp?


All good, CD-Text might be listed under the metadata for rippers which support it.

Quote
Is the footnote regarding AR2 correct or do you have suggestions for improvements or more short info to add?

Quote
People have been able to use to check multiple pressings without AR2 for a while now. Despite the problem with the old CRC, there have been no reported cases of collision. I don't think we need the extra row unless there will be problems with compatibility.


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

AR2 is about collating multiple enhancements under a branding, and even then I would prefer the programs which check multiple pressings to move to use the offset finding CRC, then check only on those offset(s) which were highlighted by the CRC rather than a blanket check +-5 frames (currently CueTools and Foobar).



Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 16:28:49
From my understanding it wasn't a blanket check.

Have you checked the code?  I haven't but was told this:
http://www.hydrogenaudio.org/forums/index....st&p=592342 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=592342)
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 20:16:44
It suggests that both CRCs are calculated, for every offset +-5 sectors and the offset finding CRC is thrown away, rather than used at the start to find specific offsets.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 20:24:06
I don't see how you can say that.  It's pretty clear from the post that the offset is largely determined through mathematics and that the AR offset CRC isn't used at all.

As a participant in that discussion, it was pretty obvious that Mr. Chudov didn't know what to do with the second CRC, excluding the fact that you did not tell him from exactly what data in the track it was calculated.

So that my point isn't lost, all AR2 is going to provide over AR1 for people already using the database* to check their rips against alternate pressings is a real CRC algorithm, unless there is something else that you haven't disclosed.

(*) This includes users of XLD, Rip, TripleFlac and nitwits like me who have been using an alternate approach for years before these other methods were made available.

EDIT: I misread your comment about the offset finding non-cyclical checksum being thrown away.
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 20:27:14
>offset is largely determined through mathematics

From a matching Main CRC

>and that the AR offset CRC isn't used at all.

I agree with this, using the Offset CRC is a requirement for AR2, because checking across 5880 offsets IMHO weakens the CRC (by that amount).
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 20:42:45
I just want to make sure that you realize that the algorithm does not continually increment the offset of the entire file in order to blindly calculate checksums in hopes of a match.

I don't understand why you would say it weakens the CRC.  It's merely exploiting a hash (not a CRC!) that is already weak.
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 21:07:57
The code suggests that all effective CRCs for +-5 sectors x 588 samples are calculated, even if the calculation is efficient (it uses a one calculation at 0 offset, then derrives off that):

Code: [Select]
private const int _arOffsetRange = 5 * 588 - 1;

    public void FindBestOffset(uint minConfidence, bool optimizeConfidence, out uint outTracksMatch, out int outBestOffset)
3891                    {
3892                            uint bestTracksMatch = 0;
3893                            uint bestConfidence = 0;
3894                            int bestOffset = 0;
3895    
3896                            for (int offset = -_arOffsetRange; offset <= _arOffsetRange; offset++)
3897                            {
3898                                    uint tracksMatch = 0;
3899                                    uint sumConfidence = 0;
3900    
3901                                    for (int iTrack = 0; iTrack < TrackCount; iTrack++)
3902                                    {
3903                                            uint confidence = 0;
3904    
3905                                            for (int di = 0; di < (int)_arVerify.AccDisks.Count; di++)
3906                                                    if (_arVerify.CRC(iTrack, offset) == _arVerify.AccDisks[di].tracks[iTrack].CRC)
3907                                                            confidence += _arVerify.AccDisks[di].tracks[iTrack].count;
3908


Perhaps Gregory can give insight.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 21:25:24
That seems to be the most plausible explanation; at least it's in keeping with my basic and shallow understanding of how I think it works.  I was quite impressed when I read that post by Gregory, which was around the same time that I was communicating with the author of XLD trying to make sense of what he was doing as well; quite humbling!
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 21:42:55
>I don't understand why you would say it weakens the CRC. It's merely exploiting a hash (not a CRC!) that is already weak.

When used disc based it does not, as the other tracks verify the offset and if there was a chance of a rouge match on a single track it would stand out. A crc collision is 5880x more likely than using an exact offset determined from the offset finding crc. It is more efficient and elegant to use the offset finding crc, hence why it is recommended.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 21:50:35
I don't see how it could be when the two methods of arriving at any particular hash value are mathematically equivalent.
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-27 22:06: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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 23:37:12
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-27 23:51:43
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-28 00:34: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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-28 00:37:23
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.
Title: Call for capable people to do a comparison of rippers
Post by: Eli on 2010-07-28 01:16:06
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-28 02:45:53
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.
Title: Call for capable people to do a comparison of rippers
Post by: Eli on 2010-07-28 04:03:00
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.


Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-28 04:18:16
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?
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-28 04:19:13
I'm certainly not trying to market for dBpoweramp.

Please don't make me count posts, let alone point to your signature.
Title: Call for capable people to do a comparison of rippers
Post by: Eli on 2010-07-28 22:33:49
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.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-29 00:15:09


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. (http://wiki.hydrogenaudio.org/index.php?title=Talk:Comparison_of_CD_rippers)

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â„¢ (http://www.dbpoweramp.com/cd-ripper.htm)".
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
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-29 01:57:13
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.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-29 23:56:22
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 (http://wiki.hydrogenaudio.org/index.php?title=Category:CD_ripping). We have a big big big mess IMO. A lot if information is hidden in program specific pages fx. offset (http://wiki.hydrogenaudio.org/index.php?title=Exact_Audio_Copy#Offset_technology). 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 (http://wiki.hydrogenaudio.org/index.php?title=Exact_Audio_Copy#Offset_technology) and C2 pointers (http://wiki.hydrogenaudio.org/index.php?title=Secure_ripping#C2_error_pointers_.28software.29) 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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 01:06:41
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 (http://wiki.hydrogenaudio.org/index.php?title=Exact_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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 01:13:16
C2 pointers (http://wiki.hydrogenaudio.org/index.php?title=Secure_ripping#C2_error_pointers_.28software.29)

Very little of the information written in that link is correct.  After finishing this post I will be removing the offending parts.
Title: Call for capable people to do a comparison of rippers
Post by: mjb2006 on 2010-07-30 10:41:21
http://wiki.hydrogenaudio.org/index.php?ti...xact_Audio_Copy (http://wiki.hydrogenaudio.org/index.php?title=Exact_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 (http://wiki.hydrogenaudio.org/index.php?title=Exact_Audio_Copy&diff=20181&oldid=20180).
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-30 14:16:06
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 19:07:45
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.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-30 19:11:55
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 19:21:27
Thanks Jan.  I will edit the table accordingly to reflect this information.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-30 19:24:17
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 19:51:17
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 21:28:21
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.
Title: Call for capable people to do a comparison of rippers
Post by: spoon on 2010-07-30 22:00:00
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.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 22:16:40
>not a theory it is a fact

You're right spoon.

There needn't be controversy over what is nothing more than a hash change.  My point is that the change is not significant enough to warrant all this extra attention (whether here or on the chart).

>GPL tend to be the least developed

Reducing OSS to secondary status is going to start a war.  Perhaps it would be best that we don't rate this at all.
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-30 22:32:13
>GPL tend to be the least developed

Reducing OSS to secondary status is going to start a war.  Perhaps it would be best that we don't rate this at all.
Or just remove license? I think only thing people care about is if it is free not. At least most people... The rest can check themselves...
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-30 22:39:40
I won't shed a tear to see it gone, but it licensing seems to resonate with a lot of people around here.

I pulled all references to AR versions.  Those interested in providing such information should consider editing the dedicated wiki article.

Seems strange that footnotes are done with letters.  Is this standard?
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-30 22:51:31
I won't shed a tear to see it gone, but it licensing seems to resonate with a lot of people around here.

I pulled all references to AR versions.  Those interested in providing such information should consider editing the dedicated wiki article.

Seems strange that footnotes are done with letters.  Is this standard?
I think it is most common to have footnotes for tables with letters and the references (to other published work or whatever) you put at the end of the document with numbers. This is the way I see it in articles as far as I remember.
Title: Call for capable people to do a comparison of rippers
Post by: Pepzhez on 2010-07-30 23:10:45
There is no proprietary method of cache defeat in XLD. The chart is misleading. XLD defeats cache solely via cdparanoia (by over-reading). Cdparanoia 10.2 can accommodate an audio cache up to 2750KB, in case anyone is wondering.

Also, XLD does indeed perform AccurateRip checking across pressings/offsets. Greynol and I spent quite some time with the XLD developer on this very issue.
Title: Call for capable people to do a comparison of rippers
Post by: greynol on 2010-07-31 00:52:31
Items that are left blank or are vague are in need of more information, like what you just gave.

Thanks!

EDIT: It's been a while since I had that communication and I remember talking to sbooth about it too, though I don't know how far along the implementation has gone in Rip.

What about album art for XLD and the other items that are blank?
Title: Call for capable people to do a comparison of rippers
Post by: Pepzhez on 2010-07-31 04:58:47
Filling in the gaps for XLD --

Image as single file: yes

Gap detection: yes

HTOA: I wish I knew the answer to this. I would love to test this, but I don't own a single disc with HTOA.

Download Album Art: yes
Title: Call for capable people to do a comparison of rippers
Post by: Jan S. on 2010-07-31 11:18:00
Filling in the gaps for XLD --

Image as single file: yes

Gap detection: yes

HTOA: I wish I knew the answer to this. I would love to test this, but I don't own a single disc with HTOA.

Download Album Art: yes
Thank you. Updated.
Title: Call for capable people to do a comparison of rippers
Post by: Porcus on 2012-02-15 10:10:12
One year and a half gone since this discussion, though the wiki says it was modified October four months ago.

Some suggestions:

- There is a line for gap detection and one for offset correction. Is offset correction worth an entire line? I suppose most of us use it only for AccurateRip (/CUETools), and only cdparanoia has offset correction without AR. Is gap detection worth an entire line per se?

- There are other items that I consider at least as important as the previous. Pre-emphasis (TOC only or full subchannel detection, logging or tagging), and defective-by-design modes. I have more pre-emphasis CDs than HTOA-featured CDs, and certainly vastly many more pre-emph'ed tracks than HTOA bonus tracks. And are there any rippers that will automatically copy data sessions on EnhancedCD?

- The OS line: Should "Linux via Wine" be considered worthy of mention at least nearly on par with cdparanoia's "Windows via cygwin"? On the other hand, I am inclined to think that "Windows via cywgin" tells Windows users what they need to know, and "Linux via Wine" is not necessary to tell Linux users what they already know

- The HTOA item for XLD is blank (I see from the discussion that this was considered unknown), but according to the changelog at http://tmkk.pv.land.to/xld/index_e.html (http://tmkk.pv.land.to/xld/index_e.html) it does not work. (Anything above 1 second fails.)

- EAC now supports GD3 metadata (payware).

- Which brings me to the following suggestion: A line (first line following the name!) which for each ripper states what version number the info is based on. Then users can get a clue on where to start reading the changelogs.
Title: Call for capable people to do a comparison of rippers
Post by: Porcus on 2012-10-07 10:11:11
Considering the knowledgebase is open for edit ...

Rip seems unmaintained for three years. (http://sbooth.org/Rip/) When should one consider removing?

Should Rubyripper be included here? Last version last December, at least that is more development than Rip. It has an actively maintained wiki page (http://wiki.hydrogenaudio.org/index.php?title=Rubyripper) with some of the information required.


Re my previous posting, I think the offset and gap lines should be kept, but if one can gather the facts on index points, merge that into the gap detection. (I've found at least one album which has a bonus track in the pregap of track >1.)


On a few factual matters:

- XLD reports to support HTOA. Disregard my previous quote, I text-searched for HTOA and didn't realize it is the burner which does not work.
- XLD reports Windows support via CrossOverMac, not only WineBottle
- XLD fetches metadata from Discogs too

- dBpoweramp: The CUEsheet and gap detection features are now in ordinary release. Worth a footnote that cuesheets are only supported for image files.

- and the EAC support for GD3 metadata (payware) ... not sure how that should be entered. dBpoweramp has a price tag as listed, but I still think a parenthesed remark (payware) looks more appropriate.

- Should pre-emphasis be added as a row, then at least CUERipper is reported to support subchannel detection, and so does cdparanoia and iTunes and WMP?
Title: Call for capable people to do a comparison of rippers
Post by: Porcus on 2015-01-07 08:40:29
* MediaMonkey version 4 claims secure ripping, and employs AccurateRip. I suppose it should have been in? (Version 4 was released in 2011 ...)

* EAC: I have no issues with Easy Audio Copy being listed separately, but one should think of whether (i) to merge it with Exact Audio Copy and use footnotes, or (ii) to move it next to EAC and indicate it is a kind-of-freemium model, and/or (iii) also have separate entries for dBpoweramp free and dBpoweramp Reference (although I think it is a bit overkill).

And, in case the following has not been considered and rejected for the second sentence, "[...] some years ago when the only answer was Exact Audio Copy (EAC).": should one add e.g. "for Windows and the Paranoia library for Linux, both developing already in the late 1990s" before the full stop? It does not matter much apart from a nod to the pioneering work.


- Which brings me to the following suggestion: A line (first line following the name!) which for each ripper states what version number the info is based on. Then users can get a clue on where to start reading the changelogs.


I still think that is a good idea. Below the name, above "Data acquisition", a line "version". BTW, the December 18 2014 beta of EAC seems not to have added anything relevant to the article?