dBpoweramp Batch Ripper: Discussions

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Next update might do the storing of log files with the multiencoder, I will have to look at the code.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Spoon-

When I had about 40 batch results sitting in the drop down for the batch ripper, pressing the Rip button would cause the application to freeze requiring the process be killed. Removal of some of the results seemed to fix the problem. Several tests later, the problem came back, and removal of results seemed to be the fixer.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Brendan: select start >> run and type %appdata%

can you zip up the dbpoweramp folder and send to me please?

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Brendan: select start >> run and type %appdata%

can you zip up the dbpoweramp folder and send to me please?

Whoops, I already went ahead and deleted all of the old batch result entries. If it happens again (at this rate, in a week or two), I'll do that?

Or should I go ahead and send it anyway?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Only in the state where it is jamming, I could not reproduce it.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Only in the state where it is jamming, I could not reproduce it.

Ok, I'll keep an eye out for it again and follow the procedure then to zip up the state and send it your way.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Just put together a Core 2 Quad system with six firewire drives (five are pioneer DVR-108 units, one is a HL-DT-ST GSA 4040B). Installed R13 and R13 batch ripper and batch ripper loader commands (all most recent..."alpha7", by my count). Plus installed/updated the audio and utlity codecs that were appropriate.

I was planning to perform a six drive test, but had to back off to a four drive test. I found out that the four-drive bridge boards (two IDE channels each, each with master/slave) that I am using does fine with two optical drives ripping audio (even if they are on the same channel) but starts to really lag behind if three or four are used.

Testing showed that four drives on one board on one firewire channel was much slower on average than two drives on two of the same boards when chained together to the same rear PC firewire connector. Regardless if the drives on the two boards only used one IDE channel per board (that is, two drives were slaves) or not.

So, it wasn't a firewire saturation issue. Probably a chipset bug, but really annoying considering the high cost of the bridge board

So, as I said, I'd planned some six drive wizardry. You'll have to settle for four for now, until I can swap out some bridge boards.

In my last four-drive test, using the Test Conversion codec (no encoding) on several ~75-85% full CDs, the max combined speed I saw, right near the end of the CDs, was 149x. It was generally > 130 during the last 1/3 of the run, until one of the discs was finished, which immediately drops down the total.

Encoding four in parallel to FLAC (set to the maximum compression setting), I was getting around 100x during the last 1/3 of the CD. It would probably be closer to the 149x at the normal FLAC settings.

I tried using the multi encoder, but was getting error dialogs popping up instead of actual ripping happening, so I'll have to track that down and submit a bug report. And yes, I am using the most recent multi-encoder from the beta subforum.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Just put together a Core 2 Quad system with six firewire drives (five are pioneer DVR-108 units, one is a HL-DT-ST GSA 4040B).

While I'm at it, this brings up another question: will support for audio disc images (wav/cue,flac/cue,whathavecue*) have a significant impact on RAM use during ripping? And, assuming that the optical and hard drive I/O is fast enough to keep up with it, how will that play out on systems ripping from 6 to 12 drives at once?

For 6-12 drive systems, will there be a need to move to windows environments which support more than 4GB of RAM, such as the x64 releases of XP/Vista, or the x32 Windows Server 2003 Enterprise Edition?

-brendan

* a little verbal levity there.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

>will support for audio disc images (wav/cue,flac/cue,whathavecue*) have a significant impact on RAM use during ripping?

No more impact than normal ripping.

[LtData]

Re: dBpoweramp Batch Ripper: Discussions

Moving to a 64-bit program would have no effect on dMC, as dMC is a 32-bit program and wouldn't be able to use over 4GB of memory.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

>will support for audio disc images (wav/cue,flac/cue,whathavecue*) have a significant impact on RAM use during ripping?

No more impact than normal ripping.

Spoon, that's excellent news.

Moving to a 64-bit program would have no effect on dMC, as dMC is a 32-bit program and wouldn't be able to use over 4GB of memory.

To clarify: I brought up x64 versions of Windows (and x32 Server 2003 Enterprise Edition) not for x64 exe support, but for OS support of more than 4GB of physical RAM. While I understand that each x32 EXE is typically limited to 2GB of process space, the batch ripper makes use of multiple CDGrab.exe processes (one per drive) each of which would have access to it's own 2GB of virtual RAM if needed.

Hence, if the rip-as-one capability was more RAM hungry, OS support for > 4GB of RAM could come in handy. But as spoon said, it appears he's coding it to not be RAM hungry (yay!), so the point is moot.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Another one for Spoon:

The CDGrab.exe, when used in GUI mode, has a drop down off the right side of Options for several items, including "Encoder Priority". If one were to change the Encoder Priority from Normal to Below Normal, would the CDGrab.exe's that are launched by the batch ripper also follow that rule?

And yes, I am aware that if so, using the option would possibly decrease disc throughput.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

Yes this option sticks for all CD Rippers.

[RipTheWorld]

Re: dBpoweramp Batch Ripper: Discussions

Personally I think the best cost trade-off on systems is reached at a 6 drive system. I have an overclocked Quad core system that can just about keep up with 5/6 encoding streams. If you go above 6 drives then you need to start looking at more expensive cases (if your using internals) and things can start getting pretty messy. The hard drive will also start to get maxed out at some where over 6 drives (I did the calculation previously, but can't find them), then you are into RAID systems to keep up with the data, and then more memory to keep up with the extra drives etc.

I also wouldn't personally touch anything involving IDE. I used to have a system that used IDE to SCSI converters which ran OK, but each drive ran with its own controller before plugging into the SCSI adapter. Even using 2 drives on the same controller can really cause problems if you hit any errors with a disc. If you are doing this to use a particular model of IDE drive then fair enough, but the far more robust solution is to use SATA drives.

IDE controllers weren't designed to handle that kind of data throughput (and certainly not in both directions at the same time), SATA ones were. Most new motherboards also come with PCIe slots so adding more SATA controllers is easy if you don't want to overload the onboard one. Extremely easy to build a system with SATA and it is lightening fast.

You can get into the debate about the accuracy of the drives etc. But I haven't started offering extremely paranoid rips to my customers yet anyway so its not an issue at present. Happy to test my current setup for accuracy etc. if others are interested.

[RipTheWorld]

Re: dBpoweramp Batch Ripper: Discussions

OK, went ahead and did a quality test anyway.

I have 2 different models of Liteon SATA drives and I ran them in CDSpeed with the test disc.

Both achieved 100% C2 accuracy with quality scores of 99.6% and 99.5%. I think that compares pretty favourably to almost any drive out there.

Spoon: Any news on the metadata deals? (Its the only thing stopping me from doing any more testing).