dBpoweramp Batch Ripper: Discussions

[sredmyer]

Re: Observations/Issues

I see from the setup information that the default command line for a load is: --changer="0" --driveid="0".

Did you set up each command line correctly?
e.g.
E: has Four lines with: --changer="0" --driveid="0"
F: has Four lines with: --changer="0" --driveid="1"
G: has Four lines with: --changer="1" --driveid="0"
H: has Four lines with: --changer="1" --driveid="1"

Yep that is exactly how it looks. Also remember that each drive ripps perfectly when used individually via CD Ripper.

If so, it looks like spoon is probably passing the right information to the drivers, but the powerfile (which he does not have to test with, I think), isn't interpeting as expected. Either that, or there's a driver bug.

Again works ok in CD Ripper so I suspect that the commands are correct.

Perhaps the folks in the xl1b thread on the avsforum might be interested in making a more featureful driver?

That is infact where I got turned on to this device in the first place. There is indeed a fairly powerful driver which provides command line control of virtually all features. It is supported by a user there (on AVSForum) using the name MediaDog. He has also written a GUI if anyone is interested. It is called gui-057x.exe just search the forum you'll find several posts pointing to how to download it.

I was actually thinking that I might be able to write some VB code to automate the commands exposed by that driver. The problem I have is how then do I get Batch Ripper to call my app(s)?

Thanks,
Steve

[bhoar]

Re: Observations/Issues

I do not think (though I admit to being completely ignorant as to coding) using both drives in a single powerfile should be to difficult. The only complexity involved is keeping track of what slots have already been ripped and this requirement is there regardless of number of drives used.

You have to keep in mind that the five executables called for the five commands have to share state information amongst themselves via external means - that information is not kept in the batch ripper proper. The batch ripper has no concept of hardware other than the five things it can ask the driver to do.

The changer commands keep track of state either via temporary files or the registry, I think.

So for more complex behaviors where the operator would need to tell the driver to not do the default action, there'd need to be a way, outside the batch ripper, to interface with the driver.

For the serial based robots, I use a couple of messagebox dialogs to ask things like the equivalent of "start where we are now, or start at the beginning?" for multistack robots.

A changer state dialog would have to be something like "start at disc # xxx?" where xxx was where the changer last stopped, but it would need to be editable. Getting more complex than that would be problematic, I think.

As for allowing the use of two Powerfiles I would think that since the system already knows that the drive is part of a media changer (via the configuration) it should just be a matter of sending the load, reject, unload, etc. commands to both (or even all four) drives when appropriate.

Technically it sends the commands "for both drives" not "to both drives".

Remember, on scsi/firewire buses, drives, changers and hosts are all peers. The host asks the drive to spin down (and then unclamp if necessary), then it asks the changer to get the disc (and as part of that last step the changer may ask the drive to eject or unclamp before it pulls the disc itself).

I see from the setup information that the default command line for a load is: --changer="0" --driveid="0".

Did you set up each command line correctly?
e.g.
E: has Four lines with: --changer="0" --driveid="0"
F: has Four lines with: --changer="0" --driveid="1"
G: has Four lines with: --changer="1" --driveid="0"
H: has Four lines with: --changer="1" --driveid="1"

If so, it looks like spoon is probably passing the right information to the drivers, but the powerfile (which he does not have to test with, I think), isn't interpeting as expected. Either that, or there's a driver bug.

Also, did you also try changer "2", "3", etc. just in case the device manager ended up giving the device an unusual changer numbers (e.g. if you used more than one firewire port, it may be confused)? Or drive "1" and "2" instead of "0" and "1"?

I suspect you are correct though, it does seem as though these devices were included more as an after thought as opposed to a designed inclusion. I say this becuase of the minimal support (no way to control which slots to rip from)

Partially right. I look at the drivers more as initial proof of concepts with support for the basic requirements - the batch ripper itself knows nothing about automation hardware. On the flip-side, the method spoon uses *is* open and extendable. If manufacturers or users want a device supported, they can just wire it up (software wise), no problem. No changes needed in the batch ripper.

Any thoughts on some back door methods (replacing some of the control exes) to accomplish what I need. I am fairly knowledgable in writting VB apps.

Some thoughts:

In the batch ripper model there isn't really consideration of more than one drive per automation method. If your device has more than one drive, this adds to the driver complexity. That is, the actions (unload load and reject) are independent calls to an external executable. If more than one drive is pending an action, or there are some rules about which disc needs to go where, you have to code that yourself.

A simple example: for robots, I have to lock the robot to the drive (via a temporary lock file that all exes check) before the end of an unload so that requests pending for other drives are put on hold until the load request for the drive I just unloaded is handled. Otherwise, I would require throughput decreasing tray closes after each unload. Similarly reject piles are often underneath all of the drive trays and you must be sure that all other trays are closed before the reject occurs.

Note that this is a lock that is in place *in between* the handoff of a robot from one executable to another...but it doesn't prevent the executables from being run. The just sit and wait until the locks clear. And that makes the batch ripper sit and wait until the exes exit. Luckily, the batch ripper is threaded...

Such locking has to be enforced on the driver side...the batch ripper puts up pending calls to executables whenever it is ready for the automation device to take an action. I can foresee similar consideration needing to be done for some changer devices, but probably not all.

Take a look at the post here < http://forum.dbpoweramp.com/showpost...85&postcount=8 > for information on the calling convention that the batch ripper used for executables for automation devices. For the robot drivers, I use the user's temporary directory (via autoit's @TempDir run-time directive) to store a great deal of the "state" information needed for my executables to know when to do things and when to wait and the state of affairs with the robots.

Spoon has been very helpful in making my drivers work with the batch ripper including a couple of code changes (e.g. added some support for hidden command line options in the DefaultCmdLine.txt). I don't want you to think that he's not interested in device support. He's just pressed for time and can't go too far out on a branch with complex features in the drivers he did create himself.

Perhaps the folks in the xl1b thread on the avsforum might be interested in making a more featureful driver?

-brendan

[sredmyer]

Re: Observations/Issues

Are you sure about that? I think once I own it I can do with it as I please...we are not dealing with copyright issues here. We are just dealing with data and I do not think there are any "fair use" type issues. Again I think the reason Spoon did not include this functionality is because AMG would not allow him to include their service if he did.

Can anybody shed some authoritative light on this? Do we own the meta-data once we have paid for the lookup? Can we then use it as we see fit to include, as I believe another poster once suggested, creating our own database and then resorting to the premium paid databases only when ours does not contain the data we need.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

You may be right, but I cannot answer that question. Though Spoon is clearly NOT allowed to build caching into the software per his contract.

[sredmyer]

Re: Observations/Issues

I agree with you here. You have purchased it for that disc from that customer.

Are you sure about that? I think once I own it I can do with it as I please...we are not dealing with copyright issues here. We are just dealing with data and I do not think there are any "fair use" type issues. Again I think the reason Spoon did not include this functionality is because AMG would not allow him to include their service if he did.

[sredmyer]

Re: Observations/Issues

I cannot speak for spoon on this, but I suspect the reason is that it wasn't coded to do that (similar to the reason that only one drive is used...) is: Spoon probably only had one xl1b unit to experiment with and wrote a driver with that use in mind.

Of course, perhaps there are undocumented means of telling the command line client to use a different unit? Spoon?

[An aside: my area of expertise is on the serial controlled robots, so I can't say it perfectly applies to the changer requirements, but...the drivers for the robots were designed with the idea of using more than one robot and multiple drives at a time...considerations for those requirements went into the drivers from day one. It does increase the complexity a bit, esp. multi-drive use, and esp. if you're concerned about balancing automation throughput with mechanism/media/operator safety issues.]

-brendan

I do not think (though I admit to being completely ignorant as to coding) using both drives in a single powerfile should be to difficult. The only complexity involved is keeping track of what slots have already been ripped and this requirement is there regardless of number of drives used.

As for allowing the use of two Powerfiles I would think that since the system already knows that the drive is part of a media changer (via the configuration) it should just be a matter of sending the load, reject, unload, etc. commands to both (or even all four) drives when appropriate.

I suspect you are correct though, it does seem as though these devices were included more as an after thought as opposed to a designed inclusion. I say this becuase of the minimal support (no way to control which slots to rip from)

Any thoughts on some back door methods (replacing some of the control exes) to accomplish what I need. I am fairly knowledgable in writting VB apps.

Thanks,
Steve

[EliC]

Re: Observations/Issues

As others have mentioned, I have already purchased the data when I unsuccessfuly attempt the first rip. Why should I have to buy it again when I re-rip it in another drive?

I agree with you here. You have purchased it for that disc from that customer. You should not have to re-pay for it. But if another customer were to send the same disc to you, you have to re-buy the meta-data.

Along the same lines, I am trying to get spoon to implement tools to weed out doubles. You don't want the batch ripper to lookup and charge for meta-data for discs that you have already ripped in that collection.

[bhoar]

Re: Observations/Issues

So do you have any ideas on why the Batch Ripper will not control two Powerfiles at once?

I cannot speak for spoon on this, but I suspect the reason is that it wasn't coded to do that (similar to the reason that only one drive is used...) is: Spoon probably only had one xl1b unit to experiment with and wrote a driver with that use in mind.

Of course, perhaps there are undocumented means of telling the command line client to use a different unit? Spoon?

[An aside: my area of expertise is on the serial controlled robots, so I can't say it perfectly applies to the changer requirements, but...the drivers for the robots were designed with the idea of using more than one robot and multiple drives at a time...considerations for those requirements went into the drivers from day one. It does increase the complexity a bit, esp. multi-drive use, and esp. if you're concerned about balancing automation throughput with mechanism/media/operator safety issues.]

-brendan

[sredmyer]

Re: Observations/Issues

Please see this thread for my proposed solution:
http://forum.dbpoweramp.com/showthread.php?t=17248

Yes I have read that thread...some very good ideas there.

For someone doing commercial ripping, as you plan to do, legally you will have to delete any rips, partial rips, and meta-data after the completion of a rip job.

While I know I can not (and do not plan to) keep any rip (music) files, I did not realize the same thing applied to the meta data. As others have mentioned, I have already purchased the data when I unsuccessfuly attempt the first rip. Why should I have to buy it again when I re-rip it in another drive? As I understand it this is just a licensing issue with the data providers...they would not provide a license to Spoon if he were to include code to archive the data pulled from them. Once pulled though I think the data belongs to me and I can use it however I choose...Is that not an acurate statement?

So do you have any ideas on why the Batch Ripper will not control two Powerfiles at once?

Thanks
Steve

[EliC]

Re: Observations/Issues

2. I have seen where others on this forum have requested that there be someway to cache meta data lookups so that we are not paying to lookup data multiple times for problem CDs which require multiple rips. I would like to jump on this bandwagon. The value of this features seems obvious during testing (where the same CD may be ripped many times).

Please see this thread for my proposed solution:
http://forum.dbpoweramp.com/showthread.php?t=17248

For someone doing commercial ripping, as you plan to do, legally you will have to delete any rips, partial rips, and meta-data after the completion of a rip job. However, the above proposal fixes the current problem, and builds a foundation for a number of features that I believe could be very exciting.

For example, a problematic track is ripped in one drive, problematic sectors are marked, but the drive is unable to read those sectors. These sectors could be marked on a temporary rip file and when the disc is placed in a different drive, it attempts to read those sectors and re-build an accurate rip, taking advantage of the different abilities of different drives.

[sredmyer]

Re: Observations/Issues

Please note that in the post above where I state that the second Powerfile unit just continually attempts to mount a disc, it is worth mentioning that the unit itself does not appear to be getting any commands. That is there is absolutely nothing going on (no sounds from the machine). This means that it is not an alignment issue or other such issue which would have the machine physically attempt to load the disc into the drive but either not succeeding (alignment issue) or the drive never recognizing that it has a disc. The commands are aparently just not getting to the unit.

[sredmyer]

Observations/Issues

So here is my situation, I am looking at getting into the CD ripping business. For hardware, I have two Powerfile R200s and I am currently investigating a few software solutions. After a few weeks of software testing I have decided on the dbPowerAmp Batch Ripper for both its AccurateRip and Perfect Match features. So first let me say WOW!! What an incredible piece of software.

Now with the kudos out of the way let me move onto some observations and questions I have.

1. My Powerfile units have two drives each. It would be nice if the Batch Ripper could utilize both drives within a single Powerfile unit simultaneously. This would double the effective throughput of a setup using these Powerfile units. Spoon said (in an earlier post on the forum) that during development he only had one of the Sony changers (which are based on these Powerfile units but only have single drive) to use for testing. My question is, will support for utilizing both drives be added in a future release.

2. I have seen where others on this forum have requested that there be someway to cache meta data lookups so that we are not paying to lookup data multiple times for problem CDs which require multiple rips. I would like to jump on this bandwagon. The value of this features seems obvious during testing (where the same CD may be ripped many times).

3. I cannot get the software to manage both of the Powerfile units at once. This is a different issue than the one of utilizing both drives within a single Powerfile unit. I have setup and configured all four drives (two drives in two Powerfile units) and tested the functionality of each drive using the test features of the configuration utility. I have also successfully calculated the offset (for AccurateRip) and ripped a disc using CD Ripper (not Batch Ripper) in each of the four drives. However when I attempt to rip from both Powerfile units simultaneously, one unit mounts its CD and begins ripping as expected but the other unit always fails to mount the CD and just continues to try mounting (loading disc from slot into drive). Has anybody else been able to get two Powerfiles (or Sony changers) to work with this software?

Steve

FWIW, The two Powerfile units are not "daisy chain" connected but are both connected directly to the PC. I have a two port Firewire card and each unit is individually connected to one of the ports.

[Spoon]

Re: Two Batch Ripper requests

The SCSI specs say that a drive should be able to respond to a disc loaded request at any time, it is a failure of the drive firmware or the bridge.

an IMMED (immediate) bit of 0 requested. If the Logical Unit does not support Asynchronous Mode, the
command shall fail as an illegal request. If the Initiator requests Asynchronous Mode using a request that is
not queued or overlapped, the command shall fail as an illegal request.
..
This command shall not return CHECK CONDITION status to report a unit attention condition.

Immed 0 is not even a requirement.

[bhoar]

Re: Two Batch Ripper requests

Can you not put a delay in load.exe? but really the "No CD After Load" is a failure of the drive / connection because:

There is code before that section which asks the cd drive if there is a disc, the cd drive says yes and it move on to the section which reads the TOC and it fails, so the cd drive cannot report it has a disc but not allow the toc to be read...

I think this is the scenario: under certain circumstances (drive+bridge combination) after a Start Stop Unit command is received with the requisite LoEj=1 Start=1 and *another* command is received in too quick succession, the tray does retract but the spin up fails to occur, perhaps leaving the disc in a loaded, but not yet "recognized" state.

If the Load.exe returns control to the Batch Ripper with this situation above in place, it appears that the Batch Ripper's attempts to probe the drive fail to return what is expected.

The situation may arise randomly if windows sends out a command (status?) to the drive/bridge at the wrong moment. And I can definitely trigger the problem if I send more than one Start Stop Unit command back to back with the Immed bit set (interrupting the previous command) even if LoEj=1 and Start=1 on both of them. I am now avoiding this.

Perhaps the Batch Ripper can issue a Start Stop Unit Immed=0 LoEj=0 Start=1 request before looking for the disc? I may also add a command the the ULCLI to request a spinup as well, which I would execute before exiting but after releasing the robot to work on another drive (I'm trying to avoid waiting for spinup before servicing other drive requests on each drive bank).

The '\' request will have to go to r2, code is frozen for r1 (apart for bug fixes).

Ok.

-brendan

[Spoon]

Re: Two Batch Ripper requests

Can you not put a delay in load.exe? but really the "No CD After Load" is a failure of the drive / connection because:

There is code before that section which asks the cd drive if there is a disc, the cd drive says yes and it move on to the section which reads the TOC and it fails, so the cd drive cannot report it has a disc but not allow the toc to be read...

The '\' request will have to go to r2, code is frozen for r1 (apart for bug fixes).