dBpoweramp Batch Ripper: Discussions

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

I've uncovered what might be a threading issue causing some delays in the batch ripper (most recent version).

The pause before robotic action on drive B might also be due to a pending metadata lookup for drive A taking a very long time...

...unrelated to whether or not drive A is on the same robot as drive B, of course. It appears that during these delays the entire GUI display contents of the batch ripper are not updated.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Spoon,

The testing that I am doing tonight involves four drives inside three separate robots controlled by a single batch ripper instance.

I've uncovered what might be a threading issue causing some delays in the batch ripper (most recent version).

Sometimes when the batch ripper has a disc in the "post-load waiting for CD" status (includes drive spin up and drive disc recognition, which can take a while depending on disc and drive) but also some other times (such as when the end of the disc is being processed?), pending loads and unloads associated with another drive on a different robot do show as pending or queued up (as show in the status lines for the drive in the batch ripper) but the external load.exe/unload.exe/reject.exe calls don't get made until the disc in the other drive gets beyond the "post-load waiting for CD status" or whatever else the threadlock(?) was waiting for.

Any ideas?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Another suggestion:

It would be nice if after you End Batch (or the called driver does so via the "[cancel batch]" text), the next time you click start by clicking Rip, the Batch Ripper asks if you would like to continue the last batch or start a new one.

Why? If you are dealing with a disc misload on a robot, and you prefer to keep your batch results organized the current forcing of a new match designation can be frustrating.

Additionally:

Maybe it should always ask, perhaps you ended the batch due to a power outage and the need to shut down before the UPS failed?

Perhaps this could be a configurable behavior if others would find the dialog bothersome?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

If the Batch Ripper is in the "Post-Load Waiting for CD" stage, hitting End Batch still waits the full timeout (90 seconds? more? drive dependent?) before canceling that stage and moving to the Unload stage.

More of an annoyance when dealing with problem discs and/or blanks in the stack.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

You need to add --rejectifnodisc on to your command line string for load (it is not used by your load.exe, but batch ripper).

One oddity: if you have no disc inserted (or one the drive/software does not recognize) and a reject occurs because of this, a Disc # is shown associated with this Reject. If multiple ones happen in a row, the same Disc # shows up.

It's a curious mix of not incrementing the disc # since no disc was processed, but at the same time, giving this reject of (potentially) no disc a disc # anyway...

Ok, sorry, I can't help myself Spoon...another question:

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?

In this specific instance, I'd want to know there might be a good reason that the hardware reject process I am about to start could expect a failure on the grab which might be OK (because there might not be a disc) unlike normal accept/reject situations. That is, if I know the reason for this reject, because, say, I was passed "--rejectreason=nodiscfound", I might script the ULCLI to ignore the grab error and not notify the operator of the failed grab+reject and just move on to the next load.

Which, of course, leads to another question...

2. In the general case, this links up with a previously asked-for feature of specifying the "reason" for a reject so that the driver can be scripted to put different reject types (nodiscfound, nometadatafound, noaccurateripfound, failedaccuraterip, failedsecurerip, riptimeexeceeded, etc.) in different output stacks for loaders capable of direct stack output, such as the composermax or even the large capacity medatechnics/mf-digital loaders with changes to their macros.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

You need to add --rejectifnodisc on to your command line string for load (it is not used by your load.exe, but batch ripper).

Doh.

You *did* take care of it. Sorry about that, chief.

(thanks)

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

You need to add --rejectifnodisc on to your command line string for load (it is not used by your load.exe, but batch ripper).

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

An addendum (if slightly off-topic) :
---
Ah. The "Get Configuration" call would of course return CD-ROM, since that's the only profile the drive has. It wasn't telling me what kind of disc was in the device, but rather, what drive profile is being used with the disc. Later drives change the profile in effect based on the disc type placed in them, but not so CD-RW drives.

So, if I want to determine whether there is a valid disc in the drive, I'll have to use another method.
---

I still think the "disc is loaded but not recognized" situation should cause the Batch Ripper to call reject.exe, of course. Your thoughts, Spoon?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Spoon:

I'm still seeing an issue in the most recent batch ripper that troubles me, as I thought this was already addressed in the past.

I have a robot that came with a TEAC CD-W552DA (CD-RW) drive (one of the Kodak Kiosk units). If the next disc in the input pile is a non-CD disc (e.g. a DVD+R), this is the sequence of events that I see occur:

Batch Ripper calls load.exe
Batch Ripper waits for load.exe to exit.
Batch Ripper examines that drive and/or disc.
Batch Ripper calls load.exe

I was expecting that the Batch Ripper would call reject.exe before the next load.exe. It's almost as if the batch ripper cannot see there is a disc in the drive and therefore assumes there isn't one.

Naturally, the above steps lead to a double load condition, which is bad.

A while back I had some scripts set up to code around it, but now my internal code is reporting that the "Get Configuration" CDB (0x46) returns a disc type of CD-ROM when this DVD-R is in the CD-RW drive. *sigh* So, my load.exe knows there's a disc in the drive and the drive is reporting the wrong type, I think.

My question is: is there a way the Batch Ripper can be more proactive and force it to issue a reject first under these circumstances?

In the mean time, I'll go through my code and see if I can figure out a way to detect that the successful load of a disc leads to a non-readable disc situation and perhaps auto-reject at that point...but it would be nice if the Batch Ripper were able to do it.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

The ripping speed is the last reported speed from CD ripper, it is possible in secure mode that that speed is not the real one during re-reads.

-------
The file (passed on the command line as "passerrorsback"), if you return any string with "[cancel batch]" it will end the batch.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Another spoon question:

Regarding end of batch behavior...

For now, with my in-development version of the ULCLI, I just throw up a dialog (and beep every minute or so) when a load fails and tell the user to close the dialog and then click End Batch. That works, but I bet people won't comment positively on that approach (why do I have to click twice?).

Is the a more appropriate way for the load.exe to tell the batch ripper that the end of the stack(s) of CDs have been reached? Perhaps pass a string through the logging functionality or create a temporary file that the batcher is looking for?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Question for spoon:

In the batch ripper, the per-disc speed value (e.g. "22x") is shown.

Is that a snapshot of/rating of the IO (data) throughput to the drive (that it, it doesn't take into consideration rereads) or is that the effective speed of final data extraction for that section of the disc (takes into consideration the negative impact of rereads)?

That is, hypothetically: if two discs of the same length each show a speed of 22x all the way through, would the time to rip be approximately the same regardless of other factors such as: in AR/not in AR, match AR/no match AR, burst vs. re-reads, etc.?

I think I'm doing a bad job of asking the question. Let me try one more time.

Given two discs of approximately the same length, if I saw 22x the vast majority of the time while ripping both of them, would it be possible for one disc to take substantially longer than the other if they were both in relatively good condition?

I guess I don't really know what, exactly, is being reported there.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

[IFCOMP][IFVALUE]album artist,[album artist],Various Artists[]\[album][IFMULTI] Disc [disc] of [disc_total][]\[track] - [artist] - [album][IFMULTI] Disc [disc] of [disc_total][] - [title][][IF!COMP][IFVALUE]album artist,[album artist],[artist][]\[album][IFMULTI] Disc [disc] of [disc_total][]\[track] - [artist] - [album][IFMULTI] Disc [disc] of [disc_total][] - [title][]

Remove the parts I have highlighted.

[daxb]

Re: dBpoweramp Batch Ripper: Discussions

The Multi CD add disc to Album option in the meta options conflicts with the dynamic naming. I get the following results if I use the dynamic naming scheme shown below as well as check the option of Multi CD add disc to album.

[IFCOMP][IFVALUE]album artist,[album artist],Various Artists[]\[album][IFMULTI] Disc [disc] of [disc_total][]\[track] - [artist] - [album][IFMULTI] Disc [disc] of [disc_total][] - [title][][IF!COMP][IFVALUE]album artist,[album artist],[artist][]\[album][IFMULTI] Disc [disc] of [disc_total][]\[track] - [artist] - [album][IFMULTI] Disc [disc] of [disc_total][] - [title][]

Folder
Subfolder(s)

Led Zeppelin
Physical Graffiti Disc 1 of 2
Physical Graffiti, Disc 2 of 2 Disc 2 of 2

On some, the first disc does not even get the folder name with disc #
On the Album tag, the second disc gets the tag "Physical Graffiti, Disc 2 of 2" but the first disc album tag has no disc numbering, simply "Physical Graffiti".

It is almost as though the dynamic naming scheme for file names and folder structure should ignore what the checkbox is doing. Not sure if there is any workaround for getting the disc numbers on the first disc of multiple disc sets.

-Dax

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

The latest beta fixes the freedb issue.