Re: [Libcdio-devel] Re: isrc API?

[Robert William Fuller]

R. Bernstein wrote:
> Sorry. What you have looks fine. Only thing I'd suggest is to add a 
> MMC command equivalent which seems to be a READ_SUBCHANNEL command.
> And then used from the specific drivers (e.g 
> lib/drivers/gnu_linux.c).

Unfortunately MMC READ SUB-CHANNEL is kind of a screwed up command. 
This is what I called the "slow interface" for reading the Q sub-channel 
in the section I wrote for libcdio.texi.  You have to be playing the 
track for it to read the Q sub-channel and you have to have been playing 
the track for a little bit of time.  It's basically the interface that 
is intended for a software player to use to display the current track 
and time.  It's documented in section 5.22 of MMC-3 (mmc3r10g.pdf.) 
Here's what the document says:

"The READ SUB-CHANNEL command (Table 216) requests that the Logical Unit
return the requested Sub-channel data plus the state of audio play
operations. NOTE: Sub-channel data, returned by this command, may be
from the last appropriate sector, encountered by a current or previous
media accessing operation. When there is no current audio play 
operation, the Logical Unit may access the media to read the Sub-channel
data. The Logical Unit is responsible for ensuring that the data
returned is current and consistent."

Alright, so let's parse it.  It basically says that if you're playing 
the disc, it returns the most recent data from the Q sub-channel.  If 
you're not playing the disc, the unit "MAY access the media."  Parse 
that as most implementations will NOT return Q sub-channel data if 
you're not playing the disc.  If you look at the code in cdrdao that 
tries to read the Q sub-channel with READ SUB-CHANNEL, you'll see that 
it starts to play the disc where it wants to read the channel, then 
loops sleeping and re-trying the READ SUB-CHANNEL command until it 
succeeds.  (This is the "settling time" in the "slow interface" that I 
alluded to in libcido.texi.)  Meanwhile, sound may come out of your 
speakers  (Also alluded to in libcdio.texi.)  O, and did I mention it 
only works at normal audio disc playing speed (1X)?

Basically, READ SUB-CHANNEL is a great interface for displaying track 
time when you're playing a disc.  It otherwise sucks.  That is why in 
cued I use MMC READ CD to get the Q sub-channel data.  It works at high 
speed and it doesn't play music.  It's great for ripping. 
Unfortunately, not all drives support reading the Q sub-channel with MMC 
READ CD because that part of MMC READ CD is optional, and there's no 
feature test to answer the question "does MMC READ CD support reading 
the Q sub-channel?"  If the drive doesn't support reading the Q 
sub-channel with MMC READ CD, a number of SECONDS later, you get an IO 
error back.  But that's not good enough, because the drive might have 
been just spinning up, so you should at least try again.  (My solution 
in cued is to have an option -i that tells it whether or not to read the 
Q sub-channel.)

The ISRC codes are in Mode-3 records in the Q sub-channel.  They occur 
in at least 1 out of every 100 frames, according to the documentation. 
That means about every second and a quarter.  This is documented in 
MMC-3 (mmc3r10g.pdf) in section 4.2.3.4.3.  So it will probably take a 
few seconds PER TRACK to get an ISRC code from READ SUB-CHANNEL 
(settling time + 1.25 seconds.)  This is not nearly as bad as trying to 
get pre-gap information this way :-)  So I think it's doable, although 
ugly (plug your ears and get a cup of coffee!)

What do you think is the best way to approach this?  We could try MMC 
READ CD and if it doesn't work, fall back to READ SUB-CHANNEL?  We could 
forget about READ SUB-CHANNEL altogether and don't support getting the 
isrc if the drive doesn't support reading the Q sub-channel with READ 
CD?  In all fairness, most NEWER drives support reading the Q 
sub-channel with READ CD.  However, I do have older drives here that do 
not (circa 2001.)

> On a possibly unrelated topic. I jsut tried a "make test" and seem to
> have gotten an error in running test/check_fuzzyiso.sh:

Yeah I get that too....  I'm not sure what it's about.  p1.bin I added, 
but cdda.bin was already there and is NOT an ISO 9660 image.  p1.bin is 
a copy of cdda.bin.