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
Jan S.
post Jul 26 2010, 00:13
Post #1





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



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
Go to the top of the page
+Quote Post
willow
post Jul 26 2010, 12:38
Post #2





Group: Members
Posts: 28
Joined: 15-January 09
From: Russia
Member No.: 65602



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.

This post has been edited by willow: Jul 26 2010, 12:41


--------------------
maiko.elementfx.com
Go to the top of the page
+Quote Post
Jan S.
post Jul 26 2010, 13:26
Post #3





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



Did you account for offset and difference in headers when you did this comparison? My guess is no.
Go to the top of the page
+Quote Post
Jan S.
post Jul 27 2010, 00:22
Post #4





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



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..
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 00:36
Post #5





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



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

This post has been edited by greynol: Jul 27 2010, 00:50


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
Jan S.
post Jul 27 2010, 01:01
Post #6





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



* 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?
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 01:10
Post #7





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



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.

This post has been edited by greynol: Jul 27 2010, 01:33


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 01:18
Post #8





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



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.

This post has been edited by greynol: Jul 27 2010, 01:18


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 07:22
Post #9





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



I've made quite a few updates. Please review my work.


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
spoon
post Jul 27 2010, 10:14
Post #10


dBpowerAMP developer


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



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


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





Group: Members
Posts: 41
Joined: 6-December 08
Member No.: 64023



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
Go to the top of the page
+Quote Post
Jan S.
post Jul 27 2010, 14:36
Post #12





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



I have reorganized the table and added info.

QUOTE (stevenmmm @ Jul 27 2010, 11:42) *
MusicBee supports many of the ripping features listed:
MusicBee added

QUOTE (spoon @ Jul 27 2010, 10:14) *
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?


QUOTE (greynol @ Jul 27 2010, 07:22) *
I've made quite a few updates. Please review my work.
Looks very good to me. You did a lot of work. Thank you. smile.gif
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.
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 16:07
Post #13





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



QUOTE (spoon @ Jul 27 2010, 02:14) *
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.


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 16:09
Post #14





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



QUOTE (Jan S. @ Jul 27 2010, 06:36) *
you added more features for XLD than for cdparanoia. They independently added features?
Yes.

QUOTE (Jan S. @ Jul 27 2010, 06:36) *
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.

QUOTE (Jan S. @ Jul 27 2010, 06:36) *
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/


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
greynol
post Jul 27 2010, 16:14
Post #15





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



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.


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
spoon
post Jul 27 2010, 16:20
Post #16


dBpowerAMP developer


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



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





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





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



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


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
spoon
post Jul 27 2010, 20:16
Post #18


dBpowerAMP developer


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



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.


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





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



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.

This post has been edited by greynol: Jul 27 2010, 20:44


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
spoon
post Jul 27 2010, 20:27
Post #20


dBpowerAMP developer


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



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


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





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



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.

This post has been edited by greynol: Jul 27 2010, 20:47


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
spoon
post Jul 27 2010, 21:07
Post #22


dBpowerAMP developer


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



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


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





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



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!

This post has been edited by greynol: Jul 27 2010, 21:26


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
spoon
post Jul 27 2010, 21:42
Post #24


dBpowerAMP developer


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



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


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





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



I don't see how it could be when the two methods of arriving at any particular hash value are mathematically equivalent.


--------------------
Placebophiles: put up or shut up!
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: 26th July 2014 - 17:44