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

[R. Bernstein]

Robert William Fuller writes:
 > 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.  

Okay. I was about to try to add a reference in that section to the MMC
READ SUB-CHANNEL (I just changed some all caps emphasis words to @emph{}
emphasis). Probably better though if you could do this. 

 > 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.)

Again somehow I think tis wonderful information should get put
somewhere in the libcdio manual. I don't know where though. 

 > 
 > 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?  

This could work. Some of the drivers already do something like
this. For example see _read_mode1_sector_linux in lib/driver/gnu_linux.c. 

Also note that there is provision for driver settings, get_arg() and
set_arg() so an application or a user can decide how
important/slow/awful it is to allow such different methods. 

So far, folks haven't complained about the fallback approach, although
what may happen and has happened is that folks argue that the default
should be what works for their particular drive. 

 > 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.)

I'm not against that, but the get/set_arg approach would allow for
option this too.