Bug 140467 - cdrecord writes a 'click' on the end of the last track
Summary: cdrecord writes a 'click' on the end of the last track
Alias: None
Product: Fedora
Classification: Fedora
Component: cdrtools   
(Show other bugs)
Version: 3
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-22 23:01 UTC by Andrew Smith
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-31 15:52:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 09:28 UTC, Andrew Smith
no flags Details
gzipped 9 seconds silent wave file (1.59 KB, application/octet-stream)
2004-12-14 09:33 UTC, Andrew Smith
no flags Details

Description Andrew Smith 2004-11-22 23:01:33 UTC
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):

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

Comment 1 Andrew Smith 2004-11-22 23:04:01 UTC
Config info:
CPU: AthlonXP 2400+ (2.0Ghz)
kernel = 2.6.9-1.667 (i686)
motherboard = ASRock K7S41GX
# cat /proc/ide/hdc/model

Comment 2 Harald Hoyer 2004-11-23 11:38:20 UTC
does it happen, if you burn with -dao instead of -tao??

Comment 3 Andrew Smith 2004-12-12 04:57:20 UTC
-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
motherboard = ASUS CUSI-M
# cat /proc/ide/hdc/model

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 08:52:15 UTC
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,

Comment 5 Andrew Smith 2004-12-13 09:32:21 UTC
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 09:06:54 UTC
could you please attach the blank9.wav, so that I can easily reproduce it?

Comment 7 Andrew Smith 2004-12-14 09:28:32 UTC
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 09:33:24 UTC
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 09:41:45 UTC
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 21:06:55 UTC
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 15:52:31 UTC
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.