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: Denis L. <den...@ya...> - 2005-11-05 00:06:59
|
Hi, I'd like to release cdrdao 1.2.1 within the next couple of days. I've put a candidate tarball here : http://www.poolshark.org/src/cdrdao-1.2.1.rc1.tar.gz Please let me know if you have a chance to try it out and catch any problems. I'm especially interested in build feedback on Windows, FreeBSD and/or MacOS. -denis |
From: Denis L. <den...@ya...> - 2005-10-26 22:09:56
|
I believe this is fixed in CVS. -denis --- Steve Polishinski <ham...@ve...> wrote: > Greetings, > > Did some Googling and searching at the cdrdao sourceforge forums and > lists > since the 1.2.0 release, and didn't find any fix. Didn't try CVS. > > <SNIP much previous from "make" console spew> > > PCCTS 1.33MR32 installation complete > make[2]: Leaving directory `/home/steve/cdrdao-1.2.0/pccts' > Making all in trackdb > make[2]: Entering directory `/home/steve/cdrdao-1.2.0/trackdb' > if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../pccts/h -g -O2 -MT > Cddb.o -MD > -MP -MF ".deps/Cddb.Tpo" -c -o Cddb.o Cddb.cc; \ > then mv -f ".deps/Cddb.Tpo" ".deps/Cddb.Po"; else rm -f > ".deps/Cddb.Tpo"; exit > 1; fi > FormatConverter.h:98: error: âTocâ has not been declared > make[2]: *** [Cddb.o] Error 1 > make[2]: Leaving directory `/home/steve/cdrdao-1.2.0/trackdb' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/steve/cdrdao-1.2.0' > make: *** [all] Error 2 > > And I don't seem to be the only one. > http://www.linuxquestions.org/questions/history/371352 > http://64studio.com/pipermail/64studio-devel/2005-July/000625.html > > For the record, I'm trying this on a Fedora core 4 system, GCC (Red > Hat) > 4.0.1-5 -- BUT, given the 64 bit link above, it doesn't seem to be > isolated > to Fedora systems. However, I'm not sure if it does have something > to do > with what options I'm building, or rather not building. My > ./configure was > without any command line arguments, and this is the summary output at > the end > of it. (Just trying to build this for use with K3b & burning only > data > disks.) > > Building scsilib : yes > Building pccts : yes > Building cdrdao : yes > OGG support : no > MP3 support : no > Building toc2cue : yes > Building cue2toc : yes > Building toc2mp3 : no > Building gcdmaster : no > > The root of the build failure, AFAIK, are circular include references > between > Toc.h and FormatConverter.h. > > My hack is to remove the include of FormatConverter.h in Toc.h > and add includes of Toc.h in CueParser.cc and FormatConverter.h in > Toc.cc. No > claim that this is the most logical or eloquent fix, though it works. > > K3b is happy now since it finds and can successfully use cdrdao. > > If it would be of any use, I can make available complete text file > dumps of > configuration and make console output leading up to the build > failure. > > Thanks, Steve > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of > 2005 > Visit http://www.jboss.com/services/certification for more > information > _______________________________________________ > Cdrdao-devel mailing list > Cdr...@li... > https://lists.sourceforge.net/lists/listinfo/cdrdao-devel > |
From: Steve P. <ham...@ve...> - 2005-10-26 21:52:04
|
Greetings, Did some Googling and searching at the cdrdao sourceforge forums and lists= =20 since the 1.2.0 release, and didn't find any fix. Didn't try CVS. <SNIP much previous from "make" console spew> PCCTS 1.33MR32 installation complete make[2]: Leaving directory `/home/steve/cdrdao-1.2.0/pccts' Making all in trackdb make[2]: Entering directory `/home/steve/cdrdao-1.2.0/trackdb' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../pccts/h -g -O2 -MT Cddb.o -M= D=20 =2DMP -MF ".deps/Cddb.Tpo" -c -o Cddb.o Cddb.cc; \ then mv -f ".deps/Cddb.Tpo" ".deps/Cddb.Po"; else rm -f ".deps/Cddb.Tpo"; e= xit=20 1; fi =46ormatConverter.h:98: error: =E2=80=98Toc=E2=80=99 has not been declared make[2]: *** [Cddb.o] Error 1 make[2]: Leaving directory `/home/steve/cdrdao-1.2.0/trackdb' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/steve/cdrdao-1.2.0' make: *** [all] Error 2 And I don't seem to be the only one. http://www.linuxquestions.org/questions/history/371352 http://64studio.com/pipermail/64studio-devel/2005-July/000625.html =46or the record, I'm trying this on a Fedora core 4 system, GCC (Red Hat)= =20 4.0.1-5 -- BUT, given the 64 bit link above, it doesn't seem to be isolate= d=20 to Fedora systems. However, I'm not sure if it does have something to do=20 with what options I'm building, or rather not building. My ./configure was= =20 without any command line arguments, and this is the summary output at the e= nd=20 of it. (Just trying to build this for use with K3b & burning only data=20 disks.) Building scsilib : yes Building pccts : yes Building cdrdao : yes OGG support : no MP3 support : no Building toc2cue : yes Building cue2toc : yes Building toc2mp3 : no Building gcdmaster : no The root of the build failure, AFAIK, are circular include references betwe= en=20 Toc.h and FormatConverter.h. My hack is to remove the include of FormatConverter.h in Toc.h and add includes of Toc.h in CueParser.cc and FormatConverter.h in Toc.cc. = No=20 claim that this is the most logical or eloquent fix, though it works. K3b is happy now since it finds and can successfully use cdrdao. If it would be of any use, I can make available complete text file dumps of= =20 configuration and make console output leading up to the build failure. =20 Thanks, Steve =09 |
From: Hans-Georg F. <hg....@sn...> - 2005-09-15 14:02:19
|
Hallo, toc2cue creates the output-file but leaves it empty. Adding a close command to toc2cue.cc solves this problem. *** cdrdao-1.2.0/utils/toc2cue.cc Sun Jun 30 21:41:59 2002 --- cdrdao-1.2.0.hgf/utils/toc2cue.cc Thu Sep 15 15:52:10 2005 *************** *** 348,353 **** --- 348,354 ---- } } + out.close(); // otherwise the file will be left empty message(1, "Converted toc-file '%s' to cue file '%s'.", tocFile, cueFile); |
From: Denis L. <den...@ya...> - 2005-07-23 18:35:21
|
--- Matthias Czapla <der...@gm...> wrote: > Okay. It was a stupid idea to make it a separate "project" anyway. > > Regards > Matthias I beg to differ. It was an excellent idea. To merge your parser, i had to go through the PCCTS parser in details to understand the differences. And that was quite a pain in the behind... -denis |
From: Matthias C. <der...@gm...> - 2005-07-23 18:29:18
|
Hi Denis! On Sat, Jul 23, 2005 at 11:08:48AM -0700, Denis Leroy wrote: > --- Matthias Czapla <der...@gm...> wrote: > > Does cdrdao now support AUDIO tracks in CUE files? That would render > > cue2toc useless. > > Yes, i replaced the old pccts cue parser with yours, so in theory yes > it does render cue2toc useless. Okay. It was a stupid idea to make it a separate "project" anyway. Regards Matthias |
From: Denis L. <den...@ya...> - 2005-07-23 18:08:56
|
--- Matthias Czapla <der...@gm...> wrote: > Hi! > > Does cdrdao now support AUDIO tracks in CUE files? That would render > cue2toc useless. Otherwise I'd like to incorporate the latest > cue2toc > version into the cdrdao package since it seems to do its job and I'm > not > planning to work on it anymore. > > Regards > Matthias Hey Matthias, Yes, i replaced the old pccts cue parser with yours, so in theory yes it does render cue2toc useless. Though i'm sure there are bugs to track down (see previous email) and i had a pretty limited set of cue file examples to work with... I've been busy those past few months, but i'll have some time in the next few weeks to iron out some bugs and release 1.2.1. -denis |
From: Matthias C. <der...@gm...> - 2005-07-23 11:25:49
|
Hi! Does cdrdao now support AUDIO tracks in CUE files? That would render cue2toc useless. Otherwise I'd like to incorporate the latest cue2toc version into the cdrdao package since it seems to do its job and I'm not planning to work on it anymore. Regards Matthias |
From: Christ v. W. <cvw...@gm...> - 2005-07-22 21:57:25
|
Hi Denis, list, I mis-replied, and took if off-list... Here it is on the list as well. > Could you provide the length (in bytes) of the 3 wav files that we're > talking about here ? The error seems to imply that at least one of them > is simply too short for the specified indices... Interestingly enough, cdrdao complains at the first empty line after the specification for track 1... Anyway, here goes... There are only 2 wav files, by the way! Track 3 is a subset of track 2. I've burned another Audio CD with only 1 track of data, but with multiple track definitions in the .cue file. 274251820 xxx1.wav 271294508 xxx2.wav Hope this helps! Christ van Willegen |
From: Denis L. <den...@ya...> - 2005-07-22 21:38:05
|
Hi, Could you provide the length (in bytes) of the 3 wav files that we're talking about here ? The error seems to imply that at least one of them is simply too short for the specified indices... -denis --- Christ van Willegen <cvw...@gm...> wrote: > Hello, > > my first posting here, hope I get most of the info right :-) > > I'm on a Mac, using OS-10.4. My cdrdao version is 1.2.0. I downloaded > a compiled binary off a web site. I could compile it myself, but I'd > only get 1.1.9... > > I have a few .wav files, and a .cue file that goes with it. > > Unfortunately, cdrdao says: > ERROR: example.cue:22: Index beyond track end. > > ERROR: example.cue:23: Index beyond track end. > > ERROR: example.cue:24: Index beyond track end. > > ERROR: example.cue:25: Index beyond track end. > > ERROR: example.cue:26: Index beyond track end. > > ERROR: example.cue:27: Index beyond track end. > > ERROR: example.cue:28: Index beyond track end. > > ERROR: example.cue:29: Index beyond track end. > > ERROR: example.cue:30: Index beyond track end. > > > Here's the .cue file. Names changed to protect the innocent... > > PERFORMER "Some Artist" > TITLE "Some CD with 3 tracks" > > FILE "XXXXXX1.wav" WAVE > TRACK 01 AUDIO > PERFORMER "Some Artist" > TITLE "Track name 1" > INDEX 01 00:00:00 > INDEX 02 05:53:38 > INDEX 03 07:42:19 > INDEX 04 09:39:61 > INDEX 05 11:29:58 > INDEX 06 13:48:16 > INDEX 07 14:16:35 > INDEX 08 16:23:04 > INDEX 09 17:27:54 > INDEX 10 24:56:65 > > FILE "XXXXXX2.wav" WAVE > TRACK 02 AUDIO > PERFORMER "Some artist" > TITLE "Track name 2" > INDEX 01 00:00:00 > INDEX 02 01:18:49 > INDEX 03 05:25:52 > INDEX 04 08:47:71 > INDEX 05 11:41:20 > INDEX 06 16:29:06 > > TRACK 03 AUDIO > PERFORMER "Some artist" > TITLE "Track name 3" > INDEX 01 21:44:24 > > Can anybody shed some light on how to do this? > > Regards, > > Christ van Willegen > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________ > Cdrdao-devel mailing list > Cdr...@li... > https://lists.sourceforge.net/lists/listinfo/cdrdao-devel > |
From: Christ v. W. <cvw...@gm...> - 2005-07-22 21:14:09
|
Hello, my first posting here, hope I get most of the info right :-) I'm on a Mac, using OS-10.4. My cdrdao version is 1.2.0. I downloaded a compiled binary off a web site. I could compile it myself, but I'd only get 1.1.9... I have a few .wav files, and a .cue file that goes with it. Unfortunately, cdrdao says: ERROR: example.cue:22: Index beyond track end. ERROR: example.cue:23: Index beyond track end. ERROR: example.cue:24: Index beyond track end. ERROR: example.cue:25: Index beyond track end. ERROR: example.cue:26: Index beyond track end. ERROR: example.cue:27: Index beyond track end. ERROR: example.cue:28: Index beyond track end. ERROR: example.cue:29: Index beyond track end. ERROR: example.cue:30: Index beyond track end. Here's the .cue file. Names changed to protect the innocent... PERFORMER "Some Artist" TITLE "Some CD with 3 tracks" FILE "XXXXXX1.wav" WAVE TRACK 01 AUDIO PERFORMER "Some Artist" TITLE "Track name 1" INDEX 01 00:00:00 INDEX 02 05:53:38 INDEX 03 07:42:19 INDEX 04 09:39:61 INDEX 05 11:29:58 INDEX 06 13:48:16 INDEX 07 14:16:35 INDEX 08 16:23:04 INDEX 09 17:27:54 INDEX 10 24:56:65 FILE "XXXXXX2.wav" WAVE TRACK 02 AUDIO PERFORMER "Some artist" TITLE "Track name 2" INDEX 01 00:00:00 INDEX 02 01:18:49 INDEX 03 05:25:52 INDEX 04 08:47:71 INDEX 05 11:41:20 INDEX 06 16:29:06 TRACK 03 AUDIO PERFORMER "Some artist" TITLE "Track name 3" INDEX 01 21:44:24 Can anybody shed some light on how to do this? Regards, Christ van Willegen |
From: Denis L. <den...@ya...> - 2005-06-20 20:31:49
|
i can't provide an accurate answer, but it's probably something along the lines of "it's not supported for DVDs"... Improving DVD support is certainly at the top of my to-do list, but my knowledge of the DVD format and MMC extensions is lacking... -denis --- David Antliff <dav...@pa...> wrote: > > Hello, > > I posted this on the sourceforge Cdrdao forum but then realised, > after > looking at the number of replies for past messages, that it probably > won't > get much visibility there. So I re-post here in the hope that solving > this > problem might help others (I know of one other person already on > forums.gentoo.org who has this same problem) as well as myself. > > I am trying to use cdrdao to read and backup my (legitimate) > Playstation2 > game DVDs in Linux (Gentoo, 2.6.11.6). I have tried two different DVD > > drives (a 3 year old Samsung and a brand new LG GSA-4163B) without > success. The software seems unable to instruct the drive to reading > the > TOC as a mode2 disk. I'm no expert here at all, but it seems to me > that > the driver is reporting failed capabilities and reverting back to > mode1, > which then fails later. There is a trace of the output from cdrdao > included at the end of this email. > > I have tried cdrdao 1.1.9 and 1.2.0. I have tried the generic-mmc and > the > generic-mmc-raw drivers - both exhibit the same behaviour. I have > tried > all the options in the cdrdao README (e.g. --driver generic-mmc:0x3) > with > little success. I have even looked at the source code. Here is where > it > fails (as long as I don't have the :0x10000 option set - see below): > > GenericMMC.cc:2038 > -------------------------------- > // read disk toc length > memset(cmd, 0, 10); > cmd[0] = 0x43; // READ TOC > cmd[2] = 2; > cmd[6] = sessionNr; > cmd[8] = 4; > > if (sendCmd(cmd, 10, NULL, 0, reqData, 4) != 0) { > message(-2, "Cannot read disk toc."); > return NULL; > } > -------------------------------- > > A 'normal' DVD (e.g. the installation DVD that came with the drive) > can be > read fine (although it's mode 1). All of my PS2 disks fail (they are > all > mode 2 I think). > > I did find that 'generic-mmc-raw:0x10000' gets rid of the first error > > ("ERROR: Cannot read disk toc.") but it still reverts to MODE 1 and > then > fails in the same way (and obviously somewhere else in the code). > > Most recently I tried using the drive with Nero in Windows to read > PS2 > disks, and it works fine. > > Is there anything else I can do to try and work out a fix? Can I > somehow > collect more information on what is happening to assist with finding > a > resolution? > > Thanks in advance for any assistance. > > > --- TRACE ------------------------------ > > # cdrdao read-cd -v 4 --read-raw --device ATA:1,0,0 --driver > generic-mmc-raw gamename.toc > Cdrdao version 1.2.0 - (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. > Format converter enabled for extensions: mp3 ogg > > Using libscg version 'schily-0.8' > Using libscg transport code version 'schily-scsi-linux-sg.c-1.83' > > ATA:1,0,0: HL-DT-ST DVDRAM GSA-4163B Rev: A100 > Using driver: Generic SCSI-3/MMC (raw writing) - Version 2.0 (options > > 0x0000) > > Reading toc and track data... > getTocGeneric: data len 20 > ERROR: Cannot read disk toc. > > Track Mode Flags Start Length > ------------------------------------------------------------ > 1 DATA 4 00:00:00( 0) 360:20:52(1621552) > Leadout DATA 4 360:20:52(1621552) > > Checking for PQ sub-channel reading support (data track)... > PQ sub-channel reading (data track) not supported. > Checking for raw P-W sub-channel reading support (data track)... > Raw P-W sub-channel reading (data track) is not supported. > Checking for cooked R-W sub-channel reading support (data track)... > Cooked R-W sub-channel reading (data track) is not supported. > ERROR: Cannot read sector of track. > WARNING: Cannot determine mode of data track 1 - asuming MODE1. > Copying data track 1 (MODE1_RAW): start 00:00:00, length 360:20:52 to > > "data.bin"... > /home/david/src/cdrdao-1.2.0/dao/cdrdao: Success. : scsi sendcmd: no > error > CDB: BE 00 00 00 00 00 00 00 1A F8 00 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 10 BE F8 00 08 24 00 00 C0 > Sense Key: 0x5 Illegal Request, Segment 0 > Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0 > Sense flags: Blk 0 (not valid) error refers to command part, bit ptr > 0 > (not valid) field ptr 0 > resid: 61152 > cmd finished after 0.001s timeout 20s > ERROR: Read error while copying data from track. > > > -- > David. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Cdrdao-devel mailing list > Cdr...@li... > https://lists.sourceforge.net/lists/listinfo/cdrdao-devel > |
From: David A. <dav...@pa...> - 2005-06-19 21:46:33
|
Hello, I posted this on the sourceforge Cdrdao forum but then realised, after looking at the number of replies for past messages, that it probably won't get much visibility there. So I re-post here in the hope that solving this problem might help others (I know of one other person already on forums.gentoo.org who has this same problem) as well as myself. I am trying to use cdrdao to read and backup my (legitimate) Playstation2 game DVDs in Linux (Gentoo, 2.6.11.6). I have tried two different DVD drives (a 3 year old Samsung and a brand new LG GSA-4163B) without success. The software seems unable to instruct the drive to reading the TOC as a mode2 disk. I'm no expert here at all, but it seems to me that the driver is reporting failed capabilities and reverting back to mode1, which then fails later. There is a trace of the output from cdrdao included at the end of this email. I have tried cdrdao 1.1.9 and 1.2.0. I have tried the generic-mmc and the generic-mmc-raw drivers - both exhibit the same behaviour. I have tried all the options in the cdrdao README (e.g. --driver generic-mmc:0x3) with little success. I have even looked at the source code. Here is where it fails (as long as I don't have the :0x10000 option set - see below): GenericMMC.cc:2038 -------------------------------- // read disk toc length memset(cmd, 0, 10); cmd[0] = 0x43; // READ TOC cmd[2] = 2; cmd[6] = sessionNr; cmd[8] = 4; if (sendCmd(cmd, 10, NULL, 0, reqData, 4) != 0) { message(-2, "Cannot read disk toc."); return NULL; } -------------------------------- A 'normal' DVD (e.g. the installation DVD that came with the drive) can be read fine (although it's mode 1). All of my PS2 disks fail (they are all mode 2 I think). I did find that 'generic-mmc-raw:0x10000' gets rid of the first error ("ERROR: Cannot read disk toc.") but it still reverts to MODE 1 and then fails in the same way (and obviously somewhere else in the code). Most recently I tried using the drive with Nero in Windows to read PS2 disks, and it works fine. Is there anything else I can do to try and work out a fix? Can I somehow collect more information on what is happening to assist with finding a resolution? Thanks in advance for any assistance. --- TRACE ------------------------------ # cdrdao read-cd -v 4 --read-raw --device ATA:1,0,0 --driver generic-mmc-raw gamename.toc Cdrdao version 1.2.0 - (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. Format converter enabled for extensions: mp3 ogg Using libscg version 'schily-0.8' Using libscg transport code version 'schily-scsi-linux-sg.c-1.83' ATA:1,0,0: HL-DT-ST DVDRAM GSA-4163B Rev: A100 Using driver: Generic SCSI-3/MMC (raw writing) - Version 2.0 (options 0x0000) Reading toc and track data... getTocGeneric: data len 20 ERROR: Cannot read disk toc. Track Mode Flags Start Length ------------------------------------------------------------ 1 DATA 4 00:00:00( 0) 360:20:52(1621552) Leadout DATA 4 360:20:52(1621552) Checking for PQ sub-channel reading support (data track)... PQ sub-channel reading (data track) not supported. Checking for raw P-W sub-channel reading support (data track)... Raw P-W sub-channel reading (data track) is not supported. Checking for cooked R-W sub-channel reading support (data track)... Cooked R-W sub-channel reading (data track) is not supported. ERROR: Cannot read sector of track. WARNING: Cannot determine mode of data track 1 - asuming MODE1. Copying data track 1 (MODE1_RAW): start 00:00:00, length 360:20:52 to "data.bin"... /home/david/src/cdrdao-1.2.0/dao/cdrdao: Success. : scsi sendcmd: no error CDB: BE 00 00 00 00 00 00 00 1A F8 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 10 BE F8 00 08 24 00 00 C0 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0 Sense flags: Blk 0 (not valid) error refers to command part, bit ptr 0 (not valid) field ptr 0 resid: 61152 cmd finished after 0.001s timeout 20s ERROR: Read error while copying data from track. -- David. |
From: Carlos B. <cb...@gm...> - 2005-05-17 16:41:39
|
Hello everyone, I am storing the cdrdao-generated toc file (cueconvert'd to cue format) inside the CUESHEET block of a FLAC image file. When exporting the cuesheet from the FLAC image file back into a file, the cddb information is lost. To regenerate it is really easy: cueconvert cuefile to tocfile, then 'cdrdao read-cddb tocfile'. However, cdrdao demands that the bin or wav file is present (so to calculate or verify something). If the tocfile was originaly generated by cdrdao, doesn't it already contain the necessary information to calculate the discid, without having to doublecheck with the bin/wav file? I'm just trying to save the step of decompresing the whole FLAC image file into a wav before attemting a cddb query. Thank you very much in advance for your help and time. Carlos |
From: Denis L. <den...@ya...> - 2005-04-22 09:45:26
|
Hi, Though not a whole lot of new development is happening in cdrdao, I'd still like to release version 1.2.0 within the next few days, to fix a number of compile problems with newer gcc's, as well as a potential local root exploit. As far as gcdmaster goes, the gtkmm24 branch has been merged back into the trunk (mp3 and ogg support). Please take a look at the current CVS head and let me know if you run into any problems. I would especially appreciate feedback on platforms other that i386. cheers, -denis |
From: Kelvin L. <ke...@us...> - 2005-03-31 21:31:28
|
Bill, > Here's my question: I tried just using > > cdrdao read-cd --read-subchan rw foo.toc > > but the resulting CD+G I burned was not playable -- it kind of worked > but the graphics didn't always work and the audio buzzed. > > I'm trying to understand why I need to do the --read-raw and > --read-subchan rw_raw. > > If I understand correctly, --read-raw says to bypass the error > correction done by the drive -- so any errors in the read are then > transferred to the cdr on the write operation. Is that correct? I > would think I would want the error correction. > > Or is it not the --read-raw that is making the difference, but the > --read-subchan rw_raw that is required for some reason with CD+G. I've also been experimenting with CD+G lately. I've written some tools that take the toc/bin generated by cdrdao and encode the tracks to MP3+G files. (See http://www.kibosh.org/cdgtools/ for more details). As I understand it, the choice of rw or rw_raw depends on what modes your CD drive supports. In my case, my drive doesn't support rw mode (deinterleaved RW subchannel mode), so I can only use rw_raw (raw interleaved RW subchannel mode). It may be that your drive only supports rw_raw mode, hence your mixed results from rw mode. That said, I'm surprised that you get any graphics at all if the drive doesn't support rw mode. Are you getting the odd glitch or quite serious flaws in the graphics? I haven't looked into the --read-raw option, but I can tell you I don't use it here. Have you tried rw mode together with --read-raw to establish which option is the important one? I'd be interested to hear the results of that. FYI, I use the following command line: cdrdao read-cd --driver generic-mmc-raw --device /dev/cdroms/cdrom0 --read-subchan rw_raw mycd.toc Cheers, Kelvin. |
From: Bill M. <mo...@ha...> - 2005-03-31 18:57:06
|
The disclaimer is I know next to nothing about CD+G other than my kids are trashing their CD+Gs and I want to make a backup. And I know also little about the inner secrets of CDs in general. Then there's my shell scripting skills.... With that clear, I'm able to make a backup CDR of a CD+G using the following. Is this the recommended way? #!/bin/sh if [ -z "$1" ]; then echo "Usage: $0 <discname>" exit 0 fi cdrdao read-cd \ --read-raw \ --read-subchan rw_raw \ --device /dev/cdr \ --datafile "$1.bin" \ "$1.toc" || exit 0 echo "Burn use: cdrdao write $1.toc" Here's my question: I tried just using cdrdao read-cd --read-subchan rw foo.toc but the resulting CD+G I burned was not playable -- it kind of worked but the graphics didn't always work and the audio buzzed. I'm trying to understand why I need to do the --read-raw and --read-subchan rw_raw. If I understand correctly, --read-raw says to bypass the error correction done by the drive -- so any errors in the read are then transferred to the cdr on the write operation. Is that correct? I would think I would want the error correction. Or is it not the --read-raw that is making the difference, but the --read-subchan rw_raw that is required for some reason with CD+G. Thanks, -- Bill Moseley mo...@ha... |
From: Svend S. <sso...@gm...> - 2005-03-19 01:25:07
|
I have noticed that if the first track has a pregap, it is added to the TOC file as SILENCE. As an example: // Track 1 // pregap as SILENCE TRACK AUDIO TWO_CHANNEL_AUDIO SILENCE 00:00:32 FILE "data.wav" 0 01:31:08 START 00:00:32 <snip> // Track 8 // pregap as FILE index TRACK AUDIO TWO_CHANNEL_AUDIO FILE "data.wav" 24:22:45 05:08:28 START 00:00:10 Is this due to a restrition on the CD format (where the first track's pregap must be silence). Is the audio data that is in this pregap generated on the fly as zeros when reading (so it does not take up space)? I am curious, because when EAC generates a CUE file for this same disc, it does not use the equivalent PREGAP (generate silent pregap) keyword. The 32 frame pregap is read as index 0 and 1 in the file: FILE "data.wav" WAVE TRACK 01 AUDIO INDEX 00 00:00:00 INDEX 01 00:00:32 -- Svend |
From: Kelvin L. <ke...@us...> - 2005-03-12 02:12:33
|
Hi, I'm trying to rip the raw subchannel data from a CD+G disk to a file, but the subchannel data in the bin file doesn't seem to be correct. Does anyone know if the bin file should be arranged as follows: [2352b Audio] [96b Subch] [2352b Audio] [96b Subch] ... I'm ripping using: cdrdao read-cd --driver generic-mmc --device /dev/cdrom --read-subchan rw cdg.toc I've written a script to parse data.bin, seeking past every 2352 bytes and then storing the next 96 bytes to an output file. Unfortunately this does not get me the real subchannel data, although some values are correct. I'm comparing the data against a rip of the same CD using a Windows CDG ripper (also using the same CD drive). Some of the bytes are correct (every 8th byte is the same as the Windows rip), but the rest of the bytes are either incorrect or wildly scattered. It looks like for every 96 byte block, bytes 0, 8, 16 etc are in the correct place, but bytes 1, 9 and 17 etc are at 67, 75 and 83 etc. i.e. a lot of the byte values found in any 96 byte block of the Windows rip can be found somewhere nearby in the cdrdao rip but it's not a simple byte-reordering thing as the bytes seem to be scattered right throughout the 96 byte block, and not all byte values in the Windows rip are present in the cdrdao rip. I haven't seen anything in the MMC READ CD command structure that would result in subchannel data like this, so I'm wondering if this is down to the READ CD command returning bum data or if the subchannel data is not stored in a 96 byte block in cdrdao bin files. Many thanks, Kelvin. |
From: Giuseppe C. <co...@lu...> - 2005-02-14 13:48:29
|
On Fri, Feb 11, 2005 at 11:34:13PM +1300, Chris Dodunski wrote: > Relevant section of README: > > HP CD-Writer+ 75XX, HP CD-Writer+ 8100, SONY CRX100, HP CD-Writer+ 8200 > The firmware restricts the possible disk types in multi session > mode (DAO only) to one of the following: > > o Pure audio CD. > o CD-EXTRA where the 1st session contains only audio tracks and the > 2nd session contains 1 data track. > > Further restrictions: > > o The length of the 1st track's pre-gap is restricted to a certain > amount. > o Cue sheets with ISRC codes are rejected of the COPY flag is set. > This might be fixed in future versions. > > I think the error message output by cdrdao wasn't intended for the > layman (repeated below). What I can say, is that I was not recording > multi session, so my interpretation of the above is that those > constraints should have had no bearing. You can try a multisession with --force. > May be a red herring, but when performing a 'cdrdao --scanbus', cdrdao > reported back that my CD recorder is addressed "ATAPI:0,0,0", whereas > I've always used SCSI 2,0,0 with cdrecord. Seems that cdrdao identified > the correct drive though, as I ruined two blank disks in attempted > writes. ... This may be the problem. The 2,0,0 hints an ide-scsi device, while ATAPI: is alternate transport for 2.4 kernels. If cdrecord works with ide-scsi you should also try ide-scsi for cdrdao. If you have a 2.6 kernel you should get better luck with the ATA: transport. -- Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net DOS - Defective Operating System IBM - I Blame Microsoft BASIC - Bill's Attempt to Seize Industry Control WINDOWS - Will Install Needless Data On Whole System MICROSOFT - Most Intelligent Customers Realize Our Software Only Fools Teenagers |
From: Chris D. <Chr...@cl...> - 2005-02-11 10:34:03
|
Relevant section of README: HP CD-Writer+ 75XX, HP CD-Writer+ 8100, SONY CRX100, HP CD-Writer+ 8200 The firmware restricts the possible disk types in multi session mode (DAO only) to one of the following: o Pure audio CD. o CD-EXTRA where the 1st session contains only audio tracks and the 2nd session contains 1 data track. Further restrictions: o The length of the 1st track's pre-gap is restricted to a certain amount. o Cue sheets with ISRC codes are rejected of the COPY flag is set. This might be fixed in future versions. I think the error message output by cdrdao wasn't intended for the layman (repeated below). What I can say, is that I was not recording multi session, so my interpretation of the above is that those constraints should have had no bearing. May be a red herring, but when performing a 'cdrdao --scanbus', cdrdao reported back that my CD recorder is addressed "ATAPI:0,0,0", whereas I've always used SCSI 2,0,0 with cdrecord. Seems that cdrdao identified the correct drive though, as I ruined two blank disks in attempted writes. I've also pasted below a copy of the cd.toc file I manually created, in case there is a problem with it. Seems fine when compared against the example toc-files. **cd.toc file** TRACK AUDIO FILE "Peter_Gabriel_-_Big_Time.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Digging_In_The_Dirt.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Games_Without_Frontiers.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_In_Your_Eyes.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_&_Kate_Bush_-_Don't_Give_Up.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Red_Rain.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Salsbury_Hill.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Shock_The_Monkey.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Sledgehammer.wav" 0 TRACK AUDIO FILE "Peter_Gabriel_-_Steam.wav" 0 **Error output by cdrdao** saxon:/mnt/ultra3/Music/wav # cdrdao write --device ATAPI:0,0,0 --speed 2 --eject cd.toc Cdrdao version 1.1.9 - (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.8' ATAPI:0,0,0: HP CD-Writer+ 8100 Rev: 1.0g Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0010) Burning entire 79 mins disc. Starting write at speed 2... Pausing 10 seconds - hit CTRL-C to abort. Process can be aborted with QUIT signal (usually CTRL-\). Executing power calibration... Power calibration successful. Writing track 01 (mode AUDIO/AUDIO )... /usr/local/bin/cdrdao: Input/output error. : scsi sendcmd: no error CDB: 2A 00 00 00 01 15 00 00 17 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 12 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 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 30.484s timeout 180s ERROR: Write data failed. ERROR: Writing failed - buffer under run? ERROR: Writing failed. On Thu, 2005-02-10 at 10:21, Giuseppe Corbelli wrote: > On Wed, Feb 09, 2005 at 08:00:40PM +1300, Chris Dodunski wrote: > > I run Sun JDS Linux. Wishing to burn CD-Audio in DAO mode (I had been > > using cdrecord to burn CD-Audio in TAO mode) I downloaded the cdrdao > > source. Configuration, compilation, and installation went smoothly - > > great start! Unfortunately, the first burning didn't. I've pasted the > > output below. > ... > Pleas read the README file and see if the notes regarding the 8100 are > meaningful to your case. |
From: Giuseppe C. <co...@lu...> - 2005-02-11 07:32:08
|
On Wed, Feb 09, 2005 at 08:00:40PM +1300, Chris Dodunski wrote: > I run Sun JDS Linux. Wishing to burn CD-Audio in DAO mode (I had been > using cdrecord to burn CD-Audio in TAO mode) I downloaded the cdrdao > source. Configuration, compilation, and installation went smoothly - > great start! Unfortunately, the first burning didn't. I've pasted the > output below. ... Pleas read the README file and see if the notes regarding the 8100 are meaningful to your case. -- Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net -<! Any sufficiently advanced bug is indistinguishable from a feature. !>- Rich Kulawiec |
From: Hans-Peter J. <hp...@ur...> - 2005-02-10 23:10:16
|
On Thursday 10 February 2005 04:24, Chris Dodunski wrote: > chris@saxon:~> su > Password: > saxon:/home/chris # cdrdao > bash: cdrdao: command not found /usr/local/bin seems not in $PATH for root.. Also mentioning uname -a would be a good start.. hp |
From: Chris D. <Chr...@cl...> - 2005-02-10 22:23:56
|
<airy-voice> <echo-effect> Hellooo... is anyone out tharrr? </echo-effect> </airy-voice> Re. my earlier email about cdrdao failing to burn CD-Audio on my HP CD-Writer+ 8100. cdrecord works fine, but doesn't do DAO. Thanks, Chris. |
From: Chris D. <Chr...@cl...> - 2005-02-10 02:52:50
|
Hi there, I downloaded the latest CDRDAO source, configured ('./configure') and compiled it ('make') as user=chris, and then installed it ('make install') as root. Strange, but I can now only run cdrdao as user=chris... chris@saxon:~> cdrdao Cdrdao version 1.1.9 - (C) Andreas Mueller <an...@da...> SCSI interface library - (C) Joerg Schilling Paranoia DAE library - (C) Monty [etc...] chris@saxon:~> su Password: saxon:/home/chris # cdrdao bash: cdrdao: command not found saxon:/home/chris # ls -l /usr/local/bin/cdrdao -rwxr-xr-x 1 root root 3665588 2005-02-10 16:15 /usr/local/bin/cdrdao Binary permissions seem fine. What have I missed? Chris. |