Re: problems with xcdroast + ide-scsi
On Tue 18 November 2003 23:22, Volker Kuhlmann wrote: > > > I can't. xcdroast doesn't recognize non-SCSI devices, that's > > > why I've switched to SCSI > > > > Hmm, and neither does readcd on inspection. > > readcd pretty much supports the same device specification as > cdrecord, which means IDE drives can be accessed with > dev=ATAPI:x,y,z. Run cdrecord dev=ATAPI: -scanbus. Unfortunately > using ATAPI: changes the designation of the SCSI devices, so you > have to memorise 2 sets of numbers (IMO device names could be > seriously improved). Aha. Yeah, that works. Thanks! Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with xcdroast + ide-scsi
On Tue 18 November 2003 21:15, obarrot wrote: > >Random thoughts: > > > >- Try getting the latest version of cdrtools, and compile and > >install them from source > > I'll try what you suggest Okay. I'm starting to suspect the kernel and/or setup though, so this is probably not top priority. > >- From your lsmod output, ide-scsi isn't loaded? > > that's right. it's a copy/paste typo Ok. > >- The error message "Warning: controller returns wrong size for > > CD capabilities page." could be due to a firmware bug > > > >- The output from readcd you pasted seems to be fine. Does it > > read it correctly? > > no, the PC freezes after a few minutes and the output can't be > read with -o loop Hmm. Freezing, but only after a few minutes. Could be an IRQ problem, but then that's done by the controller, not the drive. Maybe a chipset problem? See below... > >- "DGB10: readtoc: no MMC" seems to say that the drive is not > > MMC compliant. If this is an old Goldstar drive, you may need > > the gscd.o kernel module. > > > >- How is the drive attached to the system? What kind of > > mainboard do you have? > > you're right, it's an old IDE ATAPI Goldstar drive attached on > the mother board ctler (secondary slave) > I also have a Traxdata CD writer attached to SCSI (only device in > the chain). > My MB is a DFI K6BV3+, VIA MVP3 chipset + with K6-2/500 Make sure you've got VIA chipset support enabled in your kernel, and perhaps enable PCI Quirks as well. See Documentation/sound/VIA-chipset about that. > >- Does it work without ide-scsi, ie with ide-cd? If so, you > > could add the line > > yes, it used to work that way before I swithed to ide-scsi.o. > I'll try the gscd.o driver > > >options ide-cd ignore=hdx > > > >with hdx the device of your writer, to use the reader with > > ide-cd and the writer with ide-scsi. This is not a solution, > > but may be a workaround. > > I can't. xcdroast doesn't recognize non-SCSI devices, that's why > I've switched to SCSI Hmm, and neither does readcd on inspection. Sorry about that, it works for me because I only use my reader to rip audio CDs with cdparanoia, and my burner to burn ISOs from the net, and backups. If I want to read an image off a CD, I just use the burner. But ofcourse that's no good for on-the-fly copying. Anyway, I'd go with the kernel configuration first. If that doesn't work, I suggest asking for help on lkml, this sounds like a kernel/hardware problem rather than a problem with readcd. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: problems with xcdroast + ide-scsi
On Tue 18 November 2003 21:15, obarrot wrote: > >Random thoughts: > > > >- Try getting the latest version of cdrtools, and compile and > >install them from source > > I'll try what you suggest Okay. I'm starting to suspect the kernel and/or setup though, so this is probably not top priority. > >- From your lsmod output, ide-scsi isn't loaded? > > that's right. it's a copy/paste typo Ok. > >- The error message "Warning: controller returns wrong size for > > CD capabilities page." could be due to a firmware bug > > > >- The output from readcd you pasted seems to be fine. Does it > > read it correctly? > > no, the PC freezes after a few minutes and the output can't be > read with -o loop Hmm. Freezing, but only after a few minutes. Could be an IRQ problem, but then that's done by the controller, not the drive. Maybe a chipset problem? See below... > >- "DGB10: readtoc: no MMC" seems to say that the drive is not > > MMC compliant. If this is an old Goldstar drive, you may need > > the gscd.o kernel module. > > > >- How is the drive attached to the system? What kind of > > mainboard do you have? > > you're right, it's an old IDE ATAPI Goldstar drive attached on > the mother board ctler (secondary slave) > I also have a Traxdata CD writer attached to SCSI (only device in > the chain). > My MB is a DFI K6BV3+, VIA MVP3 chipset + with K6-2/500 Make sure you've got VIA chipset support enabled in your kernel, and perhaps enable PCI Quirks as well. See Documentation/sound/VIA-chipset about that. > >- Does it work without ide-scsi, ie with ide-cd? If so, you > > could add the line > > yes, it used to work that way before I swithed to ide-scsi.o. > I'll try the gscd.o driver > > >options ide-cd ignore=hdx > > > >with hdx the device of your writer, to use the reader with > > ide-cd and the writer with ide-scsi. This is not a solution, > > but may be a workaround. > > I can't. xcdroast doesn't recognize non-SCSI devices, that's why > I've switched to SCSI Hmm, and neither does readcd on inspection. Sorry about that, it works for me because I only use my reader to rip audio CDs with cdparanoia, and my burner to burn ISOs from the net, and backups. If I want to read an image off a CD, I just use the burner. But ofcourse that's no good for on-the-fly copying. Anyway, I'd go with the kernel configuration first. If that doesn't work, I suggest asking for help on lkml, this sounds like a kernel/hardware problem rather than a problem with readcd. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with xcdroast + ide-scsi
On Mon 17 November 2003 22:50, obarrot wrote: > Hi, I can't use my CD-ATAPI cdrom with xcdroast + the ide-scsi.o > module > > I had to disable DMA on this CD drive as any operation on the > device freezed totally the > machine! > now I can mount & acccess this /dev/sg1 device ok but readcd does > detect a garbled disk: > a music disk instead of a data disk (see below) > > any hints? > thanks Random thoughts: - Try getting the latest version of cdrtools, and compile and install them from source - From your lsmod output, ide-scsi isn't loaded? - The error message "Warning: controller returns wrong size for CD capabilities page." could be due to a firmware bug - The output from readcd you pasted seems to be fine. Does it read it correctly? - xcdroast doesn't seem to detect anything, it just starts cdda2wav. Although it seems that you snipped some output. Could you try without XCDRoast? That would give some more legible output as well as remove a potential source of error - "DGB10: readtoc: no MMC" seems to say that the drive is not MMC compliant. If this is an old Goldstar drive, you may need the gscd.o kernel module. - How is the drive attached to the system? What kind of mainboard do you have? - Does it work without ide-scsi, ie with ide-cd? If so, you could add the line options ide-cd ignore=hdx with hdx the device of your writer, to use the reader with ide-cd and the writer with ide-scsi. This is not a solution, but may be a workaround. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: problems with xcdroast + ide-scsi
On Mon 17 November 2003 22:50, obarrot wrote: > Hi, I can't use my CD-ATAPI cdrom with xcdroast + the ide-scsi.o > module > > I had to disable DMA on this CD drive as any operation on the > device freezed totally the > machine! > now I can mount & acccess this /dev/sg1 device ok but readcd does > detect a garbled disk: > a music disk instead of a data disk (see below) > > any hints? > thanks Random thoughts: - Try getting the latest version of cdrtools, and compile and install them from source - From your lsmod output, ide-scsi isn't loaded? - The error message "Warning: controller returns wrong size for CD capabilities page." could be due to a firmware bug - The output from readcd you pasted seems to be fine. Does it read it correctly? - xcdroast doesn't seem to detect anything, it just starts cdda2wav. Although it seems that you snipped some output. Could you try without XCDRoast? That would give some more legible output as well as remove a potential source of error - "DGB10: readtoc: no MMC" seems to say that the drive is not MMC compliant. If this is an old Goldstar drive, you may need the gscd.o kernel module. - How is the drive attached to the system? What kind of mainboard do you have? - Does it work without ide-scsi, ie with ide-cd? If so, you could add the line options ide-cd ignore=hdx with hdx the device of your writer, to use the reader with ide-cd and the writer with ide-scsi. This is not a solution, but may be a workaround. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVD+/-R writers
On Mon 17 November 2003 15:37, Jose Casasnovas wrote: > Which double format DVD writers can be used under Linux?? Is Sony > supported?? I was wondering on drivers and software to run those > writers under Linux. In case of a single format DVD writer, which > format (+R or -R) is recommended to be run under Linux?? See http://fy.chalmers.se/~appro/linux/DVD+RW/ for a lot of information on DVD writing on Linux. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: DVD+/-R writers
On Mon 17 November 2003 15:37, Jose Casasnovas wrote: > Which double format DVD writers can be used under Linux?? Is Sony > supported?? I was wondering on drivers and software to run those > writers under Linux. In case of a single format DVD writer, which > format (+R or -R) is recommended to be run under Linux?? See http://fy.chalmers.se/~appro/linux/DVD+RW/ for a lot of information on DVD writing on Linux. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a19 - strange errors
On Wed 12 November 2003 11:33, Helmut Jarausch wrote: > > I can't remember the version, but I'm quite sure it was a 2.01a* > version. > I'll try to use the driver under Win2K first, to check if it's a > hardware problem. Okay. How do you compare the CD to the original? Read it out with readcd and then do a cmp on the images? Or using cmp on the device directly? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a19 - strange errors
On Wed 12 November 2003 11:16, Helmut Jarausch wrote: > Hi, > > I have a seldomly used PlexWriter 24/10/40A . > Using cdrtools-2.01a19 and different media I always > get strange errors: > The cd is written without any error messages. But comparing > it to the orignal I get mismatches always at a bytes with > offset n*2048 where n is integer. > > Has anybody any idea? > (Previously, at least with previous versions of cdrtools this > drive worked OK) Could you give some more information? Like the command line you use to burn the CD, and how you compare them. What OS are you using? Lastly, when you say that it works with previous versions, do you mean earlier alpha versions, or the latest stable release? Could you try to find out in what version things went broke? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a19 - strange errors
On Wed 12 November 2003 11:33, Helmut Jarausch wrote: > > I can't remember the version, but I'm quite sure it was a 2.01a* > version. > I'll try to use the driver under Win2K first, to check if it's a > hardware problem. Okay. How do you compare the CD to the original? Read it out with readcd and then do a cmp on the images? Or using cmp on the device directly? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a19 - strange errors
On Wed 12 November 2003 11:16, Helmut Jarausch wrote: > Hi, > > I have a seldomly used PlexWriter 24/10/40A . > Using cdrtools-2.01a19 and different media I always > get strange errors: > The cd is written without any error messages. But comparing > it to the orignal I get mismatches always at a bytes with > offset n*2048 where n is integer. > > Has anybody any idea? > (Previously, at least with previous versions of cdrtools this > drive worked OK) Could you give some more information? Like the command line you use to burn the CD, and how you compare them. What OS are you using? Lastly, when you say that it works with previous versions, do you mean earlier alpha versions, or the latest stable release? Could you try to find out in what version things went broke? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with growisofs on Fedora 1.0
On Sat 8 November 2003 22:22, Maciek Kozyrczak wrote: > Hi, > > I am wondering if any 'growisofs' users have upgraded their > distros to Fedora 1.0. I have a Sony DRU-510A drive that I had > working under Red Hat 9.0. After upgrading to Fedora 1.0, I > recompiled the dvd tool chain, just to ensure library > compatibility. But neither the RH9-compiled nor the > Fedora-compiled versions of 'growisofs' have been producing > reliable burns on Fedora 1.0. I don't end up with any errors > during the burn, but reading back the burned disk gives me > input/output errors. Is anyone out there experiencing similar > problems? > > Thanks, > Maciek Kozyrczak > > PS: I'm almost suspecting the ide-scsi layer, but I have no > evidence to support this. The reason I'm suspicious is because I > can only burn CD-Rs in my Plextor drive in RAW mode (cdrecord), > or else I also get I/O errors on read-back. Is there some known > issue with the 'sg' driver? Well for starters, see this thread: http://www.mail-archive.com/cdwrite@other.debian.org/msg04512.html I did some more experimentation after that, and found out that the disc that gave I/O errors actually had three tracks, not one. Another disc that had only one track worked perfectly. I haven't had time to do more research and figure out what that means and how to fix it though. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: problems with growisofs on Fedora 1.0
On Sat 8 November 2003 22:22, Maciek Kozyrczak wrote: > Hi, > > I am wondering if any 'growisofs' users have upgraded their > distros to Fedora 1.0. I have a Sony DRU-510A drive that I had > working under Red Hat 9.0. After upgrading to Fedora 1.0, I > recompiled the dvd tool chain, just to ensure library > compatibility. But neither the RH9-compiled nor the > Fedora-compiled versions of 'growisofs' have been producing > reliable burns on Fedora 1.0. I don't end up with any errors > during the burn, but reading back the burned disk gives me > input/output errors. Is anyone out there experiencing similar > problems? > > Thanks, > Maciek Kozyrczak > > PS: I'm almost suspecting the ide-scsi layer, but I have no > evidence to support this. The reason I'm suspicious is because I > can only burn CD-Rs in my Plextor drive in RAW mode (cdrecord), > or else I also get I/O errors on read-back. Is there some known > issue with the 'sg' driver? Well for starters, see this thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04512.html I did some more experimentation after that, and found out that the disc that gave I/O errors actually had three tracks, not one. Another disc that had only one track worked perfectly. I haven't had time to do more research and figure out what that means and how to fix it though. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVDs created with too large files
On Mon 3 November 2003 00:06, Volker Kuhlmann wrote: > > But can a file span multiple extents? The way I read the > > comment Gary quoted, it's legal to have an image that is over > > 2GB in size, as long as each file inside that image is no > > larger than 2GB. > > Careful - the comment was about mkisofs, although it was in the > kernel source. It definitely says file*systems* >2GB are legal, > otherwise it says mkisofs can't handle single *files* >2GB - that > doesn't necessarily mean they're illegal. The comment may also be > old and no longer true for current versions of standards. Good point. [...] > > That seems to me like > > the only logical way to explain why the comment says it's > > legal, but the code claims it's illegal to have files that are > > more than 2GB in size. > > You're mixing up file with filesystem here? Erm, actually, what I said doesn't make sense at all. Never mind... > > so apparently at least someone looked at ISO Level 3 support. > > I'd say send a message to linux-kernel and see what they say > > about it... > > Yes, together with a raft of other iso9660 issues :( > > Perhaps mkisofs is now able to handle files >2GB, the lack of a > suitable error when creating the filesystem does suggest so. > However, for Linux that's a moot point as Linux doesn't handle > >2GB, but mkisofs isn't only used on Linux. Thanks Gary for the > warning about that. Linux in general does have large file support now doesn't it? Incidentally, I had a quick look at the same file in 2.6.0-test9, but apart from adding support for compressed iso9660 filesystems (zisofs?) and some stuff apparently to do with multisession handling nothing much seems to have changed here. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: DVDs created with too large files
On Mon 3 November 2003 00:06, Volker Kuhlmann wrote: > > But can a file span multiple extents? The way I read the > > comment Gary quoted, it's legal to have an image that is over > > 2GB in size, as long as each file inside that image is no > > larger than 2GB. > > Careful - the comment was about mkisofs, although it was in the > kernel source. It definitely says file*systems* >2GB are legal, > otherwise it says mkisofs can't handle single *files* >2GB - that > doesn't necessarily mean they're illegal. The comment may also be > old and no longer true for current versions of standards. Good point. [...] > > That seems to me like > > the only logical way to explain why the comment says it's > > legal, but the code claims it's illegal to have files that are > > more than 2GB in size. > > You're mixing up file with filesystem here? Erm, actually, what I said doesn't make sense at all. Never mind... > > so apparently at least someone looked at ISO Level 3 support. > > I'd say send a message to linux-kernel and see what they say > > about it... > > Yes, together with a raft of other iso9660 issues :( > > Perhaps mkisofs is now able to handle files >2GB, the lack of a > suitable error when creating the filesystem does suggest so. > However, for Linux that's a moot point as Linux doesn't handle > >2GB, but mkisofs isn't only used on Linux. Thanks Gary for the > warning about that. Linux in general does have large file support now doesn't it? Incidentally, I had a quick look at the same file in 2.6.0-test9, but apart from adding support for compressed iso9660 filesystems (zisofs?) and some stuff apparently to do with multisession handling nothing much seems to have changed here. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVDs created with too large files
On Sun 2 November 2003 19:03, ljknews wrote: > At 5:27 PM + 11/2/03, Gary Houston wrote: > >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs > > (cdrtools 1.11a29) to write backups to DVD. This generally > > works. However I encountered a problem when one of the files > > was 2351679431 bytes in size: the disk was written with no > > errors reported, but on testing proved to be unreadable to > > linux 2.4.21. On mounting the disk a warning was reported: > > > >Warning: defective CD-ROM. Enabling "cruft" mount option. > > "Defective" CD-ROM is a misleading statement. > "Interchange Level 3 ISO-9660 volumes are not handled by this OS" > would be more accurate. > > > /* > > * The ISO-9660 filesystem only stores 32 bits for file size. > > But the ISO-9660 _standard_ stores 32 bits for the size of each > _extent_ and there can be a virtually unlimited number of > _extents_ in a single file at ISO-9660 Interchange Level 3. But can a file span multiple extents? The way I read the comment Gary quoted, it's legal to have an image that is over 2GB in size, as long as each file inside that image is no larger than 2GB. I haven't actually read the spec though. But then the whole comment seems odd. It looks to me like the WARNING was added later, and written by Jörg. That seems to me like the only logical way to explain why the comment says it's legal, but the code claims it's illegal to have files that are more than 2GB in size. Lastly, at the top of the file, there is * 1998 Eric Lammerts - ISO 9660 Level 3 so apparently at least someone looked at ISO Level 3 support. I'd say send a message to linux-kernel and see what they say about it... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: DVDs created with too large files
On Sun 2 November 2003 19:03, ljknews wrote: > At 5:27 PM + 11/2/03, Gary Houston wrote: > >I have been using dvd+rw-tools (5.13.4.7.4) and mkisofs > > (cdrtools 1.11a29) to write backups to DVD. This generally > > works. However I encountered a problem when one of the files > > was 2351679431 bytes in size: the disk was written with no > > errors reported, but on testing proved to be unreadable to > > linux 2.4.21. On mounting the disk a warning was reported: > > > >Warning: defective CD-ROM. Enabling "cruft" mount option. > > "Defective" CD-ROM is a misleading statement. > "Interchange Level 3 ISO-9660 volumes are not handled by this OS" > would be more accurate. > > > /* > > * The ISO-9660 filesystem only stores 32 bits for file size. > > But the ISO-9660 _standard_ stores 32 bits for the size of each > _extent_ and there can be a virtually unlimited number of > _extents_ in a single file at ISO-9660 Interchange Level 3. But can a file span multiple extents? The way I read the comment Gary quoted, it's legal to have an image that is over 2GB in size, as long as each file inside that image is no larger than 2GB. I haven't actually read the spec though. But then the whole comment seems odd. It looks to me like the WARNING was added later, and written by Jörg. That seems to me like the only logical way to explain why the comment says it's legal, but the code claims it's illegal to have files that are more than 2GB in size. Lastly, at the top of the file, there is * 1998 Eric Lammerts - ISO 9660 Level 3 so apparently at least someone looked at ISO Level 3 support. I'd say send a message to linux-kernel and see what they say about it... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge netinst: CD-RW Sony CRX175A1
On Wed 29 October 2003 19:58, Dani wrote: > Hi. > > I'm netinstalling Debian Sarge from a minimal CD. I boot the CD > and it fails to autodetect the CD drive, maybe because it's a > CD-RW. It's Sony CRX175A1. The installation show me the > following list of kernel modules: aztcd, cdu31a, cm206, gscd, > isp16, mcd, mcdx, optcd, sbpcd, sjcd, sonycd535. > > Which may I choose? I suspect that none of the above because my > drive is CD-RW. These kernel modules are not for your drive, they're for old interfaces that a drive may be attached to. If your drive is simply attached to the IDE on your mainboard as is usually the case, then you need none of the above modules, but you do need the other CD related drivers, and ide-scsi and related modules if you want to burn CDs as well as read them. If your CD drive is connected to an old soundcard or other "multimedia" card, you should find out its type and select the appropriate driver from the list. HTH, Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Sarge netinst: CD-RW Sony CRX175A1
On Wed 29 October 2003 19:58, Dani wrote: > Hi. > > I'm netinstalling Debian Sarge from a minimal CD. I boot the CD > and it fails to autodetect the CD drive, maybe because it's a > CD-RW. It's Sony CRX175A1. The installation show me the > following list of kernel modules: aztcd, cdu31a, cm206, gscd, > isp16, mcd, mcdx, optcd, sbpcd, sjcd, sonycd535. > > Which may I choose? I suspect that none of the above because my > drive is CD-RW. These kernel modules are not for your drive, they're for old interfaces that a drive may be attached to. If your drive is simply attached to the IDE on your mainboard as is usually the case, then you need none of the above modules, but you do need the other CD related drivers, and ide-scsi and related modules if you want to burn CDs as well as read them. If your CD drive is connected to an old soundcard or other "multimedia" card, you should find out its type and select the appropriate driver from the list. HTH, Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: readcd fails on ATAPI drive
On Fri 24 October 2003 18:28, Ashish Rangole wrote: > I am trying to read a CD that I burnt on a ATAPI CD writer. > The cdrecord dev=ATAPI: -scanbus tells me that the writer > device is: 0,0,0 'HL-DT-ST' 'RW/DVD GCC-4240N' 'E112' Removable > CD-ROM > > When I run readcd: > > readcd dev=ATAPI:0,0,0 f=readback.iso , I get the following error > message: > readcd: Invalid argument. Can not send SCSI cmd via ioctl > > I am enclosing the dmesg output for more details. Please advise > me what I am doing wrong and how I can correct the problem. What OS do you have? What driver are you using? Do you have an automounter running? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: readcd fails on ATAPI drive
On Fri 24 October 2003 18:28, Ashish Rangole wrote: > I am trying to read a CD that I burnt on a ATAPI CD writer. > The cdrecord dev=ATAPI: -scanbus tells me that the writer > device is: 0,0,0 'HL-DT-ST' 'RW/DVD GCC-4240N' 'E112' Removable > CD-ROM > > When I run readcd: > > readcd dev=ATAPI:0,0,0 f=readback.iso , I get the following error > message: > readcd: Invalid argument. Can not send SCSI cmd via ioctl > > I am enclosing the dmesg output for more details. Please advise > me what I am doing wrong and how I can correct the problem. What OS do you have? What driver are you using? Do you have an automounter running? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 15 October 2003 16:19, Joerg Schilling wrote: > From: Andy Polyakov <[EMAIL PROTECTED]> > [...] > > 75 blocks exist nowhere in a seek related paper > > > The basic position accuracy (without starting to read!) for a CD > player must be < 2 seconds (150 sectors). This is why at least > 150 sectors of lead out are required to prevent the drive from > hitting the outer barrier. That makes sense. Do you know for sure whether the capacity that is returned by READ CAPACITY is actually supposed (as in according to the SCSI bus spec) to be sector accurate? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
On Wed 15 October 2003 16:19, Joerg Schilling wrote: > From: Andy Polyakov <[EMAIL PROTECTED]> > [...] > > 75 blocks exist nowhere in a seek related paper > > > The basic position accuracy (without starting to read!) for a CD > player must be < 2 seconds (150 sectors). This is why at least > 150 sectors of lead out are required to prevent the drive from > hitting the outer barrier. That makes sense. Do you know for sure whether the capacity that is returned by READ CAPACITY is actually supposed (as in according to the SCSI bus spec) to be sector accurate? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Tue 14 October 2003 12:30, Andy Polyakov wrote: > Meet the players in the field: > > - block buffer which provides for read-ahead, I/O requests' > slicing and coalescing; > - value returned by READ CAPACITY command, hereafter simply READ > CAPACITY; > - actual lead-out position; > > Rules of the game (please note that I'm not claiming that I know > all the rules in detail:-): > > - block buffer rearranges I/O depending on *momentary* > availability of spare memory, e.g. even if you ask for bs=2k, it > may coalesce them to e.g. 126KB chunks, or it may break larger > requests to a number of 4KB ones; > - no requests are posed beyond the READ CAPACITY; > - READ CAPACITY coincides with lead-out position most of the > time, *but not always*; > - CD lead-out position is documented to be inaccurate [with 75 > blocks inaccuracy?], DVD lead-out position is believed to be > accurate; - CD lead-out is preceded by few unaccesible blocks > (unless disk is recorded in DAO mode?), lead-out itself is > unaccesible; Thanks for the explanation! That sheds some more light on the case. I've dug up the ECMA-130 spec (== Yellow Book for all practical purposes) from www.ecma-international.org and after a bit of searching I found this (from section 22.3.4.2): "If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track." The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Okay, so that's how the information is stored on the disc physically. A bit of Googling got me to http://www.t10.org/ftp/t10/document.01/01-246r0.pdf, which states that the READ CAPACITY SCSI bus command returns a logical block address (LBA) and a block length in bytes. The LBA is the address of the last logical block on the disc, so the number of blocks in total before the Lead-out is actually LBA + 1. From /usr/src/linux-2.4.21/drivers/ide/ide-cd.c, cdrom_read_capacity: pc.c[0] = GPCMD_READ_CDVD_CAPACITY; pc.buffer = (char *)&capbuf; pc.buflen = sizeof(capbuf); stat = cdrom_queue_packet_command(drive, &pc); if (stat == 0) *capacity = 1 + be32_to_cpu(capbuf.lba); return stat; So it seems that as long as the drive gives the correct LBA number (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as above), ide-cd will report the correct media size. Readcd from cdrecord uses the exact same way to get the capacity from the drive, and displays the amount of blocks correctly. According to it, my Nero CD has 169825 blocks. Unfortunately the -fulltoc option of readcd isn't implemented, so I can't verify that this matches the information on the disc. Does anyone know of another way to get to the raw TOC data on a CD? Now, as I said ide-cd.c reads the amount of blocks the same way, so it will get the same value. I'm not sure what happens with this value though, presumably it ends up with the block driver as Andy described, but I haven't found out how yet. Looking at the Linux SCSI stuff, I found this in drivers/scsi/sr.c: /* * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. Therefore, if we hit a medium * error within the last 75 2K sectors, we decrease the * saved size value. */ if ((error_sector >> 1) < sr_sizes[device_nr] && scsi_CDs[device_nr].capacity - error_sector < 4 *75) sr_sizes[device_nr] = error_sector >> 1; So it seems that you were correct about that. > > Relevant question is when READ CAPACITY is not equal to lead-out > offset? I don't know about CD, but in DVD case most units would > report full media capacity for READ CAPACITY under following > circumstances: Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. > > case. One can wonder if the common block buffer could do better > job spotting the last addressible sector? Well, yes, but do keep > in mind that it's a *common* block buffer, which is not aware of > CD technicalities... So that I'd say that it's perfectly > legitimate to advice as following. If you really have to checksum > the whole image, then make sure to bypass the block buffer *and* > provide sane block count value. A. Well, it seems to me that the block driver gets the capacity from the underlying de
Re: linux kernel error reading end of cd/dvd
On Tue 14 October 2003 12:30, Andy Polyakov wrote: > Meet the players in the field: > > - block buffer which provides for read-ahead, I/O requests' > slicing and coalescing; > - value returned by READ CAPACITY command, hereafter simply READ > CAPACITY; > - actual lead-out position; > > Rules of the game (please note that I'm not claiming that I know > all the rules in detail:-): > > - block buffer rearranges I/O depending on *momentary* > availability of spare memory, e.g. even if you ask for bs=2k, it > may coalesce them to e.g. 126KB chunks, or it may break larger > requests to a number of 4KB ones; > - no requests are posed beyond the READ CAPACITY; > - READ CAPACITY coincides with lead-out position most of the > time, *but not always*; > - CD lead-out position is documented to be inaccurate [with 75 > blocks inaccuracy?], DVD lead-out position is believed to be > accurate; - CD lead-out is preceded by few unaccesible blocks > (unless disk is recorded in DAO mode?), lead-out itself is > unaccesible; Thanks for the explanation! That sheds some more light on the case. I've dug up the ECMA-130 spec (== Yellow Book for all practical purposes) from www.ecma-international.org and after a bit of searching I found this (from section 22.3.4.2): "If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track." The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Okay, so that's how the information is stored on the disc physically. A bit of Googling got me to http://www.t10.org/ftp/t10/document.01/01-246r0.pdf, which states that the READ CAPACITY SCSI bus command returns a logical block address (LBA) and a block length in bytes. The LBA is the address of the last logical block on the disc, so the number of blocks in total before the Lead-out is actually LBA + 1. From /usr/src/linux-2.4.21/drivers/ide/ide-cd.c, cdrom_read_capacity: pc.c[0] = GPCMD_READ_CDVD_CAPACITY; pc.buffer = (char *)&capbuf; pc.buflen = sizeof(capbuf); stat = cdrom_queue_packet_command(drive, &pc); if (stat == 0) *capacity = 1 + be32_to_cpu(capbuf.lba); return stat; So it seems that as long as the drive gives the correct LBA number (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as above), ide-cd will report the correct media size. Readcd from cdrecord uses the exact same way to get the capacity from the drive, and displays the amount of blocks correctly. According to it, my Nero CD has 169825 blocks. Unfortunately the -fulltoc option of readcd isn't implemented, so I can't verify that this matches the information on the disc. Does anyone know of another way to get to the raw TOC data on a CD? Now, as I said ide-cd.c reads the amount of blocks the same way, so it will get the same value. I'm not sure what happens with this value though, presumably it ends up with the block driver as Andy described, but I haven't found out how yet. Looking at the Linux SCSI stuff, I found this in drivers/scsi/sr.c: /* * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. Therefore, if we hit a medium * error within the last 75 2K sectors, we decrease the * saved size value. */ if ((error_sector >> 1) < sr_sizes[device_nr] && scsi_CDs[device_nr].capacity - error_sector < 4 *75) sr_sizes[device_nr] = error_sector >> 1; So it seems that you were correct about that. > > Relevant question is when READ CAPACITY is not equal to lead-out > offset? I don't know about CD, but in DVD case most units would > report full media capacity for READ CAPACITY under following > circumstances: Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. > > case. One can wonder if the common block buffer could do better > job spotting the last addressible sector? Well, yes, but do keep > in mind that it's a *common* block buffer, which is not aware of > CD technicalities... So that I'd say that it's perfectly > legitimate to advice as following. If you really have to checksum > the whole image, then make sure to bypass the block buffer *and* > provide sane block count value. A. Well, it seems to me that the block driver gets the capacity from the underlying de
Re: Bad media?
On Wed 8 October 2003 20:28, Gregoire Favre wrote: > Hello, > > a DVD burn ended like this: > > Track 01: 4387 of 4449 MB written (fifo 99%) [buf 100%] > 2.0x. See below. > Total translation table size: 0 > Total rockridge attributes bytes: 0 > Total directory bytes: 0 > Path table size(bytes): 10 > Max brk space used 21ac4 Information about the disc. > 2277945 extents written (4449 Mb) > Track 01: 4431 of 4449 MB written (fifo 100%) [buf 94%] This means that it stopped on the first track, after having written 4431 of 4449 MB. The fifo queue (between cdrecord and the drive) was 100% full, the buffer (in the drive) was 94% full. If this were a buffer underrun the buffer would have been empty (0%). > 2.0x.cdrecord-prodvd: Input/output error. write_g1: scsi sendcmd: > no error There was an Input/output error when writing. This is a very generic error message, that doesn't say much other then that something went wrong. The last SCSI command (write_g1) was sent to the drive succesfully (the "scsi sendcmd: no error" part), but there was a problem executing it. > CDB: 2A 00 00 22 9F F1 00 00 1F 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: F1 00 03 00 22 97 29 12 00 00 00 00 0C 08 00 00 > Sense Key: 0x3 Medium Error, deferred error, Segment 0 There was an error in the medium (ie the disc). 0x2 and 0x3 are the SCSI status codes. > Sense Code: 0x0C Qual 0x08 (write error - recovery failed) Fru > 0x0 Sense flags: Blk 2266921 (valid) It tried to recover from the write error, but that didn't work. > cmd finished after 0.002s timeout 100s The SCSI command finished after 0.002s (with an error). > write track data: error after 4647258112 bytes We wrote 4647258112 bytes and then the error occurred. > cdrecord-prodvd: A write error occured.cdrecord-prodvd: Please > properly read the error message above. This message stems from Jörgs belief that all users are familiar with the internals of CD writing and can decipher it. I've picked up some stuff from reading this list for a long time and browsing through the entire set of documentation for cdrecord and associated programs to classify them for the new website, but I'm not sure I've got it 100% correct either. > Writing time: 1758.609s > Average write speed 1.9x. > Min drive buffer fill was 93% Some statistics about the burn. > Fixating... > Fixating time:0.000s The disc was fixated. > cdrecord-prodvd: fifo had 73483 puts and > 73200 gets. > cdrecord-prodvd: fifo was 0 times empty and 15373 times full, min > fill was 97%. Statistics about the fifo queue between cdrecord and the drive. It wasn't empty, so it's not a problem with your computer being too slow to feed the drive data. > Is it a bad media (I don't understand the message)? Probably, yes. It could always be a firmware problem or a bug in cdrecord, but those are both very unlikely. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Bad media?
On Wed 8 October 2003 20:28, Gregoire Favre wrote: > Hello, > > a DVD burn ended like this: > > Track 01: 4387 of 4449 MB written (fifo 99%) [buf 100%] > 2.0x. See below. > Total translation table size: 0 > Total rockridge attributes bytes: 0 > Total directory bytes: 0 > Path table size(bytes): 10 > Max brk space used 21ac4 Information about the disc. > 2277945 extents written (4449 Mb) > Track 01: 4431 of 4449 MB written (fifo 100%) [buf 94%] This means that it stopped on the first track, after having written 4431 of 4449 MB. The fifo queue (between cdrecord and the drive) was 100% full, the buffer (in the drive) was 94% full. If this were a buffer underrun the buffer would have been empty (0%). > 2.0x.cdrecord-prodvd: Input/output error. write_g1: scsi sendcmd: > no error There was an Input/output error when writing. This is a very generic error message, that doesn't say much other then that something went wrong. The last SCSI command (write_g1) was sent to the drive succesfully (the "scsi sendcmd: no error" part), but there was a problem executing it. > CDB: 2A 00 00 22 9F F1 00 00 1F 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: F1 00 03 00 22 97 29 12 00 00 00 00 0C 08 00 00 > Sense Key: 0x3 Medium Error, deferred error, Segment 0 There was an error in the medium (ie the disc). 0x2 and 0x3 are the SCSI status codes. > Sense Code: 0x0C Qual 0x08 (write error - recovery failed) Fru > 0x0 Sense flags: Blk 2266921 (valid) It tried to recover from the write error, but that didn't work. > cmd finished after 0.002s timeout 100s The SCSI command finished after 0.002s (with an error). > write track data: error after 4647258112 bytes We wrote 4647258112 bytes and then the error occurred. > cdrecord-prodvd: A write error occured.cdrecord-prodvd: Please > properly read the error message above. This message stems from Jörgs belief that all users are familiar with the internals of CD writing and can decipher it. I've picked up some stuff from reading this list for a long time and browsing through the entire set of documentation for cdrecord and associated programs to classify them for the new website, but I'm not sure I've got it 100% correct either. > Writing time: 1758.609s > Average write speed 1.9x. > Min drive buffer fill was 93% Some statistics about the burn. > Fixating... > Fixating time:0.000s The disc was fixated. > cdrecord-prodvd: fifo had 73483 puts and > 73200 gets. > cdrecord-prodvd: fifo was 0 times empty and 15373 times full, min > fill was 97%. Statistics about the fifo queue between cdrecord and the drive. It wasn't empty, so it's not a problem with your computer being too slow to feed the drive data. > Is it a bad media (I don't understand the message)? Probably, yes. It could always be a firmware problem or a bug in cdrecord, but those are both very unlikely. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:41, Lourens Veen wrote: > On Wed 8 October 2003 13:03, Rob Bogus wrote: > > Well, it could be a bad CD ;-) I just tried using dd on my old > > burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the > > 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 > > kernel, and no error on any of them. I can't try a 2.6 kernel > > without rebooting, but I'll try that at work. > > I'm running a standard 2.4.21 kernel.org kernel. My original > experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the > same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the > same error. I've also tried a different CD, with 38789, and it > reads correctly in both, as did another burned CD with 14425 > blocks. As Jörg said in his out-of-thread mail that readcd is better than dd, just for fun I gave readcd a go with the "broken" CD. It sees 169825 blocks (where isoinfo saw 160525) and could read 160512 of them before giving an IO error. Interesting. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:41, Lourens Veen wrote: > On Wed 8 October 2003 13:03, Rob Bogus wrote: > > Well, it could be a bad CD ;-) I just tried using dd on my old > > burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the > > 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 > > kernel, and no error on any of them. I can't try a 2.6 kernel > > without rebooting, but I'll try that at work. > > I'm running a standard 2.4.21 kernel.org kernel. My original > experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the > same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the > same error. I've also tried a different CD, with 38789, and it > reads correctly in both, as did another burned CD with 14425 > blocks. As Jörg said in his out-of-thread mail that readcd is better than dd, just for fun I gave readcd a go with the "broken" CD. It sees 169825 blocks (where isoinfo saw 160525) and could read 160512 of them before giving an IO error. Interesting. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:03, Rob Bogus wrote: > > Well, it could be a bad CD ;-) I just tried using dd on my old > burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the > 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, > and no error on any of them. I can't try a 2.6 kernel without > rebooting, but I'll try that at work. I'm running a standard 2.4.21 kernel.org kernel. My original experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the same error. I've also tried a different CD, with 38789, and it reads correctly in both, as did another burned CD with 14425 blocks. I tried mounting the CD that did not work, and copy all files off of it. No problems there. Perhaps it's some sort of odd copy protection? (it's a Nero install CD that came with my burner, I figured I'd paid for it but never used it before so now would be a good time :-)) > Could be media, hardware/firmware, or as you say, something we > don't understand. Well, I'm not at all sure what it is anymore now. Perhaps it's just the quality of CDs that's less than people expect. > Another thought, with some older cdrecord versions I convinced > myself that using -pad making the ISO image was more successful > than using the option in cdrecord. Don't know if that was/is true > or just based on too few trials. Also seem to remember that > readcd works differently with the ide-cd driver. Hmm, I've never used the -pad option either way, can't comment there. > Too many possibilities, and Joerg is not motivated to do anything > with Linux except whine that the kernel people doing the work > won't take orders and do it his way. He doesn't seem to be doing much with cdrecord at all lately. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:03, Rob Bogus wrote: > > Well, it could be a bad CD ;-) I just tried using dd on my old > burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the > 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, > and no error on any of them. I can't try a 2.6 kernel without > rebooting, but I'll try that at work. I'm running a standard 2.4.21 kernel.org kernel. My original experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the same error. I've also tried a different CD, with 38789, and it reads correctly in both, as did another burned CD with 14425 blocks. I tried mounting the CD that did not work, and copy all files off of it. No problems there. Perhaps it's some sort of odd copy protection? (it's a Nero install CD that came with my burner, I figured I'd paid for it but never used it before so now would be a good time :-)) > Could be media, hardware/firmware, or as you say, something we > don't understand. Well, I'm not at all sure what it is anymore now. Perhaps it's just the quality of CDs that's less than people expect. > Another thought, with some older cdrecord versions I convinced > myself that using -pad making the ISO image was more successful > than using the option in cdrecord. Don't know if that was/is true > or just based on too few trials. Also seem to remember that > readcd works differently with the ide-cd driver. Hmm, I've never used the -pad option either way, can't comment there. > Too many possibilities, and Joerg is not motivated to do anything > with Linux except whine that the kernel people doing the work > won't take orders and do it his way. He doesn't seem to be doing much with cdrecord at all lately. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 05:09, Rob Bogus wrote: > Volker Kuhlmann wrote: > >Esteemed gurus, > > > >if anyone is able to shed some more light on this kernel problem > > I'd appreciate it. It's been going on for years. > > > >When reading the whole of an iso9660 filesystem from a cd or > > dvd, I often get I/O errors within the last blocks of the > > filesystem. Using > > This is caused by reading past the end of written data. You can > either (a) get the size of the ISO filesystem with cdrecord or > isoinfo, and then use dd to read only what's valid, or complain > to the creator of the CD. There's an option which fixes this, > from memory -dao. Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 05:09, Rob Bogus wrote: > Volker Kuhlmann wrote: > >Esteemed gurus, > > > >if anyone is able to shed some more light on this kernel problem > > I'd appreciate it. It's been going on for years. > > > >When reading the whole of an iso9660 filesystem from a cd or > > dvd, I often get I/O errors within the last blocks of the > > filesystem. Using > > This is caused by reading past the end of written data. You can > either (a) get the size of the ISO filesystem with cdrecord or > isoinfo, and then use dd to read only what's valid, or complain > to the creator of the CD. There's an option which fixes this, > from memory -dao. Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Tue 7 October 2003 00:06, Volker Kuhlmann wrote: > Esteemed gurus, > > if anyone is able to shed some more light on this kernel problem > I'd appreciate it. It's been going on for years. > > This state of affairs is not really acceptable. Does anyone know > what the problem is caused by, and what can/should be done about > it? Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. Posting it here is just going to get you another "Linus is stupid" remark from Jörg, and probably not much of a resolution. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
On Tue 7 October 2003 00:06, Volker Kuhlmann wrote: > Esteemed gurus, > > if anyone is able to shed some more light on this kernel problem > I'd appreciate it. It's been going on for years. > > This state of affairs is not really acceptable. Does anyone know > what the problem is caused by, and what can/should be done about > it? Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. Posting it here is just going to get you another "Linus is stupid" remark from Jörg, and probably not much of a resolution. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Website (was: Compile against 2.6-test5)
On Tue 23 September 2003 07:19, Matthew Beale wrote: > ps, i dont think i'm actually on this list, so please CCthe > webpage isnt very helpful in contacting the list.. You men the page at http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html right? I'm working on a new site, there is a test version at http://cdrecord.berlios.de/test/. I'm currently stuck because I need to clear a few things with Jörg and he's not responding to my email, but if you have any comments I'd love to hear them. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Website (was: Compile against 2.6-test5)
On Tue 23 September 2003 07:19, Matthew Beale wrote: > ps, i dont think i'm actually on this list, so please CCthe > webpage isnt very helpful in contacting the list.. You men the page at http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html right? I'm working on a new site, there is a test version at http://cdrecord.berlios.de/test/. I'm currently stuck because I need to clear a few things with Jörg and he's not responding to my email, but if you have any comments I'd love to hear them. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wrong: (was: Re: Another Cdrecord Format String Vulnerability Exploit Released)
On Sat 19 July 2003 15:20, Joerg Schilling wrote: > From [EMAIL PROTECTED] Fri Jul 18 18:22:22 2003 > > >> >http://www.securiteam.com/exploits/5ZP0C2AAAC.html > > > >So, what we have here is someone installing an old version with > > a=20 known vulnerability, writing an exploit for it, and > > bragging about=20 it. Either that or it took him 3 1/2 months > > more than J=F6rg to=20 figure out that there was indeed a > > vulnerability and he didn't=20 bother to check if it had been > > fixed before publishing his exploit. > > The only bad thing with this exploit is that SuSE did know about > the problem sice october but did not report it! > > So the missing will to cooperate from a commercial Linux > distributor prevented this bug from being removed before > cdrtrools-2.0 has been published. Ehm, so you're saying that cdrtools-2.0 still has this vulnerability? Is there a patch for the stable version (cdrtools-2.00.3.tar.gz on the ftp site?) or should we all just run the latest alpha to avoid problems? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wrong: (was: Re: Another Cdrecord Format String Vulnerability Exploit Released)
On Fri 18 July 2003 17:35, Joerg Schilling wrote: > >Old-Return-Path: <[EMAIL PROTECTED]> > > > >http://www.securiteam.com/exploits/5ZP0C2AAAC.html > > This is just a very very old one that has been fixed on May 3th > (3.5 months before the posting you you refer has been made). > > > It could thus nopt be called a cdrecord vulnerability but > probably a Slackware problem (if the guys on Slackware do not > react on bug alerts within 3 1/2 months). Slackware 8.1 ships with cdrtools-1.11a24, Slackware 9 and Slackware-current both have cdrtools-2.0. I haven't been able to find any cdrtools-2.01a5 packages on the official Slackware FTP sites (I used the dl.xs4all.nl mirror, which is usually up-to-date and complete). So, what we have here is someone installing an old version with a known vulnerability, writing an exploit for it, and bragging about it. Either that or it took him 3 1/2 months more than Jörg to figure out that there was indeed a vulnerability and he didn't bother to check if it had been fixed before publishing his exploit. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: two questions concerning fast burning and burn-free
On Wed 16 July 2003 16:19, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Jul 16 15:36:51 2003 > > >> Linus Torvalds usually blocks them :-( > > > >May I make a suggestion? Joerg! Next time you feel like claiming > > that Linus Torvalds (or anybody else in person, Alan Cox > > maybe?) is so to say sitting around and deliberately tries to > > complicate your life as cdrecord developer, then I suggest to > > take a deep breath and abstain from such remarks. Not that they > > are simply not true, such comments are generally inappropriate > > for essentially technical forum such as this. If you want to > > criticize, criticize technologies and their implementations, > > but not persons. If personal comment is unavoidable, explicitly > > address the person in question. Same naturally applies to all > > subscribers to this forum. A. > > First: it is Linus who started to be personal against me, so he > obviously likes this way of discussion I don't read lkml normally but in the thread you link below he uses your name as an example of someone writing a userspace tool. Perhaps you are simply the most famous/vocal user space programmer to deal with that code? I bet if you asked a random person to name a Linux kernel hacker then Linus and Alan would probably be mentioned more often than others as well... > Second: I was not critizising the person but the doings. > Let me make an example: A few weeks ago, Jeff Garzik announced a > new SCSI interface for ATAPI. > > http://marc.theaimsgroup.com/?t=10539253612&r=3&w=2 > > If you read this thread, you see that Linus obviously does not > understand the background and likes the implementation to be > better than anything before, before giving Jeff a chance. As it > should be obvious that a draft of a new implementation method > never is made complete just in order to save time, a > knowledgeable programmer would be able to understand whether a > new idea could give problems in the future. I think you and Linus are really looking at the whole thing from exactly opposite directions. You're thinking that it's all really SCSI commands that are being sent over SCSI- or non-SCSI connections. So, just write a generic SCSI kernel interface and have the kernel patch things up where it's not quite SCSI, then have cdrecord shove appropriate SCSI commands through that interface to the drive, and be done with it. So you're looking at the similarities. Linus on the other hand seems to be looking at the differences. All these different interfaces look like SCSI because they use the SCSI command set. But on other parts they're pretty different, for example because they use different connections. If you're going to map things arbitrarily (which ide-scsi is doing now, hence Jörgs complaints about unstable devices->busses mapping in Linux) anyway, then why emulate a SCSI bus if you haven't got one? Wouldn't it be silly if the kernel told userspace that I had a SCSI device on the first SCSI bus and a SCSI device on the second SCSI bus, while in reality they're both ATAPI devices on different controllers and I haven't even got a SCSI host adapter let alone any drives? So instead he wants a generic /dev/driveX and /dev/cdromX etc., because it makes more sense for the end user and you have to map things in the kernel anyway. Ofcourse, the problem for cdrecord then becomes that its IO model is based around SCSI, including SCSI attachment bus/id/lun addressing. Which is fine on everything but Linux apparently. I think I know why too. UNIX has traditionally been used on large machines, servers and mainframes, not on consumer-grade PCs. Those big machines don't have IDE. The low end has SCSI, and maybe the high end too I don't know, but at least it's not IDE. So, everything is designed around SCSI. Now what do you do when you want to run Solaris or BSD on x86 and you need to support ATAPI? Right, you look at it as SCSI with a different bus, and put it within your existing SCSI framework. Linux in the mean time was designed from the beginning for PCs with IDE/ATAPI drives and SCSI drives, so it had a generic block IO layer and underneath this layer two separate IDE and SCSI subsystems. Which ofcourse caused problems when CD writers showed up, which led to the ide-scsi ATAPI support hack. And now they're reworking things, but at the top level they still have their own block layer as the userspace interface, instead of mapping everything to the SCSI model as other OSes apparently do. So yes, Linux does do things differently from everything that's been used before. Linus actually gives the reason for that in http://marc.theaimsgroup.com/?l=linux-kernel&m=105401713912746&w=2 I don't see why Linux would have to do everything exactly like other unices. It's designed for different systems, systems on which other approaches may make more sense. Dismissing something outright because it differs from what has already been done seems to me to
Re: Dvdrecord problem
On Fri 20 June 2003 14:45, Joerg Schilling wrote: > From [EMAIL PROTECTED] Thu Jun 19 14:35:41 2003 > > The main point is that with e.g. dvdrecord, you do not have the > freedom to use the program for the announced purpose because it > only works for outdated drives and there is no support. Surely there's a difference between the freedom to do something and the possibility of doing it? Nobody is disputing that cdrecord-ProDVD is a better option from a technical and support point of view. But that doesn't mean that I also have the freedom to see how it works and modify it for example. > As nobody works in dvdrecord, the "other resons" for the so > called freedom do not apply The fact that I'm not studying or modifying dvdrecord doesn't mean that I don't have the freedom to do so. Put it this way. I'm free to run 10 km in half an hour, but I don't have the physical capability to do that. I have the physical capability to drive a car at 140 km/h on the motorway but I'm not free to do so (in Holland that is, in Germany ofcourse I would). And this is all totally independent of whether I'm actually doing it. Ability, freedom and actual occurrence are different things. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dvdrecord problem
On Thu 19 June 2003 14:25, Greg Wooledge wrote:
> On Thu, Jun 19, 2003 at 01:14:34PM +0200, Joerg Schilling wrote:
> > >From [EMAIL PROTECTED] Wed Jun 18 16:03:00 2003
> > >
> > >> Well, cdrecord-ProDVD definitely is free for private and
> > >> research/educational use.
> > >
> > >s/free/libre/
> >
> > Do you really belive that the context changes if you only
> > translate from english to french?
>
> More important is the fact that he used the wrong translation.
> cdrecord-ProDVD is gratis ("free as in beer"), not libre ("free
> as in speech").
I read that as referring to his original post, ie Jörg says that
cdrecord-ProDVD is free-as-in-beer so he clarifies that he meant
libre and not free-as-in-beer. Given that he works for Mandrake I
bet he knows a bit of French :-).
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dvdrecord problem
On Thu 19 June 2003 13:14, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Jun 18 16:03:00 2003 > > >> Well, cdrecord-ProDVD definitely is free for private and > >> research/educational use. > > > >s/free/libre/ > > Do you really belive that the context changes if you only > translate from english to french? "Libre" is used by the Free Software Foundation and others to express software that has four kinds of freedom (from http://www.gnu.org/philosophy/free-sw.html): # The freedom to run the program, for any purpose (freedom 0). # The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. # The freedom to redistribute copies so you can help your neighbor (freedom 2). # The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. The problem with English is that the word free means free-of-charge as well as free-as-in-freedom, and people generally think of the former when you mention free software. Hence the use of the term "libre" which means free-as-in-freedom, but not free-of-charge (compare "gratis" and "frei" in German). This avoids exactly the confusion in the parent posts. The context isn't different, it's just a more exact description. I realise and respect that you don't care much about these four freedoms, but opinions and values differ and people should have the right to form their own opinions and choose whether to use software based on their own principles. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error - what's wrong?
On Tue 10 June 2003 15:32, Joerg Schilling wrote: > From: [EMAIL PROTECTED] > > >The system is dedicated for writing... > > > >Both the writer and media are 52x capable, but when cdrecord > > displays progress it only comes up to 25x. All the drives have > > UDMA enabled and each has it's own IDE bus (two on-board and > > one Promise add-on IDE bus for the disk). > > > >Below is the error I get... > > > > Thanks, D. > > > >scsidev: '0,0,0' > >scsibus: 0 target: 0 lun: 0 > >Linux sg driver version: 3.1.24 > >/usr/bin/cdrecord: Warning: using inofficial libscg transport > > code version = ([EMAIL PROTECTED] > > '@(#)scsi-linux-sg.c=091.75= 02/10/21 Copyright 1997 J. > > Schilling'). > >Cdrecord 2.0 (i686-suse-linux) Copyright (C) 1995-2002 J=F6rg > > Schilling TOC Type: 1 =3D CD-ROM > >Using libscg version 'schily-0.7' > >atapi: 1 > > You are using an illegal version of cdrecord. > > This version is not working corrrectly because it has been > modified by SuSE. > > (see GPL § 2 subclause c) and GPL Preamble, subsection 6) Before I submit a report to SuSE about this, it seems that it's libscg that they patched, not cdrecord itself, correct? If they use the original cdrecord with a modified libscg (presumably to match their modified kernel) and libscg doesn't normall print anything (because it's a library) then technically this is still legal. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord: RR-scheduling prob. in 2.01a1[45]
On Sun 1 June 2003 11:58, Karl-Heinz Herrmann wrote: > Hi, > > > I wanted to upgrade to a recent cdrtools on linux 2.4.16 (and > 21-rc6, SuSE7.x+new kernel) PIII Dell I8k laptop and ran into > following problem: > > cdrecord is unable to set RR-scheduler (permission denied) Could be me, but don't you need a kernel patch for low-latency operation and real-time schedulers? Or is it just the latency that goes down by patching and is real-time scheduling always available? Something to check maybe. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error message in xcdroast.
On Thu 29 May 2003 09:29, Bob Buick wrote: > I'm a bit of a newbie and have been getting the following message > whenever I try to write, or blank a CD-RW in xcdroast with > Mandrake 9.0. > > cdrecord: Warning: controller returns wrong size for CD > capabilities page. > > I read the man file an hunted around, but can't find out what I > have to do to put it right. > > Can you help, or steer me to a HowTo file? http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html Try it from the command line, then send us the output according to the instructions above. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copy protection?
On Wed 28 May 2003 17:36, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >Yes, not having the build system in the printed header is > > really=20 > > ^^ > ?? > > >going to cause cdrecord to malfunction. It works for him, > > doesn't=20 it? Then what's the problem? > > Well his verbose ouput prooves that it die not work. Well, I think that had more to do with copy protection. Unless I'm mistaken, the purpose of cdrecord is to burn CDs on various platforms (right? If not then I'll have to change that new web design). It seems to me that displaying what platform it was compiled on is not directly required to be able to do that. The fact that it didn't work was that he had a "copy-protected" non-CD, not that the platform string didn't display properly. > But at least, I now know what happened. It is not the first time, > I did see a cdrecord verbose message that misses the platform > string and replaced is by '(--)'. Well apparently these people compiled in in a way different from what you expected. As long as it works for them, I still don't see the problem... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copy protection?
On Wed 28 May 2003 12:45, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed May 28 11:06:54 2003 > > >> >[EMAIL PROTECTED] alpha]# uname -a > >> >Linux alfonz.agenda.si 2.4.19 #1 pon avg 12 14:49:02 CEST > >> > 2002 alpha unknown > >> > > >> > > >> >cdrtools were compiled on this system using RPM. The spec > >> > file is pretty > >> > >>^^^ > >>??? > >> > >> What should this be? As RPM is no standard, there of course is > >> no RPM for the cdrtrools source package. Looks loke you are > >> using an inofficial and mofified to be broken thing. Where did > >> you get this from? > > > >I get cdrtools sources from > > ftp://ftp.berlios.de/pub/cdrecord/alpha/ and then I use MY OWN > > SPEC file to build MY OWN RPM package. > > Sounds strange! Why should one hack something around a working > packet? Why should one question whatever someone else does in their own time on their own system? Incidentally, my guess at the answer is dependencies. If you install cdrecord this way then you can install an RPM for a frontend after it and RPM will have noticed cdrecord being installed, so it knows that it's available and you get a nicely working dependency system. > >The SPEC file I use DOESN'T apply any patches and it DOESN'T run > > any scripts to change the source code. It simply runs > > 'configure' (which - in case of cdrtools - does nothing) and > > then it runs 'make'. If all this goes through without errors, > > it runs 'make install' and then packages all the relevant file > > into my RPM package. > > > >Where is the problem!? > > Your broken make system. > > Just compile the source the correct way (by simply calling "make" > after you did upack the tar archive) and it will work as > intended. > > Proof: > Conclusion: your RPM stuff is useless (even more counter > productive) and should not be used if you are interested in > correct binaries. Yes, not having the build system in the printed header is really going to cause cdrecord to malfunction. It works for him, doesn't it? Then what's the problem? Sure, you have every right to not offer support for anything that isn't compiled and installed exactly in accordance with the docs. If you want to prohibit people doing things in a different way you should put it in the license. As long as it's not in the license, I think it's pretty arrogant to believe you have the right to tell people what to do with their computers. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I just want to Burn on Asus 24x10x40x
On Wed 26 March 2003 13:23, ehab samir aziz wrote: > I have read README and README.compile adn I do not > know which one I should follow first ? > I need smake to compile install file as written in > section how to compile in README.compile there is no > file called install in cdrtool driectory but INSTALL > is found . Also I have read README in how to install > section : > what is the relation between scg driver and fbk driver > and cdrtool Apparently you didn't get my last mail. Here it is again, hope it comes through this time, and you can answer my questions so I can actually try and help you. If you don't tell me what you are doing exactly, what results you get, and what results you wanted, I can't help you, because I don't know what you want to do. --- On Mon 24 March 2003 21:36, ehab samir aziz wrote: > I tried to install cdrecord after tar -xvf > cdrtools-2.0 but it seems that I should have gcc > compiler to compiler some files . Really I do not have That would surprise me. Jörg uses Solaris himself, and README.solaris (did you follow the instructions in there?) doesn't say anything about needing gcc to compile cdrecord. So I'd say it should work. What did you do exactly and what error message are you getting when you try to compile? Oh, and please CC the list, that way this will show up in the archives and others who have a similar problem in the future will be able to look it up. --- Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I just want to Burn on Asus 24x10x40x
On Mon 24 March 2003 21:36, ehab samir aziz wrote: > I tried to install cdrecord after tar -xvf > cdrtools-2.0 but it seems that I should have gcc > compiler to compiler some files . Really I do not have That would surprise me. Jörg uses Solaris himself, and README.solaris (did you follow the instructions in there?) doesn't say anything about needing gcc to compile cdrecord. So I'd say it should work. What did you do exactly and what error message are you getting when you try to compile? Oh, and please CC the list, that way this will show up in the archives and others who have a similar problem in the future will be able to look it up. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I just want to Burn on Asus 24x10x40x
On Sun 23 March 2003 22:18, ehab samir aziz wrote: > I can not find ver 2 in this folder the maximum I can > find cdrecord-1.09.tar.gz . cdrecord is now part of the cdrtools package. You'll want to use ftp://ftp.berlios.de/pub/cdrecord/cdrtools-2.0.tar.gz HTH, Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
CDRecord website
Jörg, (short synopsis at the bottom if you're very much in a hurry) I've been looking at the cdrecord website for a bit, and noticed that it is quite chaotic. Specific information is hard to find, and everything is thrown together on one page in random order. Also several pieces of information are heavily outdated. I understand that this is because you are very busy with cdrecord development. I don't know much about SCSI or kernel hacking, and learning that would take a lot of time. I am pretty good at organising data and I have quite a bit of experience making websites, and some experience with public relations work. I figure it's time I balance the comments and criticism I've given on the cdwrite list with some more positive involvement, and with the above in mind I would like to volunteer to sift through the information currently available on the cdrecord web site, filter it for relevance to the current state of affairs, sort it, and create a new web site that allows easy access to the material. What I need to know is whether you would accept such a contribution. It is your project, and if you feel this effort would be unnecessary or undesired I will accept that, but I'd like to know before spending time on it. Hopefully, this will also help increase the quality of bug reports and allow us to streamline the support process, giving you more time to actually write code or do other things (it's your free time after all). SHORT SYNOPSIS: I'd like to volunteer to redesign the cdrecord website to make information more easily accessible. Hopefully this will also lead to better bug reports. I'd like to know if you would accept the results of such an effort, before spending too much time on it. Thanks, Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I just want to Burn on Asus 24x10x40x
On Sat 22 March 2003 17:43, ehab samir aziz wrote: > how to chose the right version of cdrecord for my > cd-writable ASUS 24x10x40x . and where can I find the > tutorial of using cdrcord for my Solaris 8 The latest stable version (2.0, available from ftp://ftp.berlios.de/pub/cdrecord/) should work fine. There's a README.solaris there too. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: howto burn a (data)dvd
On Fri 21 March 2003 23:29, Joerg Schilling wrote: > From [EMAIL PROTECTED] Fri Mar 21 22:32:42 2003 > > >> A much more realistic idea is why there is no source for > >> cdrecord-ProDVD: > >> > >> =09Commercial companies steel my work and sell it secretly. > > > >Two observations: > > > >1) Apparently, cdrecord doesn't fulfill the needs of a > > significant=20 group of potential users. Otherwise, there > > wouldn't be a market for=20 it. > > Calling bad guesses 'observations" does not help and does not > make me believe that you are really interested in the toic.:-( > > It is mere that _other_ CD/DVD writing programs (specially on > Win32) do not meet the needs of the customers so companies are > interested to use cdrecord as the base fro a new 'product'. But why don't the users of those programs use cdrecord then? I mean if you say that it meets their needs... > In addittion, commercial companies have a high level of criminal > potential. If they like to create a product for several UNIX > platforms they may either pay > 5 US $ per year to GEAR or > try to illegally use cdrecord. Agreed. > >2) Other FOSS projects (xvid comes to mind, see [1]) have=20 > >succesfully used publicising of infringements to get the > > violating=20 companies to comply with the license. It seems to > > be a very=20 succesful tactic so far, but cdrecord can't use it > > apparently. > > It is hard to go this way and gong the way described in the > attendum may not cause any change in behavior. You usually need > to sue the violaters and this is hard to do and you will need a > lot of money in advance. My point is that it usually does, and is a lot cheaper and simpler than a court case. See the examples. > >It seems to me that this is a symptom of the way cdrecord=20 > >development is done. cdrecord is open source (at least the > > CD-only=20 version), but its development is done in the > > classical cathedral=20 style. Open source isn't just about > > having the source available,=20 it's about open development, > > it's about having a community of=20 developers and users, and > > communication within that community.=20 > > I am sorry but it seems that you don't know what you are talking > about :-( > > Cdrecord development is open to anybody but few people like to > cooperate and have the neded skills. In order to cooperate, > people need to know how to deal with SCSI and how to write > portable programs. If people send me patches, they must make > sense and need to be of apropriate quality. It I receive a patch > that would cause me 1-4 weeks to integrate (mostly by a complete > rewrite) it may take a long long time until I have the needed > time for the rewrite. > > A constant cooperation is only present with Heiko (cdda2wav) and > James (mkisofs). Both send changes that only need minor ( << 5 %) > changes in order to get integrated. I would be happy if other > people would be willing to help.. But apparently they aren't. > >There is no such thing as a cdrecord development community. > > There is=20 no cdrecord-devel mailinglists where patches are > > sent to and=20 discussed, there is no cdrecord-users > > mailinglist where people can=20 get help from others in the > > community, and the developers (Joerg=20 Schilling mainly) are > > very closed when they answer email, never=20 explaining their > > answers. > > My answeres are as long as I have time. If people lik you and > others are not even willing to help replying to the incoming > mail, why do you like to make me believe that there is a > potential for coders? I'm willing to help replying to incoming mail. Most of the incoming mail seems to be sent to your email address only though, so I can't. For example, I replied to the "Linux cdrecord problem" thread of February 28 as I could answer that question to some extent. Problems reported with cdrecord seem often to be low-level problems which require intimate knowledge of SCSI and cd burning, partly because cdrecord basically dumps raw SCSI errors to the output in case of problems, so that a non-SCSI-expert doesn't have a clue as to what's going on. Unless questions are duplicated (which is hard to see unless you understand the problem to some extent) I can't help much with that. > In addition, there are frequent mail threads where people with > missing background knowledge on portability send rants about my > make system and portability guidelines. If people do not know how > to make things better, they should better be quiet instead of > sending destructive critics. If people disagree with you, you either shout them down or ignore them. Or at least that's the way it looks to me. Ofcourse the whole discussion on smake is a moot point since you're not going to use autotools and the rest of the world isn't going to use smake. With both sides dug in like that, arguing is a waste of time. > >Without infrastructure and some help understanding what's > > really=20 going on, no community will form.
Re: howto burn a (data)dvd
On Fri 21 March 2003 17:04, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Mar 19 05:11:22 2003 > > >> You definitely completely missunderstood the spirit of free > >> software. > > > >The issue, at least for me, is not "free" it's open source. It's > > software= =20 > >which can not be just pulled out from under me because the > > vendor or auth= or=20 > >has a brain fart and decides to drop my most useful feature, > > refuse to po= rt=20 > > A much more realistic idea is why there is no source for > cdrecord-ProDVD: > > Commercial companies steel my work and sell it secretly. Two observations: 1) Apparently, cdrecord doesn't fulfill the needs of a significant group of potential users. Otherwise, there wouldn't be a market for it. 2) Other FOSS projects (xvid comes to mind, see [1]) have succesfully used publicising of infringements to get the violating companies to comply with the license. It seems to be a very succesful tactic so far, but cdrecord can't use it apparently. It seems to me that this is a symptom of the way cdrecord development is done. cdrecord is open source (at least the CD-only version), but its development is done in the classical cathedral style. Open source isn't just about having the source available, it's about open development, it's about having a community of developers and users, and communication within that community. There is no such thing as a cdrecord development community. There is no cdrecord-devel mailinglists where patches are sent to and discussed, there is no cdrecord-users mailinglist where people can get help from others in the community, and the developers (Joerg Schilling mainly) are very closed when they answer email, never explaining their answers. Without infrastructure and some help understanding what's really going on, no community will form. This means that cdrecord never reaps the benefits of its being open source, and it leads to forks and unhappiness between developers. A good example of that is the latest developments in the XFree86 community (see [2]). Proof that it can in fact work even for technically complicated projects is provided by the Gatos project [3] which aims to create drivers for capturing video using ATI cards, and has a nice and friendly mailinglist where users and developers can discuss anything related to the project). Another good example of the power of an active community is the reaction of the CDex community on NeoAudio. NeoAudio was a completely legal derived work, but it wasn't very nice. Read for yourself at [4]). With all this and his bitter comments about not getting anything back for cdrecord being open source on this list in mind, I think it's Joerg who doesn't really understand open source. Or maybe he does, but is just not half as good at managing a user community as he is at writing code. A couple of messages ago (bit hard to follow the thread since Joergs mail reader doesn't understand threading) he asked for a better solution for the stealing of cdrecord source: "Give me a different _working_ way tp protect my code from being abused by commercial companies and I would even publish source." Here's a way. It has proven itself to be succesful in a number of situations. But it requires a change in the way cdrecord development is managed and done, and users are treated. I'm not saying it should be done, just giving an option. Lourens [1] http://www.xvid.org/press/press-20020822-en.html [2] http://developers.slashdot.org/article.pl?sid=03/03/20/1215243&mode=thread&tid=104 [3] http://gatos.sf.net [4] http://www.teammurder.com/archives/000205.html -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux cdrecord problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri 28 February 2003 23:13, Wai Lui Fung wrote: > Hey, > > I have RedHat with kernel 2.3. I just installed a plextor CDRW > (shown below). But whenever I try to burn CDs with the command > "cdrecord file.iso" the following error shows up. It perplexes me > how if I type "cdrecord -eject" it does eject the CD. > > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg > > > Then after I get this message if I type "cdrecord -scanbus" it > won't see my cdrw anymore. System has to be rebooted for it to > see it again. Any suggestions? Upgrade to a stable kernel. Using a heavily outdated development kernel isn't going to help much anywhere. Likewise, use the latest cdrecord, not a historic artefact (version 1.9?). If the problem persists, read http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html to find out how to report problems in a way that allows Mr. Schilling to help you. Good luck, Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+X+oavmNyqZHWDvURAiNcAJ42rAxQWvX/mSmXwjTkVBN7NpUR8wCfcG39 xbJ2GEK1JoG0yLkkcR+JX+g= =V32A -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems creating CDs
On Fri 7 February 2003 04:08, Maxx Excaliber wrote: > I have a Yamaha CRW4416S, with the latest firmware (1.0j) and I > have been unable to make CDs on this computer since I upgraded > the kernel back when I was running RedHat 7.1. I stopped using > the updated kernel because of these problems. I hoped that RH 8.0 > would solve these problems, but it hasn't. I'm hoping you can > give me some suggestions. > > My CD Blanks are Memorex 700MB / 80 Minute CD-R discs. I have the > output of the CDRECORD window in XCDRoast available if you'd > like. See http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html for how to report problems. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrdao fails with plextor dae
On Sun 2 February 2003 19:04, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >Isn't that CD supposed to be copy protected? I think I heard=20 > >something about that. Anyway, I did a little search, and there > > are=20 > > There is nothing like a copy protected audio CD. The Audio CD > standard does not include anything that would allow to implement > something like a copy protection. There are of course > unfortunately a lot of usage/buy protected media that cannot even > be called a CD because they violate the CD standards. Is that so? I read something about that recently: On Sun 2 February 2003 09:22, Lourens Veen wrote: > cable. At any rate, don't give up yet (and if you can't get it to > work, return the CD as defective if there wasn't a big fat > sticker on it saying that it's not a CDDA, copyprotected and > won't play in a computer). So it seems that indeed these "copyprotected" CDs are not CDDAs at all as you say. Interesting. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrdao fails with plextor dae
On Sun 2 February 2003 03:25, Rob van Nieuwkerk wrote:
> Hi Jörg,
>
> Jörg wrote:
> > cdda2wav is the best currently known DAE tool.
> > People report even better quality than with EAC.
> >
> > In contrary to cdrdao, cdda2wav handles nearly 100% of even all
> > play protected disks. Just use cdda2wav -paranoia to overcome
> > the intentional bad audio quality on these play protected
> > disks. For the rest of the play protedted disks,
>
> I'm a happy cdrtools user: never had any problems with it.
> Till today .. :-)
>
> I bought a new CD yesterday ("Lost Tracks" by Dutch singer
> Anouk). cdda2wav (I tried both cdrtools-1.10 & cdrtools-2.01a02)
> was not able to extract track nr 15 completely (the extraction
> just stalls halveway) and there are audible clicks and missing or
> duplicated small pieces in the other tracks.
Isn't that CD supposed to be copy protected? I think I heard
something about that. Anyway, I did a little search, and there are
MP3's of that album, including track 15. I didn't download and
listen (that would be illegal after all) so I don't know about the
audio quality, maybe they were ripped through an analog cable. At
any rate, don't give up yet (and if you can't get it to work,
return the CD as defective if there wasn't a big fat sticker on it
saying that it's not a CDDA, copyprotected and won't play in a
computer).
FWIW,
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Condition to burn DVD in speed 2?
On Mon 13 January 2003 17:52, Joerg Schilling wrote:
> From: Matthias Riese <[EMAIL PROTECTED]>
>
> >> >Disesteeming the work of other people does not prove anything
> >> > you claim. And the interest of lost of people in the
> >> > project proves the contrary wrt to the need for the project.
It proves that the people who do DVD burning at this moment (seems
to be large organisations with backup needs mainly) don't care
whether their software is free (as in speech). Once DVD writers get
to be more common to home users and FOSS hackers things might
change.
> >> If anybody is disesteeming the work of other people, it is Mr.
> >> Rosenkranzer. He did not write a single line of code for
> >> "dvdrecord" but introduced his copyright notice!
> >>
> >> Mr. Rosenkranzer is a person who falsely takes all the
> >> credit..
> >
> >$ cd dvdrtools-0.1.3
> >$ find -type f|xargs grep -il Rosenkr
> >./video/dvdgen
> >./AUTHORS
> >./ChangeLog
> >./dvdrtools.spec
>
> It seems that you are not clever enough to check files in a
> reasonable way :-(
Ad hominem. Very bad form and not very civilised either. Plus I'd
say checking for copyright statements in the name of Rosenbranzer
using that command is very reasonable, so that your statement is
not only unnecessary name-calling, but also false.
> From cdrecord.c:
>
> if ((flags & F_MSINFO) == 0 || lverbose || flags &
> F_VERSION) { printf("dvdrtools v0.1.3\n"
>"Portions (c) 2002-2003 Ark Linux
> <[EMAIL PROTECTED]>\n" "Based on:\n");
> }
I opened cdrecord.c and the first thing I saw was your name, three
times actually:
/* @(#)cdrecord.c 1.151 01/11/27 Copyright 1995-2001 J.
Schilling */
#ifndef lint
static char sccsid[] =
"@(#)cdrecord.c 1.151 01/11/27 Copyright 1995-2001 J.
Schilling";
#endif
/*
* Record data on a CD/CVD-Recorder
*
* Copyright (c) 1995-2002 J. Schilling
*/
> "Ark Linux" is not a natural person and as I am the Copyright
> holder, I must have transfered legal rights to "Ark Linux" to
> make this statement legal.
You are the copyright holder of the original work. Apparently, Ark
Linux added certain portions, thereby creating a derivative work,
and there is no reason why those portions they wrote should be
copyrighted by you. Note that Ark Linux does not claim copyrights
on the parts of the code that are written by you (in fact, it's not
quite clear _which_ portions are copyrighted by whom. Perhaps that
should be cleared up. But claiming someone stole your copyrights
based on this statement is nonsense).
> In addition, there is a falsely claimed Copyright for a mail
> address from Mr. Rosenkranzer. Believe me: he did not write a
> single line of code for dvdrecord - he only took code from other
> people.
Why should I believe you? And who says that those people did not
transfer the copyrights to him? And what about the copyright laws
for collections of work created by others?
> >On the other hand the project's homepage clearly states:
> >
> >"dvdrtools is a fork of cdrtools, with the primary goal of
> > supporting writable DVD drives."
> >
> >thereby giving you credit for developing the code baseline of
> >dvdrtools. Whereas you fight even the project just to be
> > mentioned in this mailing list.
> >
> >dvdrtool's project homepage links to all similiar projects.
> >Yours not why?
>
> Your sentence above obviously is a self contradiction:
It's not self-contradiction. It may be wrong, that depends on how
narrowly you define similar. If you take similar as in "open source
DVD writing software" then it does link to all similar projects. If
you take similar as "DVD writing software" then many things are
excluded from the list.
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord 2.0 & kernel 2.5.x
On Sat 11 January 2003 21:28, Casey Scott wrote: > I am using kernel 2.5.56 currently, and cdrecord is behaving > strangely. For example, when blanking a disk, the system because > totally unresponsive until the blanking is complete. Also, when > actually burning a disk, the system completely freezes during the > "Fixating" segment of the burn. I have never had trouble with > cdrecord with previous kernels, and I am looking for suggestions > for this. I realize that I could go back to an earlier kernel, > but I need this kernel for the scsi support options that it > provides. The system is all scsi, and the writer is a Yamaha > 4416S. There is no indication of what is taking the system over > from top, or any system logs. SCSI debug info didn't show > anything useful either. Well, if it works on older kernels I'd say it's a kernel problem, not a cdrecord problem. Maybe this question should be on linux-kernel or with the Linux SCSI maintainers instead. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Condition to burn DVD in speed 2?
On Thu 9 January 2003 22:21, Matthias Riese wrote: > Joerg Schilling <[EMAIL PROTECTED]> writes: > > >From: Matthias Riese <[EMAIL PROTECTED]> > > > > > >> >> I would never recommend unmaintained software that is > > >> >> known not to work correctly for many drives - see the > > >> >> mailing lists for this "project". > > >> > > > >> >Wrong. > > >> > > >> -> The "project" you mention is definitely unmaintained The > > >> only changes are related to useless changes in the > > >> nonstandard make system used by this project. > > > > > >Wrong. > > > > > >1. The changes are not useless. > > >2. You contradict yourself wrt to the state of maintenance. > > > > Wrong: > > > > The only thing Mr. Rosenkranzer did was to replace a make > > system that is known to work by a broken make system and later > > start trying to fix his broken make system. This cannot be > > called maintenance of the project (as it was not needed at all) > > but hobbyists work... > > Wrong. > > Disesteeming the work of other people does not prove anything you > claim. And the interest of lost of people in the project proves > the contrary wrt to the need for the project. Will you people stop wasting time and bandwidth? You're never going to convince one another anyway. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Audio-Cds, restricted
On Sun 1 December 2002 23:42, Hanspeter Roth wrote: > Hello, > > what is the difference of an `audio-CD' compared to a `data-CD'? > Does it have something to do with the `restricted' attribute? Not directly. The difference between a data and an audio CD is the way the bits are laid out on the disk. There are a whole lot of standards that specify exactly how the data should be written to the disk for it to be a legal audio CD, or data CD, or CD-I, or Video-CD, etc. These standards cater to different needs, for example the Red Book audio standard specifies that there should be extra data on the disk to recover from errors caused by scratches for example, and also exactly how this should be encoded. Video CD's need more capacity and it's not that bad if there's a couple of pixels that are bad now and then, so they don't have this error-detection and correction code. For data CDs it's absolutely imperative that every single bit is correct, so they have much more error correction code. Anyway, these standards are the coloured books. You may have heard of the Red Book standard, which describes the audio CD format; all the other formats have differently coloured books. The CDDA (Compact Disk Digital Audio) format was created by Philips, and they own the trademark on CDDA. Audio CDs that do not adhere to the Red Book standard are not Audio CDs at all, and may not carry the CDDA logo. The new "copy-protected" CDs the big record companies have been selling lately have defective error-correction codes or are formatted so that they seem to be a multi-session disk (amongs other things, different technogies exist). Normal CD players only understand standard Red Book CDs, and don't know anything about the other formats, so they just ignore the part that says "I'm a multi-session CD" and play it. CD-ROM drives are usually smarter, see the multi-session layout, and then get confused because the disk is not layed out as a multi-session disk. So you can't rip the CD (unless ofcourse you use a felt-tip pen to black out the part of the CD that causes the confusion, in which case it will work just fine again). The bad thing is that if you buy such a CD, you can't rip it and encode it as MP3s to use with your portable MP3 player, and you can't play it in your computer. Or, if the error correction codes have been tampered with, the disk will be of lower quality because real errors can no longer be corrected anymore. At any rate, because these CDs don't follow the standard, they are not CDDAs at all, and that's why Jörg referred to them as "coasters in CD shape". The Red Book CD format does not have any "restricted" attributes or anything, there is no kind of DRM built-in whatsoever, which is part of the reason why the format became so popular. I read a couple of reviews of the new download-DRMmed-music services the record companies are starting, and they really seem to be more trouble than they're worth, with you needing a Windows PC and special software and then it still only works now and then. I'll stick to buying (non-restricted) CDs for now, preferably from small labels... HTH, Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: error writing on cd with cdrecord 1.9
On Tue 19 November 2002 23:02, Robert Timm wrote: > hallo. i have a problem: > > when ever i try to write on a cd i get the following output: > > bash-2.05a# cdrecord dev=0,0,0 -data > /mnt/data/media/mp3/Incubus/* > > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Upgrade to the latest 1.11 alpha first, all other versions are unsupported. If the problem persists, write again, and be sure to follow the guidelines for support requests at http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with readcd and Aopen CDROM drive
On Friday 01 Nov 2002 10:42 pm, Tom Crane wrote: > > I followed up Jorg's suggestion of firmware updates for the Aopen > but there appear to be none for that drive. Any suggestions for a > workaround to force readcd to read only the true data/2048 > sector-size? Failing that, perhaps you could create a small program based on libedc (be sure to take the libedc code from cdrdao, as the code distributed with cdrtools is _not_ GPL and may only be used as a part of cdrecord) to manually get the data out and check the checksums? Ofcourse, if you're not interested in checking the checksums it may be even easier, all you need is a simple program that you can pipe the readcd output into and it will select the proper bytes. Put the whole thing in a shell script and there's your workaround. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Burnfree option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 29 Oct 2002 9:18 am, Isidro Cachadiña Gutiérrez wrote: > Hi all: > > This is a wish. Why the burnfree option is disabled by default?. > Why is not enabled by default? > > Bye. Because it increases the chance of bad CDs. No, I don't know how or why either, but that's what Jörg says, and there's no arguing against that. Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9vky6vmNyqZHWDvURAhSAAJ4oE83KQt73Y+JLZ/rr3306cYAVJACfanWY 7ck28en1vOg98P4sTQQw3GI= =rMaZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: P & Q in Raw Mode
On Monday 28 Oct 2002 3:59 pm, Basile, Greg wrote: > Hello, > > I have a large wav file that I want to break into several tracks > without 2 secs of a silence between tracks ( i.e. continuous > audio). I know how to do the job with goldenhawk. Can anyone > point me to where this is documented in the cdrecord? It would > require being able to define the write data and PQ independently. > (This is done in the .inf in Goldenhawk) I have been unable to > find it, but then again my wife claims I can't find anything. Why don't you just split up the WAV file with sox or something and then burn the tracks in dao (sao) mode? That would seem to be the easiest way to me. Alternatively, have you looked at cdrdao? That seems to be more geared towards this type of task than cdrecord. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with BTC BCE1610IM burner under linux.
On Monday 28 Oct 2002 1:21 pm, satan wrote: > I have problems with BTC BCE1610IM burner under linux. > > My software version is: Cdrecord 1.10 (i686-pc-linux-gnu) > Copyright (C) 1995-2001 J?rg Schillin on Linux 2.4.18. > > I have try with cdrecord 1.11 but I have a same result. What is the problem? Could you post the command line you use and the output of cdrecord (latest version, 1.11a39, 1.10 is old and deprecated) that that gives? Also, see http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html (scroll all the way down) for instructions on how to submit bug reports/support requests. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible way to get better bug reports/support requests for CDRecord
On Monday 28 Oct 2002 7:07 am, [EMAIL PROTECTED] wrote: > Lourens Veen <[EMAIL PROTECTED]> writes: > > > Well, this kind of crash handler is just a signal handler - some > code which is executed when the operating system tells a process > (a program being executed) that it has done something way wrong. > It replaces the default behaviour of dumping the core. So the > process has to do something what the operating system can > recognize as being wrong. I know, but that's not what I meant. CDRecord already has signal handlers, although not for SIGSEGV (IMHO it would be good defensive programming if it had one, if only to say "CDRecord crashed, check your hardware because the software is perfect"). Anyway, what I mean is that if something unexpected occurs, which may be a SIGSEGV (no I never had one with CDRecord either) or a SCSI error, or whatever else that's unexpected, the user should get some information on how to deal with it. Joe User isn't going to search the mail archives, and isn't going to give a decent bug report, unless there's a big fat "do _this_ and exactly _this_ or we won't help you" message to go with the error message. And if he doesn't search the mail archives or send a decent bug report, but instead send a mail that says "it doesn't work" then Jörg is going to give another rant about how he spends so much time developing CDRecord and that everybody is stupid, which we're trying to avoid, right? > By now I never saw cdrecord crashing in this way. cdrecord > certainly outputs SCSI error messages if something goes wrong, > but these are errors detected by cdrecord itself. The operating > system stays completely cool about them. Again, it's not a technical point I'm trying to make, I'm looking at it from a user-interface point of view. > So what's needed is some translation of plain SCSI error messages > to instructions what could be done to fix it. However this is a > feature already wished for a dozen times, which requires > knowledge about: I know, I took part in that discussion. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Possible way to get better bug reports/support requests for CDRecord
Yesterday, MPlayer crashed on me. In itself that's not so interesting, but what was interesting was their crash handler. A message popped up explaining that MPlayer had crashed, and that that was a bug. Then it proceeded to explain how to get basic debugging info, with a reference to a web page explaining how to submit bug reports. It also told me not to expect any reply unless I followed these rules to the letter. I'm wondering, would this be a useful feature for CDRecord? It could print such a message when an error occurs, perhaps with a command line switch to turn it off for expert users who know that what they're doing might go wrong, or for use in shell scripts that only want a return value. I know there's a feature freeze now, but perhaps this could be included before the next release still? I bet a lot of people will upgrade and have problems, this may well be a good way to manage the chaos a bit better. Comments? Lourens PS: Oh, I'm willing to write the text if you want me to. I'm not a native English speaker but my written English is as good as that. -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux graphical frontend for cdrecord?
On Thursday 24 October 2002 16:59, Marcos Lorenzo wrote: > Is there any graphical frontend for cdrecord? I mean apart from > xcdroast or gcdmaster. Just something like Nero for linux because > I want to turn on my PC only on Linux xD > > Which one(s) do you like/use and why? I like K3B a lot. XCDRoast makes it only harder to burn CDs IMHO. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fixiating problems
On Monday 21 October 2002 16:50, Markus Wagner wrote: > This was the first time I really needed help with cdrecord, and I > am sure I described my problem detailed enough, so that other > people can understand it. Especially the second question should > be of great interest, because it reveals some kind of > illogicalness. Well, as Jörg pointed out, he's very busy, and he gets many emails. He has chosen to deal with this by way of bureaucracy, which is uncommon in the Free software world, but then cdrtools isn't part of that world anyway. At any rate, it works just like any other bureaucracy, you fill out the form (http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html) and hope something happens. Of not, tough luck. Other, or differently formulated questions, like "Has anything changed with the CD fixating code recently?" will simply be ignored. Jörg takes care of support, so he makes the rules. I don't like them any more than you do, but there's nothing we can do about it. Well, we could try and become developers ofcourse, but given that there's no documentation of the code, hardly any comments, and no support, trying to understand it would be more effort than I care to spend on it. Anyway, perhaps you could get yourself an ATI All-In-Wonder card and use the Gatos drivers with it. Vladimir Dergachev is by far the nicest Free software developer I've seen so far... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cdrdao-1.1.7 released
On Sunday 06 October 2002 21:53, Andreas Mueller wrote: > Hi, > > cdrdao-1.1.7 is available from: > > http://sf.net/projects/cdrdao > > > This release is mainly triggered by the libedc_ecc license issue > that recently came up. The affected code has been replaced by a > GPL compliant implementation. And there was much rejoicing! Great work, it's nice to see that this could be resolved so quickly. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Tuesday 24 September 2002 13:25, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >> [...] explanation > > > >I've just re-read the LICENSE file in the libedc directory of=20 > >cdrtools, and it doesn't mention distribution at all, only > > use.=20 Does this mean that I do have "Nutzungsrecht" for > > libedc, but no=20 "Verwertungsrechte"? Am I allowed to > > redistributed cdrtools with=20 libedc included or not? > > Partly correct: > > You have "Nutzungsrecht" but not the "Verwertungsrechte" but you > are allowed to _redistribute_ the unmodified cdrecord including > the libedc. You have the right to make private changes in > cdrecord. Okay, but does the LICENSE file of libedc_ecc reflect this? It doesn't mention distribution at all. Or does having the right to use imply having the right to redistribute? Or have I just missed something in the file? > This makes cdrecord free software This doesn't match the FSF definition of free software (freedom 3, the freedom to distribute modfied copies, isn't met), but I'll accept it as your definition of free software. After all, what's in a name? (except a lot of possible confusion ofcourse). > If you like to _distribute_ code that uses libedc (e.g. a > modified version of cdrecord or own code) you have two > opportunities: > > - remove libedc for the distribution and make sure the rest of > the code still runs e.g. by using an #ifdef HAVE_LIBEDC. > I did this for nearly 2 years in the past with cdrecord > although I have the permission to distribute libedc with > cdrecord. > > - Ask Heiko for a permission and distribute the code with > a compatible license (in case this is your own code) > or with the original cdrecord license (in case of a modified > cdrecord). > > Note: even the GPL does not transfer all "Verwertungsrechte" to > any user so only the author is allowed do decide about the > license to use. This is why some people believe that you are not > allowed to change the text in the COPYING file distributed with > GPLd projects. Which ofcourse you are, except that then it wouldn't be the license of that project anymore, right? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Monday 23 September 2002 12:03, Joerg Schilling wrote: > Preface: I am sorry, but it seems that you don't know much about > Copyright issues :-( Many of your statements are completely > wrong and none of your mails from the last night has been > helpful. > > For a decent discussion on this topic it is important that we use > correct verbalizations. Unfortunately, the English language is > not very precise here > > Let me first quote a dictionary: > > German English > = === > UrheberrechtCopyright > Verwertungsrechte Copyright > Nutzungsrecht Rights of use > > As you see, the English language does not make a distinction > between Urheberrecht & Verwertungsrecht. As this is _very_ > important for a correct discussion, I will use the following > translation: > > German English > = === > UrheberrechtAuthorship rights > Verwertungsrechte Utilization rights > Nutzungsrecht Rights of use > > [...] explanation I've just re-read the LICENSE file in the libedc directory of cdrtools, and it doesn't mention distribution at all, only use. Does this mean that I do have "Nutzungsrecht" for libedc, but no "Verwertungsrechte"? Am I allowed to redistributed cdrtools with libedc included or not? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Monday 23 September 2002 12:03, Joerg Schilling wrote: > Preface: I am sorry, but it seems that you don't know much about > Copyright issues :-( Many of your statements are completely > wrong and none of your mails from the last night has been > helpful. > > For a decent discussion on this topic it is important that we use > correct verbalizations. Unfortunately, the English language is > not very precise here > [...explanation of _German_ copyright system...] I believe we need to make a clear distinction between the German copyright laws and the American copyright laws. Unfortunately, there seem to be some major differences here, and given what you wrote I'm not even sure if the GPL makes sense at all in the context of German (and probably other European) copyright law. > From: "Mike A. Harris" <[EMAIL PROTECTED]> > > [...] > >That's a good thing or a bad thing depending on your viewpoint. > >Some people view it as a bad point, because even if you write a > >program and GPL it, you cannot legally change the license on > > your own code, or multiple license it, unless all code > > contributors have agreed to the relicense/multi-license, or > > have assigned their copyright completely to you. > > Wrong! > > If there is an author who owns the authorship rights for the work > (like it is true for me with e.g. cdrecord), this author is the > only person who may decide on authorship right issues. > > As libscg is a major contribution from me to the cdrdao project, > I would be able to put a veto on this. But as I already did allow > cdrecord to be linked with libedc it is obvious that I don't use > my veto right here. That's what I mean. The whole idea of the GPL is that if you put your software under GPL, then everyone will be able to use it as long as the terms of the GPL are satisfied. If the original author can still veto anything that happens with the code it can't be free software as in the FSF definition. Perhaps the FSF should be notified and/or asked about this? Seems to me like it might be a major problem. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Sunday 22 September 2002 22:30, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >Erm, the GPL puts your program under what's known as a > > "strong=20 copyleft". This forbids linking with > > non-GPL-compatible code. I=20 quote (GPL (http://www.gnu.org/ , > > clause 2, sentence 5): > > > >"But when you distribute the same sections as part of a whole > > which=20 is a work based on the Program, the distribution of > > the whole must=20 be on the terms of this License, whose > > permissions for other=20 licensees extend to the entire whole, > > and thus to each and every=20 part regardless of who wrote it." > > > >Given that cdrdao without libedc_ecc is under the GPL, cdrdao > > with=20 libedc_ecc linked in is then a derived work, which must > > be=20 published under the GPL entirely. Since the libedc_ecc > > license=20 forbids this, it follows that our premise is > > incorrect. So we must=20 conclude that the parts of cdrdao > > without libedc_ecc cannot be=20 published under the GPL. > > Definitely not correct! > > The Author may put his SW under GPL. > > However, as libedc is not GPLd the "viral" part of the GPL does > not apply to libedc - no matter what's written in the GPL. The > problem is that Andreas did not make this clear before. As a > result of this "missing hint" other people did believe that > libedc is GPLd. Having thought about it some more, I think we're both correct. cdrdao cannot be published under the GPL, because then linking it to libedc would violate the license. It would however be possible to put a license on it that has everything the GPL has with the special exception that the author of cdrdao allows you to link it with libedc, even if the libedc license does not give you the rights specified in the GPL. Ofcourse then cdrdao would no longer be published under the GPL, but it (that is cdrdao without libedc) would still be under a GPL-compatible license. In the end it's a matter of wording. You say that the "viral" part of the GPL does not apply to libedc because it has a different license. I say that you can't link cdrdao to libedc as long as it's published under the GPL and libedc is not. We mean the same. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Sunday 22 September 2002 23:15, Andreas Mueller wrote: > On Sun, 2002-09-22 at 22:47, Lourens Veen wrote: > > On Sunday 22 September 2002 22:30, Joerg Schilling wrote: > > > From: Lourens Veen <[EMAIL PROTECTED]> > > > > [...] > > > > > However, as libedc is not GPLd the "viral" part of the GPL > > > does not apply to libedc - no matter what's written in the > > > GPL. The problem is that Andreas did not make this clear > > > before. As a result of this "missing hint" other people did > > > believe that libedc is GPLd. > > > > Yes, the LICENSE file was removed from that directory. That's a > > mistake. And as you say the viral part of the GPL does not > > apply to libedc_ecc because it's not under the GPL. It does, > > however, apply to cdrdao. > > The libedc_ecc source code did not contain such a LICENSE file > (in fact no license file at all) at the time I fetched it. I was > in contact with Heiko at that time and he also did not mention > any restrictions. Of course this does not excuse my mistake - I > should have explicitly asked for placing it under GPL. My apologies. I assumed it was the same code as in the libedc directory of cdrtools, which does have a LICENSE file. I assumed it had been cleaned up at some point by someone thinking it was just another copy of the GPL and that having one in the package would be enough. I didn't mean to imply you or anybody else removed it on purpose. > Regarding the license terms I think we should wait for Mike A. > Harris's answer to my question as he is an expert on this topic. > He clearly stated that GPLd software cannot have non GPLd parts. > The only open question is if they way cdrdao handles the > libedc_ecc code can count as linking in non GPLd libraries. > Depending on the answer I'll have to react... Yeah. I'm not an expert either. We'll see. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Sunday 22 September 2002 22:30, Joerg Schilling wrote: > From: Lourens Veen <[EMAIL PROTECTED]> > > >Erm, the GPL puts your program under what's known as a > > "strong=20 copyleft". This forbids linking with > > non-GPL-compatible code. I=20 quote (GPL (http://www.gnu.org/ , > > clause 2, sentence 5): > > > >"But when you distribute the same sections as part of a whole > > which=20 is a work based on the Program, the distribution of > > the whole must=20 be on the terms of this License, whose > > permissions for other=20 licensees extend to the entire whole, > > and thus to each and every=20 part regardless of who wrote it." > > > >Given that cdrdao without libedc_ecc is under the GPL, cdrdao > > with=20 libedc_ecc linked in is then a derived work, which must > > be=20 published under the GPL entirely. Since the libedc_ecc > > license=20 forbids this, it follows that our premise is > > incorrect. So we must=20 conclude that the parts of cdrdao > > without libedc_ecc cannot be=20 published under the GPL. > > Definitely not correct! > > The Author may put his SW under GPL. Ofcourse. And he, being the author, can also link it with non-free software. But nobody else can. I can download cdrdao right now, but bulding it would be illegal for me because I would be linking cdrdao with libedc_ecc, which is forbidden by the GPL, because libedc_ecc is not GPLled. I would violate the cdrdao license, but not the libedc_ecc one, because it explicitly allows me to link with cdrdao. > However, as libedc is not GPLd the "viral" part of the GPL does > not apply to libedc - no matter what's written in the GPL. The > problem is that Andreas did not make this clear before. As a > result of this "missing hint" other people did believe that > libedc is GPLd. Yes, the LICENSE file was removed from that directory. That's a mistake. And as you say the viral part of the GPL does not apply to libedc_ecc because it's not under the GPL. It does, however, apply to cdrdao. > Just note: you may put whatever you like into a contract. If > (even parts of) the content of the contract violates "good > morals", the whole contract is void except you put a "healing > clause" into the contract. AFAIK, the GPL does not carry such a > "healing clause". Indeed it does not. > Andreas also did not put this "healing clause" into the contract > so cdrdao did effectively came completely without a license. I disagree. You cannot legally build cdrdao if you link it with libedc_ecc, because that would violate the GPL, but if you want to distribute or modify or create a derived product of the cdrdao code you still have to do it under the GPL. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Sunday 22 September 2002 22:06, Joerg Schilling wrote: > From: Andreas Mueller <[EMAIL PROTECTED]> > > >> You can't GPL part of your program however, and have GPL > >> incompatible code linked into it. > > This statement is not correct Erm, the GPL puts your program under what's known as a "strong copyleft". This forbids linking with non-GPL-compatible code. I quote (GPL (http://www.gnu.org/ , clause 2, sentence 5): "But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." Given that cdrdao without libedc_ecc is under the GPL, cdrdao with libedc_ecc linked in is then a derived work, which must be published under the GPL entirely. Since the libedc_ecc license forbids this, it follows that our premise is incorrect. So we must conclude that the parts of cdrdao without libedc_ecc cannot be published under the GPL. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Sunday 22 September 2002 21:46, Andreas Mueller wrote: > On Sun, 2002-09-22 at 19:01, Mike A. Harris wrote: > > [...] > > > > >Therefore, I will restrict the GPL license for cdrdao so that > > > section 2 of the GPL will not apply to the libedc_ecc code. I > > > will shortly prepare a new cdrdao release with the new > > > license terms and remove all older releases from sf.net. > > > > The GPL license explicitly states that you may not make further > > restrictions on the license. In other words, it is not > > possible to say "My program is GPLv2, plus you cant do this or > > that". It is prohibited. > > > > If the GPL license conflicts with the license of another > > component in the software, you must either remove the > > GPL conflicting parts, or alternatively relicense your software > > with a different license than the GPL. > > > > You can't GPL part of your program however, and have GPL > > incompatible code linked into it. > > I tend to believe this but can you please let me know where this > is stated in the GPLv2 license text (I mean the part about making > restrictions to the license). I'm assuming here that you are > quiet familiar with this topic so that it is easy for you to find > it. I already scanned the license text but could not find > something matching. > > The libedc_ecc code is held in a library which gets statically > linked to the cdrdao executable. The library is not available as > a separate package so that the cdrdao sources ship with the > libedc_ecc sources. The libedc_ecc sources are strictly separated > from the remaining cdrdao sources. Does this count as linking GPL > incompatible code in? Well, as you say it gets statically linked in. So yes, that counts as linking the code in. Since you can't take out libedc_ecc and use it in another program, its license is clearly not GPL-compatible. This means that if cdrdao is published under the GPL, linking them is against the cdrdao license. However, if you publish something under a modified GPL, ie one without the "viral" component, then as far as I can see it would be possible. This would however change the license terms for the rest of cdrdao as well (it would effectively turn into an LGPL license I think). Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License of cdrdao will be changed
On Sunday 22 September 2002 19:01, Mike A. Harris wrote:
> On 22 Sep 2002, Andreas Mueller wrote:
> >Date: 22 Sep 2002 13:15:57 +0200
>
> From: Andreas Mueller <[EMAIL PROTECTED]>
>
> >To: cdwrite list <[EMAIL PROTECTED]>
> >Content-Type: text/plain
> >Subject: License of cdrdao will be changed
> >
> >Hi all,
> >
> > [...cdrdao will be licensed differently...]
>
> [...]
>
> You can't GPL part of your program however, and have GPL
> incompatible code linked into it.
I've looked at the library and the readme for it, and it seems to me
that it's only a small piece of code. The only problem with writing
a GPLled replacement for it is availability of standards. I've
checked the web, but the coloured books are not available online. I
don't feel like paying $200 or so for an ISO standard document
either. However, there's another option. We could reverse-engineer
Mr. Eissfeldts library, and use the information from that to write
a drop-in replacement. Since it's open source, it's not that hard,
but it does require a group of people who turn the code into a
description, and a nonintersecting group of people who turn that
description ("specification") back into a library, which can then
be published under the GPL. And ofcourse the people in the second
group should not have seen Mr. Eissfeldts code before to make it a
real cleanroom implementation.
But it would solve the problem and allow cdrdao to be free software
again.
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord-ProDVD (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 13 June 2002 12:09, Joerg Schilling wrote: > > Please be more polite to other people! > > Why did you choose to introduce these harsh words? I never used > them! > > > The main problem with most (maybe all???) Linux developers is > that they usually lack background knowledge. > > > Le't make me an example: The problem with non-stable interfaces > seems to be caused by the fact that the authors simply don't know > what an interface is. So they don't know what they should treat > carefully and try to keep stable. > > > If they wouldn't read Linux sources only but look to the left and > to the right (by e.g. reading Solaris and FreeBSD sources) they > would discover that there is a lot of much better coded stuff > out > > Jörg I'm wondering, why do you support Linux at all? If it's such a badly coded and proprietary system, then why don't you just drop support for it? That should save a lot of work since you can close most bugreports with a simple "sorry, Linux is unsupported", and in the extra time that that gives you you could improve support on the OSes you do like (ie Solaris and BSD). Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9CHLGvmNyqZHWDvURAmeLAKCK+15rjiNryxJQuSQGF4tmPbWzswCgnFSc 49+wkglZRMNOI/zuhXzNd0E= =DrMj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord-ProDVD (fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 13 June 2002 01:20, Joerg Schilling wrote: > From [EMAIL PROTECTED] Wed Jun 12 22:27:50 2002 > > >Maybe there's a communication gap because english isn't your > > primary language. Your arguments are not making any sense to > > me... > > If you don't understand my english, you should ask, instead it > seems that you make unrelated claims.. > > Jörg Okay, I've been reading this entire discussion for the past couple of days, and I am wondering why there isn't a fork (or even a completely alternative implementation) of cdrtools yet. Clearly, there are two sides in this discussion, and, stepping aside from who's right on what for a moment (no I'm not getting into this discussion, thank you), if the two sides don't even speak the same language, let alone agree on at least some basic technical and ideological aspects, then I don't see how there could be any cooperation. So, why not stop wasting time trying to convince each other, and instead simply write two different programs/libraries/whatever? This discussion is not going anywhere. More choice is good for everyone, so a second implementation won't hurt, while arguing without any outlook on an end to the discussion is good for nobody and simply a waste of time. Lourens - -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9B9sAvmNyqZHWDvURAmhcAJwLloeqi/mHZ2z2NcMJqTEAUD2NIACfWWrh BpQ0IBRI4Naof5vOdaogS30= =2iKk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error Messages
On Monday 10 June 2002 21:37, Art wrote: > Joerg Schilling wrote: > > >From: Art <[EMAIL PROTECTED]> > > > > > >The system will produce copies using CloneCD under Win95, > > >so we know that there is no problem with the hardware. > > > > > > > > >Then we get a bunch of error messages: > > > > > > cdrecord: Input/output error. read disk info: scsi sendcmd: > > > no error CDB: 51 00 00 00 00 00 00 00 04 00 > > > status: 0x2 (CHECK CONDITION) > > > Sense Bytes: 70 00 03 00 00 00 00 06 00 00 00 00 02 00 > > > Sense Key: 0x3 Medium Error, Segment 0 > > > Sense Code: 0x02 Qual 0x00 (no seek complete) Fru 0x0 > > > Sense flags: Blk 0 (not valid) > > > cmd finished after 137.204s timeout 240s > > > cdrecord: Cannot get disk type. > > > > > >Can anyone explain what is going on here? Is this possibly > > >a bug in cdrecord? > > > > If I got a dollar for all people who do not even read the error > > messages and tell that cdrecord is broken although it is > > obvious that the drive is broken, I would be rich > > Joerg, > > Thank you for your reply. > > Interesting, broken under Linux/cdrecord but OK with > CloneCD/Win95. I guess it's possible. > > Art It is, I've got such a drive too. It's an AOpen 20x10x40 drive, which used to work with cdrecord (albeit not at higher speeds than 4x) but now gives the same "no error" messages you're getting. I put it in a Windows box where it worked fine with Nero. Perhaps these drives have automatic OS detection and break when they detect Linux? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
