View source for W:Automated Audio and Slide Capture

{{WST}}
{{W:ArticlesM}}
{{wcat|Articles|2007-12-27}},
{{W:LectureCaptureM}}

The page [[w:Manual Audio and Slide Capture|Manual Audio and Slide Capture]] outlines how to use a stills camera and audio recording to capture a presentation. However, there are (Semi-)Automated ways of doing this. For instance, the ICTP EyA system records lowish resolution video, along with high resolution still images, and audio, to give video and slide presentations. 

We can distinguish between 'presentation computer based' systems, that use a piece of software running on the presenters laptop to capture the presentation, such as
* Camtasia
* Apple Keynote 4 built-in presentation capture
* A proposal for [[OpenOffice Slide Capture]]
Camtasia is a screen recorder that can capture a movie (say 10fps) of screen activity. It can thus easily cope with animations. For 'low action' presentations, you might want to discard most of the movie, and just keep some stills. Apple Keynote 4 can record audio and timings for events (such as page changes), from which a slides + audio presentation can be reconstructed, see [[Keynote 4 Extract Recordings]].

For a 'non-invasive' workflow, such systems have two main disadvantages:
* They require a piece of software to run on the presentation computer. That's fine if it's a venue computer, but if it's the presenters laptop, this is harder.  When capturing presentations on my own laptop (while giving a presentation), this of course isn't a disadvantage.
* They only capture what happens during the presentation. If I write on the board, or show an ohp, or point with a physical pointer to the screen, those elements don't get recorded.
The first point could be addressed by using a VGA grabber, that sits between the presentation laptop and the projector, but this doesn't solve the 2nd problem. 

To overcome this, you could use an external way of capturing the information, see [[Manual Audio and Slide Capture]]. However, while giving you a lot of flexibility, this can get tedious easily, if you have a lot of lectures to record. 

If you can capture all essential information from a single camera angle (given a sufficiently high resolution image), you might be able to adapt the [[Manual Audio and Slide Capture]] workflow, to something somewhat more automated.

*Step 1a: Set up a stills camera, and capture images regularly. You might be able to do this with software that came with your camera, or under Ubuntu, you may be able to use gphoto2.

*Step 1b: Capture audio in parallel. E.g. under Ubuntu, you can use tools like the sox library of ffmpeg to capture audio automatically.

*Step 2a: After the recording, reject duplicate images. (This can of course be done manually, but Ubuntu software suggestions needed!)

*Step 2b: Automatically process the audio: Normalise, and apply audio range compression to give better volume. (Can be done manually in Audacity, but ubuntu software suggestions needed!)

*Step 3a: Extract timings from the remaining images (see [[Manual Audio and Slide Capture]]).

*Step 4a: Resize images, e.g. using imagemagick.

*Step 4b: Split audio according to image timings (can be done e.g. in ffmpeg), and encode to mp3 (ffmpeg or lame).

*Step 5: Glue result together using e.g. flowplayer (see [[Manual Audio and Slide Capture]]). (There currently isn't a simple slde and audio player, that allows you to attach images to audio using xml-based non-embedded cue points, see [[Flash Cue Points via XML]], but this would be an alternative. However, it would not necessarily be low-bandwidth compatible, see [[Manual_Audio_and_Slide_Capture#Notes_on_export_.282.29_-_Single_file_vs._many_files.]])

Of course the result could be a lot more sophisticated, with image zoom scripts a la EyA, but it's a basic workflow.