Discussion of Automated CD Loaders

[bhoar]

Re: Discussion of Automated CD Loaders

Eli - At the current ebay prices, I haven't been able to justify adding one to my collection, so I don't have a Max unit here (just the Composer XL/Pro units).

I did, however, download the RoboPrint v1.3 utility (1.3 is for Composer-Max, 2.0 is for ADL-Max) and used Portmon to find that it seeks the robot by sending "_SV" and "_MOVE:S" on the serial port (not sure of the speed yet). This indicates to me that the command set for the Max is probably different from the Composer XL/Pro units (though it seems to share a common heritage, as "SV" is shared).

I suspect you're the only present (or technically...future) owner of one on the forum (so far), so you might be the one experimenting with the RoboPrint/Filemon combination (and later, hyperterminal) to document the command set.

-brendan

[CBQ]

Re: Discussion of Automated CD Loaders

Spoon listed experimental support for the Rimage DTP. I think those came in two different models. One model had a SCSI interface and the other model was Firewire (with a serial port maybe?).

Is the experimental support for both models or just one?

Also curious about multiple robots connected to one system. I have seen bhoar's youtube video and it is amazing. Kudos brendan.

Are there any limitations on multiple robots connected to one computer? Can I connect two USB robots, and one SCSI robot, and two Firewire robots to the same computer?

Thanks in advance for any help/guidance,
CBQ

[bhoar]

Re: Discussion of Automated CD Loaders

Spoon listed experimental support for the Rimage DTP. I think those came in two different models. One model had a SCSI interface and the other model was Firewire (with a serial port maybe?).

Is the experimental support for both models or just one?

Also curious about multiple robots connected to one system. I have seen bhoar's youtube video and it is amazing. Kudos brendan.

Are there any limitations on multiple robots connected to one computer? Can I connect two USB robots, and one SCSI robot, and two Firewire robots to the same computer?

Re: DTP serial units - I support only the serial-connected (w/ firewire) ones for now. And even then, prepare to be disappointed. From my testing, the pickers on DTP units cannot handle much variance in hub-type and thickness. After five or so audio CDs, the two DTP units I tested almost invariably got stuck trying to pick because by that point the top two CDs in the input stack had somewhat "complementary" hub styles that the picker fingers can't grab between. I think the DTP units were engineered for the hub-type of blank CD-Rs in the late 90s...and are just not a great tool for random audio CD picking. It's possible the units I tested were defective or badly adjusted?

Re: DTP SCSI units. I might end up try to support for them via the debug connector on the robot controller board. Maybe. Not sure how well that will work out, though. But really, as above, I currently doubt they're useful for CD ripping.

Re: multiple robots

There's no multiple device limitation in spoon's batch ripper. You associate each drive with the right device and provide the correct command line options in the batch config (if necessary - e.g. for serial-based ones you'd need to provide the com port(s)).

There are some limitations related to the devices, however, and those relate to the manufacturer's drivers, firmware, etc.

1. Sony Changers (firewire using a somewhat broken scsi changer interface) - I seem to recall hearing about issues with addressing multiple units in windows, so you might be limited to one of those at a time (due to a bug in the changer device firmware - I suspect that under some circumstances, it thinks it should talk to the drive inside the next changer device instead of the one inside it's own). This might be remedied by not chaining them and, instead, putting them on separate firewire buses.

2. Minicubis/Baxter/DupliQ/Pico units (proprietary USB driver) - last I heard, they too were limited to one unit per system, due to driver issues. a future device driver revision from datatronics might remedy this. Note that the datatronics driver documentation seems to show support for multiple units, I suspect they just haven't properly implemented it.

3. Serial-connected changers (mf-digital, discmakers, mediatechnics, amtren, etc.) - at least two devices, probably more. The serial library I use only allows two open devices at a time. However, each serial port is in use for only a short while. I'd need to experiment more to see if there's going to be a problem with more than 2 units.

On the plus side, I doubt there'd be a problem using several manual load drives, a baxter, a sony changer and two serial robots all at once.

Caveat: It's all experimental, no guarantees. e.g. my drivers still don't do the right thing at the end of a batch at the moment.

-brendan

[CBQ]

Re: Discussion of Automated CD Loaders

Re: DTP serial units - I support only the serial-connected (w/ firewire) ones for now. And even then, prepare to be disappointed. From my testing, the pickers on DTP units cannot handle much variance in hub-type and thickness. After five or so audio CDs, the two DTP units I tested almost invariably got stuck trying to pick because by that point the top two CDs in the input stack had somewhat "complementary" hub styles that the picker fingers can't grab between. I think the DTP units were engineered for the hub-type of blank CD-Rs in the late 90s...and are just not a great tool for random audio CD picking. It's possible the units I tested were defective or badly adjusted?

Re: DTP SCSI units. I might end up try to support for them via the debug connector on the robot controller board. Maybe. Not sure how well that will work out, though. But really, as above, I currently doubt they're useful for CD ripping.

Re: multiple robots

There's no multiple device limitation in spoon's batch ripper. You associate each drive with the right device and provide the correct command line options in the batch config (if necessary - e.g. for serial-based ones you'd need to provide the com port(s)).

There are some limitations related to the devices, however, and those relate to the manufacturer's drivers, firmware, etc.

1. Sony Changers (firewire using a somewhat broken scsi changer interface) - I seem to recall hearing about issues with addressing multiple units in windows, so you might be limited to one of those at a time (due to a bug in the changer device firmware - I suspect that under some circumstances, it thinks it should talk to the drive inside the next changer device instead of the one inside it's own). This might be remedied by not chaining them and, instead, putting them on separate firewire buses.

2. Minicubis/Baxter/DupliQ/Pico units (proprietary USB driver) - last I heard, they too were limited to one unit per system, due to driver issues. a future device driver revision from datatronics might remedy this. Note that the datatronics driver documentation seems to show support for multiple units, I suspect they just haven't properly implemented it.

3. Serial-connected changers (mf-digital, discmakers, mediatechnics, amtren, etc.) - at least two devices, probably more. The serial library I use only allows two open devices at a time. However, each serial port is in use for only a short while. I'd need to experiment more to see if there's going to be a problem with more than 2 units.

On the plus side, I doubt there'd be a problem using several manual load drives, a baxter, a sony changer and two serial robots all at once.

Caveat: It's all experimental, no guarantees. e.g. my drivers still don't do the right thing at the end of a batch at the moment.

-brendan

Well this stinks. I just purchased a used Rimage DTP 4000. And it is the SCSI model. I guess I am doubly screwed. It has a worthless/fickle picker and the SCSI interface is unsupported. :(

Do either you or Spoon need a SCSI Rimage DTP 4000 to experiment with?

Brendan, I have read your wiki and the majority of the threads here, but I am new to cd ripping so please bear with me. Please tell me if my understanding is correct.

There are two primary interfaces when ripping with robotics.
1. The data interface for the music/rip
2. The control interface for the robotics and drive

Currently, if I understand you correctly, only firewire and serial are supported for the robotics control interface? No USB or SCSI support for the robotics?

As for the data interface, on your wiki your write -
"USB limitations on ATA/ATAPI command support, including examples where you would likely run into problems.
USB (mis)handling of unusual calls (e.g. for secure ripping)
USB (and firewire) problems with secure CD ripping/damaged discs."

I am assuming you are referring to the data interface. But now that I read it again, perhaps I am wrong. Perhaps you are referring to the control interface via USB???

I had really hoped to do secure ripping with a robotic setup. Is this not possible?

CBQ

[bhoar]

Re: Discussion of Automated CD Loaders

Well this stinks. I just purchased a used Rimage DTP 4000. And it is the SCSI model. I guess I am doubly screwed. It has a worthless/fickle picker and the SCSI interface is unsupported. :(

Don't feel too bad. I've got three of the SCSI DTP-4000s and three of the SCSI DTP-1000s. :(

On the SCSI-only models, if you can hack together your own RS-232 serial cable and connect it to the four pin test connector on the control board, you can try using something like the following and see if it works "well enough":

	Suggestion 9: RImage DTP-800/DTP-1000/DTP-4000 Older SCSI using debug port serial connection (double check speed) - UNTESTED
	
	Pre-Batch.exe 	--drive=G --comport=COM2 --comspeed=19200 --close --command=MU --bindresetall --sleep=2
	Load.exe		--drive=G --comport=COM2 --comspeed=19200 --close --command=CR --command=OI  --command=MD  --command=R  --command=MU --open --command=MD  --command=P  --command=MU --close --sleep=10
	Unload.exe		--drive=G --comport=COM2 --comspeed=19200 --open --command=CR --command=CI  --command=MD  --command=R  --command=MU --close --command=MD  --command=P  --command=MU
	Reject.exe		--drive=G --comport=COM2 --comspeed=19200 --open --command=CR --command=MD  --command=R  --command=MU --close  --command=OR --command=MD  --command=P  --command=MU --command=CR
	Post-Batch.exe	--drive=G --comport=COM2 --comspeed=19200 --close --command=MU

Do either you or Spoon need a SCSI Rimage DTP 4000 to experiment with?

I'm good.

Brendan, I have read your wiki and the majority of the threads here, but I am new to cd ripping so please bear with me. Please tell me if my understanding is correct.

There are two primary interfaces when ripping with robotics.
1. The data interface for the music/rip
2. The control interface for the robotics and drive

Currently, if I understand you correctly, only firewire and serial are supported for the robotics control interface? No USB or SCSI support for the robotics?

The DTP series came in two flavors: the older SCSI models and the newer firewire+serial models. The older SCSI models used SCSI for both the data (drive) interface as well as the control (robot) interface over a single cable. The newest DTP units used a combination of firewire for the data (ATAPI drives with firewire bridgeboards) and serial for the control (robot) (two cables).

Note that the robot control board inside the unit always had both a SCSI and serial connector. Unfortunately, only the later revisions that used serial for the command interface had a "robust" control language available via serial.

USB was never used on any of the DTP models (neither drive or robot).

As for the data interface, on your wiki your write -
"USB limitations on ATA/ATAPI command support, including examples where you would likely run into problems.
USB (mis)handling of unusual calls (e.g. for secure ripping)
USB (and firewire) problems with secure CD ripping/damaged discs."

I am assuming you are referring to the data interface. But now that I read it again, perhaps I am wrong. Perhaps you are referring to the control interface via USB???

I'm talking about the data (drive) interface. USB to ATAPI bridge chipsets are notoriously bad when it comes to secure ripping. Firewire to ATAPI bridge chipsets are less bad.

I had really hoped to do secure ripping with a robotic setup. Is this not possible?

It sure is. Using a firewire to ATAPI bridge is probably the best bet.

-brendan

[CBQ]

Re: Discussion of Automated CD Loaders

Thank you Brendan. I appreciate you taking the time to share your knowledge and experience.

CBQ

[bhoar]

Re: Discussion of Automated CD Loaders

Spoon,

Eli has been interested in having the batch ripper support more than just a binary (accepted/rejected) output decision via unload/reject.

I can foresee ways that I could handle that directly in the ULCLI for certain loaders. e.g., if the disc's metadata, accuraterip and secure "status" information is passed via flags, I've got some ideas on how to use that information for rip result specific filing of discs in some of the robotic loaders that allow for explicit stack addressing.

e.g., I'd like to see something like one of the following three approaches implemented:

Idea #1:
--metadatafound=true/false	true if match was found and used
--accurateripfound=true/false	true if disc was found in accuraterip
  --accuratelyripped=true/false	true if all tracks were AR verified
  --securelyripped=true/false	true if all tracks were AR verified *or* if none were, all were securely ripped.
				alternately to deal with a result where it's Ok if 8 of 10 were AR and 2 were secure...
				true if all tracks were either AR verified *or* were securely ripped.
Idea #2:
--metadatafound=true/false
--accurateripfound=true/false
  --accurateripstatus=all/some/none
  --secureripstatus=all/some/none

Idea #3:
--metadatafound=true/false
--accurateripfound=true/false
  --totaltracks=#
  --accuratetracks=#
  --securetracks=#

-brendan

[bhoar]

Re: Discussion of Automated CD Loaders

I'd like to see something like one of the following three approaches implemented...

Or, if you have a better idea, let us know.

-brendan

[Spoon]

Re: Discussion of Automated CD Loaders

I will have to add to the wishlist for R2 of Batch Ripper, that section of the code has been frozen for full release (in a couple of weeks).

[bhoar]

Re: Discussion of Automated CD Loaders

I will have to add to the wishlist for R2 of Batch Ripper, that section of the code has been frozen for full release (in a couple of weeks).

Ok, I understand. If you want to get together to reexamine (here or via email) at a later time, just let me know.

I'll continue on my ulcli coding concentrating on the areas of more sane pre-batch and post-batch behavior, plus better device error handling.

-brendan

[EliC]

Re: Discussion of Automated CD Loaders

Brendan,

Just wondering if you have any status updates on ulcli 1.0?

[bhoar]

Re: Discussion of Automated CD Loaders

Brendan,

Just wondering if you have any status updates on ulcli 1.0?

Getting there, up to internal release v0.92.

In general work has been progressing, but I've done no coding work in the last eight or nine days for several reasons. Some of them are general day to day stuff (work and family obligations), but others are related to prepping my home office for heavy duty testing of the ULCLI with large capacity robots. In other words, things that need to be done in order for code testing before release.

-brendan.

[dastrix]

Re: Discussion of Automated CD Loaders

Hi Guys

I am looking to do large scale ripping with some software just like this, in terms of change/auto loader support which hardware device would be best for use here? Assuming I use the batch ripper software

Thanks
kris

[bhoar]

Re: Discussion of Automated CD Loaders

An update on robotics...

At the moment I have three cd/dvd robots sitting on my desk right now, performing exercises of the the ULCLI scripts all called by one instance of the batch ripper, testing the new ULCLI features and the scripts that implement them. All three robots (A discmakers micro ultra, a kodak kiosk unit and a Primera Composer Pro) use different command sets, yet are working under one instance of the batch ripper...

I feel a bit like Zorg, heh: "...look at all these little things, so busy now..."

(referring to this scene: http://youtube.com/watch?v=krcNIWPkNzA )

I should probably watch what I eat tonight.

Off to the treadmill and, later, BSG!

-brendan

[bhoar]

Re: Discussion of Automated CD Loaders

I am looking to do large scale ripping with some software just like this, in terms of change/auto loader support which hardware device would be best for use here? Assuming I use the batch ripper software

kris,

Sorry, I missed your post last month.

I think for large scale ripping, the contemporary MF-Digital and Mediatechnics 250 to 900 disc robots (see their sites) work very well. For reliable secure ripping, it may be necessary to change the connectivity arrangements from their typical method of firewire to SATA or IDE (which may interfere with the primary purpose of the robot).

Note that they both do sell their robots not just as duplicators but also with third party software (from ripfactory, GD3 and one other source) that can also be used for ripping. I'd call them up and find out their current hardware specs and package prices.

All,

I've been testing the dbpa batch ripper with several of the Mediatechnics multi-drive robots and the driver I worked on is now rock solid.

If anyone out there would like to test a pre-release of the second revision of the mf-digital or mediatechnics drivers, please drop me a PM (or email me brendandothoar@gmailDOTcom replacing "dot" with a period symbol) and let me know which hardware you have of the three listed on this page:

http://hyperdiscs.pbwiki.com/Hardware%20--%20Mediatechnics

If your hardware is under another brand name, but looks like one of those, please feel free to contact me about that as well.

-brendan