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.

Poll

Ripping Programs

E.A.C
[ 216 ] (78.3%)
Plextools
[ 4 ] (1.4%)
CDex
[ 47 ] (17%)
Feurio
[ 2 ] (0.7%)
Audio Grabber
[ 7 ] (2.5%)

Total Members Voted: 329

Topic: Ripping Programs (Read 23178 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ripping Programs

Reply #25 –
Quote
No support for CUE sheets. If you swear by CDex and don't want to use EAC, how can you make secure 1:1 copies of CDs?

There is no need to use cuesheets in order to get secure 1:1 copies. You just have to copy tracks, then burn them.

Ripping Programs

Reply #26 –
Quote
I know, and you know I know.  We had a long e-mail conversation on features for the then v1.40 release of CDex at the beginning of the year.

Ah, so it was you?

Heh. Since then, i had lots of issues that prevented me from working on CDex <cough>

Ripping Programs

Reply #27 –
Pio2001:

Quote
There is no need to use cuesheets in order to get secure 1:1 copies. You just have to copy tracks, then burn them.


But does it work if you're copying a live album or a mix CD? I remember getting some notice from Nero when I set the track gaps to 0 sec on a new Audio CD compilation that my burner didn't support this (which obviously is nonsense, because I can 1:1-copy live albums without any trouble, so it *must* be able to write 0 sec track gaps). And I'm pretty certain that I wasn't trying to write TAO.

Or are you saying that a "secure" copy doesn't necessarily have to be an "exact" copy? What I consider a "secure 1:1 copy" must be made in a way that it has no glitches (which is what you'd probably call "secure") and that the track lengths and gaps match the original, so that, for example, FreeDB recognizes the CD (you'd probably call that "exact").

...blah. If it does work allright even with live CDs, I stand corrected.


Roberto:

Don't worry, Andre hasn't been too busy during that time either


CU

Dominic

Ripping Programs

Reply #28 –
I used to use audiograbber until I found out about EAC

Ripping Programs

Reply #29 –
Quote
and once again..,
Quote
I'd never switch to something as inferior as CDex


Where you got that idea, i have no idea.
You get that idea somehow, and then spread it, and then others think it's inferior too. Maybe that's how you got that idea..

Not "inferior", not bad, not ok, not quite good, not good, great. Anyone who's reading this, try it sometime.

SK1 your very wrong as pio & Volc have said CDex is let down (& inferior as a error safe audio extraction program) because it is unreliable IT DOES NOT HAVE SECURE EXTRACTION because it doesn't report all errors so you don't know if your files are error free unless you listen through every_single_one which for most rippers is a bitch. a

It looks like your spreading inaccurate information.

I wouldn't be surprised if 1:2 lightly scratched CD's are not corrected or reported by CDex but then again I only tried it with a few CD's & found it to be unacceptable so I quit using it.

Ripping Programs

Reply #30 –
I'm not spreading any inaccurate info.
CDex HAS secure extraction.
Maybe you don't like it, but it is.
You say it's not secure because it lacks features, and i agree it would be much better if it had the features mentioned here.

Quote
I wouldn't be surprised if 1:2 lightly scratched CD's are not corrected or reported by CDex but then again I only tried it with a few CD's & found it to be unacceptable so I quit using it.


You wouldn't be surprised if it worked badly and wouldn't be surprised if it worked well. So basically, you wouldn't be surprised.
-I- would be very surprised if it worked badly with lightly scratched CDs.

edit: and, i wouldn't be surprised if EAC didn't report some errors. It depends much on the CD reader/writer you're using as well.
I wouldn't completely trust EAC OR CDex to report *all errors* i don't think it's possible.

Ripping Programs

Reply #31 –
Quote
I wouldn't completely trust EAC OR CDex to report *all errors* i don't think it's possible.

EAC verifies the extracted audio to be bit-for-bit copies of the original file.  If it is not bit-for-bit copy EAC will tell you.

Edit: Spelling error

Ripping Programs

Reply #32 –
I understand that argument, but i still wouldn't completely trust it anyway.
Call me a paranoid, but cd audio isn't always read accurately. Error protection does not exist and that's why CDDA CD's contain more data than regular data CD's.
If anyone can prove that EAC *ALWAYS*, *ALWAYS* reports errors it would be nice. But that would be very hard to prove. So, if anyone could prove EAC didn't report an error, it would be good. (i would try to, but have no scratched CD now)

Ripping Programs

Reply #33 –
Quote
CDex HAS secure extraction.
[...]
You say it's not secure because it lacks features.


I say it's not secure because I've had glitches in tracks that CDex claimed to have extracted successfully - an experience I've never had with EAC, as I said above. How can you call that "secure"?

BTW, the fact that it doesn't tell you during ripping when read/sync errors occur has nothing to do with secure extraction - that's just a missing feature. That's not the reason I'm bashing CDex's paranoia mode.

Ripping Programs

Reply #34 –
EAC does not report all errors, with whatever settings. There can always be some undetected ones. However, according to the test at http://www.hydrogenaudio.org/forums/index....=ST&f=20&t=3164 , CD ex full paranoia detects about 10,000 times less errors that EAC.
Therefore I don't understand the argument that EAC should not be used because it is not totally accurate, while the proposed alternative is 10,000 times less accurate.

On the other hand, I'm not saying that EAC is 10,000 times better than CDex, it has some drawbacks, like the slow speed, and the complete slow down when an error is encountered. As we saw, it can also read CDs on which EAC gives up.

Ripping Programs

Reply #35 –
Quote
EAC does not report all errors...

My bad. 

Ripping Programs

Reply #36 –
No, no, what you said is quite true. Saying that EAC reports all errors (in test and copy mode) is like saying that the earth is round. It is true, but from a physical, or mathematical point of view, it is not very accurate.
There was one report of same CRCs with both the same error, by BobHere, and the earth is flattened on the poles.

Ripping Programs

Reply #37 –
hm, cdparanoia is missing in the poll....

Ripping Programs

Reply #38 –
Quote
Pio2001:

Quote
There is no need to use cuesheets in order to get secure 1:1 copies. You just have to copy tracks, then burn them.


But does it work if you're copying a live album or a mix CD? ...

I splitted the thread. This question needed a thread on its own in order to be linked when it'll be asked again in the future : http://www.hydrogenaudio.org/forums/index....=ST&f=20&t=3922

Ripping Programs

Reply #39 –
Quote
You wouldn't be surprised if it worked badly and wouldn't be surprised if it worked well. So basically, you wouldn't be surprised.
-I- would be very surprised if it worked badly with lightly scratched CDs.
Yeh, good one  .

I WOULD be suprised if your a daily user of CDex & have had no unreported glitches after listeing to your ripped CD's. Understand SK1?.

Quote
i wouldn't be surprised if EAC didn't report some errors. It depends much on the CD reader/writer you're using as well.
I wouldn't completely trust EAC OR CDex to report *all errors* i don't think it's possible.

I would  be 99.9% sure that EAC Accurate stream/no C2 with test & copy gives my a perfect rip. It may no be 100% but it's alot closer than CDex (like mp3 @320 vs mp3 @64) but all I mean is people should know that they don't have a "secure" rip with CDex.

A "secure" rip  means it's safe but with CDex you can't be sure the CD is: error free or if it contains glitches so that's not secure. It may contain advanced error correction but it's not a secure rip.

& that's why your spreading inaccurate info probably cos you don't know what secure means.

Ripping Programs

Reply #40 –
Quote
You mean that it has/doesn't have secure ripping capability because you can/can't be sure it reported all errors.
Well then, you're wrong. As mentioned above, with CDex AND EAC you can never be sure it reported all errors. So does any of them have secure ripping, by your definition? No. You claim I am "spreading inaccurate info", well i can claim -you- are spreading inaccurate information by saying that you can be completely sure EAC reports all errors and that's why it has "secure" ripping.
I don't use CDex daily, not even weekly, and i'm not a blind CDex fanatic.
My definition of a secure CD audio ripping software is a software that has capabilities to detect when errors occour, and prevent them. Better, detailed reporting to my opinion doesn't define at all if it's secure or not. I admit EAC has a much better error reporting capability. I've been able to rip some super scratched tracks with CDex and not with EAC, it just wouldn't rip them correctly, wouldn't continue beyond the error. Yes, it reported errors, that it could never fix. CDex with it's full Paranoia mode, took hours to rip the track/s, but it ripped them perfectly. (oh and yes, to me perfectly is not "bit by bit".. it's "i hear absolutely no glitches, i trust my hearing, that's enough for me.")

O.K some points you made are valid.

If you want the highest possible security that your rip is error free use E.A.C. With CDex (even on slight scratches) you may have unreported errors & glitches on your tracks. If your willing to listen over your tracks Cdex can give better results than E.A.C. on hard scratched CD's. Agreed?

Ripping Programs

Reply #41 –
Quote
If your willing to listen over your tracks Cdex can give better results than E.A.C. on hard scratched CD's. Agreed?

I agree with you. 

Ripping Programs

Reply #42 –
Quote
deleted.

edit: seems like some people like pm'ing others senseless insulting pm's.

No senseless insult was made just an observation. I thought the discussion was getting personal & my comments had nothing constructive to add to the thread so I made PM to SK1.

I maybe wrong in some points but I wanted to resolve the discussion & get to an answer that we could agree on so people who read the thread could benefit.

Ripping Programs

Reply #43 –
I use CDex because I don't "like" EAC.  Simple as that :o)  My biggest gripe with CDex at the moment is it is painfully slow for me.  It only rips at about 2x-3x, both on my LG-CD and my LG-CDRW :oS  EAC is around 3 times faster, so this is an annoyance.  Neither can read a cracked cd, so they're not perfect yet :oP
< w o g o n e . c o m / l o l >

Ripping Programs

Reply #44 –
On this Compaq notbook with a Toshiba drive, Plextools 1.15 is so0O much faster than alternatives.  As a piece of news, I can proffer that on October 2 an updating program PT116AUEN.exe was linked to from www.disc4you.de .  But, I'm scared to install it cuz mebbe they thought to cut off those who don't have Plextor...Can anybody set my mind at ease (or warn! ) ?

Ripping Programs

Reply #45 –
O.K I found a CD that EAC reports track quality 100% no errors detected with my plex 24/10/40a, full safety (no C2, cache on).  Plextools detected the errors & was the following:

Code: [Select]
PlexTools V1.16A       Digital Audio Extraction
Copyright (C) 1999-2002 Plextor SA/NV
27 October 2002
---------------------------------------------------------------


Software information
--------------------
Windows 2000 V5.00.2195 Service Pack 3
ASPI Manager: wnaspi32.dll version 4.60 (1021) ( not used by PlexTools )
Description : ASPI for Win32 (95/NT) DLL (Adaptec)

Source
------
ID:0 PLEXTOR  CD-R   PX-W2410A V1.04 (#474971), Read Speed: 14-32X CAV
Disc Type    : Audio CD , 1 sessions, 15 Tracks, 65:45.62
-

Digital Audio Extraction Error Information log
----------------------------------------------

Start of extraction
Extracting track 15    (C:\Documents and Settings\Martin Chiriano\Desktop\pooooooricky\Track 15 - Unknown Title .wav - 03:14)

   28 CU errors in sector 295551(LBA), 65:40.51(MSF), 03:09.54(MSF in track)
Recovery retry  1 :     Errors detected, speed reduced to 10-24 X CAV

   28 CU errors in sector 295807(LBA), 65:44.07(MSF), 03:13.10(MSF in track)
Recovery retry  1 :  All errors recovered

    6 CU errors in sector 295828(LBA), 65:44.28(MSF), 03:13.31(MSF in track)
Recovery retry  1 :  All errors recovered

   71 CU errors in sector 295849(LBA), 65:44.49(MSF), 03:13.52(MSF in track)
Recovery retry  1 :  All errors recovered

   31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
  335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  1 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  2 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  3 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  4 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  5 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  6 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  7 :    31 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  8 :    21 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  9 :    21 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      335 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry 10 :    21 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      124 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
    Errors detected, speed reduced to 8 X CLV

   45 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
  379 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  1 :    40 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      238 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  2 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      190 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  3 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      186 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  4 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      177 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  5 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      177 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  6 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      177 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  7 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      177 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  8 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      175 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  9 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      169 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry 10 :    36 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                      169 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
    Errors detected, speed reduced to 4 X CLV

   34 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
   93 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  1 :    15 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       39 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  2 :    15 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       39 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  3 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       31 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  4 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       31 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  5 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       31 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  6 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       31 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  7 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       31 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  8 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       26 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry  9 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       26 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
Recovery retry 10 :    14 CU errors in sector 295870(LBA), 65:44.70(MSF), 03:13.73(MSF in track)
                       26 CU errors in sector 295871(LBA), 65:44.71(MSF), 03:13.74(MSF in track)
 Unable to recover errors

   66 CU errors in sector 295892(LBA), 65:45.17(MSF), 03:14.20(MSF in track)
Recovery retry  1 :    13 CU errors in sector 295892(LBA), 65:45.17(MSF), 03:14.20(MSF in track)
Recovery retry  2 :  All errors recovered
    40 errors
    Elapsed time: 00:20
1 track(s) successfully extracted
Total Elapsed Time : 00:20


EAC:

Code: [Select]
EAC extraction logfile from 27. October 2002, 20:15 for CD
Ricky Martin / Vuelve

Used drive  : PLEXTOR CD-R   PX-W2410A   Adapter: 2  ID: 0
Read mode   : Secure with NO C2, accurate stream, disable cache
Read offset correction : 98
Overread into Lead-In and Lead-Out : Yes

Used output format : Internal WAV Routines
                     44.100 Hz; 16 Bit; Stereo

Other options      : 
    Fill up missing offset samples with silence : Yes
    Delete leading and trailing silent blocks : No
    Installed external ASPI interface


Track 15
   Filename C:\Documents and Settings\lili.N-RUIRHYWB2UQ0D\Desktop\Maria.wav

   Peak level 100.0 %
   Track quality 100.0 %
   Test CRC A9DE4B56
   Copy CRC A7E5CF31
   Copy OK

No errors occured


End of status report

Ripping Programs

Reply #46 –
EAC has been working fine for me.

Ripping Programs

Reply #47 –
Quote
  • According to Case, the Paranoia mode is complete useless on drives that use caching.


Where is some info about this? I presume it's only valid for CDex and the use of paranoia libraries under windows?

Johan

Ripping Programs

Reply #48 –
Quote
Where is some info about this?


I don't know, maybe Case can tell you more.  I can't exactly remember the thread in which he said this.

Perhaps some of the Linux guys (Jon Ingram, Neo Neko?) can answer your other question... I would be interested to know this too. I'd too be surprised if cdparanoia worked as flawed as that in Linux.

Ripping Programs

Reply #49 –
Quote
Quote

  • According to Case, the Paranoia mode is complete useless on drives that use caching.

Where is some info about this? I presume it's only valid for CDex and the use of paranoia libraries under windows?

I have mentioned my findings in a few threads here, but my tests or texts are never as thorough as Pio2001's. Basically I have only one drive that caches which I have used for testing, and CDex does not detect any errors with it.
I can't say anything about paranoia library under linux, but I sure hope it does better.