dBpoweramp Batch Ripper: Discussions

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Just recently discovered dbpoweramp and still in the trial period (most likely will be buying). anyhow I saw this was in testing and I have an old Nakamichi tower. It has 5 Nakamichi SCSI drives, each drive is a 5 disc changer. Basically on the SCSI it appears as 25 distinct devices. Would this device work well with the batch ripper? I tried to write my own using linux and some perl scripts however I seemed to run into resource conflicts a lot.

The drives are only 16x so the individual rip time would be slow but being able to load it up with 25 discs and let it run while I am out would be great.

Right, in windows, the drive for nakamichi 5-disc SCSI changers (not the IDE ones) show up as separate drive letters for each of the disc slots. So two drives would be 10 drive letters, even though there are only two lens/transport assemblies. They are not standard medium changer devices. IIRC, each drive letter shows up as a separate LUN on the scsi ID but it's been a while since I looked at that.

The way that the batch ripper currently works is to rip from each drive letter in parallel assuming there is no interdependence between the drive letters.

To properly support the nakamichis, the batch ripper would need to be able to group drives together and use only one drive letter at a time per drive group.

While it is technically easy to support, I think the bigger issue would be trying to fit it into the existing device support framework of dbpa. Would you auto-group the drive letters together or force the user to do that, etc.

-brendan

[hagak]

Re: dBpoweramp Batch Ripper: Discussions

Just recently discovered dbpoweramp and still in the trial period (most likely will be buying). anyhow I saw this was in testing and I have an old Nakamichi tower. It has 5 Nakamichi SCSI drives, each drive is a 5 disc changer. Basically on the SCSI it appears as 25 distinct devices. Would this device work well with the batch ripper? I tried to write my own using linux and some perl scripts however I seemed to run into resource conflicts a lot.

The drives are only 16x so the individual rip time would be slow but being able to load it up with 25 discs and let it run while I am out would be great.

[bhoar]

Re: dBpoweramp Batch Ripper

2 baxtors cannot be used on the same computer currently, datatronics say they are working on an updated sdk.

Ok, thanks.

So far, with your Manual/No spindle reload recommended settings, the new batch ripper really kicks butt.

And I mean it. This is "alpha" quality?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper

2 baxtors cannot be used on the same computer currently, datatronics say they are working on an updated sdk.

[bhoar]

Re: dBpoweramp Batch Ripper

Spoon - should I try using both of my baxter-type devices at once, or is multi-autoloader support not ready for testing?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper

Part of the setup for ripping in batch mode is to rip 1 disc before hand with cd ripper (to get accuraterip out of the way, etc, the help will document this).

Ok.

About ending early, set the end to Manual and switch off the change spindle option, then you should see no messages (for manual) or early ending.

Ah, I didn't realize the failed disc loads setting applied to manual drives - I'd set it to 5 figuring I didn't want the baxter to keep grabbing at an empty input bin. So, when this is active, it appears that an empty manual drive causes the failed disc loads counter to constantly increase (every second?) until it reaches end of batch after a disc or two has been ripped.

Should this setting apply only to autoloaders? Shouldn't it be set on an autoloader-by-autoloader basis?

Anyway, setting this to manual fixed the issue for the manual drives - no early end to batch, no need to press OK.

Testing now to see if there's a negative impact when using the baxter with 3 additional manual drives at the same time.

There will eventually be an option to abort a cd.

Ok.

About the minicubis lockup, I have seen one lock up the ery first call made to it (after a clean restart), the watchdog works very well.

Of course, why change what works?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper

Part of the setup for ripping in batch mode is to rip 1 disc before hand with cd ripper (to get accuraterip out of the way, etc, the help will document this).

About ending early, set the end to Manual and switch off the change spindle option, then you should see no messages (for manual) or early ending.

There will eventually be an option to abort a cd.

About the minicubis lockup, I have seen one lock up the ery first call made to it (after a clean restart), the watchdog works very well.

[bhoar]

Re: dBpoweramp Batch Ripper

More on robotic ripping:
==================

1. Mixing multi-drive ripping with robotic ripping (25 in the dupliq, 3 preloaded in the other three drives) also gave a bad result. I had the dupliq listed first, then the three plextors. The batch aborted before audio ripping began on any of the drives. I tried a couple of times, but it always aborted.

On parallel manual ripping:
==============

1. The multi-drive manual rip feature is welcome addition as well.

2. I tried manual rip with three of the plextors in the box, but forgot to set up accuraterip first. Oops - the batch ripper (or rather the cli rippers) asked me about setting up accuraterip with two of them, and I answered in the affirmative. The end result was that none were configured, but perhaps that was due to the discs. I'm retrying now after keydisc-positive non-batch configuration.

update: that seems to have worked.

It's probably best to prompt the user to pre-configure accuraterip with key discs before starting batches? Also, would be nice to be able to copy the accuraterip config from one drive to the other 3-8 drives (same make/model/firmware, of course) without having to perform the long cache/c2 tests on them, but I suppose we can all suffer *a little*.

3. It would be even nicer when asking for the next disc if it did not require that the user click OK and, instead, probed the drive on a regular basis to see tray position or what disc type has been inserted, if any (vs. the alternate workaround of relying on microsoft's AIN,AP,AR mess).

4. I seem to be able to very easily cause the batch to abort even if I am filling the drives with discs and clicking OK after insert. The "Ending Batch" endgame triggers and it stops ripping. I'm left wondering what I've done to upset it.

5. It would be nice if a manual disk eject was considered a reject instead of leaving the cdgrab.exe process running. After ~60 minutes trying to rip my badly scratched Fugazi Repeater CD, I would have liked to be able to tell it, nicely, to move on.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper

Three additionals:

1. The -watchdog flag in the configuration. Yeah, the datatronics DLL interface *loves* to lock up if you open the device multiple times, even if you properly close it first. It's sad this bug still exists.

I put together a command line client a while back and ran into the same issue. My solution was similar: since I was using a non-threaded language, I'd check the process list and if I was the only copy, fork another copy of the process to be a watchdog. The watchdog would kill non-watchdog processes that ran too long. My batch file would then continue running and assume the incorrect error code meant it should retry the command.

Most automation devs don't run into the problem because they integrate the DLL directly into their app (instead of having the DLL loaded by CLI executables) and therefore can keep the handle to the device, which means they only open it once per batch. However, for CLI support, which is built into your architecture, it'd probably be best to run a hidden process that keeps the device open during the entire batch. Have the CLIs use process-to-process communication to the hidden proxy app.

Not only does this avoid the potential watchdog delays inside the batch, but it also means that you're not always resetting the device between commands, which means slightly less wear and tear, and higher throughput.

Of course...a watchdog would still help in case the proxy app froze. But that will happy much less often if you only open the device once per batch.

2. End of batch - when you manually end a batch, it's probably a good idea to send the disc to the reject pile, not the accept pile.

3. It's a good thing there are only five or so "variants" of the baxter hardware, otherwise you're going to end up wasting all that disk space on copies of the identical dlls, defs and load/unload/etc. exe files.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper

Batch Ripper Entes Alpha Stage

See the first message of this thread to download.

[kevinoconnor]

Re: dBpoweramp Batch Ripper

Tagging will be updated with 2 new meta data providers, then we can be smart with meta data.

I would like to see the option to output an XML file containing EVERYTHING you know about the CD (ripping results, TOC, contents of every music data base hit etc). Where supported, it would also be nice to dump this XML data into a custom tag in the ripped file.

In my case, I plan to re-rip my collection into a lossless format (still haven't decided which) and collect all the CD data (TOC, tags etc) into a database. In the database, I can correct tags and add more data. Finally I would have a program or script that runs a database query and re-encodes the files to a target format (MP3 for my IPod, for example) populating the tag info from my database.

[Ichiro]

Re: dBpoweramp Batch Ripper

Hi,

I am very interested in beta testing your software.

I have a Primara BravoPro II.

Thanks!
Ichiro

[bhoar]

Re: dBpoweramp Batch Ripper

I assume we will be able to run multiple drives in series? I think that makes more sense for me from a cost effective point. Load up 8 drives and walk away for a reasonable period while ripping and encoding are occurring.

That certainly would be a nice feature as well, queuing of drives. It would be similar to how Riptastic! supported the Nakamichi 5-disc SCSI changers (by default, the scsi version of the changer shows up with one drive letter per CD slot in Windows).

-brendan

[EliC]

Re: dBpoweramp Batch Ripper

I assume we will be able to run multiple drives in series? I think that makes more sense for me from a cost effective point. Load up 8 drives and walk away for a reasonable period while ripping and encoding are occurring.

Hopefully, we will be able to select the meta-data for all the discs at the beginning of the task so it can run un-interrupted without further user interface required.

[bhoar]

Re: dBpoweramp Batch Ripper

can I run multiple drives (4-8) with something like a 500mhz celeron without encoding?

I'd say that wouldn't be an issue if you were a) using burst mode and b) you had a fast I/O system, though you might still get bogged down a bit. For (ultra)secure mode, however,spoon would have to comment on the CPU usage there, as it can be a lot higher.

IIRC, 1x burst ripping would be at ~150kB/s, and 40x burst ripping would therefore be ~6MB/s. 4 drives x6MB/s = 24MB/s, which contemporary hard drives should be able to handle, though divided across 4 separate streams, a single drive is likely to lose throughput due to thrashing.

If you plan to use secure mode across multiple drives, I'd definitely be looking at a budget dual core CPU even if you weren't planning to encode on that machine.

-brendan