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: Is it normal for EAC to be that slow? (Read 15116 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is it normal for EAC to be that slow?

Hey, I'm in the process of ripping my CD collection to FLAC using EAC in secure mode. The speed is always stuck around 2X or 3X. Is that normal?
Accurate Stram is checked. I use a portable drive to rip my music, a Samsung SE-208, because for some reason my computer's internal drive has trouble ripping a few CDs. Even though they are new and in perfect condition, ripping takes a lot of time and there are a few glitches in the resulting files. I don't have this issue with the portable drive.

Is it normal for EAC to be that slow?

Reply #1
In case you're ripping entirely mint discs and the CDs are in the accuraterip database, just use burst (either plain copy or copy&test). Only in case the copy&test or accuraterip indicate ripping problems, switch to secure.
In case your drive caches audio data and this option is checked in the drive options, EAC wastes a lot of time trying to thrash data out of the cache.

I have an entirely mint CD of Type O Negative - World Coming Down and for whatever reason, my laptop's slim drive always grabs the last track incorrectly (using burst mode) unless I force the drive to 2x or 4x speed. This is the only CD in my collection where this occurs. I have no desktop drive ATM so I cannot compare.

Is it normal for EAC to be that slow?

Reply #2
You could avoid the manual intervention step by using dBpoweramp. It will first rip in burst mode, and if the rip is verified by AccurateRip then you are done. Only if the rip is not verified will it go on to attempt a secure rip, automatically.

It's not free, but I found it well worth the cost if you do a lot of ripping.

Is it normal for EAC to be that slow?

Reply #3
You may try CUEtools ripper.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Is it normal for EAC to be that slow?

Reply #4
You could avoid the manual intervention step by using dBpoweramp. It will first rip in burst mode, and if the rip is verified by AccurateRip then you are done. Only if the rip is not verified will it go on to attempt a secure rip, automatically.

It's not free, but I found it well worth the cost if you do a lot of ripping.

I agree, and the UI is much friendlier than EAC, but it can also be very slow in secure mode because of the disc or the drive or both. In either program, the drive needs to be configured correctly. The more error correction work the software has to do, the slower the rip.

DAE (Digital Audio Extraction) accuracy/quality varies a lot by drive. Those old Plextors everyone talks about had excellent DAE quality, but no manufacturer bothers with today's cheap drives, especially if they're bundled with the computer. When my old Plextor drive finally died, I went SATA and bought a Sony/Optiarc DVD-RW drive that works pretty well. My more expensive Pioneer BD-RW drive has really lousy DAE and I never use it for audio ripping.

Is it normal for EAC to be that slow?

Reply #5
My old Pioneer (DR-704S plain 36x slot-loaded CD-ROM ) was an excellent ripper (it would even rip "protected" CDs with no problems). My IDE Pioneer DVD-RW drive I have is also great (but my computer has no IDE) - rips at 52x (CAV) burst with no errors on mint discs.

Is it normal for EAC to be that slow?

Reply #6
My old Pioneer (DR-704S plain 36x slot-loaded CD-ROM ) was an excellent ripper (it would even rip "protected" CDs with no problems). My IDE Pioneer DVD-RW drive I have is also great (but my computer has no IDE) - rips at 52x (CAV) burst with no errors on mint discs.


You can get IDE to SATA converters.


Is it normal for EAC to be that slow?

Reply #8
Agree with previous comments, rip with burst mode unless the disc is not in the accuraterip database, will be much faster.  Then if there's a problem, go back and re-rip in secure mode.  Unfortunately I have found that if the discs are bad enough that they won't rip well in burst mode, they're damaged enough that the error correction of secure mode won't fix them in most cases; I have a pile of about 20 CDs that I need to polish and retry someday.

The only exception is if you have a disc that isn't in the database, then I will "test and copy" in secure mode just to make sure.  but that may even be overkill, if the CRCs match you're pretty certain that you've got a good rip.

Is it normal for EAC to be that slow?

Reply #9
<SIGH>

First, regardless of the mode, matching CRCs give you certainty in precision, not accuracy. They are not the same.  Without AR verification secure mode should actually decrease one's confidence in accuracy compared to burst mode with matching CRCs.

Second, the meaning of error correction sure has gotten contorted, now hasn't it?  Except for fixing synchronization errors, EAC performs absolutely no form of error correction, whatsoever. That is left up to the drive. dBpoweramp leaves all error correction up to the drive and assumes there will be no synchronization problems.

Error correction does come back into play with CUEToolsDB. Illustrate has a competing service, or was at least going to have one, though I don't know if it is/was free of charge.  I don't know that online correction databases can be 100% free from consistent errors which can occur through defects, copy-protection, bugs in drive firmware and/or software and lastly cross-pollination from submissions sourced from downloads.

Is it normal for EAC to be that slow?

Reply #10
I have a pile of about 20 CDs that I need to polish and retry someday.
I've been able to rip a disc (DVD) which had a few scratches so bad that the drive could not read it normally. Instead of polishing it, I've used some fluid to (temporarily) fill the scratches and make them transparent. Unfortunately, I don't remember what I used (IIRC oil did not work, maybe it was a spit? . Use at your own risk and with common sense (don't put too much in there, limit the rotation speed etc.).


Is it normal for EAC to be that slow?

Reply #12
Second, the meaning of error correction sure has gotten contorted, now hasn't it?  Except for fixing synchronization errors, EAC performs absolutely no form of error correction, whatsoever. That is left up to the drive. dBpoweramp leaves all error correction up to the drive and assumes there will be no synchronization problems.

That's completely true. Ripping times are dependent on how many times the ripping program tells the drive to try to read the original bits or the EC bits, and at what speed. In my mind (incorrectly, apparently) that's the ripping program "doing" error correction via the drive.

Is it normal for EAC to be that slow?

Reply #13
Each new technology (DVD, BD) has ever smaller wavelengths, there are combo drives which have multiple lasers, to maintain better reading abilities, this diagram shows the differences in size:

https://en.wikipedia.org/wiki/File:Comparis...VD_HDDVD_BD.svg

I hadn't considered that. I wonder if my BD-RW drive would do a better ripping job on a Sony Blu-spec audio CD than a regular CD? I have a couple of those discs, I'll have to mangle one I don't like and try it.

Is it normal for EAC to be that slow?

Reply #14
the ripping program tells the drive to try to read the original bits or the EC bits

It doesn't work that way either. Please google CIRC.

Is it normal for EAC to be that slow?

Reply #15
Cross-interleaved Reed–Solomon coding (CIRC) - Wikipedia

In the compact disc system, cross-interleaved Reed–Solomon code (or CIRC) provides error detection and error correction.[1] CIRC adds to every three data bytes one redundant parity byte.

Reed–Solomon codes are specifically useful in combating mixtures of random and burst errors. CIRC corrects error bursts up to 3,500 bits in sequence (2.4 mm in length as seen on CD surface) and compensates for error bursts up to 12,000 bits (8.5 mm) that may be caused by minor scratches.

. . .

 

Is it normal for EAC to be that slow?

Reply #16
The point is that this is always done by the drive and only done by the drive when it is asked to fetch audio.

I tried to point this out the last time erroneous theories were offered on digital audio extraction:
http://www.hydrogenaudio.org/forums/index....howtopic=100130
I'm guessing it was never read, perhaps because it was binned.