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: Andreas M. <an...@da...> - 2001-08-17 18:23:13
|
Manuel Clos wrote: > > Hi all, > > I have found a little bug in cdrdao: > > when using this command line: > > cdrdao copy --simulate --paranoia-mode 0 --device 0,0,0 --driver > generic-mmc:0x0 --source-device 0,0,0 --source-driver generic-mmc:0x0 > > cdrdao will tell that the medium is not empty not appendable. > > But this one: (cutting --source-device 0,0,0) > > cdrdao copy --simulate --paranoia-mode 0 --device 0,0,0 --driver > generic-mmc:0x0 --source-driver generic-mmc:0x0 > > will work as expected. > > Cdrdao should note that if the --on-the-fly switch is not given and the > source and target devices are the same, should not test the medium. I thought that I've done that - strange. I'll check it. Btw, I'll be on vacation for the next 4 days. Regards, Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Manuel C. <ll...@ja...> - 2001-08-17 17:31:08
|
Hi all, No luck with fixed timeouts. As Andreas said the idle timeout is the best one. We will see if we a thread dedicated to playing in a future release. Also, Is there a way to tell cdrdao to make 3 copies of a cd? instead of repeating the burning process three times? This is a simple yet cool feature :) See you. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-17 01:35:47
|
Hi all, I have found a little bug in cdrdao: when using this command line: cdrdao copy --simulate --paranoia-mode 0 --device 0,0,0 --driver generic-mmc:0x0 --source-device 0,0,0 --source-driver generic-mmc:0x0 cdrdao will tell that the medium is not empty not appendable. But this one: (cutting --source-device 0,0,0) cdrdao copy --simulate --paranoia-mode 0 --device 0,0,0 --driver generic-mmc:0x0 --source-driver generic-mmc:0x0 will work as expected. Cdrdao should note that if the --on-the-fly switch is not given and the source and target devices are the same, should not test the medium. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-16 23:11:20
|
Hi all, In the way of redesigning the cd duplication interface, I want to add "simulatio and burn", this is, burn if the simulation is successful. We can implement this in gcdmaster, say watching at the cdrdao return code and then start the burning process. But perhaps cdrdao can handle this directly. Anyway we will need this for cdrecord. doing a "cdrdao simulate" I get the following option: -n - no pause before writing what do this means? Thanks. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-16 23:02:46
|
Andreas Mueller wrote: >>Is there a standard way to get/set the reading speed of a scsi cdrom? I >>would like to be able to do so. Also for writing, I know we have already >>discussed this, but I have a clean solution now :). >> > > For SCSI-2/mmc compatible drives we such a SCSI command that returns > the maximum read and write speed. But there's nothing in common for > the older drive models. > > What is the clean solution? Quote from a 3/5/00 mail: > For most but not for all recorder models. Also think of the situation > that a user selected multiple recorders with different maximum speeds. > I guess the maximal maximum speed would be appropriate in that case. Yes, really and argument to not do it [:)] . --- Basically, letting the user to select 20x when the burner is only 8x makes no sense. If we can't get the max recording speed then selecting the speed will work like now, but with a warning telling that we don't know what is the max speed for the burner (with the *don't show again* option, of course ;) ). Well, we now know the max speed, so let's say we have two burners, 4x and 8x. The user will have two options, use the max speed (max checkbutton) or use the max common speed if manually selected. Basically you can do this now, but you can also try to make both burn at 8x, which is wrong and will probably result in a coaster. If we know the max speed we can prevent the last. Selection of say 2x and 6x won't be available. I can't think of a situation. Anyway, you can't do this now :). Well, not a very clean solution :p, but will help users with "modern" recorders. Can we force the reading speed? Reading at a lower speed means less system load and better responsiveness. How do I get the max reading and writing speed? should we implement a method in DeviceList? Can cdrdao already set the reading speed? Can we specify multiple targets to cdrdao? or do we spawn different processes and the system cache does the work? I was also thinking of maintaining a feature list of cdroms/recorders, just like the current one but with more info, like firmware version (some recorders can write CDTEXT info after a firmware upgrade), ... but well, let's implement basic features first. Hope this is the last time I mess the duplicate cd dialog :D -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Andreas M. <an...@da...> - 2001-08-16 19:28:04
|
Manuel Clos wrote: > > :) Ok, You're right. We can leave perfect audio playing for a future > release. Anyway I would like to not block editing, as the average user > can't understand why he/she can't reorder tracks while playing (you can > do this with most mp3 players). So at least this blocking should not be > present the the (future) track list child. This is also quiet difficult to implement. The play function accesses the Toc and the subsequent Track objects. If you change the Toc object while other functions are accessing it (e.g. iterating over the tracks) we can easily come into situations which lead to errors and crashes. We would have to develop mechanisms that prevent that and I'm again not sure if this is worth the effort with the same arguments as in my last mail. If we popup the right message when a user tries to modify the project while playing I don't think it will be so hard to understand what's going on. > I'm currently working on making the CD duplication a project, this way > you don't need a project or a chooser open. And this way you have access > to menus (configuration, new project, open...). > > In the way doing this, I'm redesigning the interface a bit. The idea is > to put the most used/simple features in front and the less in a dialog. > I will also want to hide the "bus, id and lun" info in the CList, not > remove them, but make it an options in the (still to be created) > preferences dialog and default to hide them. People that like this info > will be able to show it. Ok, good idea. We should also hide the 'Add Device' box in a separate dialog and place the 'Add' button right beside 'Rescan' and 'Delete' as you already suggested. > Is there a standard way to get/set the reading speed of a scsi cdrom? I > would like to be able to do so. Also for writing, I know we have already > discussed this, but I have a clean solution now :). For SCSI-2/mmc compatible drives we such a SCSI command that returns the maximum read and write speed. But there's nothing in common for the older drive models. What is the clean solution? Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-16 19:27:58
|
Manuel Clos wrote: > In order to prevent an on the fly copy with the same device, I will look > for this situation. So I will check if the user has selected the same > device in both Reader and Writer DeviceList. > > if ((targetData->bus == sourceData->bus) > && (targetData->id == sourceData->id) > && (targetData->lun == sourceData->lun)) > > While this is correct for me, I don't know if you can do an on the fly > copy with different luns on a same device :-?, I think you can only have > access to one lun at a time, but not sure, so then this should be: > > if ((targetData->bus == sourceData->bus) > && (targetData->id == sourceData->id)) > > Anyone can asure me that the last is the correct one? I'm not sure about the luns. Disk-changer drives usually provide a lun for each slot and for them we surely have no parallel access. I've never seen disk-changer writers up to now, though. I would say the latter test is safer and shouldn't hurt the majority of the users. We can change the code later whenever we make the experience that our assumption was wrong. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Manuel C. <ll...@ja...> - 2001-08-16 17:38:28
|
Andreas Mueller wrote: > No, it works that way: The idle signal calls the audio play callback > which sends a chunk of audio data to the soundcard. While the callback > is active the application is blocked. When the callback returns > pending events are processed and after that the callback is started > again by the idle signal. That's why I've chosen a small amount of > audio data that is processed by the callback. After we've increased that > to remove the audio jumping while scanning the application was less > responsive. > > I think the right solution would be using threads but that would > compilcate the program and I'm not sure if this worth the effort > compared the results. Do we really have to provide perfect playing > while editing the project. My original intention for the playback > was to verify the edits you make to the project and not to entertain > you during the work :) :) Ok, You're right. We can leave perfect audio playing for a future release. Anyway I would like to not block editing, as the average user can't understand why he/she can't reorder tracks while playing (you can do this with most mp3 players). So at least this blocking should not be present the the (future) track list child. I'm currently working on making the CD duplication a project, this way you don't need a project or a chooser open. And this way you have access to menus (configuration, new project, open...). In the way doing this, I'm redesigning the interface a bit. The idea is to put the most used/simple features in front and the less in a dialog. I will also want to hide the "bus, id and lun" info in the CList, not remove them, but make it an options in the (still to be created) preferences dialog and default to hide them. People that like this info will be able to show it. Is there a standard way to get/set the reading speed of a scsi cdrom? I would like to be able to do so. Also for writing, I know we have already discussed this, but I have a clean solution now :). See you. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-16 17:28:13
|
Hi all, In order to prevent an on the fly copy with the same device, I will look for this situation. So I will check if the user has selected the same device in both Reader and Writer DeviceList. if ((targetData->bus == sourceData->bus) && (targetData->id == sourceData->id) && (targetData->lun == sourceData->lun)) While this is correct for me, I don't know if you can do an on the fly copy with different luns on a same device :-?, I think you can only have access to one lun at a time, but not sure, so then this should be: if ((targetData->bus == sourceData->bus) && (targetData->id == sourceData->id)) Anyone can asure me that the last is the correct one? Thanks. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Andreas M. <an...@da...> - 2001-08-15 18:15:18
|
Manuel Clos wrote: > > Andreas Mueller wrote: > >>Why don't we use a fixed timeout for playing instead of the idle timeout ? > > > > It would be almost impossible to find the correct timeout value. If it > > is too small the timout will come before the playing function has > > returned. It it is too big the playing will be jumpy. I think the > > idle signal is the right choice. What advantage would you expect from > > the fixed timout signal? > > Do you mean the idle signal comes just when there is no buffer no play? No, it works that way: The idle signal calls the audio play callback which sends a chunk of audio data to the soundcard. While the callback is active the application is blocked. When the callback returns pending events are processed and after that the callback is started again by the idle signal. That's why I've chosen a small amount of audio data that is processed by the callback. After we've increased that to remove the audio jumping while scanning the application was less responsive. I think the right solution would be using threads but that would compilcate the program and I'm not sure if this worth the effort compared the results. Do we really have to provide perfect playing while editing the project. My original intention for the playback was to verify the edits you make to the project and not to entertain you during the work :) > I will play with timeouts a bit. I don't fully understand how the audio > is played, so I will thank any explanation. Perhaps creating a thread > for playing is a solution... Ok try that, maybe I'm missing something and this will really give a good solution. Regards, Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-15 18:15:16
|
Manuel Clos wrote: > > Andreas Mueller wrote: > > Manuel Clos wrote: > > > >>as configure is a generated file, shouldn't be on CVS, should it? > >> > > > > I'm not sure about that. The generated configure files are also > > contained in the released archives - and I think that's good because > > I do not expect that everyone has the autoconf tools installed which > > are only required if someone is doing active software development. > > Release files should be maintained in CVS so that I'd say we should > > keep it there. > > > > Or should we release cdrdao/gcdmaster without the generated > > configure files in future? > > > > To rebuild the configure scripts we'll just have to run 'autoconf'. > > > > Andreas > > > > I think that configure is not put in CVS, as it is a generated file. > People wanting to compile from CVS should use a autogen.sh script or > something as Giuseppe said. So this people should have autoconf anyway. > When distributing the tarball just run the autogen.sh to people gets the > configure script in the tarball, this way the configure will be up to > date (I think this was the problem in Mandrake 8.0). > > I will do some script as Giuseppe suggested. Ok, I agree. Currently we will just have to run 'autoconf' so that the script will be very trivial. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-15 18:15:15
|
thomas graichen wrote: > > i just asked this on the cdrdao list some time ago but did > not get any response so far ... do you have any idea what > might be the reason of that problem or anything i may try > to pin down the problem? i'm really interested in getting > this going Please try to use one of the following options: 1. --driver generic-mmc:0x1 2. --driver generic-mmc:0x3 3. --driver generic-mmc:0x20 4. --driver generic-mmc:0x20 --fast-toc The difference between these driver options are explained in the README. Please let me know which option works for you so that I can update the driver table (include the drive identification strings as reported by cdrdao). Regards, Andreas > > a lot of thanks in advance > > t > > ---------- Forwarded Message ---------- > Subject: [Cdrdao-devel] cdrdao problem on ppc > Date: Wed, 4 Jul 2001 10:28:46 +0200 > From: thomas graichen <tg...@sp...> > To: cdr...@li... > > i have a problem running cdrdao on a blueberry imac (ppc - > running mandrake 8.0 ppc beta btw.) - whenever i try to read an > audio cd i get: > > cdrdao: Input/output error. : scsi sendcmd: retryable error > CDB: BE 00 00 00 01 2E 00 00 0D F8 01 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 0A 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.001s timeout 20s > cdrdao: Input/output error. : scsi sendcmd: retryable error > CDB: BE 00 00 00 01 3B 00 00 0D F8 01 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 0A 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.000s timeout 20s > > endless - i tried several versions of cdrdao .13 ... .15, even > some binaries for verious ppc distribs - it's always the same ... > also i tried various 2.4.x kernels (from the ppc trees) and > always ended at this error ... on the other hand i can grab the > audio cd just fine with cdda2wav, cdparanoia oder grip - so my > question is: due you have any idea what is going wrong here? > or anything else to test? > > t > > p.s.: ah - btw. the drive is an matsushita ide cdrom drive > running with ide-scsi emulation > > -- > thomas graichen <tg...@sp...> ... perfection is reached, not > when there is no longer anything to add, but when there is no > longer anything to take away. --- antoine de saint-exupery > > _______________________________________________ > Cdrdao-devel mailing list > Cdr...@li... > http://lists.sourceforge.net/lists/listinfo/cdrdao-devel > > ------------------------------------------------------- > > -- > thomas graichen <tg...@sp...> ... perfection is reached, not > when there is no longer anything to add, but when there is no > longer anything to take away. --- antoine de saint-exupery -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-15 18:15:10
|
thomas graichen wrote: > > ok - i got a bit further on this (for "this" see the appended > old posting about the old problem all this started with): it > works fine with plextor:0x00200000 for reading the toc (but > results in errors then starting to read the data) and it gives me > an "can't read ISRC" error then using generic-mmc:0x00200020 > while reading the toc but i this mode it can read the data fine > > i tried all the other options - none helped me further - so the > problem now would be for me to hack together a driver which uses > the plextor driver for reading the toc and the generic-mmc for > the audio data but after reading the code for some time i'm not > really shure which function to change ... my idea was to make it > similar to the ToshibaReader.cc - take the Plextor settings and > overwrite the functions for reading the data or the other way > around using the GenericMMC and overwriting the read-toc realted > stuff or as third (and i think best) option: add an option to the > generic-mmc driver to use plextor scanning I think we can easily fix the ISRC related error message in the generic-mmc driver by adding a short delay before it tries to read the ISRC code. This might be required for some drives because the binary search mechanism (seleted with driver option 0x20) use a Play Audio command to play a single audio sector so that it can read out the sub-channel data for that sector. When issuing the Play Audio command the drive return success status before the command is finished so that it might happen that a new command is issued before the old command has finished. This might also be the reason for the other error messages you get. Can you send them btw? So, I would suggest to fix the binary search mode in generic-mmc driver. The first shot would be to place a 'mSleep' call right after the play command. It should sleep roughly the same time as it takes to play an audio sector (1/75 s). My problem is that I'm currently lacking free time so could you try to make the modifications and test them? Regards, Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: thomas g. <tg...@sp...> - 2001-08-09 07:50:24
|
ok - i got a bit further on this (for "this" see the appended old posting about the old problem all this started with): it works fine with plextor:0x00200000 for reading the toc (but results in errors then starting to read the data) and it gives me an "can't read ISRC" error then using generic-mmc:0x00200020 while reading the toc but i this mode it can read the data fine i tried all the other options - none helped me further - so the problem now would be for me to hack together a driver which uses the plextor driver for reading the toc and the generic-mmc for the audio data but after reading the code for some time i'm not really shure which function to change ... my idea was to make it similar to the ToshibaReader.cc - take the Plextor settings and overwrite the functions for reading the data or the other way around using the GenericMMC and overwriting the read-toc realted stuff or as third (and i think best) option: add an option to the generic-mmc driver to use plextor scanning can anyone here knowing the cdrdao structure better please tell me which way would be the best and which of the functions i have to change to make this work (i'm not really shure by now how they exactly interact)? another question: is there anything else i may try to get rid of those "can't read ISRC" errors - aside from those errors popping up (that are scsi subsystem generated errors - so it looks to me like a wrong scsi command is sent to the device for reading the ISRC's which it does not know about ... but all that are only speculations) everything seems to be fine: it reads everything and creates a valid looking toc file (even including pregaps) a lot of thanks in advance t On Wednesday 04 July 2001 10:28, thomas graichen wrote: > i have a problem running cdrdao on a blueberry imac (ppc - > running mandrake 8.0 ppc beta btw.) - whenever i try to read an > audio cd i get: > > cdrdao: Input/output error. : scsi sendcmd: retryable error > CDB: BE 00 00 00 01 2E 00 00 0D F8 01 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 0A 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.001s timeout 20s > cdrdao: Input/output error. : scsi sendcmd: retryable error > CDB: BE 00 00 00 01 3B 00 00 0D F8 01 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 0A 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.000s timeout 20s > > endless - i tried several versions of cdrdao .13 ... .15, even > some binaries for verious ppc distribs - it's always the same > ... also i tried various 2.4.x kernels (from the ppc trees) and > always ended at this error ... on the other hand i can grab the > audio cd just fine with cdda2wav, cdparanoia oder grip - so my > question is: due you have any idea what is going wrong here? or > anything else to test? > > t > > p.s.: ah - btw. the drive is an matsushita ide cdrom drive > running with ide-scsi emulation -- thomas graichen <tg...@sp...> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery |
From: Manuel C. <ll...@ja...> - 2001-08-08 00:56:00
|
Andreas Mueller wrote: > Manuel Clos wrote: > Sounds good. I think there are a lot of convienience functions we could > easily add... Ok, what ones? >>Is there any date for the next release? > Not yet, as a wrote in my last mail I'm currently out of time. Ok, I will do a redesign of the copy CD interface, and at the time, make gcdmaster not close if reading/burning a CD :) > The progressive showing of the wave form data during scanning should > be easy. We'll just have to send appropriate guiUpdate() calls > whenever the scanning function has worked on a piece of data. > To avoid scanning of data tracks I'll have to rewrite the scanning > function to work on a track basis. Currently it uses the reading > functions of the Toc object. I can do that in 2 weeks. Ok, here is my idea. The scanning will be made on a per track basis. Then, you don't need to block all the project, just the track you're scanning, so you can add new tracks to scan to a queue. I don't know if inserting a track before the one we are scanning is a trouble, but you can always have the scanning data on a per file basis, this is, insertions in the middle of a track won't be possible, but adding tracks/files before or after the track we are scanning will have no problem. I was thinking on a queue of files/tracks to scan and do this scan while be work. As you need to block a track/file, then you can abort the scanning if this track/file is to be deleted. Or queue it again in some other situation. Also, if you can make the scanning data to be associated to a track, in some way that you can reorder tracks while the scanning is being done (and not restart it). I would like to implement a "list view" of the Audio CD Project, because now is too difficult (or impossible) to change the track order, add a simple 2 seconds silence at the end of a track, ... And as every track can be composed of various files, we can use a tree view, something like: CD + |---Track One (data1.wav) <- track one is the name in CD TEXT |--+Track two <- track tow is the name in CD TEXT |--data2.wav |--date3.wav |--silence of 1.5 seconds The silence at the end should not be there but at the rigth (in the interface I have in mind), only silences that are between files or that are inside a wav file will be in the tree. This way, when the tree is collapsed, we get a simple list of tracks that can be easily reordered. And if you expand you have the contents of the track, on an object view, where there is pretty simple to increment a silence or just remove it completely, ... So, can we get something so that tracks are reordered without any problem while we scan them? (including .bin images) Also, the scanning data cache in .scanning_data files will be great! I was thinking of having such files in ~/.gcdmaster, so if you want to add "/music/data1.wav" then we look for ~/.gcdmaster/music/data1.wav, compare the date (and perhaps some other data like file size) and if it valid we get some speed up. A tipical audio CD is 12-20 songs, so the speed up can be x12 - x20 :) -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-08 00:34:07
|
Andreas Mueller wrote: > Manuel Clos wrote: > >>as configure is a generated file, shouldn't be on CVS, should it? >> > > I'm not sure about that. The generated configure files are also > contained in the released archives - and I think that's good because > I do not expect that everyone has the autoconf tools installed which > are only required if someone is doing active software development. > Release files should be maintained in CVS so that I'd say we should > keep it there. > > Or should we release cdrdao/gcdmaster without the generated > configure files in future? > > To rebuild the configure scripts we'll just have to run 'autoconf'. > > Andreas > I think that configure is not put in CVS, as it is a generated file. People wanting to compile from CVS should use a autogen.sh script or something as Giuseppe said. So this people should have autoconf anyway. When distributing the tarball just run the autogen.sh to people gets the configure script in the tarball, this way the configure will be up to date (I think this was the problem in Mandrake 8.0). I will do some script as Giuseppe suggested. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-08 00:29:21
|
Andreas Mueller wrote: >>Why don't we use a fixed timeout for playing instead of the idle timeout ? > > It would be almost impossible to find the correct timeout value. If it > is too small the timout will come before the playing function has > returned. It it is too big the playing will be jumpy. I think the > idle signal is the right choice. What advantage would you expect from > the fixed timout signal? Do you mean the idle signal comes just when there is no buffer no play? The two problems are: The application response (menus, ...) slows down when playing. And try this: zoom an audio project, play and then move the bar to show a new part, as the app is working the idle signal does not come fast enough and the sound cuts. I will play with timeouts a bit. I don't fully understand how the audio is played, so I will thank any explanation. Perhaps creating a thread for playing is a solution... >>Also, why are we doing this?: >> >>(now this is in AudioCDProject::AudioCDProject) >> soundInterface_ = new SoundIF; >> playBuffer_ = new Sample[playBurst_]; >> soundInterface_ = NULL; >> >>we create a SoundIF and then we lost the reference... why? >> > > That's of course an error; probably an relict from some code changes. > You can remove the allocation at this place. Ok. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Manuel C. <ll...@ja...> - 2001-08-08 00:21:49
|
strobe anarkhos wrote: > How stable is the cdrdao image format? Is it likely to change? > > I'd like to make a converter to convert toast images to cdrdao images, but only if I can make a format which isn't going to change with every build. You should look at some .toc example files. Basically the .toc file defines the CD. When you dump a CD using cdrdao, it creates a big .bin file, that is a copy of the CD. So if you have this .bin raw data, build a valid toc and cdrdao will be happy. I don't think it will change, perhaps it will expand, but Andreas can tell you better about it all, when he gets a little free time :) See you. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
From: Andreas M. <an...@da...> - 2001-08-07 05:47:27
|
Manuel Clos wrote: > > I just commited the following changes: > > * added a "tools" toolbar, it contains select, zoom, zoom in, zoom out, > zoom sel and full view. > * added a zoomx2 method to AudioCDView to zoom without selections. > * created some new icons for the "tools" toolbar > * got some icons from eog > * select is now the default (was zoom) Great! > Next, I will also change the play button to a simple play | stop > toolbar. Work on the drag and drop problem (1 file at a time). Zoom out > with the third button in the wav view if zoom selected. and select a > full track if double clicking with the select tool, ... and so on... > > Any ideas wellcomed :) Sounds good. I think there are a lot of convienience functions we could easily add... > Is there any date for the next release? Not yet, as a wrote in my last mail I'm currently out of time. > Features I would like to see are progressive showing of the wave as it > is read and don't waste time scanning data tracks (not showing data > tracks in the wav view would be great also). The progressive showing of the wave form data during scanning should be easy. We'll just have to send appropriate guiUpdate() calls whenever the scanning function has worked on a piece of data. To avoid scanning of data tracks I'll have to rewrite the scanning function to work on a track basis. Currently it uses the reading functions of the Toc object. I can do that in 2 weeks. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-07 05:47:11
|
Manuel Clos wrote: > > The problem with adding multiple files is that the tocEdit object return > 0 when no modify is allowed: > > if (!modifyAllowed()) > return 0; > > This return code is also "success" when appending the track. This should > be changed, but why modify is not allowed? Should we add a > "addMultipleFiles"? I think no, because the problem is that if you do > this you still can't add another file while reading the first one. Can > we break this into pieces, this is, checking that we are modifying the > piece we are scanning, and if this happens then reread/reorder? > > Can Andreas give some explanation on how this works and in what order? The TocEdit object is set to read-only mode during scanning because the scan process accesses the Toc object while it does its job. If we would modify the Toc object during the scanning process it could lead to unexpected results including a crash. I think we should extend the existing appendFile/appendTrack functions to take a list of file names. The function will then first update the Toc object and then start the scanning process. If you want to append a file while the scanning process is active we might either give an appropriate message an let the user abort the scanning process or we let the function abort the scanning process and then restart it after the Toc object we modified. This would be a bit complicated but it should be possible to implement that. I'm currently completely out of time because of my job (Infineon is in trouble as you might have heard) and my nephew is currently visiting us who takes mostly all of my remaining spare time. I'll be more active again in two weeks. Regards, Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-07 05:47:05
|
strobe anarkhos wrote: > > At 4:01 PM -0400 8/4/01, Giuseppe Corbelli wrote: > >On Fri, 3 Aug 2001, strobe anarkhos wrote: > >> Hey, > >> I'm interested in porting cdrdao to Darwin but there aren't many > >>clues as to how exactly it works (looking at the 1.1.5 archive I > >>decompressed). There is some mention that it uses the same 'SCSI library' > >>as cdrecord, but to my knowledge that hasn't been ported either. Do I > >>need to have intimate knowledge of cdrecord before I can port cdrdao? > >Cdrdao's low level SCSI transport library is libscg, written by Joerg > >Schilling, and found in his cdrecord's package. From what I see in the > >latest version he met some problems in porting to Darwin. > >Porting libscg is the first step. You should read PORTING and > >README.macosX. Question regarding libscg are welcome on cdrecord-devel > >mailing list > >(http://lists.berlios.de/mailman/listinfo/cdrecord-developers) > > So if I port libscg everything else should work? (that list had a total of three messages in 3 months) > > Last I checked cdrecord was last ported to Rhapsody (Darwin 0.3) which has little relation to Darwin 1.x. You do not have to port libscg (which could be quiet difficult). Instead you could just write your own SCSI Interface implementation for your OS. The interface is defined in "dao/ScsiIf.h". Example non libscg implementations are found in "dao/ScsiIf-linux.cc" or "dao/ScsiIf-freebsd-cam.cc". If you're facing problems with the Posix threads you can also compile cdrdao without thread support (configure option). It will then use SYSV shared memory and fork a child process to implement the buffering. I could also implement another method to get shared memory if Darwin does not have SYSV IPC support. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-07 05:46:51
|
Manuel Clos wrote: > > as configure is a generated file, shouldn't be on CVS, should it? I'm not sure about that. The generated configure files are also contained in the released archives - and I think that's good because I do not expect that everyone has the autoconf tools installed which are only required if someone is doing active software development. Release files should be maintained in CVS so that I'd say we should keep it there. Or should we release cdrdao/gcdmaster without the generated configure files in future? To rebuild the configure scripts we'll just have to run 'autoconf'. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: Andreas M. <an...@da...> - 2001-08-07 05:46:38
|
Manuel Clos wrote: > > Here is what I just commited to CVS: > > * Changed the play/stop button to a "play | stop" toolbar, this prevents > the "playing again" problem when you hit the button twice to stop the > playing and it starts again... > * moved the play and playCallback funcs to AudioCDProject > * added a playStop func to audioCDView and AudioCDProject > * got some icons from tcd for the play toolbar > * AudioCDView is no more a friendly class of AudioCDChild (read: removed > bad hack) > * Added #define UPD_PLAY_STATUS 0x00000800 to guiUpdate.h > * now AudioCDView uses UPD_PLAY_STATUS to draw the cursor and update the > buttons, ... > > My idea is to create a new cursor for playing, and show the position in > the play toolbar. This way we can set the marker even while playing, set > selections, zoom, ... we just need to care of funcs that _change_ the > Toc object. > > Why don't we use a fixed timeout for playing instead of the idle timeout ? It would be almost impossible to find the correct timeout value. If it is too small the timout will come before the playing function has returned. It it is too big the playing will be jumpy. I think the idle signal is the right choice. What advantage would you expect from the fixed timout signal? > Also, why are we doing this?: > > (now this is in AudioCDProject::AudioCDProject) > soundInterface_ = new SoundIF; > playBuffer_ = new Sample[playBurst_]; > soundInterface_ = NULL; > > we create a SoundIF and then we lost the reference... why? That's of course an error; probably an relict from some code changes. You can remove the allocation at this place. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
From: strobe a. <ana...@ma...> - 2001-08-07 01:40:00
|
How stable is the cdrdao image format? Is it likely to change? I'd like to make a converter to convert toast images to cdrdao images, but only if I can make a format which isn't going to change with every build. |
From: strobe a. <ana...@ma...> - 2001-08-06 10:22:00
|
I'm not going to suggest anything will be released soon, but libscg has been= ported well enough to use cdrecord: [localhost:cdrecord/OBJ/powerpc-darwin-cc] anarkhos% ./cdrecord dev=3D0,4,0 = -checkdrive Cdrecord 1.10 (powerpc-apple-macosx1.3.7) Copyright (C) 1995-2001 J=96rg Sch= illing scsidev: '0,4,0' scsibus: 0 target: 4 lun: 0 Using libscg version 'schily-0.5' 0xE00002BC 0xE00002BC Device type : Removable CD-ROM Version : 2 Response Format: 2 Capabilities : SYNC LINKED CMDQUE Vendor_info : 'JVC ' Identifikation : 'R2626 ' Revision : '2.05' Device seems to be: Teac CD-R50S. 0xE00002BC 0xE00002BC 0xE00002BC 0xE00002BC 0xE00002E7 0xE00002BC Using driver for Teac CD-R50S, Teac CD-R55S, JVC XR-W2010, Pinnacle RCD-5020= (teac_cdr50). Driver flags : SWABAUDIO (I know this CD-R drive isn't adequate to run cdrdao. I have a Ricoh WR7083A= for that) |