dBpoweramp Batch Ripper: Discussions

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

disc-in-drive history management

I may be wrong but I would think this would be easy if the ripper would just reply with a response of already ripped in this drive for a given TOC

or drive-to-drive moves would need to be added as batch ripper feature. I'd guess the latter would be unlikely anytime soon.

Really, I think this would be quite easy, much easier then an ideal implementation of drive history management.

As an easier alternative to the above mentioned ideal would be a two step process, were a rejected pile is build. I could inspect the discs and then start a batch RE-rip, which would take the first disc, but it in drive one, rip, if not accurate, move it to drive 2, then pick up a second disc and put it in drive one and so on.... so that each disc is tried sequentially in each drive. And since I have had a chance to inspect and possibly clean or repair them they may re-rip in any of the drives this time around.


Also, as noted in the past, I would like to be able to reject CD-R / RW disks.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Eli -

For the ULCLI, I'm not planning enough inherent configurability to support your dream as stated. There are few devices with > 2 large stacks that support directly addressing each stack (without macro modifications), and disc-in-drive history management or drive-to-drive moves would need to be added as batch ripper feature. I'd guess the latter would be unlikely anytime soon.

However, the addition of a --rejectreason= parameter by spoon to the passed parameters list could get you part of the way there, at least with the ULCLI architecture.

As things stand now, the missing-trackdata and the missing-audiodata discs are intermingled in rejects during the rip. What I do then is physically examine all of the rejected discs and clean/buff any that seem to be questionable, then resubmit them all, gradually weaning down to a group missing-trackdata and a group that are terminally missing-metadata. The former might get a spin in a semi-pro grinding machine depending on who owns them (liability issue). The latter I will end up doing one at a time in the CD Ripper (which currently has broader metadata coverage than the batch ripper).

Note that the %age of missing-trackdata disc might go down if my understanding of Spoon's upcoming changes to metadata handling in the batch ripper is correct.

-brendan

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

I am thinking once the meta data is complete there will not be a huge number of tracks which do not have meta data (there is a possibility of using 4 distinct different databases).

Good to hear. Even so, I hope the ripper gives out as many responses as possible so that the end user has the most options when setting up the batch ripper to have the power to do something like I described above.

BTW, what 4 will be used? Clearly AMG and freedb. I hope GD3, which has offered free use for dbpoweramp, has better album art, and has offered a nice additional feature set for dbpoweramp users. Musicbrainz would be the other logical choice. I see no reason not to add tracktype as a 5th. MusicDNS would probably not be as interesting, though could also be implemented for free from what I can tell.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

I am thinking once the meta data is complete there will not be a huge number of tracks which do not have meta data (there is a possibility of using 4 distinct different databases).

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

This is my dream, set it and forget it way to go using the Primera Composer Max:

Ideally I would like to be able to separate discs that the max process into the following stacks
1)accurate w/ meta
2)secure
3)accurate w/o meta
4)insecure/inaccurate

What I would like to be able to do is to re-rip secure discs in different drives to see if the rips match, which should be appended to the original log. This should not require re-encoding, just ripping, unless the new rip is found to be accurate.

Re-rip insecure or inaccurate discs in different drives as often different drives can successfully rip a disc that others cannot.

The composer max has 4 drives and 5 bins.
-Fill bin 1 with 100 discs, discs are ripped and separated

B1)original disc stack - empty at end of first round
B2)accurate w/ meta
B3)secure
B4)accurate w/o meta
B5)insecure/inaccurate

Next pass, discs from B3 are selected, and placed in different drives. If the are placed in a drive they were already ripped in they are removed and placed in a new drive, if the rip matches the discs are moved to B2. If they are insecure and do not match they are tried in the other drives. If no match is found they are moved to the now empty B1. We now have:

B1)empty at start of 2nd round - now secure, no match
B2)accurate w/ meta
B3)secure at start of 2nd round - now empty
B4)accurate w/o meta
B5)insecure/inaccurate

Next, insecure or inaccurate discs from B5 are tried sequentially in the different drives until either a rip is accurate and there is meta data they are moved to B2, 2 matching rips are secure with meta and they are moved to B2, one rip is secure w/ meta and its moved to B1, rip in insecure/inaccurate in all drive to B3, rip is accurate/securex1/securex2 w/o meta data to B4

In the end, the bins would be:
B1)secure, no match w/meta
B2)accurate w/ meta
B3)insecure/inaccurate
B4)accurate/secure w/o match/secure w/ match w/o meta data
B5)empty

Tracks are ripped to a temporary directory:
-If the full disc is secure, secure with match, or accurate the files are moved to the final directory
-If any tracks are insecure/inaccurate at the end, the files are moved to the re-rip directory. In the future, if the disc with the same TOC is re-ripped only inaccurate/insecure tracks are re-ripped. If all the tracks are now accurate or secure the album files can be moved to the final directory. These discs can then be repaired if there is no label side damage and placed back in to be ripped.
-Tracks without meta data are queued for tagging.

[bhoar]

Reject Reason (was Re: dBpoweramp Batch Ripper: Discussions)

Three suggestions:

1. Would it be possible to add a flag to the interface for the batch-ripper automation commands (load,unload,reject,pre-batch,post-batch) that passed the reject reason? I could forsee the ability to have multiple reject stack types based on reject reason. e.g. Mediatechnics Impact or Primera Composer Max units, neither of which do automatic stack management, depend on direct stack addressing for navigating to the input, output and reject stacks. And since we'd control the use of the stacks for whatever purposes we wanted...

I suggest something like --rejectreason=metadata and --rejectreason=trackerror?

Note: even some of the automated stack management units, like the newer Mediatechnics and MF-Digital units, could potentially, via modifications to their Macro programming, be set up with multiple reject stacks. This would obviously be an unsupported, or even warranty-expiring, type of change, as it might cause compatibility issues with duplication software or firmware upgrades.

2. It would be nice if there were separate columns for discs rejected due to metadata issues vs. those rejected due to track errors, in the bottom half of the batch ripper display.

3. It may be necessary to either shrink the art and font or, alternately, to give up the two column Ripped display in order to handle #2.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

This is a known issue, meta data was implemented 5% of the final implementation, work is going on right now finish meta data, using some pretty advanced routines, as they say 'you ain't seen nothin yet'...

[CiXel]

Re: dBpoweramp Batch Ripper: Discussions

In batch mode I'm noticing, if a cd isn't the version expected (ie it has bonus tracks) or the cd is looked up wrong, then the known cuts metadata is populated with track name etc, however when the additional tracks are ripped, they get no data populated to the them and they end up in a 'various artist' folder. The only fields that are embedded then are the title field with 'Track #' and the track number field. They don't even get the artist or CD name of the disc they were part of. (This is on a single artist CD)

Since we know what the Artist and the Name of the CD are (if we didn't the disc would get rejected due to lack of metadata), I would expect "Track 14" to at least have that information written to the fields. As it stands now, I end up with a bunch of random Track 14, track 12 etc under various artist, and without some digging have no idea to what disc they are associated.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Yes, press enter to move down to the next track.

[CiXel]

Re: dBpoweramp Batch Ripper: Discussions

You set the artist (in normal cd ripper) with the box at the top on the toolbar.

Right, for a single artist disc that seems to be the case. What about compilation discs... select the individual track and then go up and fill in the artist? I would try, but I'm in the middle of a batch

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Next update will have right click on ripping drive >> Show Ripper (to see the cd ripper undeneath).

You set the artist (in normal cd ripper) with the box at the top on the toolbar.

[CiXel]

Re: dBpoweramp Batch Ripper: Discussions

Ah, That would make sense and would make for a very powerful system.

A few observations after working with the current state today-
On the batch front
I would like to see a more verbose description of what's going on during a batch rip. Perhaps something akin to the "rip status" dialog in the single ripper so I can see when it's re-ripping frames or if it's stuck somewhere. (I got stuck on a few discs today. One was just taking an extra long time and eventually progressed, but on others it just sat there for hours during frame re-rips. I just wasn't sure what was going on and figured out later while doing a manual cd rip that it had stalled during that stage, as it did the same thing.) To that end, perhaps an option to skip a track if the elapsed time exceeds X times track length. (10x might be a good default) On once particular track, it spent 2 hours there stalled on a 5 minute song. I happened to catch it, but otherwise it would have sat there and nothing else would have gotten done.

It would also be great if we could drag and drop a cover art into say the results window to have it applied with our defined album art options.


In the regular CD ripper window
I can't seem to find and easy way to manually edit the 'artist' field as I can for the title field (ie. I can't click on artist and modify it). As it stand snow, I swap the title and artist, input the artist info, and then swap back. Am I just missing something here?
(also the ability to drag and drop in cover art within here too would be good)

Lastly, while utilizing a Sony changer...
Since the Sony changers maintain their disc order, and the programs remembers the "disc #" It would be great to be able to "goto" a disc number in order to rerip a file or manually enter metadata for those discs missing it.

Also a minor point, I've noticed if there is a disc mounted in the Sony changer slot when a batch rip begins, dB will start ripping that mounted disc first, and then will proceed with the batch rip. On the bright side, the implementation of a reject based on 'CD Same a last' works as intended, but if there was a way to go straight to the batch ripping it might clean things up.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Eventually we will offer a network mode for batch ripper, allowing multiple computers to be controlled from one work station, ie you have x drives on computer 1, x drives on computer 2, x drives on computer 3, x drives computer 4. On one of the systems would be the master controller which combines all into one screen (ok multi windows for multi monitor system).

[CiXel]

Re: dBpoweramp Batch Ripper: Discussions

Registry >> HKCU >> Software >> Illustrate

Great. Thanks for that.

While I can do it via the registry manually, Might it be beneficial to setup an import/export option for this where it can write the values to a file and then can be sucked into a new instance?

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Registry >> HKCU >> Software >> Illustrate