[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Re: isrc API?
From: |
Robert William Fuller |
Subject: |
Re: [Libcdio-devel] Re: isrc API? |
Date: |
Wed, 19 Mar 2008 23:33:54 -0400 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20071013) |
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.
- [Libcdio-devel] isrc API?, Robert William Fuller, 2008/03/19
- [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/19
- [Libcdio-devel] Re: isrc API?, R. Bernstein, 2008/03/19
- Re: [Libcdio-devel] Re: isrc API?, R. Bernstein, 2008/03/20
- Re: [Libcdio-devel] Re: isrc API?, Peter Creath, 2008/03/20
- Re: [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/20
- Re: [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/21
- Re: [Libcdio-devel] Re: isrc API?, Robert William Fuller, 2008/03/21
- [Libcdio-devel] Re: isrc API?, R. Bernstein, 2008/03/21