Print

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

[NickM]

I am usually in favour of making life as simple as possible, so please tell me there is little difference between MC ripping & Audiograbber....

Having a one-stop shop for everything would be great, but I have been comparing bit rates ( same PC, same CD drive ) and AG still looks better.

Does anyone have a definitive answer on this???

nick

[Mirko]

No.

But I can say something about EAC and MC, which seems to be the same "field of problem": EAC can rip secure and so on (MC may do this also) _AND_, most important, can asynchroniously encode and rip (= ripping goes on and an encoding-queue is build and worked on).

Mirko

[nila]

I can tell you this much.

EAC rips a lot better than Audio Grabber and so straight away that makes EAC the better choice.

Then you have to compare EAC to MC and there have been a LOT of previous discussions on it and threads on it (do a search) and you'll see most people find MC as good (some find it even better) than EAC.

Based on the fact that EAC is better than AudioGrabber and MC is as good as or better than EAC I'd then say that YEAH - MC is better than Audio Grabber.

[rocketsauce]

I have been comparing bit rates

What, exactly, do you mean by "comparing bitrates"?

Also, by default, MC uses the LAME encoder which will give the best sound quality for higher bitrate mp3s.

Rob

[JimH]

EAC can rip secure and so on (MC may do this also) _AND_, most important, can asynchroniously encode and rip (= ripping goes on and an encoding-queue is build and worked on).

MC does both secure rip and simultaneous rip and encode.

[Mirko]

JimH: MC does not encode in a different thread than ripping, does it?

My english is so bad, I wish it would be better - please be patient and let me try to explain:

1. all songs from a CD are ripped -
2. when a wave-file is ripped it is put into a FIFO-queue
3. this FIFO-queue is worked on by the encoder (in the background)
4. I rip the next CD and the new wave-files are put into _the same_ FIFO-queue
5. the encoder takes the next song out of the FIFO-queue (which usually is one from the first cd) on works on that one

to make it even more complicated to explain, EAC allows a max of 4 lame-encoding-processes parallel.

To picture it:

Thread 0 - EAC adds waves to "mFIFO"
Thread 1..4 - lame1..4 take from "mFIFO" and put out mp3s

Does this make clearer what I mean by "asychron"? Does MC really do that? Than that has to be a quite new feature.

Mirko

[JimH]

Have you tried the "rip and encode simultaneously" option?  It's under tools/options/encoding.

I don't know whether it is multi-threaded, but I don't believe that would make much difference in this case.  The bottleneck (limit) for ripping itself is the speed of the drive, so the processor is not used much for that and has time to encode.

Each CD must be finished before the next is begun.

Ripping and encoding to APE is very fast and people often do this to save time, then batch convert all the APE files to something else later.

[nila]

Jim - the feature your talking about encodes as it's ripping - kind of like as one process so the ripping is GREATLY slowed down by the encoding.

What mirko's talking about is like what your saying about ripping first to APE then converting in that EAC rips them all to the hard drive as .wav's and the encoder is then processing them all as fast as it can in the BG converting them to mp3s.
The difference is that all the files ripped are automatically qued up to be encoded without any further user interaction. The way you described requires ripping them all THEN encoding them all (cant be at the same time unless the person wants to keep adding each new ripped track to the converting que.)

The EAC way is unfortunately easier and faster. It'd be GREAT if it was added to MC as a feature. It was talked about alot in the past and I know a lot of users were asking for it.

I'm about to have to rip a couple of hundred CD's as I'm setting up a dedicated Media Machine to use with the TV running MC. I have to put all the persons CD's on it.
With the current ripping options in MC I'm probably going to end up having to use EAC to do this purely for this one feature.  

[JimH]

This has come up a lot in the past and if you separate the speed of ripping from the speed of encoding, you'll find that MC is as fast as other rippers.

Encoding is another story.  Lame is considered better but is slower.

To compare reasonably, you would have to rip to wav or APE with MC and whatever you want to compare.

Have you done that?  I think you're making statements that are opinion not fact.

[KingSparta]

the gogo mp3 encoder is a bit faster and is multi thread, MJ7\MJ6 did support it at one time.

[Mirko]

@Nila: Perfect :-)

@JimH: I can only answer for myself of course, but "faster" in my case does _not_ mean, that the time taken for ripping & encoding for a _single_ songs is lower with EAC as it may be with MC.
It's about sitting in front of the computer if I have to rip a couple of CDs. Choosing MC means: Waiting for one CD to rip and encode and then put in the next one. With EAC I can switch the CDs quite fast (EAC rips one CD and takes the next one, regardless of whether the encoding is finished or not) and let the computer encode the whole mess while I'm watching TV.

Just a couple of days before I did exactly that and had two EAC-processes with 3 lame-processes each. So there were 2 EACs (one for each CD-drive I have) and 6 lames. Each of the EAC had a queue of about 200 songs to encode (no more space left on the temp-drive for the waves). And _this_ takes quite some time to finish. I went to work :-)

I would suggest that you consider such a functionality - sure it is not used that often, but _when_ it comes to the time man has to rip a lot of things _then_ it will pay.
The idea with APE is not so bad really - maybe I will try that in the future (batch-converting is something that is very similar to that acquired with EAC and simultanious lame-encodings). And I know I can use the command-line-lame with MC (tried that last year or so).

Mirko, using EAC + lame 3.93-command-line for this until now

P.S. I don't use any special EAC-function besides this one!

[JimH]

Ripping and encoding to APE is very fast and people often do this to save time, then batch convert all the APE files to something else later.

[Mirko]

Ripping and encoding to APE is very fast and people often do this to save time, then batch convert all the APE files to something else later.

Yes okay, I do understand - me not stupid :-)

But it's not the same than encoding all the songs to mp3 - actually first ripping and encoding to APE and then batchconvert to mp3 would take more time in the whole then doing it to wave and then mp3... besides... is it possible to "tag" the wave-files during the ripping-process and then batchconvert the tagged wave-files to mp3? _That_ would be the thing I would like... okay, it would be nice if MC supports both cd-drives...

Mirko, pushing it

[NickM]

Wow - just a short question and already a huge amount of opinion on this - Thanks to all.

I have a fairly limited understanding of the software mechanics, but I so understand the maths - I know that sounds a bit daft, but after all I am only an engineer…

Let’s separate the two issues – ripping & encoding.  The process whereby the two processes can multi task results in a method of optimisation, but doesn’t necessarily alter the end result.

A wav file is unlike a data file.  The hardware readers in commercial disk players make a series of consecutive reads that are combined using an error correction algorithm and slip comparison feedback loop. The result is a non-unique set of data that is translated to an analogue output.

This means that reading a disc once, twice or ten times may result in a slightly different data file.  Programs like AG or EAC re-read the disk until they can be certain ( within a quantifiable margin of error ) that consecutive reads are the same.

So the first difference is in the parameter ( or accuracy ) settings that these two applications offer compared to MC.  If time is not of the essence then specifying a 99.9% similarity of successive reads may obviously increase the ripping time – especially if the disc is of poor quality.

As the ripped file is produced, encoding can take place synchronously or asynchronously.   This means that by setting a high accuracy parameter, there is no point in encoding until the last definitive read is made.

Once the base file is accepted, it can be split into different parts for encoding.  Given the processing power and multi thread capabilities, as has been already covered, a fairly standard PC can encode a few streams concurrently.

Without digressing into the codec comparison discussions, the reason for assuming APE files was for a non-lossy result.  ( All that means is a wav file can be transposed to an APE file and restored back to a WAV file, that is identical to the original – no loss of data. )

Unless there is something dramatically wrong with the implementation, any codec will produce the same end result given the same parameters and the same input.  How it does it is again a function of optimisation ( i.e. speed ) and therefore convenience.

So. going back to the start; MC ripping v.AudioGrabber ( or EAC ), the main issue is how it rips the underlying wav file in the first place.  In order for MC to replace these programs, it needs the flexibility to set the accuracy rates for ripping.  And multi-thread encoding, or simultaneous encoding, is just a convenience that speeds up the process but should not alter the end result.

Sorry, this looks like a very long post, but it is Thanks Giving and everyone should have time to read in peace!  Our turkey was great…

Nick

[Mirko]

I agree - but it's quite important to me not wastíng time waiting for something my computer can easily handle alone. So if I'm waiting in front of the monitor or not _is_ relevant and leads to appropriate software-selections.

Don't get me wrong: I would prefer doing all with one software, if this one software does an excelent job on everything. If it doesn't I choose utilities that do.

Interesting sidenote: EAC can sometimes process badly damaged CDs with "burst mode" but not with "secure mode"...

Mirko

[Sauzee]

Having a one-stop shop for everything would be great, but I have been comparing bit rates ( same PC, same CD drive ) and AG still looks better

Not sure what you mean by this. The bit rates produced by different rippers are not a function of the quality of the ripper, but are a function of the encoder and settings used.

MC is an excellent ripper in secure mode.  See http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=15912;start=msg107760#msg107760  

[kiwi]

Interesting sidenote: EAC can sometimes process badly damaged CDs with "burst mode" but not with "secure mode"...

I guess I fail to see what's interesting about that.  If you tell EAC to not worry about errors and just read whatever it thinks is there, it does just that.  

If you have that same badly damaged CD, and you tell it to read it until it can be sure of every bit, well, it does that.  And keeps rereading every bit.  When it hits an error, it slows way down, since it has to do so so many rereads.  In cases of really bad errors, it can effectively halt.

kiwi

[Sauzee]

I once got a better sounding rip in burst mode than secure mode with EAC with a badly scratched CD's.  It had more audible skips ripped in secure mode.

[Mirko]

So. Now I did my own testing (normal or burstmode, no secure-ripping) :-)

CD used: Boney M - Gold (20 Super Hits) - Tracks 1 to 4

Ripping & Encoding with external MP3 (lame 3.93):
MC: Start: 08:36:30, Stop: 08:40:48, Duration: 00:04:18
EAC: Start: 08:51:20, Stop: 08:55:08, Duration: 00:03:48

Ripping only:
EAC: Start: 08:51:20, Stop: 08:52:09, Duration: 00:00:49

Ripping & Encoding APE (MC):
MC: Start: 08:41:50, Stop: 08:43:10, Duration: 00:01:20
 --> WOW!

Converting APE to MP3 (MC):
MC: Start: 08:44:20, Stop: 08:49:19, Duration: 00:04:59

Analysis:
EAC is a little bit faster when using external compressors (30secs).
MC is a little bit faster when using internal compression (13secs in comparison to EAC-external).
EAC has a queue over many CDs, MC only has one for one - so the user may rip many CDs in a row and let the PC compress over night using EAC and has to wait until encoding finishes with MC.
The way to rip to APE and then batchconvert seems very practical, as the APE-compression is nearly as fast as only ripping - the converting process takes quite some time, but that doesn't matter in an overnight-run, does it?

I decided to rip (& encode) using MC when I have only one CD to rip (reasons: automatically get cover art, automatic audio analysis). Whenever I have more than one I will stick at EAC until MC gets queue-support (this is not meant offending guys, really).

During the analysis I discovered, that MC uses lame 3.93 for internal compression - the files are _exactly_ the same using internal or external compression. This was interesting for me, maybe not for kiwi.

Mirko

[kiwi]

During the analysis I discovered, that MC uses lame 3.93 for internal compression - the files are _exactly_ the same using internal or external compression. This was interesting for me, maybe not for kiwi.

Sorry, I reread my pervious post.  It came across a bit differently than I meant it to.  

It is good to hear that when you take content from the CD and convert it with an internal and external compression that you get the same output.

kiwi

[Mirko]

Sorry, I reread my pervious post.  It came across a bit differently than I meant it to.  

I forgot the " " in my posting, too.

Mirko

[sertua]

The ability to encode in the background while ripping would give a big overall speed jump by getting rid of those times the drive is waiting for the CPU and the CPU for the drive (especially on slower machines).  This has been discussed quite a few times after MJ 8 came out, since the new features had made ripping slower than in MJ 7.  MC 9 didn't change anything to this.

About EAC vs MJ/MC, RemyJ even made a very interesting and rigorous test a while back, which can still be found on line here: http://peakin.com/music/rip_comparison.html.

The differences noted would be greater with older CPU (like my PIII-700), as the difference between the ripping speed and the encoding process should be superior (for exemple in my case, 6x ripping in secure mode vs 1,5x encoding on average using alt-preset standard).  At the fastest MC setting (rip and encode), my drive makes very long pauses waiting for the CPU to encode after a song is ripped, and in turn my CPU will then wait for the drive to rip before encoding.  If MC could have the encoding and the ripping work simultaneously, the overall speed would be faster by just eliminating delays.  The lack of such feature is the only thing that prevents me from abandoning Exact Audio Copy for most of my ripping needs.

[Sauzee]

That link doesn't seem to be working.