Red Hat Bugzilla – Bug 70028
audio tracks written as data on change of file extension
Last modified: 2007-03-26 23:55:15 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):
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
Tracks after the last wav file are written as data
all files after the -audio flag should be written as audio
I've listed this as high priority because it's the first bug that I've reported
that can incur landfill tax ;-)
Created attachment 67504 [details]
output from a typical run -- note WARNING for last track
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.
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.
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.