Tweet
Hi Brendan & Spoon,
I have just tried your batch ripper for about 150 discs across 4 drives by inserting them manually (averaged 72 discs per hour). It works very well, I am impressed and I shall purchase the program soon*.
I have a question about robotic loaders and the method of controlling them in situations where the ejection of CD drives can impede the movement of the robot pick arm, such as a robot where the drives are stacked one on top of another. In this situation a scheduler is required so that a drive does not open its tray when it would impede the movement of the disc picker arm, queuing the request until safe to action it.
I see in the batch ripper help file that there are a number of .exe files called for the various operations. My question is what actually controls the ejection and loading of the drives?...
Ie: Does batch ripper finish a disc and then open the tray before calling unload.exe, and how does it [batch ripper] know when to close the tray again... by unload.exe returning from the command call? ... or does unload.exe and load.exe control the drive itself?
The reason I ask is that I am thinking of building my own robot (just for fun) and a stacked drive configuration is preferred design at the moment.
As an aside... I am also considering increasing the number of drives. I have seen discussions in other threads where recommendations for the number of drives is equal to the number of cores (perhaps one more to accommodative downtime when changing discs), however when I look at the load on my system it is running at around 9% CPU load whilst ripping 4 CDs to FLAC concurrently. I will always rip to FLAC, and will then post process to other formats when required using the batch converter (which is also excellent btw), so this probably accounts for the low CPU usage. Do your foresee any issues with increasing the number? 8, 12? (fast HDD can be assumed).
Thanks
-Tim
* I have a problem with no album art in batch ripper, though it works fine in the single cd ripper. Would be nice to resolve this. I'll discuss this in another thread over the weekend.
I have just tried your batch ripper for about 150 discs across 4 drives by inserting them manually (averaged 72 discs per hour). It works very well, I am impressed and I shall purchase the program soon*.
I have a question about robotic loaders and the method of controlling them in situations where the ejection of CD drives can impede the movement of the robot pick arm, such as a robot where the drives are stacked one on top of another. In this situation a scheduler is required so that a drive does not open its tray when it would impede the movement of the disc picker arm, queuing the request until safe to action it.
I see in the batch ripper help file that there are a number of .exe files called for the various operations. My question is what actually controls the ejection and loading of the drives?...
Ie: Does batch ripper finish a disc and then open the tray before calling unload.exe, and how does it [batch ripper] know when to close the tray again... by unload.exe returning from the command call? ... or does unload.exe and load.exe control the drive itself?
The reason I ask is that I am thinking of building my own robot (just for fun) and a stacked drive configuration is preferred design at the moment.
As an aside... I am also considering increasing the number of drives. I have seen discussions in other threads where recommendations for the number of drives is equal to the number of cores (perhaps one more to accommodative downtime when changing discs), however when I look at the load on my system it is running at around 9% CPU load whilst ripping 4 CDs to FLAC concurrently. I will always rip to FLAC, and will then post process to other formats when required using the batch converter (which is also excellent btw), so this probably accounts for the low CPU usage. Do your foresee any issues with increasing the number? 8, 12? (fast HDD can be assumed).
Thanks
-Tim
* I have a problem with no album art in batch ripper, though it works fine in the single cd ripper. Would be nice to resolve this. I'll discuss this in another thread over the weekend.
Comment