Bug 70028
| Summary: | audio tracks written as data on change of file extension | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Jón Fairbairn <jon.fairbairn> | ||||
| Component: | cdrecord | Assignee: | Mike A. Harris <mharris> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.2 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2002-07-29 22:24:31 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 fixed. 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. |
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- mat. so it shouldn't do this Version-Release number of selected component (if applicable): cdrecord-1.10-4 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 ;-)