dBpoweramp Batch Ripper: Discussions

[kevinoconnor]

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.

[Spoon]

Batch Ripper Entes Alpha Stage

See the first message of this thread to download.

[bhoar]

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

[bhoar]

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

[Spoon]

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]

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

[bhoar]

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

-brendan

[Spoon]

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

[bhoar]

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

[hagak]

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]

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]

You are correct, the Nakamichi drives show up as seperate LUNs and the software would require knowledge of this setup to work. Which is why I asked if they would work with this ripper .

The script I wrote in perl used cdparanoia to access the drives. I basically coded the script to sequential handle each drive and defining in code how many that was. Then just ran five instances of this script in parralel. Worked ok but I think the machine I was using (old slow machine) had issues doing that much work at once and would get resource conflicts. Course those conflicts could be a timing issue when switching CDs.

[bhoar]

"Combined Speed x73"

Oh yeah, that's what I'm talking about.

(Two 52x drives, burst mode, clean discs.)

-brendan

[RipTheWorld]

I also run a Bulk Ripping service and have 600 Disc Autoloaders and 300 Disc Auto Loaders from Mediatechnics and MF Digital as well as a whole load of machines setup to do manually loaded rips.

I have a whole heap of ideas that I would like to see integrated into software such as this. It is good to see a software supplier asking the people who will actually make use of it on their ideas.

I would be more than happy to discuss some of their ideas and would obviously love to get on the Beta list.

Feel free to PM me and ask any questions.

[bhoar]

As far as I am aware, you're on the "beta list" already: the alpha is a public alpha! You can already test the alpha using non-automated drive towers or the single-drive minicubis/baxter units.

So far, the alpha is not so good at handling running out of discs (think: Energizer Bunny). But if that's the worst problem I've encountered in my (< 20 disc) testing...

Spoon's interface to the autoloaders doesn't yet have external support to handle the serial-controlled ones, but he did provide a simple (and robust) way of interfacing with loaders when he created the config screen and interface for the minicubis/baxter. So, if you can write some pretty simple code (e.g. VB or if you're lazy like me, AutoIT), here's how you would do it:

1. Develop your own load.exe, unload.exe, reject.exe, pre-batch.exe and post-batch.exe executables. I use a single executable, renamed five times.

2. Duplicate one of the baxter subdirs and rename it as appropriate. Spoon's code looks for some contents here in order to allow the config app to give you access to all five command lines so do this even if you are copying over files you think aren't necessary.

3. Replace the five exes with your own.

4. In the batch ripper configuration app, modify the command line invocations when configuring each drive.

Before going into what I've done personally, I'd like to hear more from spoon on the direction of the device support.

-brendan