dBpoweramp Batch Ripper: Discussions

[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.

[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 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

[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

[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.

[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

[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.

[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

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.

[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

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

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

Note that these commands aren't used at all by the CD Ripper. It has no concept of automation. It just talks to the drive.

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

As above.

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.

No, that's not a driver in the context of the batch ripper. It's a command line client, yes. But it does not fit the driver model of the batch ripper.

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)?

You must have missed my link to the post where spoon describes the calling convention four the five actions and command line options they should expect to be passed. I'll post it again: http://forum.dbpoweramp.com/showpost...85&postcount=8

That's all you need. If you write something that can be called that way, then you are golden.

-brendan

PS - if you want to see how the Medium Changer driver is called, I recommend installing Process Explorer, enabling the column that shows the entire command line and make it wide, enabling the start time column and then sorting by start time. You'll see the load.exe (etc.) process launched and can see exactly what command line options are passed. It should match what is specified in the link above.

[bhoar]

Some additional suggestions.

Spoon,

Eli and I were discussing some issues in dealing with his large collection. I think I can condense it down to two or three requests:

1. A "Reject discs already ripped Accurately (only for this batch name)" checkbox.

Enabling would cause the batch ripper to store the ARID of each disc at the end of the ripping process when ripped Accurately. It could then automatically reject CDs that have already been accurately ripped the next time they are encountered (before the metadata lookup).

The ARIDs would be stored locally and associated with the batch name (I assume this would be preferable for most users - unless batch names are not reusable). I suggest a sorted flat file for this read at start of batch and checkpointed every xx minutes during a batch (unless you already have a local database structure that is more appropriate). Keeping it per-batch allows a flat file to be an appropriate solution as it wouldn't cause problems with commercial operations except in rare cases.

2. A "Reject non-pressed discs (CD-Rs, etc.)" checkbox. It would-auto-reject CD-Rs, etc.

3. Perhaps a variant of #1 for Secure-no-warning rips.

-brendan

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

Spoon,

Is there any chance that you will be doing any more development on the support for the Powerfile devices? If so I have few requests.

1) Allow for the use of both drives in a single Powerfile unit.

2) Along with the use of both drives, if the mounting of disc could be sequential by slot position not slot number, the load time could be reduced to the absolute minimum.

3) And finally allow for the use of more than one Powerfile unit within the same batch.

If these features were implemented these inexpensive Powerfile devices could compete (on disc throughput) with the most expensive robots out there.

Thanks for an excellent product,
Steve

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

If you have Visual Studio 2005 I would be willing to share that driver for fixing.