This is driving me insane Ever since upgrading to my new box (and SuSE 9.1) I can't get creating audio cd's from mp3's to work properly.
I have tried every version of k3b I can find (from the version on the SuSe disks, through the version available on YOU to the bleeding edge version 0.11.13 I found on SuSE's website)
I have even tried compiling k3b from source (however it seems to dislike or at least not understand 64bit machines) and unless I manually build everything from alsa to qt to the versions it wants it isn't going to work.
The truly sickening thing is that it worked once. About the first thing I did when I built my new machine is burn a CD for my Girlfriend to play at work.
Now (regardless of what version of k3b I use) I get a perfectly readable CD, with all the track information in the right place, times etc. yet when I try and play it (in a regular CD player) a strange pulsing sound which vaguely resembles the original music is heard (and no someone hasn't overwritten all my mp3's with German techno music...I checked)
Funnily enough if I ask k3b to produce a clone copy of an audio cd the result is perfect (something I could never get to work on audio disks before) so at least I know the writing bit is working.
I think it is either something to do with the mp3's getting decoded (by the mad_lib ?) or between there and the raw tracks being passed to cdrecord.
I am trying to create a disk using the command line tools only (to better understand the stages) However all my mp3's are at 160kps or higher. If I pass them through say mpg123 to get a wav output track how do I resample it to 128kbps so that cdrecord will accept it ?
Also after reading the cdrecord man file I wonder if cdrecord is confused about the endian mode of my (admittedly rather current NEC 2510 drive) however if I try and specify -swab in the user parameters for cdrecord within k3b it seems to get ignored (and forgotten)
Any ideas, or perhaps a quick how to burn a 160kps mp3 to audio cd using only the command line so I can at least drop cdrecord into verbose mode.
Ta Wayne
On Wed, Aug 11, 2004 at 01:24:35AM +0100, Wayne Stallwood wrote:
I think it is either something to do with the mp3's getting decoded (by the mad_lib ?) or between there and the raw tracks being passed to cdrecord. I am trying to create a disk using the command line tools only (to better understand the stages) However all my mp3's are at 160kps or higher. If I pass them through say mpg123 to get a wav output track how do I resample it to 128kbps so that cdrecord will accept it ?
The fact your MP3s are encoded at 160kbps should not be relavent. You want to be decoding them to 16bit sterio 44KHz wave files (the raw format of audio CDs).
Hope this helps!
Tim.
On Wed, Aug 11, 2004 at 01:24:35AM +0100, Wayne Stallwood wrote:
<snip/>
Any ideas, or perhaps a quick how to burn a 160kps mp3 to audio cd using only the command line so I can at least drop cdrecord into verbose mode.
I'd be tempted to try... mpg321 --cdr tracknumber.wav blah.mp3 then when you've done all the tracks... cdrecord -v dev=0,0,0 track01.wav track02.wav ... trackmn.wav
(obviously, set dev to something that is your cd writer ;)
and see what you get.
On Wednesday 11 August 2004 9:24 am, Brett Parker wrote:
On Wed, Aug 11, 2004 at 01:24:35AM +0100, Wayne Stallwood wrote:
<snip/>
Any ideas, or perhaps a quick how to burn a 160kps mp3 to audio cd using only the command line so I can at least drop cdrecord into verbose mode.
I'd be tempted to try... mpg321 --cdr tracknumber.wav blah.mp3 then when you've done all the tracks... cdrecord -v dev=0,0,0 track01.wav track02.wav ... trackmn.wav
(obviously, set dev to something that is your cd writer ;)
and see what you get.
Ahh cheers for that,
Next question
Assuming I am using a 2.6 kernel and a late version of cdrecord I understand I can write to IDE devices directly rather than using IDE=SCSI emulation .
I understand that the dev format is something like ATAPI:2,1,0 my writer is the first device on the second IDE channel.
cdrecord dev=help gives me output as below but none of the suggested entries for dev seem to work, what should I be putting here ?
Cdrecord-Clone-dvd 2.01a27 (x86_64-suse-linux) Copyright (C) 1995-2004 Jörg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://www.suse.de/feedback Note: The author of cdrecord should not be bothered with problems in this version. Supported SCSI transports for this platform:
Transport name: sg Transport descr.: Generic transport independent SCSI Transp. layer ind.: Target specifier: bus,target,lun Target example: 1,2,0 SCSI Bus scanning: supported Open via UNIX device: not supported
Transport name: pg Transport descr.: SCSI transport for ATAPI over Parallel Port Transp. layer ind.: Target specifier: bus,target,lun Target example: 1,2,0 SCSI Bus scanning: supported Open via UNIX device: not supported
Transport name: ATA Transport descr.: ATA Packet specific SCSI transport Transp. layer ind.: ATAPI: Target specifier: bus,target,lun Target example: ATAPI:1,2,0 SCSI Bus scanning: supported Open via UNIX device: not supported
Transport name: ATA Transport descr.: ATA Packet specific SCSI transport using sg interface Transp. layer ind.: ATA: Target specifier: bus,target,lun Target example: 1,2,0 SCSI Bus scanning: supported Open via UNIX device: not supported
Transport name: RSCSI Transport descr.: Remote SCSI Transp. layer ind.: REMOTE: Target specifier: rscsi@host:bus,target,lun Target example: REMOTE:rscsi@host:1,2,0 SCSI Bus scanning: supported Open via UNIX device: not supported
On Wed, Aug 11, 2004 at 06:20:50PM +0100, Wayne Stallwood wrote:
On Wednesday 11 August 2004 9:24 am, Brett Parker wrote:
On Wed, Aug 11, 2004 at 01:24:35AM +0100, Wayne Stallwood wrote:
<snip/>
Any ideas, or perhaps a quick how to burn a 160kps mp3 to audio cd using only the command line so I can at least drop cdrecord into verbose mode.
I'd be tempted to try... mpg321 --cdr tracknumber.wav blah.mp3 then when you've done all the tracks... cdrecord -v dev=0,0,0 track01.wav track02.wav ... trackmn.wav
(obviously, set dev to something that is your cd writer ;)
and see what you get.
Ahh cheers for that,
Next question
Assuming I am using a 2.6 kernel and a late version of cdrecord I understand I can write to IDE devices directly rather than using IDE=SCSI emulation .
Hrm - try the "other" less documented method of using cdrecord...
dev=/dev/cdwriterdevice
That might work, otherwise, try cdrecord -scanbus and see what it can find...
If all else fails, open the gui one, and see what command it runs itself ;)
Cheers,
On Wednesday 11 August 2004 8:10 pm, Brett Parker wrote:
<snip/>
Any ideas, or perhaps a quick how to burn a 160kps mp3 to audio cd using only the command line so I can at least drop cdrecord into verbose mode.
I'd be tempted to try... mpg321 --cdr tracknumber.wav blah.mp3 then when you've done all the tracks... cdrecord -v dev=0,0,0 track01.wav track02.wav ... trackmn.wav
(obviously, set dev to something that is your cd writer ;)
and see what you get.
Right, thanks to the latest handy tip about dev setting I ran the following
mpg321 --cdr 1.wav music.mp3 followed by cdrecord -v -pad dev=/dev/dvdrecorder 1.wav
The result is the same as using k3b, a valid disk (in terms of table of contents) but corrupted audio. Then I tried cdrecord -v -pad -swab dev=/dev/dvdrecorder 1.wav which gives a different (higher pitched) but similar effect.
So now we are down to either mpg321 (which plays my mp3s fine) producing broken output. Or cdrecord either broken or not liking my NEC drive.
Funny thing is that despite presumably being a raw audio file, nothing on this machine appears able to play 1.wav. Xmms totally refuses to open it cat'ing it to /dev/audio makes a horrible sound (like white noise)
file says this about 1.wav 1.wav: raw G3 data, byte-padded which is hardly conclusive
1.wav is comming out at about the right size (about 10MB a minute)
Probably the next step is to produce a 1.wav on another machine (that I know works) or obtain a suitable file from somebody and pass that to cdrecord, unless of course somebody out there has a bright idea.
On Wed, 11 Aug 2004 22:04:53 +0100, Wayne Stallwood ALUGlist@digimatic.plus.com was rumoured to have said:
[snip]
Right, thanks to the latest handy tip about dev setting I ran the following
mpg321 --cdr 1.wav music.mp3 followed by cdrecord -v -pad dev=/dev/dvdrecorder 1.wav
The result is the same as using k3b, a valid disk (in terms of table of contents) but corrupted audio. Then I tried cdrecord -v -pad -swab dev=/dev/dvdrecorder 1.wav which gives a different (higher pitched) but similar effect.
So now we are down to either mpg321 (which plays my mp3s fine) producing broken output. Or cdrecord either broken or not liking my NEC drive.
Funny thing is that despite presumably being a raw audio file, nothing on this machine appears able to play 1.wav. Xmms totally refuses to open it cat'ing it to /dev/audio makes a horrible sound (like white noise)
file says this about 1.wav 1.wav: raw G3 data, byte-padded which is hardly conclusive
1.wav is comming out at about the right size (about 10MB a minute)
Probably the next step is to produce a 1.wav on another machine (that I know works) or obtain a suitable file from somebody and pass that to cdrecord, unless of course somebody out there has a bright idea.
1) Have yout tried mpg321 -w? It shouldn't make a difference to cdrecord (it's supposed to detect & support both formats) but at least with -w you can play the output with sox etc.
2) Slower speed, different media, firmware update, wait for full moon...?
Rgds, /-sb.
On Thursday 12 August 2004 5:15 am, Stelios Bounanos wrote:
- Have yout tried mpg321 -w? It shouldn't make a difference to
cdrecord (it's supposed to detect & support both formats) but at least with -w you can play the output with sox etc.
- Slower speed, different media, firmware update, wait for full moon...?
Right..... The -w option you suggested produced a playable wav that sounded fine. file says
1.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz
Which looks reasonable enough, however cdrecord produced the same results (a playable but wrong sounding disk) So logic would dictate that there is something wrong with the way that cdrecord and my nec drive do the business, I can't believe that cdrecord on SuSE 9.1 is completely broken in this respect as if it were there would be a lot more shouting in the newsgroups.
Therefore I suspect that there is something about my nec drive that cdrecord doesn't like, it still produces data cd's and DVD's fine and as I have previously mentioned other things like cloning audio or data disks works perfectly. Surely this means that the drive and media are ok.
Now I have tried compiling the latest cdrecord and cdrtools from the authors site, but I haven't yet completely worked out how you are supposed to compile x86_64 unaware source. Not a single application that I have tried to compile on this system has worked yet, I know I am doing something wrong there.
The other thing that keeps nagging me (apart from the Girlfriend that wants some new compilation cd's for her car) is the fact that this all worked once, on this very system, with these versions of cdrecord and friends. I can't find anything that has changed, YOU hasn't updated any related packages, I haven't messed with DMA modes etc (although I did try that just now)
I think the next step is to slot my old Pioneer drive into this machine and confirm that it is a cdrecord-nec 2510 problem, but in the meantime to save me having to crack open the case and disturb my lovely neat wiring, is there an alternative to using cdrecord for creating audio cd's in linux ?
Cheers Wayne
Just posting it here in case anybody else has the same issue in the future.
I had almost given up trying to burn audio cd's on this machine. Nothing would work, building different versions of cdrecord, making the wav files on another machine, different writers...despite the best advice from other ALUG members, all tried and failed.
Then I run YoU today and guess what ? There is a new kernel available
This update fixes several issues: Most important are * kNFSd fix (medium security impact) * CD and DVD writing fixed (mainly affected audio and video, as it only got triggered by unaligned/odd size writes, effect was a large memory leak and defective data on CD)
I didn't even consider the possibility that it was the kernel !!
Anyway downloading the kernel now so (hopefully) that is another one I can tick of my list of new machine issues.
Oh and the reason it worked once, the first time I tried it ? I can only think that this was a bug introduced into the kernel in a version between the one on the SuSE disks I installed from and one that YoU downloaded as soon as I had configured the updater. I had checked that this hadn't happened to cdrecord and friends as it was the only logical explanation for why it had worked once...but like I say didn't consider the kernel.
On Tue, Aug 31, 2004 at 11:00:22PM +0100, Wayne Stallwood wrote:
Just posting it here in case anybody else has the same issue in the future.
I had almost given up trying to burn audio cd's on this machine. Nothing would work, building different versions of cdrecord, making the wav files on another machine, different writers...despite the best advice from other ALUG members, all tried and failed.
After the "fun" I had trying to burn an audio CD in the past week from some .wav files I recorded of our French teacher last week doing pronunciation excercise and getting them onto CD all I have to say is that, I needed to convert the .wav files into stereo, and then convert them to .cdr format with sox. After this I had to burn them onto CD with a machine running a 2.4 series kernel (trying to use any 2.6 kernel with limited testing cause much pain)
Adam
On 2004-08-31 23:00:22 +0100 Wayne Stallwood ALUGlist@digimatic.plus.com wrote:
[...] cdrecord [...] SuSE [...]
SuSE's hacking caused cdrecord author Schilly to turn it undistributable, allegedly: http://lists.debian.org/cdwrite/2004/08/msg00112.html and also "Thread Next". Now the saga has its own clothes: http://www.cafepress.com/mjg59.13063296 and http://www.cafepress.com/mjg59.13089491
Roll on apps moving to libburn: http://icculus.org/burn/
On Wednesday 01 September 2004 1:56 am, MJ Ray wrote:
SuSE's hacking caused cdrecord author Schilly to turn it undistributable, allegedly: http://lists.debian.org/cdwrite/2004/08/msg00112.html and also "Thread Next". Now the saga has its own clothes: http://www.cafepress.com/mjg59.13063296 and http://www.cafepress.com/mjg59.13089491
Roll on apps moving to libburn: http://icculus.org/burn/
Thank you for pointing me to this, the thread you mention is pretty much required reading for anybody interested in making software available through the GPL Generally (for those who haven't got time to digest the whole thread) the gist is this
SuSE made several changes to cdrecord to allow two things (DVD burning and the ability to run without being suid root)
Jorg the original author dislikes these changes and doesn't want people complaining about his software being broken if it is SuSE's mods causing the issue.
SuSE have added a discalaimer saying that Jorg should not be contacted regarding issues with cdrecord as they have applied many changes. However Jorg's problem is that people don't read this disclaimer and contact him anyway.
Essentially the gist of Jorg's statement is that changes within the terms of the GPL are only good if they (in his opinion) somehow improve the software, and that anything else is essentially deformation of character as his name ends up on a faulty (in his opinion) binary (despite it being next to several lines clearly stating that someone else has messed with it)
Seems a bit unreasonable to me I must say. I was disappointed with the attitude that came across from his website. Sometimes I find myself working with Linux on pretty cutting edge hardware and often things don't work as expected. If I can't resolve these issues myself I think it's the only decent thing to do to at least inform the author(s) (and possibly work with them to make things good) I
However Jorg will not even discuss these issues unless you send him a sample burner. Also there are comments like this on the front page
"Both RedHat and SuSE publish bastardized and defective variants of cdrtools in their distributions. If you have problems on RedHat or SuSE systems, first fetch a recent original cdrtools source, compile it yourself and run the original instead of broken software that illegally claims to be cdrecord."
That claim of illegality is very intersting and not the way I interpret the GPL.
Hi Wayne
Being involved several GPL projects (two as project leader), I fully understand Jorg's viewpoint. To have to fix a problem of your own making is bad enough, but when someone else screws things up and others give you the flack...
Based on the assumptio that Jorg is the copyright holder on cdrecord, then he is within his rights to restrict the use of the package name.. However, the code appears to based on another work, so somehow, I doubt if his claims are enforcable.. (b.i.a.n.a.l.)
Regards, Paul.
On Wednesday 01 September 2004 20:12, Wayne Stallwood wrote:
Essentially the gist of Jorg's statement is that changes within the terms of the GPL are only good if they (in his opinion) somehow improve the software, and that anything else is essentially deformation of character as his name ends up on a faulty (in his opinion) binary (despite it being next to several lines clearly stating that someone else has messed with it)
On Wednesday 01 Sep 2004 21:26, Paul wrote:
Based on the assumptio that Jorg is the copyright holder on cdrecord, then he is within his rights to restrict the use of the package name.
Hm, that would presumably mean Open Source authors can effectively stop people distributing their software, unless they call it something else. MS could buy up the Apache Foundation and stop distros including 'apache' packages. Seems a bit counter the the spirit of free software. Aren't names covered by trademarks rather than copyright? IANAL obviously...
Of course it might be preferable if Suse either provided a package that worked better or forked it properly so Joerg didn't get the flak. But I find it hard to believe they're doing anything illegal by distributing a patched version, even though it might arguably be a bit disrespectful towards the author.
The open source community usually manages to work these kinds of problems out reasonably amicably and productively. Joerg's managed to get himself a bit of a reputation for intransigence though. I would be too surprised if cdrecord went the way of xfree86 at some point.
Isn't it called cdrtools now anyway?
On Wednesday 01 September 2004 10:12 pm, Joe Button wrote:
Of course it might be preferable if Suse either provided a package that worked better or forked it properly so Joerg didn't get the flak. But I find it hard to believe they're doing anything illegal by distributing a patched version, even though it might arguably be a bit disrespectful towards the author.
As far as I can tell (apart from the kernel issue with Audio CD's, that had nothing to do with SuSE's modifications to cdrecord) the package they provide does work properly. I have been using cdrecord in SuSE from 7.2 through to 9.1 and the recent kernel issue was the first time I had problems.
Obviously if he has been getting bombarded with email from people having issues specific to the SuSE package then there is a problem, but what it is I don't know.
I don't like the idea of a complete fork for the reasons stated in my recent post and because isn't that even more disrespectful to the original author ?
On Thursday 02 Sep 2004 00:23, Wayne Stallwood wrote:
On Wednesday 01 September 2004 10:12 pm, Joe Button wrote:
Of course it might be preferable if Suse either provided a package that worked better or forked it properly so Joerg didn't get the flak. But I find it hard to believe they're doing anything illegal by distributing a patched version, even though it might arguably be a bit disrespectful towards the author.
As far as I can tell (apart from the kernel issue with Audio CD's, that had nothing to do with SuSE's modifications to cdrecord) the package they provide does work properly. I have been using cdrecord in SuSE from 7.2 through to 9.1 and the recent kernel issue was the first time I had problems.
Obviously if he has been getting bombarded with email from people having issues specific to the SuSE package then there is a problem, but what it is I don't know.
Don't use SuSE so I don't really know, but the k3b website suggests the problem's related to the 2.6.8 kernel, but it showed up in SuSE, presumably 'cos it was the first big distro to use that kernel version (?).
As I understand it the issue is that the kernel fixed what could reasonably be seen as a bug, ie. that burners could be written to when opened read-only. Unfortunately various apps (presumably including cdrecord?) rely on this rather odd behaviour and consequently don't work with the latest kernel. From what I understand from the kernel mailing list, modifying apps to work with the new kernel should be trivial, and is something the maintainer could reasonably be expected to address.
Oh, there's also a memory leak that stops audio CDs writing properly, which is a bona fide kernel bug.
NB: if I sound like I know what I'm talking about it's just an illusion, my knowledge is very sketchy and I may well be completely wrong about everything.
I don't like the idea of a complete fork for the reasons stated in my recent post and because isn't that even more disrespectful to the original author ?
Depends what s/he wants. Schilling seems to be complaining about getting unwanted bug reports and "broken software that illegally claims to be cdrecord." Forking it would address both complaints, although I don't know if it would make him happy or not.
I should really stop gibbering on ALUG and get on with the funding proposal I need to get done by tomorrow morning...
Joe x
On 2004-09-01 22:12:11 +0100 Joe Button alug@joebutton.co.uk wrote:
[...] buy up the Apache Foundation and stop distros including 'apache' packages. Seems a bit counter the the spirit of free software. Aren't names covered by trademarks rather than copyright? IANAL obviously...
Summary: the interaction of trademarks and copyrights is nasty, but "misuse" fears help us.
Your situation isn't that far-fetched. The Apache Foundation has a trademark on the name "Apache" for software and its members have made vaguely threatening noises towards Debian about its "apache" packages. See about halfway down http://lists.debian.org/debian-legal/2003/11/msg00086.html for an example. (I suggest ignoring the "I know the DFSG better than you" thread that follows. It gets ugly.)
One can use a trademark to honestly describe the origin of goods. If it comes from Apache, we can call it Apache and the trademark doesn't stop it. There's a fun grey area in the Apache copyright licences about that. I'm told if they try to use the copyright licence to stop people honestly using the trademark, that might be judged "copyright misuse" by the courts and void their copyright. IANAL though, so don't bet on it.
It's really easy to make software non-free by a trademark-related copyright clause, but Apache doesn't quite do that. Debian's http://www.uk.debian.org/logos/ are non-free though.
[...] Joerg's managed to get himself a bit of a reputation for intransigence though.
I think opening with accusations of deliberate illegal behaviour hasn't endeared him to many people on debian mailing lists.
I would be too surprised if cdrecord went the way of xfree86 at some point.
Well, libburn is there for CDs and growisofs already works really well for DVDs. Write a "cdburn" replacement for cdrecord (without the horrid syntax, please) or add libburn support to growisofs and get fame, riches and the wisdom of the ages (or none of the above maybe...)
On Wednesday 01 September 2004 9:26 pm, Paul wrote:
Hi Wayne
Being involved several GPL projects (two as project leader), I fully understand Jorg's viewpoint. To have to fix a problem of your own making is bad enough, but when someone else screws things up and others give you the flack...
I guess that I am not seeing this from a developers perspective, but why would he have licensed his software under the GPL if he didn't want others to be able to make modifications without his approval ?
Maybe it has more to do with the non GPL, DVD enabled version of cdrecord that he also offers ? Have SuSE stepped on his feet somewhat by offering functionality in the open version of cdrecord that he only offers in the closed version ?
Do Linux Distributors NEED to be able to modify the packages they provide ?, if they can't then surely the only thing that is going to differentiate them in the marketplace is the installer and the default package list.
Based on the assumptio that Jorg is the copyright holder on cdrecord, then he is within his rights to restrict the use of the package name.. However, the code appears to based on another work, so somehow, I doubt if his claims are enforcable.. (b.i.a.n.a.l.)
What I don't want to see is a situation where there are a million different names for package x depending on who was the last person to modify it. If that were the case then you would have to use cdrecord if you downloaded it from Jorg, RedHot CD toaster if it came with Red Hat, YaBA if you had SuSE and so on.
As long as those Distributors take ownership of the support of those packages they modify, or at least state somewhere in a very clear manner that the original authors should not be bugged as the provider has performed modifications, then all should be well...shouldn't it ?
On Wed, 2004-09-01 at 20:12, Wayne Stallwood wrote:
Thank you for pointing me to this, the thread you mention is pretty much required reading for anybody interested in making software available through the GPL
Ok, I've just upgraded from SuSE 9.0 to 9.1. In the process of moving drives about in my machine I "broke" the CD-RW drive. (I forgot about the ide-scsi emulation running on hdc)
I had to run cdrecord from the command line with "-scanbus" I think.
When you run the SuSE version it clearly says "We've hacked this, don't bother the original author if it doesn't work". I can't see SuSE can do more than that.
Jorg comes over as a "brat" in the thread, and it seems clear to me that he's annoyed with SuSE for adding the DVD functionality which he keeps to himself in the closed source version. "I'll take my ball away if you won't play by MY rules" seems to be the attitude, but he has already agreed to play by the GPL rules !
Peter
On Wed, 11 Aug 2004 18:20:50 +0100, Wayne Stallwood ALUGlist@digimatic.plus.com was rumoured to have said:
On Wednesday 11 August 2004 9:24 am, Brett Parker wrote:
On Wed, Aug 11, 2004 at 01:24:35AM +0100, Wayne Stallwood wrote:
<snip/>
Any ideas, or perhaps a quick how to burn a 160kps mp3 to audio cd using only the command line so I can at least drop cdrecord into verbose mode.
I'd be tempted to try... mpg321 --cdr tracknumber.wav blah.mp3 then when you've done all the tracks... cdrecord -v dev=0,0,0 track01.wav track02.wav ... trackmn.wav
(obviously, set dev to something that is your cd writer ;)
and see what you get.
Ahh cheers for that,
Next question
Assuming I am using a 2.6 kernel and a late version of cdrecord I understand I can write to IDE devices directly rather than using IDE=SCSI emulation .
I understand that the dev format is something like ATAPI:2,1,0 my writer is the first device on the second IDE channel.
So starting from zero this would be 1,0,0. As for the transport, I'm sure that ATAPI: worked until recently (around June or so), but Debian's cdrecord package now recommends ATA: under 2.6 kernels.
cdrecord dev=help gives me output as below but none of the suggested entries for dev seem to work, what should I be putting here ?
AFAICT, dev=/dev/hdc and dev=ATA:1,0,0 are the same, so it's a question of which pedantic cdrecord warning you prefer :)
[snip]
rgds, /-sb.
-
adam＠thebowery.co.uk -
Brett Parker -
Joe Button -
MJ Ray -
Paul -
Peter Onion -
Stelios Bounanos -
Tim Green -
Wayne Stallwood