dBpoweramp Batch Ripper: Discussions

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

The album art editing section (on manual meta review) is only shown with screen resolutions above 1300x

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

I like the option of choosing the different meta data sources and it works pretty well. It would be good if it could be done on a per track basis as well though.

Despite being a HUGE proponent of the intelligent meta-data system I have not been able to try the one in the batch ripper yet, so I am not sure how it works. Is it not choosing the best meta-data for each song, but instead taking all of the meta data from one source?

It would be good if there was the option with the album art to only allow artwork above a certain size. I have a customer who will only accept images above 1200x1200 (yes I know that most of the databases don't offer this, its just an example).

Agreed, though you will not find 1200x1200 anywhere. I would also like to be able to save a larger version in the folder and use smaller ones to add to album tags.

I can't wait till the editing can be done as a post process as this would make the work flow much better instead of having to watch the software all of the time. Is there any news on the tagger program. Is it going to be tightly integrated with the ripper?

I agree, it would be very nice to be able to manually review the meta-data for the batch rip process as described in my meta-data tool thread.

[RipTheWorld]

Re: dBpoweramp Batch Ripper: Discussions

Looks like its all going pretty well with the new updates.

I have got the settings the way that makes sense for my operation now and getting a reasonable throughput.

I like the option of choosing the different meta data sources and it works pretty well. It would be good if it could be done on a per track basis as well though.

One thing that I couldn't seem to find that is listed as a feature is the album art assigning and scanning. I am guessing it is supposed to be on the same window as the metadata correction bit.

It would be good if there was the option with the album art to only allow artwork above a certain size. I have a customer who will only accept images above 1200x1200 (yes I know that most of the databases don't offer this, its just an example).

I can't wait till the editing can be done as a post process as this would make the work flow much better instead of having to watch the software all of the time. Is there any news on the tagger program. Is it going to be tightly integrated with the ripper?

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

It would be nice if we had an option to set a max number of simultaneous rips. I have the Composer Max with 4 drives and it could potentially send A LOT of data to the PC very fast. I would prefer to set it to rip one disc at a time until I get a new PC with multi core CPU.

I think this would be a good idea as well, essentially having a batch-time clamp on the the number of concurrent CDGrab processes (and therefore effectively a clamp on CoreConverter processes, which tend to use more cpu than the cdgrab processes, but are less sensitive to timing issues than cdgrab).

Note that this is different than the maximum number of drives available for ripping in the batch and also different than the maximum number of drives that a loader would handle load/unload/reject from. The loader should still be able to pre-position discs in drives that would be pending in the rip queue, waiting for another drive to finish, thus reducing load delays.

-brendan

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

It would be nice if we had an option to set a max number of simultaneous rips. I have the Composer Max with 4 drives and it could potentially send A LOT of data to the PC very fast. I would prefer to set it to rip one disc at a time until I get a new PC with multi core CPU.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

In HKCU\Software\Illustrate\dBpoweramp\GenericChanger-Pos-Changer-0

contains the next disc number, so let it load disc 1, set that number and cancel disc 1.

[CiXel]

Re: dBpoweramp Batch Ripper: Discussions

This new release seems to be working well. The new meta engine hasn't left me with any rejects this round which is a pleasant surprise. It's really coming along now.

It would be nice to be able to start from a disc # on a sony changer and continue from there. Ejecting anything other than the entire carousel is a huge manual process, especially when it's more than a few rejects

Also in Sony land, since we have the 'populate' button, it would be great to use that number as the 'stop after this many discs" number. As it stands now, the screen that gives you the populated info shows up after the point you can input the field.

Lastly on an 'almost there' note since the meta engine is mostly in, I'm pining for a 'skip disc if time elapsed is greater than: 1x, 2x, 3x, none of disc length. I started a group last night to wake up to find it stuck 7 hours- 12 discs in.

Great progress though!

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

If you eject the first 63 discs, it should start ripping at 64.

[latefordinner]

Re: dBpoweramp Batch Ripper: Discussions

I have noticed a couple of additional problems with the Jan. 30 release. First, Batchripper froze after it attempted to rip a track for several hours. No matter how many times I told it to skip the track or the disk, it refused, eventually forcing me to shut down the program. Second, when I restarted, I had to skip the first 62 discs (which it had ripped before) manually, by clicking on the Skip Disc feature for each disc, until it reached disc number 63. Is there no way to have Batchripper eject certain CDs (whether CDs selected individually by the user or CDs of a certain category, such as rejected CDs) or at least skip certain CDs, such as those that have already been ripped?

Yes. Several proposals have been made to avoid the nearly-intolerable prospect of paying two to three times for the privilege of using premium metadata on damaged discs that may need to be re-ripped in following sessions: move premium lookup to end-of-successful-rip only, time-limited cache of premium metadata, or the capability to post-rip bulk retag with the premium metadata tool using disc info tags stored in the tracks.

I know there are both contractual and architectural reasons why none of the above are a quick fix. The reality is that most CD collections will have a good percentage of discs that are in poor condition. In the long run, especially if dbpa batch-ripper gets traction in the commercial ripping space and the issue cuts into profit-margins, I am convinced the matter will need to be addressed.

-brendan

[latefordinner]

Re: dBpoweramp Batch Ripper: Discussions

I have updated to the latest version of Batchripper. Two questions:

1. It seems that often multi-disc sets receive the same album name, with no differentiation between disc numbers. For example, "Al Green Anthology" is always called "Al Green Anthology," without stating which disc is disc one, which disc 2, etc. I have a program called J.River Media Center, which normally easily lets me edit metadata. But with a multi-volume set, even with Media Center it is very difficult to edit multi-volume sets because there is no easy way to short by track number. For a four-disc set, there will be four tracks # 1, four tracks # 2, four tracks # 3, etc. For 21-disc set, the problem multiplies by 21. Is there a way within Batchripper to rename each disc with the proper disc number? If one could right-click on a disc to change the name, for example, that would be ideal.

2. When Batchripper encounters a disc whose metadata is unknown, it labels the disc and the artist as unknown. But with a third-party program, because there will be multiple discs labeled "unknown," there is no easy way to edit the metadata. Again, if one could at least enter the artist and disc information from within Batchripper, that would be ideal. Is there a way to do so?

Yes. Several proposals have been made to avoid the nearly-intolerable prospect of paying two to three times for the privilege of using premium metadata on damaged discs that may need to be re-ripped in following sessions: move premium lookup to end-of-successful-rip only, time-limited cache of premium metadata, or the capability to post-rip bulk retag with the premium metadata tool using disc info tags stored in the tracks.

I know there are both contractual and architectural reasons why none of the above are a quick fix. The reality is that most CD collections will have a good percentage of discs that are in poor condition. In the long run, especially if dbpa batch-ripper gets traction in the commercial ripping space and the issue cuts into profit-margins, I am convinced the matter will need to be addressed.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Which is why I am trying to come up with a solution to avoid paying for meta data that is not used.

This is also why I have tried to come up with numerous proposals that minimize the time the ripper spends on discs that do not have significant potential to be ripped without error (max re-read options, ect...)

Yes. Several proposals have been made to avoid the nearly-intolerable prospect of paying two to three times for the privilege of using premium metadata on damaged discs that may need to be re-ripped in following sessions: move premium lookup to end-of-successful-rip only, time-limited cache of premium metadata, or the capability to post-rip bulk retag with the premium metadata tool using disc info tags stored in the tracks.

I know there are both contractual and architectural reasons why none of the above are a quick fix. The reality is that most CD collections will have a good percentage of discs that are in poor condition. In the long run, especially if dbpa batch-ripper gets traction in the commercial ripping space and the issue cuts into profit-margins, I am convinced the matter will need to be addressed.

-brendan

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

the design spec for Batch Ripper is to pass discs through with as little user interaction as possible, as quickly as possible

Which is why I am trying to come up with a solution to avoid paying for meta data that is not used.

This is also why I have tried to come up with numerous proposals that minimize the time the ripper spends on discs that do not have significant potential to be ripped without error (max re-read options, ect...)

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

It was not in the design spec of Batch Ripper to handle discs in the way CD Ripper does (ie re-rips, then re-rip, then re-rip), the design spec for Batch Ripper is to pass discs through with as little user interaction as possible, as quickly as possible (freedb & AMG often disagree, ie freedb can be 100% wrong because of collisions).

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

What about getting metadata from free sources, ripping the disc to a temporary directory, and if the rip is good, get the pro meta data, find the best overall data and write it to the file and move the rip to its final destination.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Batch Ripper needs the meta data before ripping, all the programs are written that way.