From: "Martin G. McCormick" <martin@dc.cis.okstate.edu>
To: blinux-list@redhat.com
Subject: Plextor Plexwriter Another Question
Date: Fri, 04 Jan 2002 08:19:20 -0600 [thread overview]
Message-ID: <200201041419.g04EJK260079@dc.cis.okstate.edu> (raw)
I am also working on installing a Plextor CD writer on my
Debian Linux system. The biggest problem I have run up against
is a little discontinuity in documentation. I built a kernel
an answered yes to SCSI emulation as well as yes to SCSI CDROM
support and the kernel build went properly as far as I can tell.
I haven't yet actually put the Plextor in to the system
because I know for sure it won't work until I get all the SCSI
issues solved.
The documentation for cdda2wav which extracts .wav files
from CD's says I should use cdrecord -scanbus to find out about
my SCSI devices. When I do that, I get an admonition to use
cdrecord -scanbus from cdrecord;-- sort of like calling 911 and
getting a recording that says to call 911 for help.
There is also a mention in the cdda2wav documentation of
a script called scan_scsi.linux which is supposed to tell all
about what devices one can use. I can't seem to find that
anywhere except for that mention.
This all leads to one final problem which is due, I hope,
to my not knowing the proper SCSI device to use for the IDE CDROM
drive.
If I use cdda2wav -e -D/dev/cdrom, it all tries to work.
This option for cdda2wav is supposed to pipe the digital data
from the CD track right to the sound card.
What happens is that cdda2wav generates a complaint that
this is not the native SCSI channel so cooked mode is to be used.
What I get are brief segments of audio with a scratchy
buzz that I think is related to the raw CD data. It could be
about 75 pops per second. You don't really hear it as a buzz so
much as an interruption in the audio. It's definitely not proper
CD decoding.
My sound card plays other known good wav files properly
so it is the ripping process that is broken at this time.
Also, while all this is going on, the mmotor on the CDROM
drive races and slurps up a buffer full of data which get played
with the static. Then everything falls silent and another shot
of data is loaded and briefly played.
This all makes me feel kind of stupid except that I am
hoping I am just using the wrong representation of the SCSI
emulation.
These various drivers are optimized to do specific things
and I think I am using a SCSI driver that is meant for data
rather than the specific application of audio.
The directory and table of contents information on the
disk come through with no trouble. I haven't read a CD with any
text on it, but normal music CD's have a calendar display of
playing times, etc, and there is no evidence that anything is
wrong with that part of the process.
So my last questions follow: How do I find out the name
of the correct SCSI channel to use? Where do I get this
scan_SCSI.linux script or anything that will point me to the name
of the right device.
Martin McCormick
next reply other threads:[~ UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
Martin G. McCormick [this message]
` Willem van der Walt<vdwaltw@health.gov.za>
` Brent Harding
` Willem van der Walt<vdwaltw@health.gov.za>
Martin G. McCormick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200201041419.g04EJK260079@dc.cis.okstate.edu \
--to=martin@dc.cis.okstate.edu \
--cc=blinux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).