Bug 140467 - cdrecord writes a 'click' on the end of the last track
cdrecord writes a 'click' on the end of the last track
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: cdrtools (Show other bugs)
3
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-22 18:01 EST by Andrew Smith
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-31 10:52:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
5 Seconds silent wave file (861.37 KB, application/octet-stream)
2004-12-14 04:28 EST, Andrew Smith
no flags Details
gzipped 9 seconds silent wave file (1.59 KB, application/octet-stream)
2004-12-14 04:33 EST, Andrew Smith
no flags Details

  None (edit)
Description Andrew Smith 2004-11-22 18:01:33 EST
Description of problem:
cdrecord writes a 'click' on the end of the last track - this is most
likely during fixating the disc

Version-Release number of selected component (if applicable):
cdrecord-2.01.1-5

How reproducible:
Every time

Steps to Reproduce:
1. create a blank 9 second wav file (see below)
2. cdrecord -eject -v dev=/dev/hdc -speed=4 -pad -audio -tao
blank9.wav blank9.wav
  
Actual results:
Click on the end of the last track - but none on the first track

Expected results:
No click on the end of the last track

Additional info:
# od -c blank9.wav
0000000   R   I   F   F 264   9 030  \0   W   A   V   E   f   m   t
0000020 020  \0  \0  \0 001  \0 002  \0   D 254  \0  \0 020 261 002  \0
0000040 004  \0 020  \0   d   a   t   a 220   9 030  \0  \0  \0  \0  \0
0000060  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
6034660  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
6034674
#
Comment 1 Andrew Smith 2004-11-22 18:04:01 EST
Config info:
CPU: AthlonXP 2400+ (2.0Ghz)
kernel = 2.6.9-1.667 (i686)
cdrecord-2.01.1-5
motherboard = ASRock K7S41GX
# cat /proc/ide/hdc/model
SAMSUNG CD-R/RW DRIVE SW-252F
Comment 2 Harald Hoyer 2004-11-23 06:38:20 EST
does it happen, if you burn with -dao instead of -tao??
Comment 3 Andrew Smith 2004-12-11 23:57:20 EST
-dao doesn't have the problem - i.e. no click at the end of the CD

Some more info ...

I have found one setup that does work with -tao

In a different machine with a tao drive (doesn't support dao):
CPU: Pentium III 933Mhz
kernel = RH9 2.4.20-31.9
cdrecord-2.0-11.9.1
motherboard = ASUS CUSI-M
# cat /proc/ide/hdc/model
RICOH CD-R/RW MP7040A

However, the above uses the ide-scsi option.
Also, this drive is quite old and fails to write a CD with SCSI
sendcmd errors on about 2 out of 3 CDs it writes

I then swapped the CD-R/RW drives so the RH9 PC had the
SAMSUNG drive but then the -tao disks had the same problem
as when the SAMSUNG drive was in the Athlon PC

The RICOH drive failed to write anything every time in the Athlon PC
so I can't test that setup
Comment 4 Harald Hoyer 2004-12-13 03:52:15 EST
I think this is a the kernel bug in 2.6 for IDE (bug #131051), where
the kernel does not read to the end of the disk.

You may close this bug as a duplicate of bug #131051, if you think so,
too.
Comment 5 Andrew Smith 2004-12-13 04:32:21 EST
No idea - I keep getting this error when I try to access bug #131051
"You are not authorized to access bug #131051"

However, as I said above, it also happens on RH9 2.4.20-31.9
I only have one TAO drive and it doesn't give a click on RH9
(when it succeeds in writing a CD)

All of my DAO drives (I have 3) give a click on FC3, FC2 and RH9
So maybe it has something to do with the driver?
It took me almost 6 months before I realised it was happening -
I do music editing for a dance studio
(i.e. I probably created over 50 different CD's for people with this
problem before I realised it)
Comment 6 Harald Hoyer 2004-12-14 04:06:54 EST
could you please attach the blank9.wav, so that I can easily reproduce it?
Comment 7 Andrew Smith 2004-12-14 04:28:32 EST
Created attachment 108498 [details]
5 Seconds silent wave file

Supplied a 5 second file coz bugzilla wont accept a 1.5Mb file (9 seconds)
The bug condition occurs with ANY wave file
the 'od -c blank9.wav' in the bug description will only differ in 3 ways:
1) File size
2) Wave header size attribute (4 bytes after 'RIFF')
3) Data header size attribute (4 bytes after 'data')
Comment 8 Andrew Smith 2004-12-14 04:33:24 EST
Created attachment 108499 [details]
gzipped 9 seconds silent wave file

sorry - realised that gzip will make a very small file - here is the 9 second
wave - oops
Comment 9 Andrew Smith 2004-12-14 04:41:45 EST
Comment on attachment 108498 [details]
5 Seconds silent wave file

Attachment #108498 [details] can be deleted - it's unnecessary
Comment 10 Matthew Miller 2006-07-10 17:06:55 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 11 John Thacker 2006-10-31 10:52:31 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.