CDDA Version 1.0a - This is the second public release of CDDA. CDDA - What is it? ------------------ In February 1993, I needed to get some audio samples into digital form on my PC. Toshiba had just released the 3401 CDROM drive which allowed reading of DA frames across the SCSI bus. Because there were no programs available to do this, I had to write my own. I used it to get the samples, and then left it alone because I had no idea anyone else wanted to do this. Some months later CDGRAB came out, but they wanted much too much money for their program, so I cleaned up the program and released it as CDDA09A.ZIP. Note: Some time later I heard from a very irate person who told me I couldn't use the name CDDAxxx.zip because he was already using the name. I've looked everywhere, used ARCHIE, and asked people who seem to know every program on the net, and no one has seen this guy's program. However, in the interest of keeping peace on the net, I have changed the distribution file name to DA2WAV1A.ZIP. The program itself will still be called CDDA. The first release fully supported the Toshiba 3401 CD-ROM drive. I have added the Sony 561/8003/31/33/55, the NEC 2X/3X/4x, the Chinon 535, the Plextor 3028/5028, the Panasonic 562/563 and MSCDEX only to this release. Unfortunately I don't have a Sony/NEC or drivers that allow the MSCDEX part to work. I have given prerelease versions of my program to people who have to some degree had success with other drives. I have no guarantees that this program will work with your drive. Since the release of 1.0a I have heard from people who were having trouble with the NEC 74-1/84-1 drives. So, I went out and borrowed one for a few days. To my surprise the 84-1 didn't work. The next thing I did was get the data sheets for the drive sent to me from the NEC faxback. There is no mention of being able to read DA frames on that data sheet. Next, I reread the NEC programming manual. It says about the 74-1/84-1 drives "Read CD-DA is under consideration of content in the SCSI support commnds". This suggests that it may or may not be supported. Next I called NEC tech support. They told me that "reading digital audio through the SCSI port is NOT supported on the 74-1/84-1 drives. It is supported on the 3x and 4x drives." So, for the time being, I will leave in the code to support the 74-1/84-1 drives. If I don't hear from someone who gets it to work in the next while, I will remove the support and mention it in this file. I have also heard from someone who has a NEC 211 drive. I have no idea what this drive is other than it is a 2X drive. This person has had good success running CDDA. Different ROM revisions cause the drives to do things differently. One version may work just fine and others might not. It is very tough for me to help with drives that don't work, when I don't have one of those drives to work with. If your drive revision is on the bad list, I don't know what to tell you. Perhaps you can make a really big stink with the manufacturer and have them upgrade your rom. Here is a list of known good and bad rom revisions. I will add to this list as I receive reports from the field. good bad ---- --- Sony 561 rev 1.9a Sony 561 rev 1.7x Sony 561 rev 1.8f Toshiba rev 0283 Toshiba rev 2732 Toshiba rev 3593 NEC 211 rev 1.0 NEC 84-1 rev 1.0 Because the Toshiba/Sony/etc. drives need proprietary SCSI commands to read the audio sectors, I chose to talk to the drive through the ASPI interface. I hope that most people with SCSI drives have gone the ASPI route. What drives support DA? ----------------------- I have heard from many different people who say such-and-such drive will read DA frames. The following is a list of which drives which I understand have the ability to read DA frames: (thanks to bwilliam@iat.holonet.net for starting this list) Apple 300, 300i, 300e (Sony CDU-8003, CDU-8003A) Apple CD300+ Chinon CDS-535 NEC CDR 200, 300, 400, 500, 600, 900 series NEC CDR 84-1/74-1 (with special firmware) Panasonic CR-562B/563B Plextor (formerly TEXEL) DM-3028, DM-5028 Sony CDU-561, CDU-31A, CDU-33A, CDU-55S Toshiba XM3301 (Silicon Graphics) Toshiba XM3401, XM4101, XM3501 You may want to run CDROMINF.EXE and have a look at the output. If there no mention of being able to read RAW frames, and/or the RAW READ SIZE is not 2352, there is no chance that CDDA will work using the MSCDEX interface. Also, if it reports that your drive supports reading RAW, that DOES NOT mean that CDDA will work. It all depends upon the person who wrote the driver for your drive. If he/she passes DA frames to MSCDEX, you're laughing. Otherwise, you're out of luck. There are rumors that the Mitsumi LU055 drive will work using the MSCDEX interface, but I have yet to hear specifically what version drive, and what version driver works. If you know or think you know of other drives, let me know and I will do some investigating. How do I use this program? -------------------------- This is a command line utility which allows the user to specify the start and end points of the data transfer and the output type. The start and end points may be entered in one of three modes,: LBA, MSF and track. Logical Block Address mode is the number of the frame from the start of the disc. Minute, Second, Frame mode specifies the time from the start of the disc in actual time. Track mode allows you to dump an entire track (or song) to disk. The LBA and MSF are related by the following formula: LBA = Minutes * 60 * 75 + Seconds * 75 + Frames - 150 The lead in track is usually 150 because there are usually 2 empty seconds at the start of a CD, but it can also be any number +- 75 frames from 150. A commmon number other than 150 is often 182 or 183. The Toshiba and NEC programming manuals define the LBA equation to be as above with -150 at the end. The Sony manual is very vague, and it could be interpreted as either -150 or as -(lead in track). Since two of the three manuals say clearly -150, I have chosen -150 for the Sony as well. I managed to do a fair bit of testing on a Sony 561 drive, and it appears that the -150 figure is correct. If anyone has more precise information on the Sony please pass it along. The /ID option allows you to manually set the SCSI ID of the CDROM drive you want to use. This is useful if my software incorrectly guesses your drive's ID, or if you have more than one CDROM drive in your system. The /MSC option allows you to manually set the MSCDEX drive letter of the CDROM drive you want to use. This is useful if my software incorrectly guesses your drive's ID, or if you have more than one CDROM drive in your system. This option does not force the software into the /M option. The /M option forces the software to use only MSCDEX commands. This may or may not work with your drive. If you don't have a SCSI CDROM drive with ASPI drivers, this is your only hope. This option would be used with the Panasonic CR-562/563, Sony CDU-31A/33A drives. For the options /S /E /F which expect a following parameter, remember that there needs to be a space between the letter and the parameter. ie if you enter /S01:10:10, it would come up as an error, but if you entered /S 01:10:10, it would be correct. For the MSF mode, there need to be 2 digits for each of minutes, seconds and frames or it will come up as an error. When entering the filename with the /F, don't include an extension, as the software automagically adds the extension for you. At present there are only two file formats supported, WAVE and Binary. There is also the option to dump the data in HEX format out to the STDOUT device. The binary format has the samples stored in the order Left LSB, Left MSB, Right LSB, Right MSB. The samples are 16 bit 44.1 KHz stereo. I am not expecting to add options to output files in 8-bit or 22.05 KHz. This is not as simple as just throwing away samples, as this causes aliasing in the output files. Correcting this is way beyond the scope of this program. I am not planning to add many more formats because there are plenty of other programs out there that will do the conversions much better than I can. Besides, the whole purpose of this program was to get the raw data out to the hard disk, not duplicate SOX. On every CD there is a bit which defines if copying a particular track is permitted or prohibited. CDDA checks this bit and will not continue with the dump to disk. I have included an override option /O which forces the user to explicitly specify and to knowingly copy a copy prohibited song. Have look at the file ROYALTY included in this distribution, which was honourably pinched from the program CDGRAB. It is a list of most country's contacts for paying royalties. One thing to remember is that this audio fills up the hard disk fast. It takes between 9 and 10 megabytes per minute of music. Because of this I put in a check to make sure that you will have enough space to put the requested samples. As well there is the /U option which will give you an estimate of how much disk space will be used without actually dumping the data to disk. Examples -------- CDDA /MSF /S 10:14:36 /E 13:55:11 /F outfile /W will dump using MSF mode from 10:14:36 to 13:55:11 to a WAV file CDDA /LBA /S 106232 /E 109443 /F outfile /B will dump using MSF mode from 106232 to 109443 to a Binary file CDDA /T 2 /F outfile /W /O will dump the entire track 2 to a WAV file with the override mode on CDDA /T 2 /U will display the estimated disk space for all of track 2 CDDA /T 2 /H will dump the entire track 2 in HEX to STDOUT CDDA /T 2 /M /F outfile /W /O will dump the entire track 2 using MSCDEX interface only CDDA /T 2 /MSC G /ID 4 /F outfile /W /O will dump the entire track 2 from MSCDEX drive G, SCSI ID 4 CDROM drive What is this jitter business? ----------------------------- The following is a post made over a year and a half ago which discusses the technical reason for a CDROM drives difficulty in accurately positioning itself on an audio CD. -------------------------------------------------------------------------- Newsgroups: alt.cd-rom,aus.cdrom From: adrie@ica.philips.nl (Adrie Koolen) Subject: Re: Reading Audio CDs - Why is it so complicated? Keywords: cd, cd-rom, cdrom, audio, sampling, naivety Organization: Philips Consumer Electronics, Eindhoven, The Netherlands Date: Fri, 19 Feb 1993 08:23:53 GMT Lines: 63 In article dce@smsc.sony.com (David Elliott) writes: >In article <1993Feb17.213223.24058@isa.de>, schwarz@isa.de (Diemo Schwarz) writes: >|> What I don't understand is: >|> Why should it be so difficult to extract pure audio data from a CD? > >It isn't. The problem is that the SCSI controllers in most CD-ROM >drives simply don't support it. > >|> The medium is structured by tracks and indices, isn't it? > >Yes. Note that the `tracks' on a CD aren't layed out like tracks on a hard disk. The track and index are just numbers that are stored with each sector on the CD (in the Q-subchannel packet). The start address of a track is stored in the Table Of Contents on the CD, indices are not. Indices are normally not used, except index 0 for the 2 seconds pause at the start of each track. The REAL structure of the CD medium is a large continuous spiral, starting at the center of the CD (at 46mm diameter). Finding a specific sector is not as trivial as it is on a hard disk. You'll have to employ a kind of binary search algorithm. Finding the start position of a specific index is even more difficult as you don't even know where it starts. >|> And every CD player somehow manages to ship the data from the disc to >|> the D/A converter, doesn't it? But at the DAC, they don't know which sector the sample came from or what the relative position the sample takes in a sector. >|> So, what's the difference between reading data CDs and music CDs? > >The format of the data, to put it simply. Well, most decoders used in audio CD players, output a stream of samples and sub-channel data, mostly used for their time code. As the decoder has to adjust the spindle speed, it uses a FIFO to store the data. If the FIFO fills up, the spindle motor is slowed down, if it gets empty, the motor is sped up. The sub-channel data normally doesn't pass through the FIFO, but goes directly to a microcontroller. That way, the microcontroller can't be sure that it knows the exact address of the data, coming out of the FIFO. To circumvent this problem, the address of a sector is also stored in the data itself, together with a 12 bytes sync pattern. This way, one can determine the starting of a sector and its address just by looking at the data coming out of the FIFO. Here's the real problem: audio sectors don't have this sync pattern, nor the address of the sector, in the data area of a sector. Most CDROM drives use chips that are coming from audio players. The first CDROM drives were just modified audio CD players. To read audio sectors on a CDROM drive, you'll need a special decoder or you'll need to connect a standard decoder with some custom hardware to generate pulses to indicate the start of a sector and to synchronize the sub-channel packets with the real 2352 bytes of data. I hope that this explains it a bit. Adrie Koolen (adrie@ica.philips.nl) Philips Consumer Electronics, Eindhoven, the Netherlands -------------------------------------------------------------------------- Because of this, most every CDROM drive that can read DA frames cannot accurately return to the exact same location on the disc every time. It will usually return within a few samples either way. It took a lot of time and thought to write the code to correct for the "jitter" efficiently. My first try brought the transfer rate to a crawl. I have been refining the process to the point that it barely has any computing overhead, but still I have to read most every frame twice. I am still working on getting this to work faster. Some people have reported an 8x slowdown from 0.9a to 1.0a. I have no explaination for that large a difference. It is nowhere near that large on my machine, as I see only about 3x. I do agree that it is still much too slow. I have made a number of improvements in 1.0e that help with this slow down including making the receive buffer as large as possible (64K) when using real mode drivers like ASPI and MSCDEX. What kind of help is there? --------------------------- There is very limited help from the command line for CDDA. You can get the "USAGE" by just typing CDDA.e.g.: C:>CDDA Usage: CDDA /(mode) [/U,H,B,W,M] [O] /S /E /F filename [/ID ][/MSC ]. modes are LBA, MSF, T /MSF - times in minute, second, frame format (MM:SS:FF) /LBA - times in Logical Block Address format (xxxxxx) /T - send whole track to file /S - Start time /E - End time /U - estimated disk usage required for data /H - hex dump of sectors to stdout /B - write to file in Binary format /W - write to file in WAV format /O - override copy protection bit /M - override ASPI interface and use MSCDEX /MSC - override MSCDEX find first CD-ROM /ID - override ASPI find first CD-ROM Binary mode extension CDA will automagically added to the filename Wave format extension WAV will automagically added to the filename e.g. CDDA /MSF /S 10:14:36 /E 13:55:11 /F outfile /W e.g. CDDA /LBA /S 106232 /E 109443 /F outfile /B e.g. CDDA /T 2 /F outfile /W /O Copying and Registration (does he mean this costs $$$?) ------------------------------------------------------- I am allowing full freedom to copy this program. It IS a fully functional version. It is NOT Crippleware! There is NOT a pro version available for an unreasonable sum of money. I'm NOT asking for $ to register this program. What I am asking is, that if you use this program to let me know (via EMAIL, snail mail, Carrier Pigeon etc.), AND if your karma so directs you to make a small donation to a local charity. So far since the first release in late '93, only a couple people have shown they have good karma. I guess this makes a rather sad statement about society. I would also like to try and keep all the files together and unchanged in the archive, so if you are passing this around don't change the files. In this distribution the files contained are: CDDA.EXE - the program itself CDDA.DOC - this document file ROYALTY - the list of people to whom you should pay royalties CDROMINF.EXE - the MSCDEX exerciser program CDROMINF.DOC - the text file describing CDROMINF MSCTEST.EXE - the test program for MSCDEX only access reading DA TOSHTEST.EXE - the test program for TOSHIBA drives reading DA TOSH_RST.EXE - the program to reset TOSHIBA drives after fatal errors NECTEST.EXE - the test program for NEC drives reading DA SONYTEST.EXE - the test program for SONY drives reading DA CHINTEST.EXE - the test program for CHINON drives reading DA PLEXTEST.EXE - the test program for PLEXTOR drives reading DA SCSIPING.EXE - the program which uses ASPI to search for SCSI drives If you are one of those Shareware houses, I don't want to see this program available for $6.99 plus shipping and handling. I don't like seeing the average Joe getting burned for a 10 cent disk, 1 cent label and 2 cents worth of labour to make the disk, especially when he can get 600+ Meg of really good stuff from something like the Simtel CD for $25 (thanks to Robert Bruce for starting the cheap archive business). How to get hold of me --------------------- If you want to mail me about problems or to tell me I'm going to rot in hell for copying music, put your message in a file and copy it to the NUL device. If you want to make suggestions or want to send compliments you can contact me at the address below. If you encounter trouble with the program CDDA, try and run the included test program most suited to your drive. There are four test programs: one for each of the Toshiba, Sony and NEC type drives, and one which is a MSCDEX only version. These programs are scaled down versions of CDDA and use the command line to specify the drive letter and ID. The programs TOSHTEST, SONYTEST and NEC test take a single command line argument. It is -n, where n is the SCSI id of the drive. eg. c:>toshtest -3 This will run TOSHTEST on the SCSI drive id 3. There is also the program SCSIPING. It searchs for are reports all devices connected to the SCSI controller. It uses the ASPI interface. Finally there is a new program called TOSH_RST. It is used to reset a Toshiba drive after CDDA has stopped with a fatal error. It uses the same command line argument as the TOSHTEST program. If you would like assistance in solving problems, please include all dumps from all the related programs. You should be able to run the programs like this and get the dumps in a text file: CDDA /T 2 /W /O /F testfile >dumpfile.txt I have real difficulty in tracking down problems without these dumps. In the past the majority of people asking for help just send along a short note telling me my program doesn't work, and what they remember the error messages saying. This just doesn't cut it. I have to have the dumps to help. The bottom line - RTFM before writing me. Also read the alt.cd-rom FAQ. many of your questions can be answered by reading. EMAIL: jmclaugh@bnr.ca Snail Mail: Jim McLaughlin 449 Viewmount Dr. Nepean, Ont. Canada K2E 7P1 Things on my wish list of new functions --------------------------------------- I want to add support for other CDROM drives that can read DA sectors over the SCSI, but I don't have access to these drives. If someone could supply me with the programming information, I could try and do up a new version of CDDA, if I ever get some spare time. Aren't there other programs which do the same thing? ---------------------------------------------------- Yes. There are several other programs out there which do some or all of what CDDA does. In the spirit of the Internet, here are all (I think) the other programs which read DA frames. CDDA.ZIP - ftp.cdrom.com - contact: jmclaugh@bnr.ca (my old version) DA2WAV1A.ZIP - ftp.cdrom.com contact: jmclaugh@bnr.ca (my new version) CDGRAB32.ZIP - ftp.cdrom.com - contact: cdgrab@aldigital.algroup.com CDAR010.ZIP - wuarchive.wustl.edu - contact: rhofboer@knoware.nl NECTOWAV.ZIP - ftp.cdrom.com - contact: zerucha@shell.portal.com CDINFO12.ZIP - archive.utoronto.edu - contact: hpverwei@cs.ruu.nl CDDAREAD.ZIP - archive.utoronto.edu - contact: ap@jyu.fi ??????.??? - posted to alt.cd-rom - contact yenchee@Jupiter.cdie.nctu.edu.tw CDDA2WAV.ZIP - ftp.cdrom.com - contact: heiko@colossus.escape.de READCDA.ZIP - ftp.cdrom.com - contact: hst@mh.nl Questions I have received since the release of 0.9a and 1.0a ------------------------------------------------------------ Why is the program so slow? This program is so slow because of the following: 1. My poor programming skills. 2. Many of the CDROM drives only read DA frames in 1X mode even though they may transfer data at 2X or 3X. 3. The amount of computing to do jitter correction. 4. Reordering the bytes from the CD to the WAV file. 5. Having to read 16 frames for every 10 actually written to disk to allow for up to three frames of jitter. 6. When there is more than three frames of jitter, I slightly shift the aim of the search and reread the problem frames. What is ASPI? ASPI stands for Advanced SCSI Programming Interface. It was developed by Adaptec, and has been adopted by many SCSI card manufacturers as a standard SCSI programming interface. If you want more information on ASPI call Adaptec (408) 945-8600. When I use /T, the start and ends of the track are a couple of seconds away from where I think they should be. Why is this? In version 0.9a, there was a deep rooted bug which caused this. I have fixed it (I hope), and this should no longer be a problem. When I play back my samples, why are there pops and clicks? These pops and clicks can come from two places: 1. version 0.9a did NOT handle the jitter problem, it is handled now. 2. your sound card can't handle 16-bit 44.1 KHz samples. Try using SOX or a similar program to change the sample to 22.05 or 11.025 KHz samples and try again. The program stops with the error xxx. What is wrong? The 0.9a release had very limited error reporting. I thought that if it worked on my machine it work on everybody's. This version has much more error reporting. As I understand it, CDDA will not necessarily work correctly if SMARTDRV is installed. This has been the source of a lot of trouble. As well some people have been having trouble using CDDA in a DOS window in Windows. I think there may be a problem when being used with a DPMI manager installed. So, the bottom line is DON'T run CDDA under Windows. When will you release an OS/2 version? I have no interest in writing a version for OS/2. Period. However, There is a program from Adaptec called VASPI, which will allow you to run CDDA in a DOS window. I got the following email with the how-to for OS/2 from Stefan Eichner (Stefan-Eichner@k2.maus.de): > 1. Your CONFIG.SYS has to include the follow lines: > [...] > BASEDEV=TMV1SCSI.ADD > BASEDEV=OS2ASPI.DMD > REM DEVICE=C:\OS2\OS2CDROM.DMD /Q > E=C:\OS2\MDOS\VASPI.SYS > [...] > !If no OS2CDROM.DMD is loaded you can't read Data-CDs! > > 2. Add to the autoexec.bat the start-comand for MSCDEX2.EXE > (e.g. C:\MSCDEX2.EXE /D:MSCD001 /L:H /m:10 /v) > > 3. Change the settings of the DOS-Session on the WPS: > DOS_DEVICE=C:\TSLRCDR.SYS /d:mscd001 /p:3 > > Now CDDA works great!!! VASPIBET.ZIP is available from ftp.cdrom.com When will you release a Windows version? I have no interest in writing a Windows version. I don't have the time, and I don't think Windows is a particularly good OS (if you can call it an OS). I have had a couple of offers to help, but I have been too busy with the rest of my life to work on it. Don't hold your breath. When will you release a UNIX version? Never. Although I run LINUX on my machine, I have no interest in rewriting CDDA. When will you be writing a version for my CDROM drive? Getting the programming information from CDROM drive manufacturers is like pulling teeth. I've been hunting for this stuff for almost two years, and have only managed to get the programming manuals for Toshiba and Sony. If you have a drive and it does support DA frames, I need the programming manual. I also need about 5 or 6 extra hours in each day. I have a Toshiba drive. Why doesn't your program work? It appears that different ROM revisions cause the drives to work differently. For instance, my Toshiba 3401 is revision 0283. I have heard from people who have ROMs older and newer that can't use my program. I don't know why. Why doesn't your program work with my ASPI driver? Several vendors supply ASPI drivers for their SCSI cards. However, all drivers are not created equal. I have heard from people who have had trouble with just about every SCSI card on the planet. I only have Adaptec's EZSCSI to do my testing. I'll try and do my best on case by case basis, but I really don't have any spare time. CDROMINF works on my machine, so why doesn't CDDA? CDROMINF only uses MSCDEX calls, and CDDA also uses ASPI calls. It is these ASPI calls that do the meat of the program. If ASPI isn't on your machine, or doesn't work correctly, then CDDA will never work. Your only other choice is to try the /M option and use only MSCDEX commands. This is unlikely to help any SCSI drive owners. Why is there tons of zeros at the beginning and end of my track? Most every audio track has some silence at the beginning and end. This silence is actually digital silence which is all zeros for the samples. Can I use CDDA to read from DAT drives? As far as I know there are only a couple of DAT drives out there that allow reading of digital audio through SCSI. In theory, I could add that feature to CDDA, but since I don't have one of those drive, and I don't have the programming manuals either, I seems very unlikely that this will ever happen. Sometimes CDDA doesn't work when I first put in a CD. Why? I don't know. Some people have reported that CDDA works better after a new CD is put in the drive if you use some other utility to play and then stop the CD. This seems to force some sanity into some drivers. Can you change CDDA to read the song titles from my audio CD? There are no song titles recorded on an audio CD. The following is a post which explains this better than I can. ---------------------------------------------------------------------------- From: dplatt@ntg.com (Dave Platt) Newsgroups: alt.cd-rom Subject: Re: Ascii Track data on Audio CDs Keywords: Audio CD Ascii Track Date: 23 Feb 93 19:16:03 GMT Organization: New Technologies Group, Inc. Palo Alto CA Lines: 41 >A friend told me that encoded on Audio CDs are the track titles, CD title, >credits and even a bitmap image of the cover art. Can anyone confirm or >deny this? If it is true, how does a programmer get to this information? In general, this is _not_ true. The disc table-of-contents has information about the total disc length, number of tracks, and the starting time of each track. It has no room for human-readable text and there is no provision in the standards for such, as far as I've ever been able to find out. The audio tracks have "subcode" information associated with each frame (75 frames per second). The P subcode bit is used for primitive track-signalling flags, and is rarely interpreted by modern CD players. The Q subcode contains some useful information: control (type, preemphasis, and copy-protect fields), address information, index numbers, and sometimes the disc catalog/barcode number or the ISRC code (serial number, country, year, owner ID) of the recording. Still, no room for text or artwork. The R,S,T,U,V,W bits in the subcode can be used in a variety of ways. The most popular de facto standard is for CD+G graphics. These provide a sort of slow-scan video (288x192 pixels, max of 4096 colors using an encoded color lookup table). The CD+G graphics can include almost anything... lyrics, still photos from concert footage, and copies of the cover artwork are all quite possible and have been done. Only a relatively small percentage of audio CDs have CD+G graphics. Some CD players have a "subcode out" jack which can be fed to an external decoder. Some CD-ROM drives allow the subcode data to be read over the SCSI (or other) communication bus while the drive is playing audio CDs through its built-in DACs. Some [fewer] drives allow both the audio data and the subcode to be retrieved over the bus and manipulated by the host computer. Details vary; see your drive reference manual. -- Dave Platt VOICE: (415) 813-8917 Domain: dplatt@ntg.com UUCP: ...netcomsv!ntg!dplatt USNAIL: New Technologies Group Inc. 2470 Embarcardero Way, Palo Alto CA 94303 ---------------------------------------------------------------------------- Changes in version 1.0e from version 1.0a (versions 1.0b to 1.0d were not formally released) - UPC code display added for NEC drives - Toshiba mode select to return the drive to normal operation after reading DA frames had a conflict with EZSCSI drivers - this has been fixed - length of WAV file did not always match length contained in header - this has been fixed - added support for the Chinon CDS-535 drive (since I don't have one of these drives, this is untested) - added support for the Plextor 3028/5028 drives (since I don't have one of these drives, this is untested) - there was a bug which on some machines would allocate memory wrong when using the /M option, and would fill the file with zeros - this has been fixed - program TOSH_RST was added for users of the Toshiba drives who have CDDA exit with a major error. It resets the drive back to normal operation - there was a bug on some machines that would allow the user to run CDDA fine, but the respective test program would fail. It appeared mostly on the SONYTEST and NECTEST programs - this has been fixed - during running with NEC drives extra debug messages were printed - this has been fixed - the jitter correction routine has been rewritten - CDDA now runs about twice as fast as 1.0a did on my machine - a problem with one version of the Sony rom has a peculiar failure which may be corrected by a rewrite of the sector search routine - a problem with copy permitted discs sometimes required /O in order to dump to disk - when the last track of a disc or the last LBA or the last MSF was selected to be dumped, some drives actually only allow reading of the second to last frame, and not the last frame. since there is virtually no sound on the last frame of the disc, I have forced the program to stop at the next to last frame Known bugs: - someone has reported the program failing on a very large drive with very large amounts of disk space available. The specific example was a 250M drive with 235M free. It would appear that there is a bug in the Borland dfree routines. I will be looking into the problem, except for the fact that my drive is only 100M, so I can't duplicate it. - a couple of people have reported that the WAV files created are not compatible. I can't say much except that in one case the file size written in the WAV header was incorrect, and I don't know why. I have however found that really large WAV files (>10M) often confuse some players. I have seen a file work correctly on a couple of players, and not on others. My guess is that some players out there are not interpreting WAV files correctly, or are not expecting very large files. Wish list: (which may or may not get implemented) - option to play selected range before saving to disk - have start and end times include offset from beginning of track - more CD-ROM drives supported