[rescue] suitability for use question

[Curtis H. Wilbar Jr.]

On Sat, 2004-03-06 at 01:39, Phil Stracchino wrote:
> On Fri, Mar 05, 2004 at 11:33:01PM -0500, Curtis H. Wilbar Jr. wrote:
> > For quite some time I've been planning a 'pet' project....
> > 
> > Take a 7 Plextor CD-ROM tower, a system, and turn it into
> > a box that takes 7 audio CDs, rips the tracks and mp3 or ogg
> > (or both) encodes them including using cddb to populate the
> > mp3 data and to organize the resulting files into a hierarchy.
> > 
> > Now... the question is what to use.... 
> > 
.
.
.
> 
> As far as I can tell, notlame is nothing more than someone's binary
> packaging of precompiled LAME compiled without the GTK frame-analyzer
> option.  There is nothing whatsoever on the notlame site to suggest to
> me that the core of notlame is, in fact, anything other than LAME
> renamed, and in fact the site owner admits in his FAQ that notlame is
> nothing more than LAME compiled.

I'll have to look into it... I was only recently told about notlame
by a friend... and he said he prefers it to lame... so I assume he
looked into the details (bad me to assume).

> 
> So, really,the comparison drops down to two encoders -- LAME (whether
> compiled by you from source, or by the "author" of notlame), or
> bladeenc.  Of these two, LAME is so far superior it's not even worth
> arguing about; bladeenc takes four times as long to generate MP3 streams
> of audibly inferior quality.  At 160 kilobits, LAME will encode in
> realtime or better on a Pentium 200.  I encode using 64-320 kilobit VBR,
> and on an Athlon 1800XP, LAME 3.92 encodes using those settings at
> speeds in excess of 20x realtime.  (This typically means a minute or two
> of essentially idle CPU while it reads a track, then a burst of 100% CPU
> for 10-20 seconds while it encodes.)
> 

Are there limitations on players when using VBR ?  I would also like
good compatability, as I may play these using various players from
different programs on different computers (on the network) to a portable
CD player that suports MP3, and possibly even a tiny MP3 player (made
by RCA as I recall... got it free with broadband service).

> I haven't tried encoding on a Sparc machine.  Any of the Intel machines
> you list above would work perfectly well, as should the U60.
> 

Suppose I could always rip a wav, and at least on the machines that
have OSes installed, I could see what encoding performance is like.

>
>
.
.
.

> 
> 
.
.
.

> 
> I don't recommend trying ripping in parallel from your CD tower, because
> I'm betting those seven drives are all on one bus.  You'll most likely
> run into bus-bandwidth issues and probably get data dropouts.  However,
> on a good fast machine with a good single CDROM, Grip can probably
> process a CD for you every ten minutes or less.  My advice is if you
> want to rip in parallel, do it on multiple machines, storing the MP3s on
> a central NFS share and feeding the DDJ metadata to a single central
> database.  (Again, this is how I do it here.)  You'll probably find three
> fast machines ripping one disc each at a time will keep you busy pretty
> much full time swapping CDs and verifying cddb information (ALWAYS check
> the cddb data, a hell of a lot of cddb entries -- and especially freedb
> entries -- seem to be filed by people who either can't read or can't
> spell, or both).
> 

I hadn't even put much thought yet into the scsi chain bandwidth.
Depending on the box I go with I could always use multiple busses,
but yes, the tower is currently wired as one bus.  If I can 
control the read speed though, I think the bus could handle 7 
simultaneous rips at 4x, 6x, and possibly 8x (but that would be
pushing it).  I based this on 600k X 7, 900k X 7, and 1200K x 7
and knowing there is 10M/sec on the buss...  although, if I use
a PC, I wonder if the UltraPlex 32s do Ultra SCSI... which would
give me 20MB/sec on the narrow bus and possibly jump what I could
handle up to 12x.... ???

Even if I didn't do them in parallel, I'd like to load up 7
discs... and have something do all the work sequentially... so
I don't have to load and unload, and attend to the software
one disc at a time.

Thanks for the advice and info... will have to go looking,

-- Curt