上传日期:2001-04-26 09:27:12
上 传 者管理员
说明:  CD工具,使用MSCDEX底层接口
(CD tool, uses the MSCDEX first floor connection )

CDROM.CPP (34078, 1994-01-20)
CDROM.HPP (5733, 1994-01-20)
CDROM.OBJ (19682, 1994-04-19)
CDS.CFG (79, 1994-01-18)
CDS.CPP (578, 1994-04-19)
CDS.EXE (34927, 1994-04-19)
CDS.MAK (781, 1994-01-18)
CDS.OBJ (6255, 1994-01-20)
CDS.PRJ (5422, 1994-01-18)
CDX.CFG (73, 1994-04-19)
CDX.CPP (7615, 1994-01-20)
CDX.EXE (38040, 1994-04-19)
CDX.OBJ (9659, 1994-04-19)
DEVICE.H (3271, 1994-01-18)
IOCTL.CPP (9150, 1994-01-18)
IOCTL.HPP (4427, 1994-01-18)
IOCTL.OBJ (7887, 1994-04-19)
MAKEFILE (1215, 1994-01-20)
README.1ST (4525, 1994-04-19)
TYPES.H (1311, 1994-01-20)

19 April 1994 This package is a freeware source code kit for a CD Audio utility for DOS. It uses low-level MSCDEX functions to do its job. I've been interested in writing a soup-to-nuts CD Audio Windows app for a while and find the Multimedia functions in Windows to be somwhat slow. They're also limited in that they don't support access to all of the housekeeping info (and none of the raw audio data) stored on a Redbook (audio) CD. One of the things I was interested in accessing was the UPC string audio CDs are *supposed* to possess, so that I'd have a completely unique ID for all audio CDs encountered by my program. It turns out that UPCs aren't normally found on audio CDs, but in porting this code to work under Windows I learned a lot of other interesting stuf, but that's another story.... Anyway, CDX (the principal program contained in the kit) is a nice little command-line util for controlling an audio CD from DOS. The version of CDX contained in this archive was created using Borland C++ 3.1, altho with a few minor changes it would work just as well with MS C++. In fact, the 1st cut of my Windows port has been compiled w/ VC++ 1.0 and works very well. The program, as supplied, compiles cleanly and generates no warnings or errors of any kind. This is a real C++ program, altho it didn't have to go that way, because I don't think that "objectifying" the interface has really added to the clarity of the code and the services it provides. I picked up the original sources from the BBS ether, but it was a non-working pile of junk. After a week or so of steady work, I was able to not only get this to compile but I also understood how CD audio programming works and was able to flesh out a C++ framework that seems to make some kind of sense. However, one should be aware that this is still a work-in-progress and there are a few aspects of the project that haven't been fully implemented or (for that matter) completely thought out, since I stopped working on the DOS version. Case in point: I noticed, when testing the program on a self-loading, dbl-speed Mitsumi drive, that the program should wait a few seconds for the drive to become ready after loading a disk, so that the TOC can be read on a single pass. The theory of operations is simple. The main program module is CDX.CPP. Its main() fn initializes the CDRom class, then instantiates a CDRom object and issues hi-level commands to that object, corresponding to the types of things a user would want to do w/ an audio CD. The main pgm also displays the CD's TOC (Table of Contents) and the status of the current audio program in progress. The CDRom class translates these hi-level commands into MSCDEX commands via the IOCTL class. The driver program only performs a single hi-level command at a time, but that was all that was needed to get the project started. There is also a trivial program included (CDS.EXE) that shows a minimal use of the classes, which I used to check out a couple of routines (that didn't fit into CDX) and certain MSCDEX status operations. The code has loads of comments, so there should be no ambiguity about how things work. I haven't done anything to support multiple CD drives on a system, altho that aspect of the code can be fleshed out w/ in an hour or two. I've also subsequently discovered that the CDRom::PlayPreview() fn isn't well implemented because it samples the Q-Channel for the end of the audio span and can result in some weird results that may cause the sampling loop to fail. (The 1st Windows port simply lets each preview span terminate before commencing to the next track to preview.) I had to change the memory management scheme for the Windows port and struggled with this for quite a while, hence there is no longer a single source for all versions of the code. One minor improvement implemente ... ...