[rescue] suitability for use question

Sat Mar 6 00:39:33 CST 2004

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.... 
> 
> My original plan was to use my SparcServer 1000E with 8
> 85MHz Supersparcs each with 2M Cache, and the system with 2G
> of RAM....
> 
> I was originally planning on bladenc, then lame, and now am
> looking at notlame.
> 
> I also have other boxes at my disposal including:
> 
> SGI Octane (1 225MHZ R10K)
> Ultra 60 (450MHz single)
> Athlon 650
> Athlon 600
> Dual PIII 933
> Dual PIII 550
> iMac DV Se 500MHz
> Celeron 1.2GHz socket 370 (powerleap slocket on a BX chipset board)
> 
> Given this potential hardware to use... what would you recommend.
> 
> Is notlame the better of the three encoders ?  What bitrate... I
> was originally thinking 128K, but am now thinking 192K (for MP3
> anyway).  What about VBR ?  use it or avoid it ?

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.

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.)

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.

I started out ripping my MP3s at 160 kilobits, then went up to 192 when
I wanted better quality.  Shortly after, I discovered LAME's VBR
capability.  I now feed LAME the following arguments:

-p -v --vbr-new -V 0 --nohist -b 64 -B 320

This is telling it to use the newer of its two VBR algorithms, with a
minimum encoding rate of 64 kilobits and maximum of 320, optimizing for
quality over size, no histogram display.  This produces files slightly
larger than a flat 192 kilobit file (for most of my music) that sound
almost indistinguishable from CDs to my ear.

> Which platform would give me the best performance and would it do
> so by ripping and encoding each CD separately, or faster by 
> ripping and encoding 7 in parallel (that was my original idea
> figuring with the 8 procs in the SS1000E that it would work
> out pretty well, but now I'm more concerned with speed and
> since most of my boxes available are uniprocessor I'd imagine
> they are going to be more efficient by encoding sequentially
> (possibly ripping from one disc while encoding another ?)).
> 
> What recommend UNIX tools do you recommend for the ripping ?
> How about pulling cddb information and populating the mp3 file
> with the info ?

The traditional Unix ripper tool is cdda2wav.  However, I strongly
recommend using CDParanoia III instead, a much more capable ripper that
can detect and correct many types of reading error, including making a
good effort to correct out scratches.  It's currently at v9.8; find it
on www.xiph.org.

Consider also using Grip as a front-end (www.nostatic.org/grip) and
possibly DigitalDJ as well (same site, link from the Grip page). Grip
can manage the whole rip-and-encode process for you, including cddb
lookups, and will rip one track while encoding the previous track.  It
can be a bit tricky to get it set up properly for multiple CD drives
(you'd have to run one Grip for each loaded CD drive), but once set up,
it works extremely well and will tuck everything neatly away in a proper
heirarchy just like you want.  This is the setup I use, in fact; Grip,
running CDParanoia III and LAME, and feeding the metadata to a MySQL 
database for DDJ.

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).

-- 
 .*********  Fight Back!  It may not be just YOUR life at risk.  *********.
 : phil stracchino : unix ronin : renaissance man : mystic zen biker geek :
 :  alaric at caerllewys.net|phil-stracchino at earthlink.net|phil at novylen.net  :
 :   2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)   :
 :    Linux Now!   ...Because friends don't let friends use Microsoft.    :