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

Re: Cdrecord bug in DAO mode (version 2.01a19)



Joerg Schilling wrote:

From trentalg@aston.ac.uk  Fri Oct 24 05:28:44 2003


Each time I try to burn an Audio CD in DAO mode using Cdrecord and my
QSI Combo CD-writer (I tried speed=4,8,12,16) I receive an error as the
one in the attached file and the CD writing process fails with the waste
of a blank media (I disposed tons of useless blank CDs).

Everything works fine in TAO mode, though I need to use DAO in order not
to have the silence gap between audio tracks.

I am currently using a Redhat 9 distributions and a custom-compiled
kernel 2.4.22. Cdrecord version is 2.01a19 but I also encounter the same
problem with the original version supplied by Redhat.

Any help/advice/patch would be greatly appreciated.

Also, I wish to express a warm "thanks" to all the developers involved
in the Cdrecord project for providing us this great piece of software.

Regards,

Guido

--=-8Lfkags299yMpplZof9E
Content-Disposition: attachment; filename=cdrecord.out
Content-Type: text/plain; name=cdrecord.out; charset=UTF-8
Content-Transfer-Encoding: 7bit

Calling: /usr/lib/xcdroast-0.98/bin/xcdrwrap CDRECORD dev=ATAPI:0,0,0 gracetime=2 fs=12288k driveropts=burnfree -v -useinfo speed=8 -dao -overburn -ignsize -immed -text -audio "/mnt/hda2/track-01.wav" ...

scsidev: 'ATAPI:0,0,0'
devname: 'ATAPI'
scsibus: 0 target: 0 lun: 0
Warning: Using ATA Packet interface.
Warning: The related libscg interface code is in pre alpha.
Warning: There may be fatal problems.
SCSI buffer size: 64512
TOC Type: 0 = CD-DA
Using libscg version 'schily-0.7'
Driveropts: 'burnfree'
atapi: 1
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   :
Vendor_info    : 'QSI     '
Identifikation : 'DVD/CDRW SBW-161'
Revision       : 'SX13'
Device seems to be: Generic mmc2 DVD-ROM.
Current: 0x0009
Profile: 0x0010
Profile: 0x0008
Profile: 0x0009 (current)
Profile: 0x000A
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-2 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1605632 = 1568 KB
FIFO size      : 12582912 = 12288 KB
pregap1: -1
Track 01: audio   58 MB (05:49.45) no preemp copy
Track 02: audio   35 MB (03:33.65) no preemp copy pregapsize:   0
Track 03: audio   43 MB (04:16.53) no preemp copy pregapsize:   0
Track 04: audio   50 MB (04:59.57) no preemp copy pregapsize:   0
Track 05: audio   62 MB (06:09.28) no preemp copy pregapsize:   0
Track 06: audio   61 MB (06:04.90) no preemp copy pregapsize:   0
Track 07: audio   52 MB (05:14.54) no preemp copy pregapsize:   0
Track 08: audio   64 MB (06:20.54) no preemp copy pregapsize:   0
Track 09: audio   50 MB (05:02.92) no preemp copy pregapsize:   0
Track 10: audio   54 MB (05:25.28) no preemp copy pregapsize:   0
Track 11: audio   52 MB (05:10.74) no preemp copy pregapsize:   0
Track 12: audio   54 MB (05:25.54) no preemp copy pregapsize:   0
Track 13: audio   50 MB (04:58.00) no preemp copy pregapsize:   0
Track 14: audio   55 MB (05:30.96) no preemp copy pregapsize:   0
Total size:      747 MB (74:01.94) = 333146 sectors
Lout start:      747 MB (74:03/71) = 333146 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, low Beta category (A-) (2)
ATIP start of lead in:  -11634 (97:26/66)
ATIP start of lead out: 359846 (79:59/71)
Disk type:    Short strategy type (Phthalocyanine or similar)
Manuf. index: 3
Manufacturer: CMC Magnetics Corporation
Blocks total: 359846 Blocks current: 359846 Blocks remaining: 26700
Starting to write CD/DVD at speed 8 in real SAO mode for single session.
Waiting for reader process to fill input buffer ...
input buffer ready.
BURN-Free is ON.
Performing OPC...
Sending CUE sheet...
SAO startsec: -11634
Writing lead-in...
Lead-in write time:   20.086s
Writing pregap for track 1 at -150
Starting new track at sector: 0

Track 01: Total bytes read/written: 61643568/61643568 (26209 sectors).
Starting new track at sector: 26209

Track 02: Total bytes read/written: 37688448/37688448 (16024 sectors).
Starting new track at sector: 42233

Track 03: Total bytes read/written: 45252480/45252480 (19240 sectors).
Starting new track at sector: 61473

Track 04: Total bytes read/written: 52844736/52844736 (22468 sectors).
Starting new track at sector: 83941

Track 05: Total bytes read/written: 65140992/65140992 (27696 sectors).
Starting new track at sector: 111637

Track 06: Total bytes read/written: 64369536/64369536 (27368 sectors).
Starting new track at sector: 139005

Track 07: Total bytes read/written: 55486032/55486032 (23591 sectors).
Starting new track at sector: 162596
cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB:  2A 00 00 02 8E DD 00 00 1B 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 00 0C 00 00 00 00 00
Sense Key: 0x3 Medium Error, Segment 0
Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
Sense flags: Blk 0 (not valid) cmd finished after 0.000s timeout 200s
cdrecord: A write error occured.
cdrecord: Please properly read the error message above.

What do you expect when you use low quality media on a low quality drive?

I don't think that's the whole story, honestly. I have been having problems with 2.01a19 and audio as well. This week I have burned 17 data CDs without *any* problem, and using the same media and burner had to try eight times to finally get one single audio CD. The media may not be great, but it works for data, so there is some other issue in place. Yes, I tried both default and the -dao option.

System is a 1.4GHz Athlon, Linux 2.4.20 Redhat kernel, ASUS 20x burner.

Other note, I was shipping four of the data CDs so I ran the excelent -c2scan on them, and found only a few sectors with any bit errors, none with more than 10 or so. I believe that indicates the media may not be worderful, but is certainly reasonably good.

Could you comment on what else is different between the data and audio burns which could contribute to this?


Jörg



--
E. Robert Bogusta
 It seemed like a good idea at the time





Reply to: