dBpoweramp Batch Ripper: Discussions

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Spoon -

In the batch ripper, it might be useful to designate drives that have not yet been configured for accuraterip with an icon of some sort (both on the initial screen as well as during the ripping process). Just as a reminder to users that they need to stick around for a bit and respond to the dialogs that show up about configuring accuraterip.

OR, alternately, have cdgrab.exe automatically do it without operator intevention when called from the batch ripper.

Or both.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Output filenames are not available until meta data is read, so load.exe would never get it.

Ok, then either load.exe would have to pass a filename back to the batch ripper or the batch ripper would pass the filename to the unload.exe and/or reject.exe.

The specifics of the mechanism isn't too important at this point in time, I just wanted to add the idea to your radar.

[I am considering expanding the ULCLI to allow it to invoke an external command during processing (such as triggering a webcam snapshot between the disc load and tray close and/or between the tray open and disc unload). Perhaps useful in the batch ripping context as noted in my previous post, but definitely useful should the ULCLI ever be used in data ripping and/or forensics.]

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Output filenames are not available until meta data is read, so load.exe would never get it.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

The R13 thread on scanning support leads me to a batch ripper question (a feature request, I guess):

If one wanted to store a picture of the disc in the tray with the rip output, assuming a web cam were attached pointing down at the tray location in front of the drives: such a picture would a) need to be taken either during the load.exe or during both the unload.exe and reject.exe calls and b) would you consider passing a pathname value either to the exe's where the picture should be output or receiving such a pathname via the --passerrorsback= file?

Low priority, of course, but potentially useful for improving the workflow / assisting cleanup efforts when encountering unrecognized or mis-recognized discs.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Yes, even explorer will not know the disc has changed.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

It should not have any effect, then again I always have the option on in batch ripper to disable the AIN + autorun at a low level.

Oh - I thought the "Prevent auto-run on all drives" option only disabled Autorun. It disables AIN too?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

It should not have any effect, then again I always have the option on in batch ripper to disable the AIN + autorun at a low level.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

I would always turn off autorun, especially with the Sony Rootkits that are out there on audio cds.

Spoon - note that Auto-Insert Notification and Autorun are two separate things.
My question was on the former.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

I would always turn off autorun, especially with the Sony Rootkits that are out there on audio cds.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Q for spoon on the Windows Auto-Insert Notification (AIN) feature:

Does the enabled/disabled status of the Windows Auto-Insert Notification have any bearing at all on the batch ripper? e.g. more specifically...

1. Should it be enabled or disabled?
2. Will having it enabled impact performance of the batch ripper and if so, can disabling it potentially increase throughput?
3. Can AIN (even rarely) lead to disc-recognition timeouts in the batch ripper or the read errors in the cdgrab application?

-brendan

[Nonreality]

Re: dBpoweramp Batch Ripper: Discussions

A comment from the little guys.
Downloaded R13 and batch ripper. Installed. Started and loaded saved multi encoder profile. Started batch, loaded 2 internal drives (cd/dvd) 1 USB dvd and ripped and encoded to flac and mp3 on a firewire USB drive, 28 albums. Start up to batch run after install - 10 minutes. Problems 2 1-Operator got confused and loaded same cd twice, program corrected operator. 2 CD needed cleaned, program corrected operator.

Very awesome!

[daxb]

Re: dBpoweramp Batch Ripper: Discussions

Another note on logic within the interface. In the batch ripper, pressing the metadata button brings up a configuration window while in CD ripper it refreshes the metadata for the currently loaded disc. I would suggest an options button rather than a metadata button in batch ripper. It would be more intuitive between both programs.

As I said in a previous post somewhere on these forums, I am assuming that some of the options in the CD Ripper ought to be mirrored in the batch ripper. Even better, get rid of redundant options and only have batch ripper specific options in the batch ripper.

Keep up the great work!

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Two suggestions for the Batch Ripper Configuration interface...on the Configure drive subscreen, I'd like to see two changes:

1. Change the order from alphabetical to logical: Pre-Batch, Load, Unload, Reject, Post-Batch.

2. Add two additional buttons for open-tray and close-tray (or alternately one button for toggle-tray). It's useful, before going to the test subsubscreen, to make sure you're working with the right drive.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

No, it will be R2 before reject reasons are added.

Ok, that's fine for now. I believe/hope that the newly implemented ULCLI feature for unknown parameters (where any unknown --parameter=value string encountered on the command line gets stored as a variable with drive scope that can later be used for flow of control changes) will cope with a future "reject reasons" feature without requiring actual code updates to the ULCLI.

Adding to an existing batch is planned from the start, but is full of hidden software 'gotchas' so perahps R2.

Glad to hear that's on the todo list.

Disc load / unresponsiveness - all programs suffer this, even Nero (insert a blank DVD and watch Nero show (Unresponsive application in the title), it is the bad design of CD drivers and the system.

Sure, I do understand that certain Windows or even direct SPTI calls to optical drives can take a long time to respond.

However, if those calls were placed in their own separate thread then the delay doesn't have to hit other threads as long as the other threads are aware enough to not try to interact with the stuck thread or make calls that require the other thread's "stuck" call to finish.

Before these types of calls are made by the child thread, it should let the parent thread know that the child thread is about to be super-busy and it will therefore send a message to the parent when it is done and it shouldn't be queried in any way that might lock the parent until the child responds. e.g. perhaps the parent thread would then mark that drive as one in the GUI that shouldn't be have the drive status until the child thread is done.

It was just a bit frustrating to find the calls to the robotic handler (esp. pending unloads/rejects on a different drive) being delayed because a disc spinup/recognition or metadata check was taking a long time in an unrelated drive (or even on an unrelated robot!). It may have less impact in manual operation, of course, but these delays shave precious time off of the process during automated operation. In addition, I fear that my own drivers are going to get the "blame" for that.

Something to consider for future releases of the batch ripper, I suppose.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

1. Is there a flag you give (or can add) to rejects triggered by this rule to differentiate them from rejects flagged for other reasons?

No, it will be R2 before reject reasons are added.

Adding to an existing batch is planned from the start, but is full of hidden software 'gotchas' so perahps R2.

Disc load / unresponsiveness - all programs suffer this, even Nero (insert a blank DVD and watch Nero show (Unresponsive application in the title), it is the bad design of CD drivers and the system.