[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] libcdio - mode detection - linux

From: R. Bernstein
Subject: [Libcdio-devel] libcdio - mode detection - linux
Date: Tue, 30 Nov 2004 04:42:16 -0500

Justin B Ruggles writes:
 > Rocky,
 > I wasn't sure if this message should be sent to the libcdio-devel list 
 > or to you, so I figured I would bounce it off you first.  


 > While writing 
 > a program to examine svcd's (I know there is already vcdimager.  I just 
 > wanted to make one myself as a learning tool), 

Perfectly reasonable. 

 > I found that any SVCD's I 
 > put in the drive came up as mode1 for all tracks even though I know 
 > they're mode2.  Libcdio seems to be looking at the TOC info to determine 
 > this.  I'm running on a kernel 2.4.26 and reading in ioctl mode, so this 
 > may have something to do with it.  At any rate, my suggestion is to make 
 > the get_track_green function more accurate by reading the 1st sector of 
 > the track in raw mode (2352 bytes) and examining the header to determine 
 > the mode for that track.  

Seems also reasonable. 

 > This seems to do the trick for the SVCD's I've 
 > tested.  I could write a patch for this if it sounds like a good idea to 
 > you.   Also, have you considered adding any functions to examine mode2 
 > subheaders or is that outside the scope of libcdio?

I've known for a while that get_track_green is flaky and a bit OS
specific. (Actually a lot of things in libcdio are. I've been amazed
however at how few people notice enough to mention it.)

The get_track_green routine is probably less flaky for for CD images
where one has to specify the correct mode somewhere in the CD

I haven't considered adding internal or external functions for examing
the mode2 subheader. My understanding of how the funny thing that is
done in GNU/Linux works is precisely by checking to see of there is a
Q-subchannel reported back; and this seems to be set in one of the
bits in reading the TOC. And given that there is a libcdio way to
issue SCSI MMC commands, that may be a more reliable way to determine
the mode of a track by issing a SCSI MMC command rather than reading
the raw mode and examining the header. But I really don't
know. Experience and testing is probably needed.

As for how to put into libcdio, I'm not sure if this experimental
raw-sector reading thing should tacitly added to the get_track_green
or put in as something the user has to be mode conscious of. My guess,
but it's just a guess, is that if one knew this was very reliable and
couldn't be fooled by some specific data (such as an audio track with
a pattern that looks like a mode2 track), it would just become part of
the routine.

Suggestions, ideas, and *definitely* patches are always welcome.

The truth is that I was hoping for others to get more involved since
really I am not the expert that folks think I am. 

 > Thanks,

No, thank you (in advance).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]