You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(5) |
Aug
(55) |
Sep
(16) |
Oct
(28) |
Nov
(35) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(12) |
Feb
(15) |
Mar
(14) |
Apr
(27) |
May
(35) |
Jun
(42) |
Jul
(22) |
Aug
(21) |
Sep
(62) |
Oct
(52) |
Nov
(49) |
Dec
(14) |
2003 |
Jan
(11) |
Feb
(41) |
Mar
(16) |
Apr
(18) |
May
(9) |
Jun
(8) |
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
(6) |
Dec
(5) |
2004 |
Jan
(13) |
Feb
(32) |
Mar
(10) |
Apr
(5) |
May
|
Jun
(6) |
Jul
(12) |
Aug
|
Sep
(2) |
Oct
|
Nov
(6) |
Dec
|
2005 |
Jan
(1) |
Feb
(7) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(4) |
2006 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
(9) |
Jun
(4) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Nikolai W. <no...@bi...> - 2007-09-12 11:53:16
|
Hi! The attached patch (can't inline, as Gmail will break formatting) abstracts the config file lookup, allowing for a CDRDAO_HOME environment variable to be added. This makes it possible to specify some other location than $HOME for the configuration file. The reason for this feature is to allow users, such as me, to put their configuration file some other place than .cdrdao. Also, seeing as how cdrdao reads $HOME/.cdrdao-drivers, making it possible to place these two files in a subdirectory such as CDRDAO_HOME=$HOME/cdrdao makes sense. If CDRDAO_HOME is set, cdrdao will now look there instead for a file with the same name as the old configuration files, but skipping the leading dot. I've added documentation to the manual page. I noticed also that $HOME/.cdrdao-drivers is not mentioned in the manual page. Is that intentional? Thank you for an excellent piece of software! nikolai |
From: Thomas P. <tp...@gm...> - 2007-08-31 21:54:13
|
Denis Leroy (den...@ya...) wrote: > In english please. Sorry for that. I forwarded Scott's mail to Joerg Schilling who is the programmer of the cdrtools which are also affected by the GPL violations. Since the "Reply-To:" header was set this mail shouldn't have been sent to the cdrdao mailing list. -- mfg Thomas |
From: Denis L. <den...@ya...> - 2007-08-31 12:27:29
|
--- Thomas Plank <tp...@gm...> wrote: > Joerg Schilling (Joe...@fo...) wrote: > > > Thomas Plank <tp...@gm...> wrote: > > >> Hallo Jörg! > >> > >> Da auch Teile deines Programmes dabei verwendet werden, schick ich > dieses > >> Mail weiter, solltest du es nicht bereits kennen: > > > Danke für die Info! > > Bitte gerne. > > > Bist Du auf der Mailingliste? > > Ja, als cdrdao 1.2.2 herauskam, habe ich es nur mühsam auf win32 zum > Laufen gebracht, seither habe ich die Liste abonniert. > > > Ist da eine Antwort gekommen? Irgendwie scheint cdrdao ja relativ > tot zu sein. > > Ja, es gab Replies. > Sende sie dir auch. > > Es war erst das 5.e Thema in diesem Jahr, also so gut wie kein > Traffic. In english please. |
From: Thomas P. <tp...@gm...> - 2007-08-31 10:34:53
|
Joerg Schilling (Joe...@fo...) wrote: > Thomas Plank <tp...@gm...> wrote: >> Hallo Jörg! >> >> Da auch Teile deines Programmes dabei verwendet werden, schick ich dieses >> Mail weiter, solltest du es nicht bereits kennen: > Danke für die Info! Bitte gerne. > Bist Du auf der Mailingliste? Ja, als cdrdao 1.2.2 herauskam, habe ich es nur mühsam auf win32 zum Laufen gebracht, seither habe ich die Liste abonniert. > Ist da eine Antwort gekommen? Irgendwie scheint cdrdao ja relativ tot zu sein. Ja, es gab Replies. Sende sie dir auch. Es war erst das 5.e Thema in diesem Jahr, also so gut wie kein Traffic. -- mfg Thomas |
From: Denis L. <den...@ya...> - 2007-08-29 20:53:01
|
--- Scott Fritzinger <sc...@un...> wrote: > Denis and others, > > In the DVD Photo Slideshow installation, the file "BurnLib.dll" > contains > cdrdao (and Nero client libraries). If you grep for > "PQChannelEncoder", > you'll see the mention. If you hex edit it, you'll see the cdrdao > error > messages and strings around "PQChannelEncoder". > > -Scott So have you tried contacting them (and when) ? |
From: Scott F. <sc...@un...> - 2007-08-29 18:40:38
|
Denis and others, In the DVD Photo Slideshow installation, the file "BurnLib.dll" contains cdrdao (and Nero client libraries). If you grep for "PQChannelEncoder", you'll see the mention. If you hex edit it, you'll see the cdrdao error messages and strings around "PQChannelEncoder". -Scott Denis Leroy wrote: > > Yes definitely, we need to seek help from either (or both) EFF and FSF. > > --- Scott Fritzinger <sc...@un...> wrote: >> Hey there! >> >> I'm writing to say that I came across a piece of software that looks >> like it is violating the cdrdao license. It appears that they are >> trying >> to hide the fact that they are using it by wrapping your software in >> a DLL. >> >> The name of the closed-source software is DVD Photo Slideshow >> (http://www.dvd-photo-slideshow.com). The only email address I can >> find >> on their site is su...@an... . The software sells for $60 >> (!!) >> and is highly dependent on the software that it is mis-using. >> >> The software is also violating the licenses of several software >> packages >> as well. I am sending those other projects a similar email. For GPL >> packages, there is no source available. For LGPL packages, there is >> no >> license anywhere and there is no link to download the sofware. >> grep'ing >> the installation shows that there is no mention of 'gpl' anywhere. >> >> Project Component License >> --------------------------------------------------------------- >> cdrecord mkisofs GPL >> cdrdao cdrdao GPL >> dvdauthor dvdauthor, spumux GPL >> id3lib id3lib LGPL >> lame lame LGPL >> mjpeg-tools mpeg2enc, mplex GPL >> >> I may very well have missed other violations. This is pretty freaking >> >> stupid of the company. With such a large number of violations, I'm >> wondering if the FSF would jump in to represent all of the projects? |
From: Denis L. <den...@ya...> - 2007-08-29 17:41:17
|
--- Scott Fritzinger <sc...@un...> wrote: > Hey there! > > I'm writing to say that I came across a piece of software that looks > like it is violating the cdrdao license. It appears that they are > trying > to hide the fact that they are using it by wrapping your software in > a DLL. > > The name of the closed-source software is DVD Photo Slideshow > (http://www.dvd-photo-slideshow.com). The only email address I can > find > on their site is su...@an... . The software sells for $60 > (!!) > and is highly dependent on the software that it is mis-using. > > The software is also violating the licenses of several software > packages > as well. I am sending those other projects a similar email. For GPL > packages, there is no source available. For LGPL packages, there is > no > license anywhere and there is no link to download the sofware. > grep'ing > the installation shows that there is no mention of 'gpl' anywhere. > > Project Component License > --------------------------------------------------------------- > cdrecord mkisofs GPL > cdrdao cdrdao GPL > dvdauthor dvdauthor, spumux GPL > id3lib id3lib LGPL > lame lame LGPL > mjpeg-tools mpeg2enc, mplex GPL > > I may very well have missed other violations. This is pretty freaking > > stupid of the company. With such a large number of violations, I'm > wondering if the FSF would jump in to represent all of the projects? Yes definitely, we need to seek help from either (or both) EFF and FSF. |
From: Scott F. <sc...@un...> - 2007-08-29 17:25:10
|
Hey there! I'm writing to say that I came across a piece of software that looks like it is violating the cdrdao license. It appears that they are trying to hide the fact that they are using it by wrapping your software in a DLL. The name of the closed-source software is DVD Photo Slideshow (http://www.dvd-photo-slideshow.com). The only email address I can find on their site is su...@an... . The software sells for $60 (!!) and is highly dependent on the software that it is mis-using. The software is also violating the licenses of several software packages as well. I am sending those other projects a similar email. For GPL packages, there is no source available. For LGPL packages, there is no license anywhere and there is no link to download the sofware. grep'ing the installation shows that there is no mention of 'gpl' anywhere. Project Component License --------------------------------------------------------------- cdrecord mkisofs GPL cdrdao cdrdao GPL dvdauthor dvdauthor, spumux GPL id3lib id3lib LGPL lame lame LGPL mjpeg-tools mpeg2enc, mplex GPL I may very well have missed other violations. This is pretty freaking stupid of the company. With such a large number of violations, I'm wondering if the FSF would jump in to represent all of the projects? - Scott Fritzinger Founder and former developer for the gPhoto Project |
From: <sc...@hu...> - 2007-07-08 16:42:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The current cdrdao tarball's version of scsilib is too low to compile properly on the intel-based Macs. We need Schily's a27 version at the very least, where he introduced support for i386-darwin. After figuring out how cdrdao does its magic under its scsilib tree, I first made sure a27 would work before upgrading to a29, as a29 is suppose to have bluray support now and has some massive changes (so the ANnouncement files on a28 & a29 say). Yes I am actually able to kludge cdrdao-1.2.2 to compile & link with the a29 the same way. Here's some bit of proof it's working on my new 24-inch iMac Core2 Duo stock machine: $ cdrdao drive-info Cdrdao version 1.2.2 - (C) Andreas Mueller <an...@da...> SCSI interface library - (C) Joerg Schilling Paranoia DAE library - (C) Monty Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables. Using libscg version 'schily-0.9' IODVDServices: MATSHITA DVD-R UJ-85J Rev: FCQA Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000) Maximum reading speed: 4234 kB/s Current reading speed: 4234 kB/s Maximum writing speed: 4234 kB/s Current writing speed: 4234 kB/s BurnProof supported: yes JustLink supported: yes JustSpeed supported: no $ cat /etc/cdrdao.conf write_device:"IODVDServices" cddb_server_list:"freedb.freedb.org:/~cddb/cddb.cgi" $ $ file /usr/local/bin/cdrdao /usr/local/bin/cdrdao: Mach-O executable i386 i.e. at least cdrdao+cdrtools can see the drive and it's native i386 code. (I need to upgrade 'file' so it can report .a files properly; for now you'll just have to trust me the .a's are i386-native, too ;) .) How 'bout that? :) btw I can't possibly test bluray support unless/until someone might want to donate a firewire enclosure with one of them expensive critters in it. ;) Supposedly Toast 8.0.1 has a kext that we can use for comparisons. I will attempt to try those native SCSI patches from Edgar Fuß <ef...@ma...> next. But I think I need to take a nap first. ;) Stay tuned. -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkaRE50ACgkQZbt5KOxKrtR8bwCgqBInPSw5U7wOHR5KoanxyhDuxmMA nj9/yKQKJfMJNVZkHV9mNqm3ZEAt =R0KG -----END PGP SIGNATURE----- |
From: <ef...@ma...> - 2007-07-08 12:04:36
|
> Please provide the rest of the patches e.g. your drivers somehow http://www.math.uni-bonn.de/people/ef/cdrdao-ScsiIf/ |
From: <sc...@hu...> - 2007-07-08 05:26:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Please provide the rest of the patches e.g. your drivers somehow, perhaps zip them up and put them on rapidshare.de or a similar site. Or perhaps open a Patch Tracker Report at Sourceforge's cdrdao project site where we can all keep track of this progress. I am quite excited to try your OSX-native code on this new 24-inch iMac Intel Core2 Duo I just got. (Later when I can, I will test your drivers on my G4 & G5 machines.) And thank you very much for doing this! :) -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkaQdXsACgkQZbt5KOxKrtSzPgCgii/cgJXD4BpJjbrjHc009eHcWNgA oItbpKzn7qDqDcuBpb0AmdwH/RiQ =SAYD -----END PGP SIGNATURE----- |
From: <ef...@ma...> - 2007-07-07 21:09:55
|
Guten Tag. (English version below) Hier haben sich einige Erweiterungen von cdrdao angesammelt, die ich =20 eigentlich mal der Allgemeinheit zug=E4nglich machen k=F6nnte. Ich = hoffe, =20 damit bin ich hier richtig. Vermutlich am interessantesten sind native (also Schily-freie) SCSI-=20 Treiber f=FCr NetBSD, Irix und Mac OS X. Die f=FCr NetBSD und Irix sind =20= ziemlich alt und schon jahrelang im Einsatz (auf cdrdao 1.1.7), =20 insbesondere der f=FCr NetBSD hat schon tausende von CD-Rs auf dem =20 Buckel. Der f=FCr Mac OS X ist neu, also noch wenig getestet. Alle =20 erlauben die Angabe des Devices im ,,nativen`` Format des =20 Betriebssystems, also unter NetBSD ,,cd2``, unter Irix ,,sc1d3l0`` =20 und unter Mac OS X den IO-Registry-Pfad. Ich h=E4nge die Treiber hier =20= erstmal noch nicht dran, weil die m=E4=DFig gro=DF (je grob 10KB) sind. Der Patch first_track erlaubt im toc-File die Angabe einer von 1 =20 abweichenden Nummer des ersten Tracks. Ja, das ist erlaubt (IEC 908, =20 17.5.1). Ja, ich wei=DF, da=DF es CD-Spieler (auch namhafter Hersteller) = =20 gibt, die sich daran verschlucken. Ich finde es aber praktisch, wenn =20 bei einem auf zwei CDs verteilten Werk die Nummer n auch Tracknummer =20 n hat. Implementiert ist das nur f=FCr GenericMMC. Der Patch power_cal erh=F6ht den Timeout f=FCr die power calibration und = =20 macht die Routine (meiner Meinung nach) etwas =FCbersichtlicher. Der Patch stop erlaubt, mehrere cdrdao-Prozesse zu synchronisieren, =20 indem man die Kommandos mit einem Parameter --stop aufruft, und sie =20 dann, nachdem sie sich nach der power calibration gestoppt haben, mit =20= kill -CONT a b c d alle gleichzeitig weiterlaufen l=E4=DFt. Ich benutze =20= das, um auf einer SparcStation 20 vier oder mehr Brenner gleichzeitig =20= bedienen zu k=F6nnen. Durch die unterschiedlich langen Zeiten, die die =20= power calibration braucht, laufen die Prozesse sonst nicht synchron =20 genug, da=DF sie gleichzeitig aus dem buffer cache mit Daten versorgt =20= werden k=F6nnen. Wenn man das nicht schafft, rei=DFt der Datenstrom ab, =20= weil die Platten rumseeken m=FCssen. Der Patch start_init verschiebt einige Aktionen (insbesondere die =20 power calibraion) von startDao() nach initDao(). Ich mu=DF zugeben, da=DF = =20 mir die genaue Motivation dazu nach drei bis f=FCnf Jahren entfallen =20 ist. Ich meine mich an eine Treiberdokumentation zu erinnern, die =20 besagt, da=DF startDao() noch keine Ver=E4nderungen am Medium vornehmen =20= darf, finde die aber weder im Source-Archiv noch im Netz wieder. Bis auf den Mac-OS-X-SCSI-Treiber waren alle Patches bei mir gegen =20 1.1.7. Ich habe sie dann gearde auf 1.2.2 =FCbertragen -- es ist nicht =20= ausgeschlossen, da=DF mir dabei irgendwelche d=E4mlichen Fehler =20 unterlaufen sind. Kommentare? Over the years, I've accumulated several extensions to cdrdao that =20 maybe others can benefit from, too. I hope this is the right place to =20= make them available. I guess the most interesting of those may be native (i.e. non-Schily) =20= SCSI drivers for NetBSD, Irix and Mac OS X. Those for NetBSD and Irix =20= are rather old and been in productive use for years (the NetBSD one =20 must have burnt literally thousands of CD-R's by now). The Mac OS X =20 one is very recent and thus has not been extensively tested. All =20 three allow for the respective OS's ''native=B4=B4 device names like = ''cd2=20 =B4=B4 on NetBSD, ''sc1d3l0=B4=B4 on Irix and the IO Registry Path on = Mac OS =20 X. As the driver are moderately large (some 10KB each), I don't =20 attach them right now. The first_track patch allows starting a CD with a track number other =20 than 1. Yes, IEC 908 allows this in section 17.5.1. Yes, I'm aware of =20= the fact that several CD players (even some by well-known =20 manufacturers) get horribly confused if you use this feature. =20 However, I like a programme spanning two disks to be numbered =20 continuously. The power_cal patch rises the timeout for the power calibration =20 command. Additionally, it makes that function somewhat more =20 readable---at least in my opinion. The stop patch allows you to synchronise several cdrdao processes =20 serving a number of writers. You start each with a --stop option, and =20= they stop themselves after having executed the power calibration. You =20= then restart all of them by a kill -CONT command. I use this to =20 operate four or more writers on a SparcStation 20. It's not =20 sufficient to start all of the commands simultaneously because the =20 slight difference the respective power calibrations take suffice to =20 make them run out of sync. If you can't serve the data reads from the =20= buffer cache, the disc starts to seek like mad an you can't deliver =20 data fast enough. At least not on a SparcStation 20. The start_init patch moves some actions (power calibration being one =20 of them) from startDao() to initDao(). I must admit not remembering =20 precisely why having done so three or five years ago. I remember some =20= cdrdao driver documentation (which I can't find right now) stating =20 you're not supposed to do anything that actually changes the medium =20 in startDao(). Save the Mac OS X driver, all my changes were to 1.1.7 originally. =20 I've extracted them to patches and converted those to apply to 1.2.2. =20= I'm sorry should I have made any silly mistakes in that process. Any comments? |
From: Ingo v. L. <in...@gm...> - 2007-03-09 14:07:03
|
Dave Burns wrote: > The command given predates the MMC spec. According to the spec for the > old Plextor CD-ROM drives, the 2 MSBs of the Control byte give the > format desired, so the 80 in the last byte requests format 2. Ah, that explains my confusion. I wondered about the 0x80 Control byte, but all I could find about those upper two bits was "Vendor-defined". The MMC spec could at least have mentioned this oddity in a footnote somewhere. Thanks, Ingo |
From: Ingo v. L. <in...@gm...> - 2007-03-08 14:34:10
|
Hi there, I apologize if my mail is not perfectly on-topic, but the chance to get competent support appears to be best on this list: I'm developing firmware for a device that's capable of emulating, among other things, a CD-ROM drive. It was brought to my attention that the device was not recognized when connected to a MAC OS X host, so I compared its SCSI responses with those of several other drives. The primary source of confusion appears to be this SCSI Read TOC request (0x43) issued by OS X: 43 02 00 00 00 00 00 FF FE 80 The Format field is set to 0000b (TOC), and the MSF flag is set to one (use MSF instead of LBA). According to the MMC spec the device is supposed to respond with a 4-byte header and one or more 8-byte track descriptors. All devices I checked for reference seem to use the 11-byte Full TOC track descriptor format (0010b), though, and apparently this is also what OS X expects. The other drives are flawlessly accepted by the host while it just displayed a "Cannot read CD" error message for my device. So, am I just misinterpreting the spec or is this an error that was spread so widely that it became a sort of "common law"? And is OS X behaving sensibly when it's requesting format 0 and expecting to get format 2? Cheers, Ingo |
From: Thomas P. <tp...@gm...> - 2006-11-11 11:48:24
|
I made a patch to let cdrdao 1.2.2 and the newest CVS Checkout compile under cygwin. Thanks to Giuseppe Corbelli for his help! -- mfg, Thomas |
From: Thomas P. <tp...@gm...> - 2006-11-06 14:53:58
|
Hi! I tried to compile cdrdao 1.2.2 on cygwin, but it failed. I found out that there are problems between the macro "min" and a member function also called min(). But I don't know where to start to solve this problem, perhaps any of you know. Thanks in advance, Thomas make all-recursive make[1]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2' Making all in scsilib make[2]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib' Makefile:18: warning: overriding commands for target `install' RULES/rules1.dir:27: warning: ignoring old commands for target `install' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/conf" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/conf' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/conf' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/inc" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/inc' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/inc/align_test.mk" make[4]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/inc' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/inc' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/inc/avoffset.mk" make[4]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/inc' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/inc' make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/inc' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/lib" NOTICE: Partial source (SRCROOT/lib) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libdeflt" NOTICE: Partial source (SRCROOT/libdeflt) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libedc" NOTICE: Partial source (SRCROOT/libedc) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libfile" NOTICE: Partial source (SRCROOT/libfile) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libhfs_iso" NOTICE: Partial source (SRCROOT/libhfs_iso) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libparanoia" NOTICE: Partial source (SRCROOT/libparanoia) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/librscg" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/librscg' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/librscg/librscg.mk" make[4]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/librscg' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/librscg' make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/librscg' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libscg" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libscg' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/libscg/libscg.mk" make[4]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libscg' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libscg' make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libscg' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libschily" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libschily' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/libschily/libschily.mk" make[4]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libschily' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libschily' make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/libschily' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/libunls" NOTICE: Partial source (SRCROOT/libunls) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav" NOTICE: Partial source (SRCROOT/cdda2wav) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" NOTICE: Partial source (SRCROOT/cdrecord) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cmd" NOTICE: Partial source (SRCROOT/cmd) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/mkisofs" NOTICE: Partial source (SRCROOT/mkisofs) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/mkisofs/diag" NOTICE: Partial source (SRCROOT/mkisofs/diag) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/readcd" NOTICE: Partial source (SRCROOT/readcd) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/rscsi" NOTICE: Partial source (SRCROOT/rscsi) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/scgcheck" NOTICE: Partial source (SRCROOT/scgcheck) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/scgskeleton" NOTICE: Partial source (SRCROOT/scgskeleton) missing ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/man" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/man/man4" make[4]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man/man4' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/man/man4/makefiles.mk" make[5]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man/man4' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man/man4' ==> MAKING "all" ON SUBCOMPONENT "SRCROOT/man/man4/makerules.mk" make[5]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man/man4' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man/man4' make[4]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man/man4' make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/man' ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/export" make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/export' /bin/rm -f -r libschily scg xconfig.h libschily.a libscg.a librscg.a /bin/ln -s ../include libschily /bin/ln -s ../libscg/scg scg /bin/ln -s ../incs/i686-cygwin32_nt-gcc/xconfig.h xconfig.h /bin/ln -s ../libs/i686-cygwin32_nt-gcc/libschily.a libschily.a /bin/ln -s ../libs/i686-cygwin32_nt-gcc/libscg.a libscg.a /bin/ln -s ../libs/i686-cygwin32_nt-gcc/librscg.a librscg.a make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib/export' make[2]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/scsilib' Making all in pccts make[2]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts' Making all in antlr make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts/antlr' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts/antlr' Making all in dlg make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts/dlg' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts/dlg' make[3]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts' make[2]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/pccts' Making all in trackdb make[2]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/trackdb' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/trackdb' Making all in utils make[2]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/utils' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/utils' Making all in paranoia make[2]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/paranoia' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/paranoia' Making all in dao make[2]: Entering directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/dao' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../trackdb -I./../paranoia -I./../scsilib/export -I./../scsilib/export/libschily -DDRIVER_TABLE_FILE=\"/usr/local/share/cdrdao/drivers\" -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cc; \ then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi main.cc:2419:46: error: macro "min" requires 2 arguments, but only 1 given main.cc: In function 'int main(int, char**)': main.cc:2419: error: invalid use of member (did you forget the '&' ?) make[2]: *** [main.o] Error 1 make[2]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2/dao' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/cdrtools/cdrdao-1.2.2' make: *** [all] Error 2 |
From: David P. <pa...@rc...> - 2006-09-20 06:17:35
|
Denis Leroy wrote: > I'd like to do a quick bug fix release (1.2.2) which a few patches to > fix the G++ 4.1 compilation issues, as well as a gcdmaster > file-insertion bug. > > Does anyone has any patches they would like to see applied ? Hi, Denis. Since you asked, I wanted to point out (reproduced below) a one-line patch for cdrdao I submitted three years ago but I don't think was actually applied (I just checked cdrdao-1.2.1). I probably should have been more persistent about it, but better late than never, I suppose. :-) Thanks, David ----------------------- Subject: [Cdrdao-devel] patch for writing to Pioneer DVR-104 From: David Paschal <pa...@rc...> Date: Tue, 29 Jul 2003 23:07:15 -0700 To: cdr...@li... Cc: pa...@rc... 1. Hi. Attached is a patch against cdrdao-1.1.7 to make it able to write audio to my ATAPI "PIONEER DVD-RW DVR-104". Originally this drive worked fine, but for some reason after power cycling my computer it started giving the following failure early in the write or simulate process, even after recabling (such that the writer and hard disk were on separate IDE channels), upgrading the drive firmware, upgrading from cdrdao 1.1.5 to 1.1.7, and experimenting with the --speed and --buffers options: ----------------------------------------------------------------------- # cdrdao simulate --device 1,1,0 --driver generic-mmc foo.toc Cdrdao version 1.1.5 - (C) Andreas Mueller <an...@da...> SCSI interface library - (C) Joerg Schilling L-EC encoding library - (C) Heiko Eissfeldt Paranoia DAE library - (C) Monty Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables. Using libscg version 'schily-0.5' 1,1,0: PIONEER DVD-RW DVR-104 Rev: 1.32 Using driver: Generic SCSI-3/MMC - Version 1.2 (options 0x0000) Starting write simulation at speed 8... Pausing 10 seconds - hit CTRL-C to abort. Process can be aborted with QUIT signal (usually CTRL-\). Turning BURN-Proof on Writing track 01 (mode AUDIO/AUDIO)... Wrote 1 of 624 MB (Buffer 100%). ?: Input/output error. : scsi sendcmd: no error CDB: 2A 00 00 00 05 61 00 00 1B 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0E 00 00 00 00 04 07 00 80 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x04 Qual 0x07 (logical unit not ready, operation in progress) Fru 0x0 Sense flags: Blk 0 (not valid) operation 0% done cmd finished after 0.012s timeout 180s ERROR: Write data failed. ERROR: Writing failed - buffer under run? ERROR: Simulation failed. ----------------------------------------------------------------------- Here's the patch "inline" as well: diff -ru cdrdao-1.1.7.original/dao/GenericMMC.cc cdrdao-1.1.7/dao/GenericMMC.cc --- cdrdao-1.1.7.original/dao/GenericMMC.cc 2002-10-06 11:53:56.000000000 -0700 +++ cdrdao-1.1.7/dao/GenericMMC.cc 2003-07-24 18:43:06.000000000 -0700 @@ -1269,7 +1269,7 @@ // check if drive rejected the command because the internal buffer // is filled if(senseLen >= 14 && (sense[2] & 0x0f) == 0x2 && sense[7] >= 6 && - sense[12] == 0x4 && sense[13] == 0x8) { + sense[12] == 0x4 && (sense[13] == 0x7 || sense[13] == 0x8)) { // Not Ready, long write in progress mSleep(40); retry = 1; ----------------------------------------------------------------------- All the patch does is make it also use the above sense result as a signal to retry the operation, just as it already does with {code=4,qual=8}. It doesn't seem to hurt anything, and it definitely helps for my purposes. :-) Hopefully one of the cdrdao maintainers will see fit to check this into CVS or to figure out a better way to fix this problem. Let me know if I need to try anything else. I'm using ide-scsi on RedHat Linux 8.0 (kernel 2.4.18-14). FWIW, while debugging this I found that an ATAPI "HP CD-Writer+ 8100" on a similar machine worked perfectly, and noticed a slight difference in the timing for the initial "Wrote 1 of 624 MB (Buffer 100%)" message. On the Pioneer, it appeared immediately, stayed at "1 of 624 MB" for about 10 seconds, and sometimes but not always got past a few more MB before failing as above. OTOH with the HP, it took about 10 seconds for the "1 of 624 MB" message to appear, but it didn't delay any before counting its way to the end of the disc. That suggested to me (knowing almost nothing about the SCSI protocol) that the HP treats the "write" command as a blocking operation, and the Pioneer treats it as non-blocking and returns the above sense code when it can't handle any more requests. In addition to the above (now fixed) issue, "cdrdao read-cd" doesn't seem to work on this same drive. It can read the TOC fine, but upon reading the data it reports a long stream of errors such as the following: ----------------------------------------------------------------------- Copying audio tracks 1-12: start 00:00:00, length 49:46:37 to "FOO.bin"... Track 1... ?: Input/output error. : scsi sendcmd: no error CDB: BE 00 00 00 00 00 00 00 14 F8 01 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 24 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.006s timeout 20s ----------------------------------------------------------------------- Fortunately this isn't much of a problem for me, because I also have a "LITEON DVD-ROM LTD163" which reads successfully using the generic-mmc driver. But if anybody has any ideas on how to make this work on this drive, I'd be interested to know. "invalid field in cdb" suggests to me that the "read audio" command is supported but perhaps a field in the CDB is missing or incorrect. In any case, cdrdao is very useful to me for making backup copies of my audio CDs, so thanks to all the developers for providing it. David |
From: Denis L. <den...@ya...> - 2006-09-18 17:33:43
|
Hi, I'd like to do a quick bug fix release (1.2.2) which a few patches to fix the G++ 4.1 compilation issues, as well as a gcdmaster file-insertion bug. Does anyone has any patches they would like to see applied ? -denis |
From: <th...@gm...> - 2006-02-06 16:18:00
|
Hi, every time I read an audio CD I get the message that several hundreds of CRC Errors occured... What does that mean? What are CRC Errors? Thomian -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++ |
From: Andrew S. <asu...@de...> - 2006-01-18 19:32:51
|
The manpage really sucks. Here's a patch that makes it suck marginally less. It needs some more serious attention though. Preferably by somebody who knows roff this time - the last person to write it clearly did not, given some of the stuff I fixed here. I don't either, but at least it's actually readable now. -- Andrew Suffield |
From: Giuseppe C. <co...@lu...> - 2006-01-11 20:02:34
|
1) Device locking for win32. When burning you must take care not to access device, as stated in the README. I have some code to lock the device, and I can integrate it into cdrdao. Questions are: *) Is it needed? *) Where to put it? In main or perhaps in a new #ifdef __CYGWIN__ ScsiIf::LockDevice() 2) Option parsing. I think it would be better to switch to an option parsing library: code size & readability would improve. Do you believe this is a good idea? -- Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net -<! At first there was nothing. Then God said 'Let there be light!' Then there was still nothing. But you could see it. !>- |
From: Paul W. <pw_...@sl...> - 2005-12-21 21:35:31
|
On Thu, Dec 15, 2005 at 12:36:54PM -0800, Denis Leroy wrote: > Still, I would feel better if we understood exactly what the bug and > found a workaround. Any help is appreciated here. Sure. Is there any more information I can provide? strace? or some gdb tricks? (I don't have a clue with gdb but I can muddle along with some instructions...) -- Paul Winkler http://www.slinkp.com |
From: blah <at...@gm...> - 2005-12-21 20:46:05
|
I'm trying to burn an svcd which I have the bin and cue files for. I execute the command: #cdrdao write --driver generic-mmc --device 0,0,0 --capacity 80 --speed 12 CD_Image_File_CD1.cue Cdrdao version 1.2.1 - (C) Andreas Mueller <an...@da...> SCSI interface library - (C) Joerg Schilling Paranoia DAE library - (C) Monty Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables. ERROR: CD_Image_File_CD1.cue:13: Index beyond track end. ERROR: CD_Image_File_CD1.cue:14: Index beyond track end. ERROR: CD_Image_File_CD1.cue:15: Index beyond track end. ERROR: CD_Image_File_CD1.cue:16: Index beyond track end. ERROR: CD_Image_File_CD1.cue:17: Index beyond track end. The cue file looks like this: # cat CD_Image_File_CD1.cue FILE "CD_Image_File_CD1.bin" BINARY TRACK 01 MODE2/2352 FLAGS DCP INDEX 01 00:00:00 TRACK 02 MODE2/2352 FLAGS DCP INDEX 00 00:04:00 INDEX 01 00:06:00 INDEX 02 04:40:64 INDEX 03 22:55:71 INDEX 04 31:02:22 INDEX 05 55:01:31 INDEX 06 66:46:48 The file size of the bin is: # ls -l total 823684 -rw-r--r-- 1 daishi daishi 842618112 2005-11-28 19:59 CD_Image_File_CD1.bin I'm not sure what else could help, I tried shortening the length of INDEX 06 just to test and it didnt work. Extra (useful?) information: # vcd-info -T -c CD_Image_File_CD1.cue ---------------------------------------------------------------------------= ---- vcd-info - GNU VCDImager - (Super) Video CD Report $Id: vcd-info.c,v 1.23 2005/05/08 08:42:09 rocky Exp $ ---------------------------------------------------------------------------= ---- SVCD/TRACKS.SVD ID: `TRACKSVD' version: 0x01 tracks: 1 track[00]: 57:53:56, audio: 1 stream, video: NTSC stream, SVCD subtitle (OGT) stream: None CVD interpretation (probably) (track[00]: 57:53:56 (cumulated), audio: 00, ogt: 0d) ---------------------------------------------------------------------------= ---- CD-ROM TRACKS (1 - 2) #: MSF LSN Type 1: 00:02:00 000000 XA 2: 00:08:00 000450 XA 170: 79:38:56 358256 leadout ---------------------------------------------------------------------------= ---- 1# vcd-info -T -b CD_Image_File_CD1.cue ---------------------------------------------------------------------------= ---- vcd-info - GNU VCDImager - (Super) Video CD Report $Id: vcd-info.c,v 1.23 2005/05/08 08:42:09 rocky Exp $ ---------------------------------------------------------------------------= ---- SVCD/TRACKS.SVD ID: `TRACKSVD' version: 0x01 tracks: 1 track[00]: 57:53:56, audio: 1 stream, video: NTSC stream, SVCD subtitle (OGT) stream: None CVD interpretation (probably) (track[00]: 57:53:56 (cumulated), audio: 00, ogt: 0d) ---------------------------------------------------------------------------= ---- CD-ROM TRACKS (1 - 2) #: MSF LSN Type 1: 00:02:00 000000 XA 2: 00:08:00 000450 XA 170: 79:38:56 358256 leadout ---------------------------------------------------------------------------= ---- Any help is very appreciated. I didn't make the VCD but afaik it was made with vcdimager 0.7.3 in cygwin. I know i can use vcdxrip to extract and re-encode but that is a lot of trouble and takes a long time. I also now notice that INDEX 06 goes way over the time limit of the video file. Is that that problem? |
From: Denis L. <den...@ya...> - 2005-12-15 20:37:20
|
--- Paul Winkler <pw_...@sl...> wrote: > Hi, > > I've got gcdmaster 1.2.1 on gentoo. > Every time I try to create a new audio project, > either with the icon on the start screen or the > File -> New -> Audio CD menu item, I get: > > "The Application "gcdmaster" has quit unexpectedly." > > I see (presumably) this same crash mentioned on > http://cdrdao.sourceforge.net/changelog.html > but it just says "seemed to be related to gtkmm and libsigc++ and > went > away with newer releases of those packages." > What version(s) are known to work? > I have gtkmm 2.4.11 and libsigc++ 2.0.15 and those are the > latest versions that are listed as stable in gentoo. http://bugzilla.gnome.org/show_bug.cgi?id=162145 Still, I would feel better if we understood exactly what the bug and found a workaround. Any help is appreciated here. I'll try to setup an environment with an older version of gtkmm and reproduce it. Unfortunately Gentoo is behind in its versions of gtkmm and libsigc++. |
From: Paul W. <pw_...@sl...> - 2005-12-14 15:08:01
|
Hi, I've got gcdmaster 1.2.1 on gentoo. Every time I try to create a new audio project, either with the icon on the start screen or the File -> New -> Audio CD menu item, I get: "The Application "gcdmaster" has quit unexpectedly." I see (presumably) this same crash mentioned on http://cdrdao.sourceforge.net/changelog.html but it just says "seemed to be related to gtkmm and libsigc++ and went away with newer releases of those packages." What version(s) are known to work? I have gtkmm 2.4.11 and libsigc++ 2.0.15 and those are the latest versions that are listed as stable in gentoo. Thanks. (p.s. I attempted to search the mailing list archives, but I suspect you all know how completely awful sourceforge's archive search is... and surprisingly, gmane turned up nothing at all for "gcdmaster crash".) -- Paul Winkler http://www.slinkp.com |