Bug 70028 - audio tracks written as data on change of file extension
audio tracks written as data on change of file extension
Product: Red Hat Linux
Classification: Retired
Component: cdrecord (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-07-29 10:06 EDT by Jón Fairbairn
Modified: 2007-03-26 23:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-29 18:24:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from a typical run -- note WARNING for last track (2.58 KB, text/plain)
2002-07-29 10:09 EDT, Jón Fairbairn
no flags Details

  None (edit)
Description Jón Fairbairn 2002-07-29 10:06:12 EDT
Description of Problem:
if I issue a command like

cdrecord -v dev=0,0,0 /usr/isofs/Data -audio A/01.cdr B/01.wav C/01.cdr

then /usr/isofs/Data is written correctly as data, A/01.cdr and B/01.wav are
written correctly as audio
but  C/01.cdr is written as data

man cdrecord says

       -audio   If this flag is present, all subsequent tracks  are
                  written  in  CD-DA (similar to Red Book) audio for-

so it shouldn't do this

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


How Reproducible:

every time I've tried it

Steps to Reproduce:
1.  make appropriate cdr and wav files
2.  issue the above command
3.  look at the resulting disc with xplaycd or a cd player

Actual Results:

Tracks after the last wav file are written as data

Expected Results:

all files after the -audio flag should be written as audio

Additional Information:
I've listed this as high priority because it's the first bug that I've reported
that can incur landfill tax ;-)
Comment 1 Jón Fairbairn 2002-07-29 10:09:25 EDT
Created attachment 67504 [details]
output from a typical run -- note WARNING for last track
Comment 2 Mike A. Harris 2002-07-29 17:50:54 EDT
I don't know what .cdr tracks are, but I presume they are audio tracks of
some kind.  The simple solution is to make sure all the files are .wav files.

This is IMHO a very minor nit, and is something that is very low priority,
and something which should be fixed by the upstream cdrecord maintainer, if
he considers it a bug.

On a side note, the bugzilla "priority" field is meaningless.  It was
intended for users to give a general initial priority to, and for
developers to then reprioritize if necessary depending on the various
problems reported that need work.  However, every user seems to think
their bug is high priority and should be fixed ASAP, so the field ends
up being useless.  Since developers cant currently change the priority
and have it locked, users tend to get into a "you change it to low, I'll
change it back to high, back to low, back to high" mexican standoff, and
ultimately the developer decides the priority based on his own workload.
The reporter has zero say, and zero effect on work prioritization.  Thus
"priority" is meaningless.  It does seem to satiate some users though.

Just thought you might like to know the honest truth about the
meaninglessness of end user settable priority.
Comment 3 Jón Fairbairn 2002-07-29 18:24:27 EDT
Hmph. At the very least there's a bug in the documentation. As I listed above,
it explicitly says that all arguments after -audio are treated as audio files.
It shouldn't matter what the file extension is. (FYI .cdr is what sox uses to
indicate a raw audio file in 16bit stereo at  44100Hz with length padded to a
whole number of 75ths of a second -- ie CD audio). WAV files are a special case.
and I suspect that that's where the logic is broken.

I presume that getting the real problem (as opposed to the documentation) mended
requires that I contact Jvrg Schilling myself?

I take your point about "Priority".

I don't mean to get into a cycle of opening and closing this thing, but the bug
is present in the version supplied with RH7.3, which I expect means subsequent
versions too, so I think it is worth documenting at the very least.
Comment 4 Mike A. Harris 2002-07-29 18:46:09 EDT
Well why did you just reopen it then and waste even more of my time?
As I said, it is EXTREMELY low priority.  You're the first person in 3
years of cdrecord 1.10 to even mention it.  It isn't worth wasting time
to edit a manpage on.

Reopening the bug doesn't accelerate the priority of it either.
Contact Jeorg Schilling if it bothers you and you think it should be

This bug is WONTFIX period.  Feel free to reopen it if it makes you feel
warm inside, but it is not ever going to get touched.  I'm just
being realistic about it.  At least you could respect that instead
of playing a game.

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