From alsa-user-owner@alsa.jcu.cz  Wed Feb 10 03:43:13 1999
Received: from cs45-196.austin.rr.com (mail@[24.93.45.196])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id DAA16643
	for <alsa-user@alsa.jcu.cz>; Wed, 10 Feb 1999 03:41:45 +0100
Received: from rlb by cs45-196.austin.rr.com with local (Exim 2.11 #1 (Debian))
	id 10APau-0006wi-00; Tue, 9 Feb 1999 20:41:40 -0600
To: alsa-user@alsa.jcu.cz
Subject: recording: arecord to stdout? suggestions for real-time compression?
Content-Type: text/plain; charset=US-ASCII
MIME-Version: 1.0
From: Rob Browning <rlb@cs.utexas.edu>
Date: 09 Feb 1999 20:41:39 -0600
Message-ID: <8790e7yo7w.fsf@raven.localhost>
Reply-To: alsa-user@alsa.jcu.cz
Sender: alsa-user-owner@alsa.jcu.cz
Precedence: list


I'm trying to set up my machine to record some things from the radio,
and I came up with a couple of questions.  Ideally, what I'd like to
do is (yes I know that CD quality is overkill for radio...):

  arecord -m -t 1800 - | BladeEnc -b 256 - > something.mp3

However, there are three problems with this:

  1) arecord doesn't seem to be able to redirect it's output to
     stdout.  Is this intentional, or is it just something no-one's
     gotten around to?  If the latter, I'd be happy to volunteer to
     fix it.

  2) BladeEnc doesn't seem to be able to read from a pipe.  I don't
     know if this is a limitation of the algorithm used to generate
     mp3's (i.e. you have to see the whole file before you can
     encode), or a limitation of the program.  Either way, since it's
     closed-source :< (right now, though I thought I heard that was
     changing), I couldn't fix it.

  3) My machine's not quite fast enough to run BladeEnc in real time,
     it's about 30% too slow (so close :>  I bet a good Alpha could
     handle it easily).

So, for now, I'd just like to fix arecord to write to stdout (and
perhaps I'll fix aplay to read from stdin -- real-time filters
anyone?) and then use some lighter weight compression program.  I know
I could do:

  arecord -m -t 1800 - | gzip -9v > something.cdq.gz

which would get a little compression (so far seems like ~10%), but
that's far from the best (even lossless) algorithm for sound.  Is
there something better already available?

(BTW, I have a SoundBlaster 128, which claims hardware Mu-Law.  I'm
 pretty sound file format ignorant.  (Is there a "FAQ" somewhere?)  I
 didn't know if Mu-Law would be useful -- I had heard it was only for
 low-quality recording.  Is that true?  What about the other formats?

    -p <type>     compression type (alaw, ulaw, adpcm)

 Do they only apply if your hardware supports them?
 )

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

