Home

Welcome to the eesen-transcriber wiki! Here find some more detailed instructions on running eesen-transcriber:

The batch processing system SLURM is installed in the VM, and remains running whenever the VM is booted. It lets you achieve parallelization and queuing, so that only a certain maximum #jobs can run at a given time, and as old jobs complete, new jobs are started

1. Edit the Vagrantfile to give the VM a reasonable amount of your host computer's RAM and CPU cores (leaving some overhead) Here are the pertinent lines from ours, for example:

       vbox.cpus = 4
       vbox.memory = 12000

edit this file before bringing up the VM with vagrant up

2. You have a folder on your host computer with a bunch of files to be transcribed... we can go ahead and purpose "transcribe_me" for that. (The VM has a file handle on the shared host folder as: /vagrant/transcribe_me/)

3. You ssh into the VM with vagrant ssh

4. Configure the SLURM scheduler in the VM to match the number of CPUs you assigned in step 1. That number is the parallelization: how many parallel jobs. The configuration appears in file /etc/slurm-llnl/slurm.conf. Near the very end of the file, edit this line, typing in the number of "Procs":

NodeName=localhost Procs=4 State=UNKNOWN

If you are stuck on how to edit a file in the VM, use pico or vim, e.g:

pico /etc/slurm-llnl/slurm.conf

Because you have made a change, it probably helps to restart the SLURM daemon, so also give the command

sudo service slurm-llnl restart

5. You change to the home directory of the transcriber. It's a little confusing because of a symbolic link, it could be either of these:

cd ~/bin cd ~/tools/eesen-offline-transcriber

6. Higher level scripts call lower level scripts, so let me start with the top:

• `batch.sh` - this script takes a list of files to be queued for processing
  

• `slurm.sh` - this script specifies a single processing job for 1 file
  

• `speech2text.sh` - this script does the actual processing
  

An example command to process several files would look something like:

./batch.sh /vagrant/transcribe_me/*.mp4 # or *.wav or whatever file extension you use

Example output for a single mp3 file would look like this:

vagrant@vagrant-ubuntu-trusty-64:~/tools/eesen-offline-transcriber$ ./batch.sh /vagrant/transcribe_me/*.mp3
Submitted batch job 2
vagrant@vagrant-ubuntu-trusty-64:~/tools/eesen-offline-transcriber$

I think there is also a restriction on file names. Windows is notorious for allowing spaces in file names, which will break many linux things. Also I think filenames with the dash character in them result in problems for our system... just to keep in mind.

Monitoring output

* log files appear in `/vagrant/log`  one for each job
* status of the queue in SLURM can be monitored with squeue.
* if a job results in error, the log file points to other log files in the VM with more info.
    for example, a path like  `/vagrant/build/trans/<input filename>/eesen/decode/log/decode.1.log`
    has detailed output for that input file. If it failed, you might see the words "Killed" or
    "broken pipe"
* From the VM perspective, results appear in `/vagrant/build/output/<input filename>.*`
 (Several output formats are produced for each input.)
The same results really exist on your host computer, in subfolders
 of the path you were in when you started the VM, for example `build\output\<input filename>.*`

Errors
If you see "Killed" or "broken pipe" it's most likely that the system ran out of RAM during processing. Either run fewer jobs in parallel, or increase the amount of virtual RAM assigned to the VM in the Vagrantfile

I would strongly suggest queuing a small test file first following these steps. If that works, then try more, or bigger. Processing time is several times the length of the original file, so a 5 minute audio/video might take 20 minutes to process.

You might not wish to view results in a web browser. To leave out this feature, edit slurm.sh and replace 'vids2web.txt' with 'speech2text.sh'