dBpoweramp Batch Ripper: Discussions

[okrachokra]

Re: dBpoweramp Batch Ripper: Discussions

Thanks for all the stuff you have written for the Nakamichi drives Brendan!

And I can confirm all that you have written about it ( I do see the drives fine if I map it to lettered drives ( ie E: , F: etc ).

Spoon: Any thoughts on whether this will be supportable. Specifically if drives mounted to files on the filesystem ( and not lettered drives ) will be recognized; and if some form of serial ripping ( on drive at a time or even better as Brendan suggested only multiple sets of CD drives at a time - in my setup it would mean 7 rip jobs in parallel as I have a 7 set of 5-CD changers in the tower.)

I for one would be very grateful if you do. I was using riptastic but find the dbPowerAmp far superior for the fact that it does support ripping to Apple Lossless ( Riptastic does not ) and that you use the AMG data base - free cddb ( which Riptastic uses ) is great, but does have tons of errors and cleaning it up is a real pain.

Thanks all

[peterfs]

Re: dBpoweramp Batch Ripper: Discussions

I'm noticing that none of the CD's ripped using the batch ripper are reported to be in the AccurateRip database, yet they appear to be when using the CD ripper directly. Is this expected? [correction - some of the CD's do appear to be in AccurateRip but there are inconsistencies between the batch and CD ripper]

Also, I've noticed I'm getting different meta-data results with the batch ripper than I am with the CD ripper. For example, when I use the batch ripper I get a CD result showing the album as part of a box set but when using the CD ripper I get the correct album title.

On a related point, what is the best way to update or correct meta-data information? I can change information manually but I'm wondering if there are any recommendations for a more automated way to change disc related information, e.g. modifying tags, renaming directories and downloading new album art. Ideally this would be something like re-ripping the discs without transferring content.

[LtData]

Re: dBpoweramp Batch Ripper: Discussions

FreeDB doesn't support album art, you can only get that from AMG.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

@bhoar - use the normal cd ripper, also try the old plextor read d8 mode (options >> communication).

Oh yeah, duh. Why do things the hard way, right?

Test complete. The nakamichi MJ-5.16 (SCSI) changer worked fine with the CD ripper set to the normal settings. Just pick the drive letter and rip.

I was getting ~4.0x extraction (seemed constant, probably CLV). For my test, I connected mine via a rather slow SCSI connection, as I used a Microtech USB 1.1 -> SCSI bridge cable - perhaps the device is capable of faster?

---

Batch ripper: if you only load one disc in the unit, it doesn't work with the batch ripper as a manual drive. This is even if you only select a single drive letter in the batch ripper. It spends most of the time in post-load, and then times out and tries load, then goes back to post-load. Not sure what the issue is there.

What I think would be initially necessary to make multiple slots work with the batch ripper, at least in terms of batch flow, is below. Context: most people using these with Ripstastic! used several of these units on the same SCSI chain, so the idea is to get several working at once - the point wasn't speed so much as it was to just load 35 discs and go. However, with the dbpa batch ripper, speed improvements could be seen.

In other words, a "single device at a time" mode for the batch ripper wouldn't allow more than one unit to work at once, so that's not what I recommend. It'd be nice to get more than one device (but only one slot per device) working at a time.

a) the unit probably needs a bit of settle time after the five discs are loaded, as it actually spins up each and caches the TOC and some other info from each disc so as to reduce unnecessary disc swaps.

b) it would probably be best to leave all insert/eject (or tray open/close) actions to the operator. when you eject a disc it just sticks the edge out...if you programmatically eject another disc in the same unit while a disc is sitting there, nothing happens.

c) the cd ripper should be locked out of reading a disc in any drive letter mapped to the same unit (ID) if any other disc/slot (LUN) is in use. if I were going for the quick implementation, I'd have the load/unload/reject commands coordinate and prioritize by keeping track of which LUN is currently in use for the device's SCSI ID and not allowing load to exit to the batch ripper until it is time for the associated LUN to run. Perhaps after all five slots are processed, eject the lowest LUN to alert the operator that it is time to swap all five discs? Not sure what the signal should be to the batch ripper that all five were swapped.

d) dbpoweramp currently seems to require drive letters for all drives. this limits you to a maximum of five nakamichi units usable at once.

Anyway, just some thoughts.

-brendan

[peterfs]

Re: dBpoweramp Batch Ripper: Discussions

Thanks Spoon, I'm getting Album titles now when I check All Media Guide as an active provider.

Regarding the qualitative differences with freedb, I noticed that album art was not available on the discs I was ripping using freedb. But my original question was more in regards to the accuracy of track listings and other meta-data. I've noticed inconsistent standards for information from e.g. Gracenote, probably because the information is user-supplied and I assume unverified.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

@bhoar - use the normal cd ripper, also try the old plextor read d8 mode (options >> communication).

------------------------
@peterfs - beta2 fixes the problem completely, it was uploaded a few hors ago.

------------------------
> freedb is not working in the batch ripper yet, is it? At least its not on mine Beta1

Yes it works, the last few days freedb have changed server IP addresses and many people cannot connect.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

re nakamichi drives:

If they are so old then possibly modern programs cannot rip using MMC.

It's possible they don't do mmc...I don't know.

If you can devise a quick plscsi test to test for core mmc commands, I can arrange some time to put together a scsi-connected system to perform it on.

But I get the feeling you're implying that it is not worth the time.

-brendan

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

freedb is not working in the batch ripper yet, is it? At least its not on mine Beta1

[peterfs]

Re: dBpoweramp Batch Ripper: Discussions

Thanks. Looks like if I have freedb selected it works okay. Is there a qualitative downside to using freedb or should I wait for AMG support in beta 2?

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

re nakamichi drives:

If they are so old then possibly modern programs cannot rip using MMC.

-------
re Peter: fixed in Beta 2

[peterfs]

Re: dBpoweramp Batch Ripper: Discussions

With the latest update of the batch ripper, I'm getting "(never)" for all the album title on all discs. All other track and album information appear correct. When I open the disc with the regular CD ripper, all information appears correct.

I'm enabling both All Media Guide and freedb for meta-data, but no other changes to the defaults for meta providers. I'm using the medium changer profile for a Sony XL1B.

Is there some config option I'm missing?

Thanks,
- peter

[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

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

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

[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