Print

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

[blafarm]

JohnT,

Great work on the ripping software but I have a question; I have 4 CD drives connected to a SIIG PCI-IDE interface (highly regarded to work well with optical drives).

When I launch the ripping app with four discs loaded, all of the tracks are listed but I don't have the option to rip all four CDs in parallel (at the same time) - the app seems to only support serial ripping (one CD after another).

Like many people, I have hundred, if not thousands of discs to rip, and I was actually considering adding another IDE interface to enable ripping 8 discs at a time. Some competing apps allow multiple iterations of their software to be launched so that multiple CD can be ripped simultaneously - but I'd much prefer to use your application and MC9.

Is there a setting that I am missing - or is it possible to enable parallel CD ripping so that users with more than one optical drive can accelerate the long and arduous process of ripping their collection?

Thanks for your feedback.

[JimH]

There is currently no way to do that.  It could cause problems in the quality of the tracks.  It might work on some machines and not others.

[blafarm]

Too bad. Thanks for the response though.

[PhatPhreddy]

While I have no idea if the SCSI drives may present an additional hassle I have happily used EAC (+ Monkeys DLL's) to rip and encode multiple drives (inluding networked drives) simultainiously...

I had 2 drives in one machine and a networked CDR from another ripping 3 dives at once... I thought about bringing my laptop into the mix also but to be honest as I was correcting tags and checking plus getting High Rez cover art all at once it was full time work keeping up with 3 fast ripping drives... Ripped / Tagged / Cover arted over 400 in a weekend...

[blafarm]

PhatPhreddy,
It's entirely possible that I'm deluding myself into thinking that I can process 10 discs at a time but it's the only way I can see to attack the number of discs that I need to rip.

I figured I'd check tags while the next set was ripping and use MC9 to download the cover art. Maybe I'm out of my mind.

[JohnT]

While MC can't do parallel ripping, you can put it in auto-rip mode so you don't have to do a bunch of mouse clicks and hang around for each CD to finish. Just load up the drives, select auto-rip, enable the "eject drive after rip" option. Now you just need to stop by once in a while to swap the CD's in the drive drawers that have opened.

[kiwi]

While MC can't do parallel ripping, you can put it in auto-rip mode so you don't have to do a bunch of mouse clicks and hang around for each CD to finish. Just load up the drives, select auto-rip, enable the "eject drive after rip" option. Now you just need to stop by once in a while to swap the CD's in the drive drawers that have opened.

I wondered what exactly auto-rip did.  That's very handy. I assume that it pretty much rips anything you put into any drives?

How does it deal with disks that don't have proper tag information?  Would the best option be to do the following:  (assuming 20 disks to rip)

for i=1->20
  put disk in, correct tag info, take disk out

(now all the tag information is correct)

start ripping in "auto-rip" mode

for i=1->20
  put disks in to which ever drive is waiting for the disk?


ideally, it would allow you to change the tag information while the other disk was ripping, so any time the drive opened, you'd place a new disk in, correct the information, and then it would know to start ripping.  (It may already do this.)

Also, slightly off topic, is it possible to perform yadb lookups off line?  (maybe by downloading the database, the way one can do with the freedb)  Or, maybe saving "dynamic tags" that would perform the lookup when you were connected to the internet and fill in the appropriate information.  Also, i don't know what's involved, but some other programs can use the bar codes on the CDs to lookup the information.  That could be very handy.

Thanks,
kiwi

[JohnT]

I wondered what exactly auto-rip did.  That's very handy. I assume that it pretty much rips anything you put into any drives?

yep

How does it deal with disks that don't have proper tag information?  Would the best option be to do the following:  (assuming 20 disks to rip)

for i=1->20
  put disk in, correct tag info, take disk out

(now all the tag information is correct)

start ripping in "auto-rip" mode

for i=1->20
  put disks in to which ever drive is waiting for the disk?

That's the way I do it. It's an especially good method if you're on a dial-up internet connection.

ideally, it would allow you to change the tag information while the other disk was ripping, so any time the drive opened, you'd place a new disk in, correct the information, and then it would know to start ripping.  (It may already do this.)

It does this. You can set the behavior of Yadb during auto-rip on the advanced ripping options page.

Also, slightly off topic, is it possible to perform yadb lookups off line?  (maybe by downloading the database, the way one can do with the freedb)  Or, maybe saving "dynamic tags" that would perform the lookup when you were connected to the internet and fill in the appropriate information.

I don't know about the downloadable database idea, but the second idea has been bounced around here and we may do something similar in the next version of MC.

Also, i don't know what's involved, but some other programs can use the bar codes on the CDs to lookup the information.  That could be very handy.

Interesting. I assume you're talking about the bar code on the CD case?

[kiwi]

That's the way I do it. It's an especially good method if you're on a dial-up internet connection.

It does this. You can set the behavior of Yadb during auto-rip on the advanced ripping options page.

I'll play around with it this evening and see.  That would be very handy.

If you have only one drive, and put it in "Auto Rip" mode, does it just sit waiting for the next disk to be inserted?

I don't know about the downloadable database idea, but the second idea has been bounced around here and we may do something similar in the next version of MC.

As always, I can't wait.  Though, just thinking about it, I can imagine some issues with regard to syncing everything.

That said, I'd love to separate out the two processes, that way, I could rip rip rip, and then have a stack of CDs sitting next to me, and go through and have it auto tag anything it can, and then have it let me fix everything else, in a reasonably nice manner.

Also, i don't know what's involved, but some other programs can use the bar codes on the CDs to lookup the information.  That could be very handy.

Interesting. I assume you're talking about the bar code on the CD case?

Yeah, that's my understanding.

http://collectorz.com/music/

They have some very interesting features, if only I could combine it with a good ripping program... and import the information into MC.  I don't know if I can, I just haven't tried it at this point.  I bought the program about 5 or 6 years ago... or so... before the whole MP3 phase really hit.  I wanted it for cataloging my CD collection.

Here's it's lists of things:

# Catalog your CD collection quickly and easily
Insert a CD in your computer, scan its barcode or type artist/title and Music Collector will automatically add it to your catalog.
# Download CD info from multiple sources on the net
Combined info from CDDB, Amazon, AllMusicGuide or AllClassicalGuide results in detailed CD information: artist, title, year, label, track titles. cover image and much more.

[JohnT]

If you have only one drive, and put it in "Auto Rip" mode, does it just sit waiting for the next disk to be inserted?

Yep

[Ce.D]

I may be missing the point completely but...

Having a given amount of CPU power (whether you have a PII or the latest CPU @ lot-a-Ghz), the amount of time for ripping a given quantity of data will be the same whether you do it sequetially or parallelly (maybe some app can take advantage of a dual-or-more CPU board... but who has a 10-CPUs board ?)

I would say it's even better to do it sequentially for two reasons:
1. Avoid memory page faults (thus delays) by swapping processes (at least for single CPU board)
2. Have each CD being processed one at a time, thus freeing each drive more quickly for you to prepare the next CD instead of having to wait for all drive to finish more-or-less in the same time.

Shortly put, sequential or parallel processing, put the CDs in, (edit your tag info), (auto-)launch the rip and go for a coffee: the processing time will be the same ! If you want it faster, dont't buy only CD drives but also CPUs to go with.

[kiwi]

I don't know.  When ripping to APEs, it doesn't seem to take too much processor time.  I was able to rip two CDs at a time with EAC and it didn't really take much longer than ripping 1 CD.

kiwi

[nameless]

I don't know.  When ripping to APEs, it doesn't seem to take too much processor time.  I was able to rip two CDs at a time with EAC and it didn't really take much longer than ripping 1 CD.

Same here.  And memory (read: page faults) was not a problem for me, either.

[Ce.D]

I actualy missed a point ! If ripping to WAV or low CPU-greedy encoding (such as APE), thus using less than 100% CPU per data stream (or, differently put, where DAE speed is the limiting factor), it may be useful to rip simultaneously from multiple drives. I had stucked in my head that ripping always went along with MP3 encoding (that's MY prefered format), which is particularly CPU intensiv (especially for high variable bitrates).

@ kiwi & nameless : you got a point

PS: I used to rip to WAV then convert to MP3... but at the end of the day, you end up with the same amount of time until your files are done with. And ripping "directly" to MP3 allows me to lower down the CD-drive read speed (since it is encoding that slowers down the process) and thus have a much more reliable DAE (especially with bad-shape CDs).

As for the encoding speed, with my "old" PIII @ 1 Ghz + 512MB, I encode MP3 (LAME --preset standard) no faster than 2.5x.
I'm curious how fast can the new CPUs be, especially with the augmented bus speed and high-performance RAM. Anyone interested in comparing (for the "LAME 3.93.1 --preset standard" scenario, for example) ?
Personally, I had the feeling in was not worth spending several hundreds bucks (CPU+RAM+board) to achieve no more than 2-odd times speed gain. But if we're speaking 5-odd times or more...  

UPDATE:
Just went to have a look @ http://www.spec.org ; using the latest P4 @ 3.2 Ghz (lotta $...), it seems I could expect a 3x (integer ops) / 5x (floating ops) perforance gain compared to my PIII... now, as for actual application speed gain (mix of int ops, float ops, I/O access, etc..), I wonder... and I don't know if SPEC's benchmark go deeply into the MMX domain (one would need to read and understand their benchmark's description better than I do)

But sorry ! I'm disgressing from the original topic of this thread. If everyone interested to follow the matter, let's start a new thread.