dBpoweramp Batch Ripper: Discussions

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

No commercial meta data povider will allow us to cache their meta data, the large ripping houses would at the end of the year end up with the whole database

---------------------
>I've noticed that the app crashes pretty consistantly if you exit without
>first stopping the rip. (app inactive, no CDs in drives).

Yes this is on my todo list.

------------------------
>Batchripper will get stuck on a given track of a CD and will keep trying to rip
>that track for

You can right click on the drive line and see the ripper behind, how may frames it is re-ripping.

---------------

>Does that mean that ripping to a single file is already done? I can't find any
>way to do it (in the batch ripper or in the regular ripper).

There is Rip as One in R13 alpha, batch ripper will not offer single image ripping upon release.

>Is it planned to be able to choose a lookup order via the meta providers?

Your best bet would be to use a profile with freedb only, and reject any cds with no meta data, then use a different provider. The power of batch ripper will come from using 3 providers at the same time.

-----------------
>I assume that Batchripper is using freedb. (Can I verify which database it is using?)

The next release will correctly portray which provider is active.

> Is there no way to benefit from the CDRipper AMG license that I acquired by
> purchasing the registered version of CDRipper?

We are bound by the rules of the providers, AMG are allowing 400 lookups with the CD Ripper AMG license (it took many weeks of negotiating that).

>"Ray Charles - Pure Genius; The Complete Atlantic Recordings (1952-1959) Disc 1 - 01 - The Sun's Gonna Shine Again,"
>"Pure Genius; The Complete Atlantic Recordings (1952-1959) Disc 3,"

If the providers are not consistant it is difficult for batch ripper to 2nd guess the correct storage.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

>Batchripper will get stuck on a given track of a CD and will keep trying to rip
>that track for

You can right click on the drive line and see the ripper behind, how may frames it is re-ripping.

I think the key is that its a batch ripper and the user does not want to sit around and watch to cancel tracks. That is why we need more power in changing settings to skip tracks and if something can be done to skip tracks or cancel rips more elegantly (software seems to temporarily freeze when stopping a rip) that would help too.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

No commercial meta data povider will allow us to cache their meta data, the large ripping houses would at the end of the year end up with the whole database

This policy does seem rather rude on their part, esp. when using dbpoweramp for dealing with problematic discs (a forte of the program) that may require several rip attempts. Next time you sit down with them, perhaps you can suggest a time-limit based cache (e.g. each matched lookup record can be cached for 30 days, maximum or perhaps as little as 7 days).

As a business owner, being charged several times for the same data means I will end up having to limit my rip->reject->clean/buff->resubmit cycles to the frustration of customers who will end up with larger reject piles to deal with on their own. Or I may just not use premium metadata at all, which means no album art (with dbpa that is...with ripstation they still pull the amazon art if available when using only freedb).

> Is there no way to benefit from the CDRipper AMG license that I acquired by
> purchasing the registered version of CDRipper?

We are bound by the rules of the providers, AMG are allowing 400 lookups with the CD Ripper AMG license (it took many weeks of negotiating that).

I take it you meant "Batch Ripper AMG license" above? The CD Ripper AMG license is limited only by time, correct?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Correct

[RipTheWorld]

Re: dBpoweramp Batch Ripper: Discussions

I think the key is that its a batch ripper and the user does not want to sit around and watch to cancel tracks. That is why we need more power in changing settings to skip tracks and if something can be done to skip tracks or cancel rips more elegantly (software seems to temporarily freeze when stopping a rip) that would help too.

Totally agree. When you are doing hundreds of CDs a day it is not practical to monitor all of the different machines all of the time. For example there could be a time limit on trying to achieve the error corrections.

I also cannot seem to bring up the ripping windows for each individual rip job, nothing happens at all.

I'm not overly happy about the prospect of having to pay for each lookup every time I do the same lookup, I agree that maybe a time limit on it would be a good compromise.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Install the lastest R13 alpha, that is needed to show the Ripper.

[LtData]

Re: dBpoweramp Batch Ripper: Discussions

Remember that the meta-data providers are the ones dictating the restrictive terms, not Spoon. However, a time-limit might be acceptable, but who knows.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Remember that the meta-data providers are the ones dictating the restrictive terms, not Spoon. However, a time-limit might be acceptable, but who knows.

Right - just wanted to keep that idea (idea=a limited-time premium metadata/art cache of a week or a month) in Spoon's head for any future negotiations.

We're not trying to get a two-for-one (or dozens-for-one) deal/steal on premium lookups, but since this tool will more often be used multiple times on problem CDs (unlike other batch ripping products), it's more of a fairness issue.

While most discs for a collection go through only once, problem discs (whether the problem is lookup related or damage related) may go through two to four times.

An alternate method, which would require re-architecting the batch ripper, would be putting off all premium meta-data lookups until after all CD audio ripping is completed. There might be contractual reasons this wouldn't be allowed, though.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

I always thought that very problamatic discs would be taken out of Batch Ripper and ripped in CD Ripper, atleast that is what I would do.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

I always thought that very problamatic discs would be taken out of Batch Ripper and ripped in CD Ripper, atleast that is what I would do.

Ideally, in the future I would like the batch ripper to be able to move problematic discs between the 4 different drives in my robot and see if any of them can rip the disc without my intervention. This would potentially cost 8 lookups.

One possible solution is that the metadata is not downloaded by the batch ripper until AFTER a successful rip...

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

I always thought that very problamatic discs would be taken out of Batch Ripper and ripped in CD Ripper, atleast that is what I would do.

Hmm. Let me give you a part-actual/part-hypothetical example, Spoon. I did the following with other software, but let's imagine I'm doing it with yours:

I loaded the last 800 CDs of my sister's ~2000 CDs into one of my machines last month. I set the unit to reject discs that were damaged or missing metadata. Over a day and a half, it ripped about 650 of them and rejected about 150 (I was manually clearing the reject pile and also right-click rejecting discs that were ripping for over an hour with no progress).

I then had 150 discs that might have been rejected due to one of several reasons: a) missing metadata, b) disc damage, c) disc needs cleaning, d) temporary network outage between me and metadata providor(s) or e) unknown and/or unrepeatable cause (e.g. transient problem due to drive firmware bug). I manually check the read sides to put b and c type discs into my clean/buff pile and take care of those, returning them to the reject stacks when done.

However, I don't want to manually run the CD Ripper on the remaining 150, I want to use an automated process. And, of course, I don't want to have to pay to re-lookup these 150 either when using premium metadata.

Of course, what I want and what I get aren't always the same.

But I suspect that ripping services will have a similar workflow: first let the device sort out the problematic discs in the first run, do some quick hit cleaning/buffing (if service offered), resubmit rejected discs and then...(decision tree will differ here)...

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Ideally, in the future I would like the batch ripper to be able to move problematic discs between the 4 different drives in my robot and see if any of them can rip the disc without my intervention. This would potentially cost 8 lookups.

One possible solution is that the metadata is not downloaded by the batch ripper until AFTER a successful rip...

Yeah, that's similar to what I suggested a few posts back: postpone metadata lookups until a disc rip is successful. Or more specifically, postpone *premium* metadata lookups until a disc rip is successful. Where successful = all accurate or all secure.

Perhaps pre-success the freedb information would be shown, and then the premium info could be gathered and applied after success?

A slight variation of the above, which would be both a "network polite" and "lookup saving" approach, would be to use a local freedb/tracktype database cache. Support for this could be integrated directly into dbpoweramp batch ripper or it could be supported via one of the java-based local server apps. If dbpoweramp allowed the batch ripper to have configurable freedb lookup information, little to no additional coding would be necessary to allow power-users to set this up on their own.

The reject column would, of course, have no album art, but that's ok with me.

-brendan

[latefordinner]

Re: dBpoweramp Batch Ripper: Discussions

When the metadata is incorrect for a particular album (a problem that seems most prevalent with Freedb), is there an easy way to edit the metadata manually? Sometimes, for example, freedb will simply make up an artist name or will throw in some kind of junk, such as "art," for the name. I would hate to have to re-rip in CDRipper each erroneous album.

Also, does Batchripper recognize live albums, which should not have pauses between tracks?

Yeah, that's similar to what I suggested a few posts back: postpone metadata lookups until a disc rip is successful. Or more specifically, postpone *premium* metadata lookups until a disc rip is successful. Where successful = all accurate or all secure.

Perhaps pre-success the freedb information would be shown, and then the premium info could be gathered and applied after success?

A slight variation of the above, which would be both a "network polite" and "lookup saving" approach, would be to use a local freedb/tracktype database cache. Support for this could be integrated directly into dbpoweramp batch ripper or it could be supported via one of the java-based local server apps. If dbpoweramp allowed the batch ripper to have configurable freedb lookup information, little to no additional coding would be necessary to allow power-users to set this up on their own.

The reject column would, of course, have no album art, but that's ok with me.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Any CD ripper can rip live albums, gaps are prepended to tracks so if not there...there is no pause.

To edit meta data, right click on a ripped album and select show files, select files >> right click >> edit id tags.

[latefordinner]

Re: dBpoweramp Batch Ripper: Discussions

I just experienced a similar problem. Batchripper had ripped 69 discs, but when I came home I found out that Windows Vista had rebooted after installing Microsoft's latest updates. When I ran Batchripper, it showed that it had ripped the 69 discs and had rejected about seven.

Ideally, I could have ripped the remaining 124 CDs--Batchripper would have simply picked up where it had left off. But I ended up having to tell it to rip all 200 CDs in the changer. If I had told it to rip 124 CDs, I feared, it might rip the first 124 CDs, including the 69 it had already ripped, stopping at disc # 124 and leaving the final 76 unripped.

I could have manually ejected all 200 CDs, removed those that had been ripped, sorted out those that had been rejected, reloaded the unripped CDs, and placed the previously rejected CDs into a pile for manual ripping, but those steps would have defeated the automated-ripping process. Was there an easier route?

Separately, there are some CDs that have one or two tracks that both Batchripper and CDRipper simply cannot rip--or that do not, in any event, appear as "accurate" when ripped. These discs seem to tend to come from multi-disc boxed sets, though I cannot say that there is a causal relationship: a large portion of my collection comes from boxed sets. I cannot see any defects on the CDs. Is it hopeless to rip these errant tracks?
:teufel8:

Hmm. Let me give you a part-actual/part-hypothetical example, Spoon. I did the following with other software, but let's imagine I'm doing it with yours:

I loaded the last 800 CDs of my sister's ~2000 CDs into one of my machines last month. I set the unit to reject discs that were damaged or missing metadata. Over a day and a half, it ripped about 650 of them and rejected about 150 (I was manually clearing the reject pile and also right-click rejecting discs that were ripping for over an hour with no progress).

I then had 150 discs that might have been rejected due to one of several reasons: a) missing metadata, b) disc damage, c) disc needs cleaning, d) temporary network outage between me and metadata providor(s) or e) unknown and/or unrepeatable cause (e.g. transient problem due to drive firmware bug). I manually check the read sides to put b and c type discs into my clean/buff pile and take care of those, returning them to the reject stacks when done.

However, I don't want to manually run the CD Ripper on the remaining 150, I want to use an automated process. And, of course, I don't want to have to pay to re-lookup these 150 either when using premium metadata.

Of course, what I want and what I get aren't always the same.

But I suspect that ripping services will have a similar workflow: first let the device sort out the problematic discs in the first run, do some quick hit cleaning/buffing (if service offered), resubmit rejected discs and then...(decision tree will differ here)...

-brendan