Date: Thu, 6 Jan 2000 17:30:35 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: current@FreeBSD.ORG, phk@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: So, tell me again why we can't read audio CDs in SCSI drives? Message-ID: <20000106173035.A39324@panzer.kdm.org> In-Reply-To: <5510.947202451@zippy.cdrom.com>; from jkh@zippy.cdrom.com on Thu, Jan 06, 2000 at 03:47:31PM -0800 References: <5510.947202451@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 06, 2000 at 15:47:31 -0800, Jordan K. Hubbard wrote: > If I stick an audio CD in my SCSI (rebadged Toshiba) CDRW drive > and try to read data off of it, I get the following behavior: > > root@zippy-> dd if=/dev/rcd0c bs=2k of=/dev/null > dd: /dev/rcd0c: Invalid argument > 0+0 records in > 0+0 records out > <and on the console at the same time> > (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 4 0 > (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 > (cd0:ahc0:0:4:0): Illegal mode for this track > (cd0:ahc0:0:4:0): cddone: got error 0x16 back > dscheck(#cd/2): b_bcount 512 is not on a sector boundary (ssize 2048) > > and I've gotten this behavior for quite some time. I didn't *use* to > have this behavior, as my mpeg backups of various CDs done on this > same machine can demonstrate, but if we can't even read data off an > audio CD with dd then you can rest assured that utilities like tosha > aren't going to be able to read data either, and that really sucks. Some drives need a special mode select command before they'll let you read off audio blocks. Some drives use special read CDBs for reading CDDA. Toshiba drives, in particular, need a special mode select command before you can read audio blocks. After that, they use a standard read command. In any case, the point is, reading raw audio data off a CDROM drive is not standard across drives. So I'm surprised that you could ever read audio tracks off your CDROM drive using dd, or anything else that accesses the raw/block devices. tosha and cdda2wav should work, however, since they know about many different kinds of drives and access methods. They may need tweaking to recognize the specific vendor name there, but they should work. (tosha at least has a nice rc file that you can use to tweak this kind of thing) One way that this *might* have worked is if you were using some utility on your CDROM drive that did the special mode select stuff, and didn't reset the mode to 'normal' before you did the dd. That could cause problems with reading normal data CDs, however. > Drive information: > > cd0 at ahc0 bus 0 target 4 lun 0 > cd0: <SAF CD-R8020 1.20> Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 8) > cd0: cd present [227322 x 2048 byte records] > > Controller information: > > ahc0: <Adaptec aic7850 SCSI adapter> irq 10 at device 4.0 on pci2 > ahc0: aic7850 Single Channel A, SCSI Id=7, 3/255 SCBs > > [This is a BIOS-less Advansys controller, used exclusively for the CD > drive. The machine also has dual on-board 7895 wide controllers > which are used just for disk in order to avoid mixing wide and narrow > devices in (what I consider) less-than-elegant fashion] You mean an Adaptec controller, right? > I also say "tell me again" because this issue isn't new and I brought > it up back when this first broke. Justin said it clearly wasn't his > code, SCSI device or no, and phk intimated that maybe it had something > to do with the blockdev stuff and then handed me several patches which > didn't have any effect on the problem. All I know is that my FreeBSD-current > box has lost a powerful and popular capability and I'm more than willing > to test patches or work with someone in fixing it. This area of the > kernel isn't my forte', but my love of mp3s may send me in there at > some point if this is still broken as we get close to code freeze. :-) Like I said, I'm not sure how this ever worked properly. Try tosha or cdda2wav and report back on whether or not it works. dd has never been a supported way to read audio tracks, for the reasons outlined above. It may be possible in some situations, but it was probably just a fluke. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000106173035.A39324>