EAC Secure Mode Ripping is Slow

Topic: EAC Secure Mode Ripping is Slow (Read 5455 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

EAC Secure Mode Ripping is Slow

2004-02-28 18:59:35

For several years I have exclusively used EAC in the secure mode for all audio extraction. The latest version of EAC is the most stable and bug free of all.

On my last drive, an LG GCE 8160B, EAC would eliminate a severe click on a particular track where there was a scratch. No other ripper that I tried could do that. Last week I purchased a Liteon 811s DVDR. Suddenly, audio extration using the EAC secure mode is very slow. About 3 or 4x realtime with the Liteon vs 12x with the LG drive. On my machine this is slower than encoding with lame 395.1 APS.

Some searching of these forums revealed that other Liteon drive owners have a similar problem and that it is caused by EAC's secure mode treatment of the caching of audio data. Similarly the audio data cache is said to render the full paranoia mode of CDEX useless.

Being not too hapy about the prospect of spending 20 minutes to rip an album, I tried the EAC burst mode on the problem track and the result was no audible click. Then I did the same thing with Foobar2000 .8 and got the same good result.

Now I wonder, are some of these new drives so good that I don't need to bother with the secure mode anymore.

Being free of the secure mode has more advantages than just the extra sppe of burst mode ripping. As the secure mode is unique to EAC, not needing it opens up the field to other software. Even with having to use .7 legacy support the integration in Foobar2000 is really nice and considerably more convenient than EAC. Furthermore, EAC is a bit inconvenient to use with the now getting popular AAC encoders as there is no way to keep console windows from opening up allover the place when encoding with the "cmd.exe /c" type of command line necessary with Nencode or FAAC. Finally, EAC seemed to work best on CD's that were just a little bit damaged, like the one I just tested. On the really messed up CD's EAC would just bog down. I am not interested in spending 8 hours to get an error free rip.

I realize there are people out there that insist on bit for bit perfect rips. For me, If I can't hear the clicks or pops the job is done. As it is, the audio CD is designed to play back with errors so long as they stay inaudible.

So what does the rest of the HA community think about this issue, especially those of you with Liteon drives.

EAC Secure Mode Ripping is Slow

Reply #1 – 2004-02-28 19:07:43

I have mixed feelings about EAC.. for perfect, like-new CDs other rippers or burst mode give much better speeds with the same results.

For badly scratched CDs it doesn't help much.. trying for minutes spinning up and down, then proudly proclaiming "there were errors" and you end up over-reading the errors in burst mode anyway and hope the unavoidable clicks are not too severe

I found secure mode useful for mildly scratched CD's though, there it can grab a "perfect" rip where others would fail.

The point seems to be, if (properly set up) secure mode reports an error-free rip, you can trust it

EAC Secure Mode Ripping is Slow

Reply #2 – 2004-02-28 19:17:36

EAC main goal is not quality, but security. If CD and drive are both OK, output files should be the same on most tracks. Most times: it means that even with perfect conditions, some problems might appear. With EAC, you're informed about the problems just after the ripping process end. With other software, you have to discover them. That's for me the big difference.

EAC (or probably plextool too) is important if your purpose is archiving. But for casual listening, portable use, etc... other software or EAC Burst are OK. Nobody will die for two glitches happening while listening music in the street... if you're unhappy with bad rips, just encode this track again in secure mode.

EAC Secure Mode Ripping is Slow

Reply #3 – 2004-02-28 19:21:22

It comes down to personal preference: I'm a really paranoid person, so burst-mode extraction is nothing I'd ever do.
If you can live with the possibility of glitches in your extracted files, use burst mode or any other ripper you like.

EAC Secure Mode Ripping is Slow

Reply #4 – 2004-02-28 19:53:14

Personally, I rip using Burst mode. However, I do this with the "Test and Copy" option. If the CRCs match up at the end of the rip, I'm satisfied that everything's ok. If the CRCs don't match for a particular track, I'll re-rip it using Secure mode. So, I guess I'm not really that paranoid.

Even with "Test and Copy" using Burst mode, ripping is about 3-4 times faster than just using Secure mode. Ideally, I'll rip once (to FLAC) and never have to touch my CDs again, but if I notice a click a year down the line I figure it's not going to kill me to dig up the CD and try re-ripping it...

-Aaron

EAC Secure Mode Ripping is Slow

Reply #5 – 2004-02-28 20:06:00

you have other faster secure modes like "Test and Copy" in EAC, or CDDAE, which does something similar (I don't like it very much). I use an intermediate option, which is reporting C2 errors in Feurio. If there are no C2 errors reported, then I know that extraction was exact. And this is done in burst mode. If there are errors, then you can extract with EAC secure mode.

EAC Secure Mode Ripping is Slow

Reply #6 – 2004-02-28 21:43:17

@Atreus

Thank you for telling me what test & copy is. It took me a while to find it on the drop down menues.

On the problem track using burst mode test and copy ran at 4.5x raeal time, taking into account that the extraction must be done twice. Trying secure moce, I gave up after 15 minutes halfway into a 00:08:30 track with a bad section of about 20 seconds in it. Trying a "normal" track from the same album and adjacent position the secure mode ran at 10x and test and copy 12.5x taking into account that two extractions must be done.

The real time savings would be on the tracks with problems that can make it through the burst mode. If you are concerned enough you could go look at the EAC logs and listen to the tracks in question. I used to do this, but found audible problems to be so rare that I no longer believe it worth the time, and I have a lot of time.

This only reinforces my belief that some of the latest drives do audio extraction well enough to leave the whole thing to burst mode and not worry about it. There may be an audible click or pop every now and then, but you probably could not do anything about it anyway, and it is just not worth the effort.

@sony666

Interesting name. Your experiences are similar to mine. It is just that with audio caching the problem becomes more extreme.

What it boils down to (for me) is that the choice of extraction program has more to do with interface, seamless support for codecs (including the troublelsome AAC codecs) and other features. At the momnt I like Foobar2000 the best as it can fix a lot of tagging problems. The other good one looks like Dbpoweramp.

Again, I have to wonder if people are shying away from things like iTunes or WMA due to a lack of EAC compatibility. (Yes, I realize ther are a lot of other negatives in the HA community regarding WMA and its closed architecture.)

EAC Secure Mode Ripping is Slow

Reply #7 – 2004-02-29 01:13:29

One issue I have always had with the "Test and Copy" mode is that there is no way to compare the crcs afterwards if you use "Eject CD After Extraction". What would be nice is if Andre implemented an equal crc confirmation for the Test and Copy mode, so that if you are ripping a lot of cds, you can know at a glance if both rips successfully had the same crcs, and still have the cd eject automatically to save you some time.

EAC Secure Mode Ripping is Slow

Reply #8 – 2004-02-29 01:57:52

CRC are reported in log files. Just ask to EAC to automatically create one after extraction.

exemple:

Code: [Select]

Track  3
     Filename C:\Mes nouveaux rips\Haydn\Concertos pour violoncelle (Coin)\03. Track03.wav

     Peak level 76.0 %
     Track quality 99.9 %
     Test CRC 7CDF7FC7
     Copy CRC 7CDF7FC7
     Copy OK

EAC Secure Mode Ripping is Slow

Reply #9 – 2004-02-29 02:15:03

Actually, I do that already, I just didn't know it gave the "Ok" and displayed the CRCs in the log. guruboolez, you are on fire answering my questions tonight. Thanks

EAC Secure Mode Ripping is Slow

Reply #10 – 2004-02-29 12:02:20

I'm in a case where I can't trust burst mode. I have many CDRs, and most of them are dying or dead. I don't know how much longer the new CDRs in gold that I use now will live.
Whatever drive is used, when the CDR is dead, it can't be read. In burst mode, it just spins down, and after some time stop reading and return a read error (I don't know how EAC behaves in this case). But for CDRs not completely dead, the burst extraction goes on, finishes, and the tracks are quite unlistenable. Listen to this example.
I can't know if a CDR is dead or not without either listening to it, ripping it in secure mode, or scanning it with CDSpeed or KProbe. So I rip it in secure mode.

I've got a LiteOn drive too, called JLMS XJ-HD165H, they say it's a LiteOn LTD165 (the box says LiteOn, and the firmware sites give the same firmware to download for LiteOn LTD165 and JLMS XJ-HD165H). I bought it because my Memorex begins to show weaknesses (sometimes it won't speed up, unless I eject, move the CD one millimeter, and reload).
Seeing how slow was the LiteOn, I just put the Memorex back in place, together with the LiteOn that will just play DVDs, and still use it to rip until it dies completely.

EAC Secure Mode Ripping is Slow

Reply #11 – 2004-02-29 14:04:57

@Pio2001

I still have my GCE 8160B, although I am thinking of mounting it another box around here. While the 8160B would extract with reasonable speed using the EAC secure mode, it would produce audible errors where the new Liteon does not produce audible errors on theses same tracks using burst mode in EAC, Foobar2000 and Dbpoweramp, to name a few.

Your point about the gold CD's is well taken. The moral of the story is it takes the right tool for the job.

Anyway, I have slipped into the ranks of those who do not use the EAC secure mode unless there is a special problem. Since the price was right, the application is completly non intrusive and it does not take a lot of drive space, I will not be deleting it from my hard drive anytime soon.

By the way, I have found many of your posts to be very informative.

EAC Secure Mode Ripping is Slow

Reply #12 – 2004-03-04 05:54:33

Quote

CRC are reported in log files. Just ask to EAC to automatically create one after extraction.

exemple:

Code: [Select]

Track  3
     Filename C:\Mes nouveaux rips\Haydn\Concertos pour violoncelle (Coin)\03. Track03.wav

     Peak level 76.0 %
     Track quality 99.9 %
     Test CRC 7CDF7FC7
     Copy CRC 7CDF7FC7
     Copy OK

I thought that something was fishy about this, and now I can confirm it. EAC "Test and Copy" doesn't actually compare the crcs to tell you that it is "Copy OK". So, when using the option to eject after rip, it makes this mode useless, as you would manually have to compare the crcs in the log file, and if there are any differences, you would most definately have to try ripping by Secure mode again, and have to re-insert the cd. So this makes your point, guruboolez, informative, but not helpful in my situation. I guess I will just continue to rip with Secure mode so I won't have to second guess anything...until Andre can implement a feature where EAC verifies the crcs with the Test and Copy mode.

EAC Secure Mode Ripping is Slow

Reply #13 – 2004-03-07 04:34:42

Quote

Quote
CRC are reported in log files. Just ask to EAC to automatically create one after extraction.

exemple:
Code: [Select]
Track  3
     Filename C:\Mes nouveaux rips\Haydn\Concertos pour violoncelle (Coin)\03. Track03.wav

     Peak level 76.0 %
     Track quality 99.9 %
     Test CRC 7CDF7FC7
     Copy CRC 7CDF7FC7
     Copy OK
I thought that something was fishy about this, and now I can confirm it. EAC "Test and Copy" doesn't actually compare the crcs to tell you that it is "Copy OK". So, when using the option to eject after rip, it makes this mode useless, as you would manually have to compare the crcs in the log file, and if there are any differences, you would most definately have to try ripping by Secure mode again, and have to re-insert the cd. So this makes your point, guruboolez, informative, but not helpful in my situation. I guess I will just continue to rip with Secure mode so I won't have to second guess anything...until Andre can implement a feature where EAC verifies the crcs with the Test and Copy mode.

Andre's argument is how can you be sure that the copy has had a read error?

There are three possibilities,

1. Copy had a read error
2. Test had a read error
3. Both (most likely but can't be confirmed)

I think the EAC log shows a "#" when there are CRC mismatches but I'm not sure.

EAC Secure Mode Ripping is Slow

Reply #14 – 2004-03-07 04:52:35

No, Andre is right. Those ARE the three possibilities, and I am not arguing that. All I am saying is that SOMETHING uniquely searchable should be written to the log files if the CRCs differ so you can find out later without actually having to look at each log file, and also / or instead have a message pop up TELLING you that the crcs didn't match. If ANY of those three possibilities occur, it is a bad thing, and you should know about it.

The only other case that could happen is if both crcs match but both were bad rips. That is very unlikely and actually isn't even relevant to the discussion, besides mentioning that it COULD happen.

Notice