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 54056 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Call for capable people to do a comparison of rippers

Hi.

Over the years and recently (here and here) 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 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
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
Kind of comparison here for secure ripping features: http://wiki.hydrogenaudio.org/index.php?title=Secure_ripping

Call for capable people to do a comparison of rippers

Reply #1
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.
maiko.elementfx.com

Call for capable people to do a comparison of rippers

Reply #2
Did you account for offset and difference in headers when you did this comparison? My guess is no.

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

Reply #4
"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.

Call for capable people to do a comparison of rippers

Reply #5
* 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?

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

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


Call for capable people to do a comparison of rippers

Reply #9
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).

Call for capable people to do a comparison of rippers

Reply #10
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

Call for capable people to do a comparison of rippers

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

  • 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.
  • About accurate stream: maybe we should just forget about that. As far as I know it would be very difficult to impossible to find a recent drive where this is an issue. If you are serious enough about ripping to read that wiki page you wouldn't be using a drive like that anyway.



edit: Do you have a link for "rip"? I can't find it and it is kind of difficult to search for.

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

Reply #13
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/

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

Reply #15
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).




Call for capable people to do a comparison of rippers

Reply #16
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

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

Reply #19
>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).

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

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

Call for capable people to do a comparison of rippers

Reply #22
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!

Call for capable people to do a comparison of rippers

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