dBpoweramp Batch Ripper: Discussions

[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

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

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

[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

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'...

[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

[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.

[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

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.

[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

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

Spoon -

1. You may want to update this text on the Batch Ripper page to include the sony unit and the ulcli-covered units:

Currently the following loaders are supported:

Auto Eject - Manual Load (for CD Towers)
MFDigital Baxter
Datatronics Minicubis
Stordigital 25
Diskmakers Pico
Acronova DupliQ
MediaTechnics Fusion X

2. I'd change the line "Primera Composer [Max]" to "Primera Composer & Composer Max", since the units and drivers are substantially different.

3. You may want to label the drivers I put together as "experimental, please test and provide feedback", as that's what we'd both like to see - people trying them out and reporting on how they work (or don't work). The drivers do not necessarily take full advantage of the equipment (e.g. the Composer Max driver is limited to two stacks and two drives, I think), nor are they optimized for throughput. e.g.

a. The drivers often send unnecessary hardware resets to the loaders, to work around the current lack of error testing/checking capabilities.

b. At the time I submitted them, I hadn't implemented the immediate bit in the start stop unit commands used to close the drives in certain circumstances.

c. The load commands examine each disc to see if it is unrecognized and in need of a reject before exiting, even though you now handle that in the batch ripper. This is a duplicate check which adds to time before each disc can rip.

d. I don't have an MF-Digital BaxterRip (the 300 to 600 disc unit, not the 25 disc Baxter) unit to test against, so that's the driver I have the least confidence in - the driver was coded to the hardware documentation and remains totally untested.

---

I have a couple of weeks off at the end of the month, and am planning to do some serious clean up work at that time. Hopefully we'll get some feedback before then!

-brendan

[okrachokra]

Re: dBpoweramp Batch Ripper: Discussions

I have a SCSI Tower of 7 Nakamichi 5-CD Changers ( 35 drives in all ) and currently the Batch Ripper does not recognize the drives. I have mapped the drives to mount points on the file system ( ie /CD Changer <n>/Drive <m> ).

( Note: Riptastic does support this device).

Will this be supported by the Batch Ripper ? Is there any chance it will be supported in the future? Is there any work around I could use to make this work?

Thanks in advance for your help.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Your cd drives should be recognizable by the system as a CD drive, ie Windows Media Player should be able to rip from the drive.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Are any of the drives mapped to drive letters, or are they all mapped to paths? If you give some of them standard drive letters, do those start getting recognized by the dbpa cd ripper app? Try giving one of the five slots in each a drive letter as the first experiment.

Spoon - the MJ-5.16 16x SCSI CD-ROM changers by nakamichi are standard 5.25 form factor optical units. They are also slot loading and hold 5 discs at once! And they have a rather unique changer interface.

Windows recognizes each single unit as *five* separate drives (via five LUNs) automatically, one drive for each disc slot, though only one of the five can be used at a time since there's a single optical mechanism. Hence 7 nak's require 35 separate paths, and typically one would remap each of the five "drives" to a path on the c:\ drive (a reparse point?) for direct access. Plus, any software that uses them needs to play by some ground rules: only read from one LUN at a time, don't eject any discs on the same ID while reading from a sibling LUN, etc.

Note: if dbpoweramp assumes every optical drive always has a drive letter, then one would be limited to 25 or so "drives". In this case, five naks (maximum) if you have a single boot disc, and no other optical/floppy/network/flash drives.

Spoon - I suspect you would have to add explicit support for these in several areas (ID + LUN support, path vs. drive letter support, and changer management that locked the batch ripper to only working with one LUN at a time, etc.). These are ancient...but I have a dozen or more of them, so if you are interested in explicitly supporting these, I can send one or two on a one way trip to you. Or, you can typically find one or two on ebay for $10 - $40 each.

-brendan