Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[boliver]

Has anyone done a real comparision between EAC (Exact Audio Copy) and MC for CD ripping?  It is obviously much easier to use MC but I wonder if its SECURE mode is actually as good as EAC for creating bit perfect rips.  A recent comparision I guess would be the most important since both of these programs have changed a bit over the last year.

[kiwi]

It's been discussed a few times in the past.  If you search for EAC and Ripping, you might find it.  (Though, eac might turn up too many times... as parts of other words.)  

I think on the EAC site, there's a link to a program that creates a test CD with exact instructions for damaging it for testing.  

I think that the conclusions from the past discussions were that on a non-damaged CD, that there was no difference between the two.  And that for damaged CDs, there again was probably little difference and that in some ways MC was better.    They've added a few more features to MCs ripping in MC 10, including offset adjustment, if you desire it.  And one other thing from memory was that cache size handling for multiple reads was potentially done better in MC.

The biggest thing that I've found in both cases, is that cleaning CDs before ripping makes a huge difference.

Oh yeah, the other difference between the two programs is that MC uses YADB (which seems to be improving recently) and EAC uses FreeDB.  

In the end, I decided that I couldn't prove that either was definitely better than the other, and the simplicity/ease of using MC has won out.

kiwi

[xen-uno]

The consensus nowadays is they are essentially equal. I prefer EAC as it is more flexible in regards to tagging and other external encoder options.

10^-27

[paulr]

A few people have performed these tests fairly recently.  I was one of them.  I'll summarize my results here, but you should be able to find more detail by searching.

Rips made with MC Secure mode and EAC Secure mode and compared in the EAC WAV comparator were bit identical in every case when the CD was in perfect or good condition.  Some of the CDs I tested were in only in fair condition, and they also resulted in bit identical WAVs.

I made a test CD (as outlined on the EAC website) and tried to perform the same test.  The test CD is a severely damaged CD with a single track on it.  The WAV files created from ripping this CD were not identical, but I did not allow the test rips to complete as it was taking, literally, all day.

My conclusion was that for all but the most damaged CDs, there is no difference in the ripped files between MC and EAC.  For severely damaged CDs, there were differences, but I couldn't say which one was more correct...

MC in secure mode is faster than EAC with bit identical results...  I don't believe more recent comparisons would be worthwhile unless something has been broken lately in one of the programs.

EDIT:  I forgot to add that I tested this on more than 10 CDs.  I can't remember the exact number, but it was more than 10 and less than 15.  The CDs varied in quality from perfect (excellent) to fair.

[shAf]

...

My conclusion was that for all but the most damaged CDs, there is no difference in the ripped files between MC and EAC.  For severely damaged CDs, there were differences, but I couldn't say which one was more correct...

I remember posting as if comparisons in quality cannot be made, or otherwise difficult to evaluate.  No reply suffinciently addressed the following.

(1) are percentages as reported by EAC and MC equivelent, and determined the same way?

(2)  I don't believe MC will post to its log exactly where it had problems ... e.g., at 1min:27sec ... so it's difficult to see if either/both softwares had similar problems. (correct me if I'm wrong ... it seems MC has been reporting 100% with respect to my most recent RIPs).

cheerios  

[paulr]

I don't pay attention to the percentages given in the log files.  They probably have different meanings and the EAC ones don't mean anything other than it had to re-read a portion of the CD.  If the EAC log says "No errors" but has a percentage less than 100%, it still means no errors...

The direct WAV comparison, bit for bit, between EAC rips and MC rips is what convinced me.  In all cases (except for extremely damaged CDs) the WAVs were identical.

[boliver]

Is the recommendation for using MC for ripping over EAC also apply to Media Jukebox?  I purchased Media Center but I think I will continue to use the MJ since I like the more streamlined interface.

Is there any difference in quality of rips from MC versus MJ?

[xen-uno]

Different engines fer sure... (MC = EAC) > MJ

[boliver]

Can you have both MJ and MC on your PC at the same time?

[Charlemagne 8]

Can you have both MJ and MC on your PC at the same time?

No. That MIGHT change with version 11 but it hasn't yet.

I've done no exhaustive comparisons but Media Center, Secure Mode works faster and more reliably than EAC on borderline CDs. As has been said, it takes a LONG time to rip some tracks on EAC that are MUCH faster with MC10.

CVIII

[boliver]

For brand new CD's, is the secure mode in MJ good enough?  I.e. will it create perfect rips or was the MJ engine a bit defective?

[Charlemagne 8]

It's been a while since I used MJ but I don't recall any problems. As fully 90% of my rips were back then, I would think I would notice.
The biggest advantage to using MC(J) is that when it's done, all of the importing has been done.
CVIII

[Alex B]

Is the recommendation for using MC for ripping over EAC also apply to Media Jukebox?  I purchased Media Center but I think I will continue to use the MJ since I like the more streamlined interface.

Is there any difference in quality of rips from MC versus MJ?

You can generally trust secure ripping in MJ 8, MC 9, MC 10 and EAC. If those programs say that the ripping was OK then everything was read. Even several rereads are OK if the end result is successful. You can also trust that if the report says that it was not OK then there were errors.

The quality differences are in error correction capability. I guess that MC 10 and EAC are the winners.

There have been tens (maybe hundreds) of corrections and changes in the ripping part of MC during the last about two years. You can read about them here in the forums if you are interested about.

Two old threads for starters:

http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=17476;start=msg120031#msg120031

http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=15912

[Sauzee]

You can generally trust secure ripping in MJ 8, MC 9, MC 10 and EAC. If those programs say that the ripping was OK then everything was read. Even several rereads are OK if the end result is successful. You can also trust that if the report says that it was not OK then there were errors.

The quality differences are in error correction capability. I guess that MC 10 and EAC are the winners.

There have been tens (maybe hundreds) of corrections and changes in the ripping part of MC during the last about two years. You can read about them here in the forums if you are interested about.

http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=15912

The above link is to a thread I started about secure ripping in MC9, which I found to be good.  However....

My experience,with poor quality CD's, indicates that the ripping logs cannot be relied upon in MC10 - I have had rips with errors which were not picked up by the ripping log - and so I cannot recommend MC for secure ripping of CD's in poor condition.  

If the ripping log omits errors then there isn't much point in ripping in secure mode.

I've found that MC is fine for ripping good condition CD's.

See  http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=22200;start=msg154617#msg154617

[Alex B]

I have had no problems with that. Recently I tried to rip some scratched CDs, which were correctly reported bad by both programs (MC 10 and EAC). In one case I was able to rip the CD errorless with EAC after several restarts. The final ripping speed was about 0.2x. I guess that MC gives up earlier. The other CDs were hopeless.

[Alex B]

Sauzee,

I didn't notice that June 25 thread. I was traveling then. I am surprised that nobody from JRiver was actually trying to find out if there was a real bug. No technical answers etc.

EAC reports that my drive is not caching audio. You wrote that your drives do. Maybe that has some effect.

[Sauzee]

Alex B

Interesting points.

MC did report errors on the CD's I ripped........ but there were several errors which were clearly audible on the rips which the ripping log did not pick up, as well.

I'm not saying that MC is poor at ripping in secure mode (I was using some pretty scratched CD's)...... I'm saying that it's poor at reporting all the problem areas of a poor rip.

[hsc]

Hi,

besides secure ripping EAC also supports access to a local free DB for tagging. In my opinion this is an extremely useful feature if your media PC does not have an internet connection.

Hsc.

[kiwi]

Yeah,

Local FreeDB access is very nice.  Though, the local FreeDB files are pretty big.  

[soren]

I must say that the EAC rips to a single bin/cue file is must better then JRMCs way with individual files. This way you can restore the CD exactly the way it was.

The problem is that cue support has STILL not been included in MC, so you have to use Monkey Audios tool to create *.apl files for the bin/cue.
This works but is a p.i.t.a.

BTW.. is the read offset actually correctly implemented in MC?
I have problems using the setting reported for my drive... it always fails on the last track, which probably means that it is off.

/Sören

[Alex B]

Here are two log files from rip attempts of a damaged track:

EAC v. 0.95pb5
EAC extraction logfile from 23. July 2004, 10:32 for CD
Various / The best of Italo Disco

Used drive  : HL-DT-STRW/DVD GCC-4480B   Adapter: 1  ID: 0
Read mode   : Secure with C2, accurate stream, NO disable cache
Read offset correction : 6
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 11
     Filename E:\rip\The best of Italo Disco -  - 11 - Baby Doll - Baby Doll.wav

     Suspicious position 0:02:03 - 0:02:18
     Suspicious position 0:02:21
     Suspicious position 0:02:25
     Suspicious position 0:02:27 - 0:02:53
     Suspicious position 0:03:04
     Suspicious position 0:03:13 - 0:03:20
     Suspicious position 0:03:31 - 0:03:38

     Peak level 95.9 %
     Track quality 92.1 %
     Copy CRC 7F7F49B0
     Copy finished

There were errors


End of status reportMC 10 v.10.0.149
Secure Rip Log created at 10:22:45  Friday, July 23, 2004

The quality percentage is the ratio of the minimum number of re-reads
to the actual number of re-reads of the CD data sectors.

F: The best of Italo Disco - Premio Nobel
   Track  11: Completed with unreliable data - Quality 18,64%  [Baby Doll]
      00:01:51  2 re-reads required to get good data
      00:01:55  10 re-reads required to get good data
      00:01:58  Unreliable data after 16 re-read attempts
      00:02:02  Unreliable data after 16 re-read attempts
      00:02:06  Unreliable data after 16 re-read attempts
      00:02:09  Unreliable data after 16 re-read attempts
      00:02:13  Unreliable data after 16 re-read attempts
      00:02:16  Unreliable data after 16 re-read attempts
      00:02:20  Unreliable data after 16 re-read attempts
      00:02:24  Unreliable data after 16 re-read attempts
      00:02:27  Unreliable data after 16 re-read attempts
      00:02:31  Unreliable data after 16 re-read attempts
      00:02:34  Unreliable data after 16 re-read attempts
      00:02:38  Unreliable data after 16 re-read attempts
      00:02:42  Unreliable data after 16 re-read attempts
      00:02:45  Unreliable data after 16 re-read attempts
      00:02:49  Unreliable data after 16 re-read attempts
      00:02:52  Unreliable data after 16 re-read attempts
      00:02:56  Unreliable data after 16 re-read attempts
      00:03:00  Unreliable data after 16 re-read attempts
      00:03:03  Unreliable data after 16 re-read attempts
      00:03:07  Unreliable data after 16 re-read attempts
      00:03:10  Unreliable data after 16 re-read attempts
      00:03:14  Unreliable data after 16 re-read attempts
      00:03:18  Unreliable data after 16 re-read attempts
      00:03:21  Unreliable data after 16 re-read attempts
      00:03:25  Unreliable data after 16 re-read attempts
      00:03:28  Unreliable data after 16 re-read attempts
      00:03:32  Unreliable data after 16 re-read attempts
      00:03:36  Unreliable data after 16 re-read attempts
      00:03:39  Unreliable data after 16 re-read attempts
The reported error positions are quite similar.


Matt wrote this in last October:

... MC is always caching-drive safe because of how it is designed.  In this respect, it is as good or better than EAC.

However,

As I mentioned earlier, according to EAC my drive is not caching audio data. My guess is that if the drive caches audio data the current MC cannot override that (just in some cases?). That would explain those reports about MC not logging errors. If the problem spot is already read into the drive's cache (with the all possible errors) then MC can read it from the cache without apparent errors. EAC claims to have means to overcome this.

My other guess is that MC's log is perfectly accurate. I don't think that there is any other way to do such a log than directly link it with the actual happenings. I can hear and see (progress bar) when MC makes re-read attempts. Those are also logged accordingly. If the re-reads are unsuccessful that is logged too. That leads to the next assumption: if the log is not reporting anything then no error correction process actually happened. That doesn't say that there were no errors.

Please, correct me if I am wrong with these assumptions. JohnT and Matt, you would be welcome to comment this thread!

[Alex B]

.. is the read offset actually correctly implemented in MC?
I have problems using the setting reported for my drive... it always fails on the last track, which probably means that it is off.
/Sören

Read this: http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=22358

[JohnT]

As I mentioned earlier, according to EAC my drive is not caching audio data. My guess is that if the drive caches audio data the current MC cannot override that (just in some cases?). That would explain those reports about MC not logging errors. If the problem spot is already read into the drive's cache (with the all possible errors) then MC can read it from the cache without apparent errors. EAC claims to have means to overcome this.

MC handles caching drives similar to EAC (but faster and more automatic for the user). It will force the drive to dump it's cache and do actual re-reads from the disk rather than re-read info already in the cache.

[JohnT]

.. is the read offset actually correctly implemented in MC?
I have problems using the setting reported for my drive... it always fails on the last track, which probably means that it is off.
/Sören

Read this: http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=22358

I'll look into how the read offset is implemented in MC. It sounds like there could be a problem from what you describe.

[Alex B]

Thanks for the answers, JohnT

My rips with MC have been correct including the logs. There were some others reporting in this forum that they don't get accurate logs.

For me the accurate log is the most important thing. If I am correctly informed about the unrecoverable errors I can try other ripping methods or try to polish the file with a wave editor or even try to buy the CD again if I like it that much.

P.S. The credit for those read offset findings goes to Roar:

I believe that the EAC offset is measured in samples while the MC offset is measured in sectors a.k.a. frames - each sector consists of 588 samples or 2352 bytes (2 channels at 16 bits equals 4 bytes).

When you use a +6 sectors offset in MC it corresponds to using a +3528 offset in EAC; this is clearly not what you want and is prpbably the source of your problem, since MC is trying to read 3522 (3528 - 6) non-exisiting samples from the end of the last track.

My personal opinion is that the read offset setting in MC should either be removed, or changed to be samples instead of sectors, in order to be actually useful - otherwise problems such as this will arise for people who assume that the offset is measured the same way as in EAC or PlexTools.

BTW I also got bitten by this assumption, but since my Plextor drive has a +99 read offset, the 99*588 samples offset used by MC amounted to 1.3 seconds, so I could hear that the start of some tracks were appended to the end of the previous track! ...so I changed the offset back to 0, and I suggest that you do the same.

- Roar