Print

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

[rungabic]

Two separate questions for those with advice to give:

1. I'm a stickler for sound quality.  I also want my CD rips to serve as a disaster backup of my CDs (which I'll eventually store offsite).  However, I have about 3,300 CDs to rip  .  So, should I use "Digital Large Buffer" or should I use "Digital Secure" (or EAC) -- even though that will take several eternities to complete, instead of only one.

2. Specifically with reference to .APE encoding, why would someone check or uncheck "Rip and encode simultaneously"?  Is there a difference in the amount of time it takes?  Is one more prone to errors or something?

Thanks!
Brent

[lightnin]

I'll let someone smarter than I answer #1, but as for #2 I usually rip cds a bunch at a time then encode them to ape overnite.

The ripping is *much* faster than the encoding.

Lightnin'

[rungabic]

It seems like .APE encoding is pretty fast.  However, your point is well taken since even 10 seconds or so per track will add up over the course of all the ripping I have to do, so that might as well happen by batch overnight, rather than cut into my ripping time...

Still though -- I'm wondering why the option exists in the first place -- assuming you were not going to batch encode later, why would you want to simultaneously rip & encode versus sequentially rip & encode?  Either there's a reason for choosing one over the other, or it's not a worthwhile option to have in the first place...

Brent

[dragyn]

If you use MC, I would rip with digital secure.

When I rip CDs, I use EAC to make an image file (1 .ape file for the whole CD). Then I make the tracks using a CUE sheet. That's where APL comes in. There's pro and cons for doing it that way. It's just the way I do it for full albums.

[MachineHead]

1) Digital Secure. MC and EAC behave a bit differently when ripping using this settings. MC is faster than EAC. Mainly because it doesn't do a spin-up of the drive between tracks like EAC is prone to.

NOTE: Speed really has nothing to do with the program. It has everything to do with your CPU. If you're running on older processor, the wait is indeed painful.

2) Again this boils down to how fast your box is.

If you want pure speed and quality, just do the file convert mentioned above. Wav is the king of speed as far as a rip goes. The convert files process with MC is simple enough. And you can specify a new folder location for the converted files if you desire to do so.

EDIT:

Still though -- I'm wondering why the option exists in the first place -- assuming you were not going to batch encode later, why would you want to simultaneously rip & encode versus sequentially rip & encode?  Either there's a reason for choosing one over the other, or it's not a worthwhile option to have in the first place...

Not everyone has to go through a huge pile of cd's.  

[rungabic]

Thanks, MachineHead --

As far as #1, I figured I should use secure mode (guess I was just hoping someone would advise me otherwise  )

Can you tell me why when I rip to uncompressed WAV in MC, the track status briefly flashes "Normalized" in between the "Copying..." and "Finished" stages?  I *do not* have have normalized checked in the encoding options.  I want to make absolutely sure that nothing weird is happening behind my back before I start this mammoth project....

Regarding #2, I still don't understand what the difference would be between ripping & encoding (to a format other than WAV) simultaneously, as opposed to sequentially (i.e., it appears to rip to WAV, then encode to whatever, and then rip the next track, etc.)  There's got to be some pros/cons to checking or unchecking this box, otherwise it doesn't make sense to me to have the choice...

One unrelated question that maybe you or someone else can answer for me:  after I rip a CD, the original CD tracks appear to get permanently put in the Media Library under the heading "CD & DVD."  Why in the world would I want a duplicate listing of my tracks that are no longer even accessible, since the CD has long been removed?  More importantly, is there an option I've overlooked to prohibit every CD you stick in a drive from being plopped in there?

Thanks again,

Brent

[MachineHead]

Normalized may be a bug...will check tomorrow to see if it does it here. It shouldn't do that if unchecked. Anyone?

Rip and encode simultaneously is just that. On the fly conversion of wav file to format of choice. Otherwise it is rip to wav then encode to format of choice.

It just keeps metadata info of the cd's. So if you need to re-rip you will not have to go online for cd info. Basically can ignore if you wish. Also note that if you're testing out the betas, the install will often times zorch that info anyway.

[rungabic]

Thanks for checking out the Normalize thing -- seems like a bug, although the question is, is it really doing something, or is it just an errant report?

Regarding the simultaneous vs. sequential rip and encode, I understand the difference -- I just don't understand the rationale between why you'd choose one way or the other -- they both end up with (presumably) the same product when the task is complete.  It seems to me logically that either there must be a reason(s) for checking/unchecking that box, or else it's an option that simply doesn't make sense to exist.

Thanks for the explanation of retaining the removable CD info for local lookup purposes.  That makes sense (although I wouldn't mind an option to disable it).  I would think most people would rip their stuff and never put the CD back in the drive, so it seems to be a waste of space (not to mention sort of confusing).  Anyway, I suppose every 1,000 rips or so I'll just go in there and delete those entries...

Brent

[rungabic]

Omni,

Thanks for trying to explain.  Makes sense, but if that's the case, I'm still left with the question of why you'd ever want to do them serially instead of in parallel.  Maybe if you have some ancient processor, then parallel would choke it?  I have no idea -- but this sounds like an option that deserves some sort of explanation...

Edit:  I just saw your edit about the slow CD-ROM...it all makes sense.  Hopefully someone in authority will come along and set us all straight (and stick this info in the help file )

Brent

[Omni]

(OOPS... I accidently removed the message.  [I clicked too fast and wasn't paying attention.]  Here it is, now out of order in the thread... sorry.)

If you rip and encode simultaneously, depending on how slow the encoder is, you can effectively eliminate the "rip" time from the overall time.

In other words, while the encoder is busy doing its thing on one frame, MC is buffering up the next frame.

If you don't do it at the same time, then the total time is the time to rip (create the WAVE file) and the time to encode (convert WAVE to whatever).

Put mathematically,

Let X = time to rip,
Let Y = time to encode, and
Let Y >= X, then

If done separately, Time = X + Y,
If done in parallel, Time = Y.

Also, for the purists out there, this would only be strictly true if MC were running on a dual processor machine, and it intelligently allocated the tasks to both processors.  But even on a uniprocessor setup, very little actual CPU time is needed to physically read a CD.

Admittedly, this is just an educated guess as to purpose of the option.  I have never actually benchmarked it, so don't flame me if Matt comes along and tells you I'm an idiot.

(Update #1[/color]) Also, the reverse wouldn't be true.  If it took longer to rip than encode (say you have an old, old CD-Rom drive), then doing them in parallel would take longer since the encoder would be spinning idle most of the time.  This is probably why they provide it as an option rather than forcing the choice on the user.

(Update #2[/color])  Theoretically speaking, my update #1 is flawed logically in that no time penalty would be incurred even if ripping was slower:

Let X = time to rip,
Let Y = time to encode, and
Let X >= Y, then

If done separately, Time = X + Y,
If done in parallel, Time = X.

Omni

[rungabic]

Omni,

Now you're just trying to confuse me!  

Well, before long, someone in charge will tell the answer, right?  Anyone?  

Brent

[NanjingGuy]

It seems like .APE encoding is pretty fast.  However, your point is well taken since even 10 seconds or so per track will add up over the course of all the ripping I have to do, so that might as well happen by batch overnight, rather than cut into my ripping time...

Still though -- I'm wondering why the option exists in the first place -- assuming you were not going to batch encode later, why would you want to simultaneously rip & encode versus sequentially rip & encode?  Either there's a reason for choosing one over the other, or it's not a worthwhile option to have in the first place...

Brent

Let's say you are financially challenged. So you have a slow CPU. If you rip/encode simultaneously you will proceed track by track very slowly.

If you uncheck that box the ripping will go on and the encoding will take place later. You should be able to finish the ripping way ahead of the encoding in this case.

I'd also think, in the case of using an external encoder, you might find that setting is the best way to go.

But really, I think that option is in all these ripping apps just because it was in one long ago and everyone just adds it to their tool to be 'fully featured'.

[NanjingGuy]

Two separate questions for those with advice to give:

1. I'm a stickler for sound quality.  I also want my CD rips to serve as a disaster backup of my CDs (which I'll eventually store offsite).  However, I have about 3,300 CDs to rip  .  So, should I use "Digital Large Buffer" or should I use "Digital Secure" (or EAC) -- even though that will take several eternities to complete, instead of only one.


Thanks!
Brent

I do the same here, going to APE for storage and converting to whatever format I need for various devices.

For a project of that size, I'd use EAC in secure mode. Why?

Because I have had problems with the CD ripping in MJ. Others also report problems.

I have random results on getting track/album info from MJ. EAC usually returns data on the same CDs.

Once ripped, it is not that much of a problem to import them into MJ.

Doing 3300 CDs is gonna be a chore no matter what. But you'll be very happy you took the time to do it right once you are finished. Have fun!

[zevele10]

Maybe a kind of answer from Mister Average will do:

Rip&encode == put the cd in the drive  ,when your drive opens === you have the format you need --APE,Mp3 ,OGG ect-
IT IS FINISH FOR GOOD - Nothing more to do ,put your cd back on the shef.
This will take the time to rip ==fast -and the time to convert == slow.
So you need 'fast+slow' time.

If you rip only first ,you need only "fast" time.

The convert "slow" can be done other nigth ,or when you are at work.

Means that when at your computer you can rip XXXXX cds in one hour
But rip&convert only XX cds in the same among of time.

IMPORTANT

If you convert after - night or when at work- do not forget to set MC TO DELETE THE ORIGINAL FILE AFTER CONVERTING.
If not you would have the wav AND the APE for each cd.

Now ,i assume you realise that 3300 cds to APE is ,more or less 350/450 MB for each cd.

You need a LOT of space

[rungabic]

NanjingGuy,

Thanks for the info -- I hadn't heard of people having problems with ripping from MJ/MC....but I certainly could use EAC and then import -- just an extra step.

Zevele,

I know what you're saying about batch encoding *later* to maximize ripping time.  But the checkbox for rip & encode simultaneously doesn't have anything to do with that. If you uncheck it, it rips & then encodes sequentially *within the same session* track by track.  The way to do what you propose is simply to set encoding on rip to "WAV."  Then you can batch encode later.  That's what I'm gonna do anyway, I'm just curious why the option exists...again, I'm surprised someone in the know hasn't commented on this thread yet.  But Omni's discussion of CPU vs. CD-ROM speed might be on the right track...

As far as the relative speeds though -- ripping in secure mode is SLOW.  Encoding to .APE is *FAST* (like 10 seconds per track).  So it's the ripping that's the time-killer in this scenario.

As far as the space I'm gonna need -- I know....I'll be building a RAID5 array -- at least 1 TB, maybe 2...

Brent

[zevele10]

OK

I did from time to time kind of "operation massive rip"..Not close to your 3300 number,but few hundreds cds . From friends ,means you cannot keep such a number for a long time. You really need to give them back a soon as possible.

Here are some tips:
- get cd infos for all of the cds BEFORE you start to rip. You may need to use more than one program to get them,Really a mess to go from one to another and back to your ripping program.
Beside it ,if you have all the cds infos , you can set MC to rip as soon as the cd in the drive.

-Give a break to your drive each 10/15 cds you rip.
If both of your drives are good , use the second one when giving a break to the first one

-Every 20-25 cds ,run a cd lens cleaner cd. This is of great importance to get your speed allways good.

-Just clean your cds with a special sheet-- dry i mean , liquid needs to be use very rarely.

This is a HUDGE task you will start ,so ,good luck.

PS: 1 or 2 TB....make me dream . I just have 0,6 TB and not more room left allready......

[lightnin]

If you want pure speed and quality, just do the file convert mentioned above. Wav is the king of speed as far as a rip goes. The convert files process with MC is simple enough. And you can specify a new folder location for the converted files if you desire to do so.

Ah yes...I forgot to mention that...it was late.  I do rip everything to WAV then I encode to APE.

Lightnin'