illustrate
Products            Buy            Support Forum            Registrations            About           
 

dBpoweramp Batch Ripper: Discussions

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • bhoar
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    Originally posted by Spoon
    >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.

    Originally posted by LtData
    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

    Leave a comment:


  • LtData
    replied
    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.

    Leave a comment:


  • Spoon
    replied
    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.

    Leave a comment:


  • bhoar
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    Originally posted by bhoar
    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.

    Leave a comment:


  • bhoar
    replied
    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

    Leave a comment:


  • bhoar
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    Originally posted by Spoon
    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

    Leave a comment:


  • Spoon
    replied
    Re: dBpoweramp Batch Ripper: Discussions

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

    Leave a comment:


  • bhoar
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    Originally posted by Spoon
    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

    Leave a comment:


  • Spoon
    replied
    Re: dBpoweramp Batch Ripper: Discussions

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

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

    Leave a comment:


  • bhoar
    replied
    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

    Leave a comment:


  • Spoon
    replied
    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.

    Leave a comment:


  • jgs2n
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    I thought that I had but apparently not. I reinstalled and everything is working great. Just one more question. Is there a way to write log file to final destination of music files when using multiencoder? Thanks.

    Leave a comment:


  • Spoon
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    Install the R13 music converter alpha, batch ripper cannot work with R12.

    Leave a comment:


  • jgs2n
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    I am using R13 and just tried batch ripper tonight. When I load a cd, cd ripper opens but I have to hit rip. Is there a way for the ripping to start automatically? Also, in the batch ripper dialog, nothing is updated until I close the cd ripper. Any help is appreciated.

    Leave a comment:


  • Paul_B
    replied
    Re: dBpoweramp Batch Ripper: Discussions

    My mistake it was the batch convertor not the batch ripper

    Leave a comment:

Working...