Ron Stordahl <[email protected]> wrote: > Joerg > I realize that you probably did mean -vv rather than -VV, as the later > generated an enormous amount of debug data. However since I did run both I > am providing links to both just in case. > Writing E-CD to ASUS here are the relevant documents: > Debug logs with cdrecord -vv : > http://www.dxspots.com/cd/cdrtfe_log-vv.7zDebug logs with cdrecord -VV : > http://www.dxspots.com/cd/cdrtfe_log_uppercase-VV.7zThe CUE sheet used : > http://www.dxspots.com/cd/E-CD_test/Test_Files/Large/Special_Cues/Large_minimal.cue > Complete test set and results : http://www.dxspots.com/cd/E-CD_test.7z > Here is the Large_minimal.cue > REM Large-minimal.cue is the minimal cue sheet for the large test wave file. > FILE "..\Large.wav" WAVE > TRACK 01 AUDIO > INDEX 01 00:00:00 > TRACK 02 AUDIO > INDEX 01 05:02:14 > TRACK 03 AUDIO > INDEX 01 10:30:14 > TRACK 04 AUDIO > INDEX 01 16:20:01 > TRACK 05 AUDIO > INDEX 01 24:23:00 > TRACK 06 AUDIO > INDEX 01 34:54:00 > TRACK 07 AUDIO > INDEX 01 44:19:01 > TRACK 08 AUDIO > INDEX 01 48:23:03 > Excerpts from cdrtfe_log-vv.txt: > 00:50.29: > Start: Disc Image > 00:50.29: > "C:\Program Files (x86)\cdrtfe\tools\cdrtools\cdrecord" > gracetime=5 dev=0,0,0 driveropts=burnfree -vv -v -multi -pad -text -dao > cuefile=/cygdrive/C/Users/Ron_Stordahl/Documents/E-CD_Test/Test_Files/Large/Special_Cues/Large_minimal.cue > 01:02.42: > Sending CUE sheet... > 01:02.42: > 01 00 00 41 00 00 00 00 > 01:02.42: > 01 01 00 00 00 00 00 00 > 01:02.43: > 01 01 01 00 00 00 02 00 > 01:02.43: > 01 02 00 00 00 05 04 0E > 01:02.43: > 01 02 01 00 00 05 04 0E > 01:02.45: > 01 03 00 00 00 0A 20 0E > 01:02.45: > 01 03 01 00 00 0A 20 0E > 01:02.45: > 01 04 00 00 00 10 16 01 > 01:02.46: > 01 04 01 00 00 10 16 01 > 01:02.46: > 01 05 00 00 00 18 19 00 > 01:02.46: > 01 05 01 00 00 18 19 00 > 01:02.46: > 01 06 00 00 00 22 38 00 > 01:02.46: > 01 06 01 00 00 22 38 00 > 01:02.46: > 01 07 00 00 00 2C 15 01 > 01:02.48: > 01 07 01 00 00 2C 15 01 > 01:02.48: > 01 08 00 00 00 30 19 03 > 01:02.48: > 01 08 01 00 00 30 19 03 > 01:19.06: > 01 AA 01 01 00 37 3A 40
Looks OK, except that the index 0 positions for track 2 ff are invalid according to the red book. > 01:19.06: > SAO startsec: -11077 > 01:19.06: > Writing lead-in... > 01:19.06: > Lead-in write time: 21.262s (00:00:21.262) > 01:19.25: > Writing pregap for track 1 at -150 > 01:19.25: > Starting new track at sector: 0 > 01:49.31: > Track 01: 50 of 50 MB written (fifo 100%) [buf 100%] 10.8x. > 01:49.33: > Track 01: Total bytes read/written: 53305728/53305728 (22664 > sectors). > 01:49.33: > Starting new track at sector: 22664 Didn't you write that the drive rejects this? If you have other drives that don't accept this cue sheet, I recommend you to create a legal cue sheet and use it. To do this, you could add INDEX 00 05:00:14 before INDEX 01 for track 2 and so on... see also the official cue sheet documentation from CDRWin. > Note that with the Large_minimal.cue the the message appears: > > 01:19.25: > Writing pregap for track 1 at -150 > 01:19.25: > Starting new track at sector: 0 > 150 frames is 2 seconds. Did you intend for that to be 'minus 150'? It > seems to me it should be 'plus 150'. NO, what cdrecord does is 100% correct: the time 00:00.00 is sector -150 and the time 00:02.00 is sector 0. See Red Book... > My limited understanding is that without a PREGAP statement the default is to > impose a pregap of 2 seconds of digital silence generated by cdrecord, > however CD players start playing at index 01 so that 2 seconds is not > actually seen by a typical cd player. This is not documented in the cdrwin documentation. Note that your cue sheet explicitely tries to avoid INDEX 00 and this can only be achieved by sending INDEX 00 with the same time stamp as INDEX 01. If your drive does not accept this, you are lost because you try to get something illegal that is not granted to work. > This is described about half way down this page: > http://www.pcnineoneone.com/howto/cdburnadv4.html > If one uses the PREGAP statement, it is additive (I am not sure about this!). > So if I wrote: > PREGAP 00:01:00INDEX 01 00:00:00 > The effect would be 1+2 seconds of PREGAP...maybe. > I could try writing with CDRWin and then read the disc using cdrtfe debug > data prove this one way or the other. > I am just speculating and you are the expert so I hope the data I am > providing is helpful. > I am hoping that the problems start with the pregap processing, but it seems > strange the all 9 drives write what appears to be the correct E-CD with > CD-RWs, but some (too many really) fail with CD-Rs. If CDRWin behaves different than cdrecord for this, then CDRWin does not follow it's own documentation. >From the original documentation: Rules: All index numbers must be between 0 and 99 inclusive. The first index must be 0 or 1 with all other indexes being sequential to the first one. The first index of a file must start at 00:00:00. INDEX 0 Specifies the starting time of the track "pregap". INDEX 1 Specifies the starting time of the track data. This is the only index that is stored in the disc's table-of-contents. ------- I interpret this in a way that the absense of INDEX 00 enforces INDEX 00 == INDEX 01 Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Cdrtools-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cdrtools-support
