title
Products            Buy            Support Forum            Professional            About            Codec Central
 
Results 1 to 5 of 5

Thread: Ripping from command-line in scripted workflow - is this possible?

  1. #1

    Ripping from command-line in scripted workflow - is this possible?

    Hi,

    I'm trying to work out a suitable workflow for making images / rips of a large (about 15-20,000 discs total!), heterogeneous collection of CD-ROMs, DVDs and audio CDs using Acronova Nimbie disc robots. Having done some first tests over the last weeks I have a rough idea how to tackle this:

    1. Use the *load* utility that is shipped with BatchRipper to load a disc.
    2. Use the [*cd-info*](http://manpages.ubuntu.com/manpages/...cd-info.1.html) tool from the *libcdio* library to find out what type of disc it is (audio CD, CD-ROM or DVD), and if the disc contains multiple sessions (e.g. enhanced CDs).
    3. Use the outcome of 2 above to determine how to extract the data from the disc. For CD-ROMs and DVDs I simply create an ISO image using [IsoBuster](https://www.isobuster.com/) (which can be launched and controlled from the command line). If it is an audio CD I'd like to use dBpoweramp to rip the audio tracks to WAVE files. For enhanced audio CDs I could use a combination of both (rip the audio with dBPoweramp and extract the data track with IsoBuster).
    4. Depending of the outcome of the above steps, use the *unload* or *reject* utility to unload the disc.

    This would all be pretty straightforward in a Python script. The main thing that puzzles me to what extent it is possible to control and launch the ripping process from the command-line (if at all) with dBpoweramp?

    Searching this forum I found [this thread](https://forum.dbpoweramp.com/showthr...Ripping-how-to), which mentions calling the batch ripper from the command line with the `--autorip` switch. I gave that a try, but once batch ripper fires up it completely takes over over the load/unload reject process, which is exactly what I don't want. Ideally, I would like to be able to do the following:

    1. Make a call to dBPoweramp to rip the current disc to a user-defined directory
    2. Return some info that tells my script if the ripping process completed normally (this could simply be an exit code) + (ideally) the info that would normally end up in the Batch Notes file
    3. Quit (without any eject, reject or unload, so my script keeps in control of the load/unload process).

    Is this possible at all? If yes, how?

    BTW apologies for possible cross-posting; I originally tried to post this in the CLI/scripting forum, but I think something went wrong when I tried to submit - either that or it's still in the moderation queue (but there seems to be very little activity in that forum so I'm not even sure if it's monitored).

  2. #2
    Administrator
    Join Date
    Apr 2002
    Posts
    38,919

    Re: Ripping from command-line in scripted workflow - is this possible?

    Batch ripper would take over the ripping process, there is no per disk command line. Why would you need to control at the individual disc level?

  3. #3

    Re: Ripping from command-line in scripted workflow - is this possible?

    The reason I need control at the individual disc level is that I want to be able to process batches that contain a mix of audio CDs (which would be ripped with dBpoweramp), data CD-ROMs and DVDs (which are disc types that need to be processed differently using different software; in my case probably IsoBuster). Once batch ripper takes control of the ripping process, it will simply reject any non-audio CDs (unless I'm missing something and there's a way to launch Isobuster from within batch ripper, but I don't think so?).

    Some context (possibly too much, but here goes): I'm trying to build a workflow that we can use to make disc images of a national libray's collection of optical carriers (CD-ROMs, audio CDs, DVDs).

    For this I'd like to end up with a batch structure that is more or less like this:

    Code:
        |   metacarriers.csv
        |
        +---disc001
        |       track01.wav
        |       track02.wav
        |       ::
        |       track12.wav
        |       tracks.md5
        |
        +---disc002
        |       image01.iso
        |       image01.iso.md5
        |
        \---disc003
            +---session01
            |       track01.wav
            |       track02.wav
            |       ::
            |       track12.wav
            |       tracks.md5
            |
            \---session02
                    image3.iso
                    image3.iso.md5
    In this example the batch contains 3 carriers, with each carrier represented by a directory. Here disc001 is an audio CD, disc002 a CD-ROM and disc003 an 'enhanced' audio CD with a data track on the 2nd session. Metacarriers.csv is a CSV file with metadata that allows us to link the discs back to existing records in our library catalogue. For example:

    Code:
        carrierID,catalogID,filePath
        1,121274306,./disc0001/
        2,121274306,./disc002/
        3,236599380,./disc003/
    Which tells us that disc001 and disc002 both belong to the same catalogue record (e.g. this could be an audio CD and a CD-ROM that are both supplements to the same physical book). After a batch is completed, its contents are reformatted into archival packages, where each package contains the data for all carriers that are part of a catalogue record.

    Of course we could process audio and data CDs using two separate workflows (with each having their dedicated machine + disc robot). However, in many cases that would mean that the information needed to generate 1 archival package (catalogue record) is spread out across multiple batches (audio batch + data batch). This would make the processing chain a lot more complex and error-prone. It would also complicate the processing of multi-session enhanced discs. For these reasons I'm really keen on avoiding this, if possible.

    Does this make sense?

  4. #4
    Administrator
    Join Date
    Apr 2002
    Posts
    38,919

    Re: Ripping from command-line in scripted workflow - is this possible?

    You could replace the reject.exe program with one of your own, which starts iso buster.

  5. #5

    Re: Ripping from command-line in scripted workflow - is this possible?

    Thanks, I will give this a try. Since I also want to be able to handle enhanced CDs I should probably replace load.exe and do any Isobuster calls *before* dBpoweramp kicks in.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •