[Paranoia] Force-Read-Speed -- Does It Work?

[R. Bernstein]

Monty asks/reports: 

  Are other rippers/utilities able to set the speed on this drive (eg,
  is there windows software that can do it?)

I don't know about that particular drive, as I don't have one. However
I just did some tests on the libcdio cd-paranoia (version 0.77) from
GNU/Linux with a kernel 2.6.15** and a TOSHIBA drive Model CD/DVDW
SD-R5372, Revision TU53.

There was definitely a difference in overall time and speed reading
using -S1 vs -S64. For a 1:39 track, using -S1 took about 13 seconds
to rip while -S64 took about 7 while the user and system time on both
runs were the same. In neither rip were there errors in reading. To
set the speed on GNU/Linux, libcdio uses the CDROM_SELECT_SPEED ioctl.

libcdio supports issuing MMC commands (if the OS supports it and we
can figure out how to use it). So I changed from using the OS ioctl to
the MMC way and alas this doesn't work. 

Now with respect to cdparanoia (non-libcdio) and -S. In unpatched
sources from
http://downloads.xiph.org/releases/cdparanoia/cdparanoia-III-alpha9.8.src.tgz,
best as I can tell, cdparanoias use the same ioctl, but only for
"cooked" devices (in cooked_init_drive). I also tried the binary had
installed from the Fedora Core 5 RPM (cdparanoia-alpha9.8-27.1) and
the -S option does not seem to work. But my guess is that on GNU/Linux
and my CD-ROM drive it *would* if that ioctl were used.

  In the bad old days, there was no documented way to set the speed on
  an ATAPI (IDE) CDROM drive.  Every manufacturer invented their own
  commands.

As we saw at the GNU/Linux OS level, there is that "set speed" ioctl;
both libcdio and cdparanoia have user-callable routines to set the
speed. So in theory all of this mess can be hidden from the
user. Good.

At present cdparanoia does better in this kind of drive-idiosyncrasy
customization, (drive_exceptions.h), but there is much room for
improvement.  Relevant here is the fact that, at present, there is no
field to specify a custom "set-speed" routine. Also ideally there
would be a way for the user to be allowed to somehow influence this
choice, because new models get added all the time and, let's face it,
cdparanoia releases aren't all that frequent. (This kind of user
customization is a real pain from the user's standpoint - think X11
server customization - but it's better than having things be broken.)

  Since about 2000, the MMC spec for CDROM drives has specified a speed
  set command which is optional.  Drives are not required to implement
  it, or may accept the command but ignore it (the smile/nod/ignore
  option).

As mentioned above, yes, libcdio does make this available to
applications. And yes you are right that either my drive uses the
option you've mentioned or (equally likely), I've got a bug in my
code).

  So, it's possible you can't influence the speed of the drive at all.
  If other software can do it, though, and CDParanoia doesn't know the
  necessary (non-standard) command (-S uses the standard command only),
  I'd be interested in trying to reverse engineer a commandset that
  works.

There's something here that's a little sad. With all of libcdio's
flaws and it does have many, it was put together as a placeholder for
this kind of common wizardry "set speed" stuff. But many of the
projects that could benefit from it really haven't been all that
interested let alone supportive. Rather they would just like to find
some other project out there that's figured out how to hack it, and
copy that rather than say contribute to a common base that all
projects could use. For all I know, xine or mplayer may have figured
out the magic command for some OS's and some drives.

Let's say you reverse engineer the magic command. The "official"
cdparanoia sources at present support GNU/Linux. And alas there isn't
a coordinated federation of "cdparanoia porters" for other
platforms. I think I've seen 4 cdparanoia ports for OSX (including
libcdio), and guess what, they *all* suck.

But I have two opinions at least on any topic. Forgive me for letting
my frustration show. Okay, great - you find or reverse engineer the
magic command, and I'll then do the same thing that happens in all of
those projects in the preceding paragraph I was criticizing and copy
that over to libcdio. And then those multiple applications on multiple
OS's will be able to use that wizardy too.


** Ooops: 2.6.16 just came out - another day, another Redhat Kernel release