Captivate 4 is awesome. It still has its warts, but considering all the new functionality I’m just amazed at this product and highly recommend it. I’ve now decided that it is going to be my primary elearning development tool. Of course I’ll still use Flash a lot for actual content, I think the packaging/TOC/aggregator features are worthwhile (though they have some serious shortcomings too) and just make the process so much simpler when working with Adobe Connect (or any other LMS I suppose).

Anyways…I plan on posting my opinions on a lot of the new features as I have time. First up: the new text-to-speech feature.

This feature is based on a 3rd-party product and it’s quite easy to use. You simply type in your slide notes (I *believe* that this new ‘text/notes’ area is new to Captivate 4 but I’m not sure) and then click a little button/checkmark next to the text, under the ‘Text to Speech’ column. Really simple. View a screenshot to see:

Captivate 4 Text-to-Speech Feature

It then converts your text to an audio file and adds it to the slide’s timeline, the same as if you recorded your voice into a microphone. No different, except much easier and better sound quality in terms of no noise, good volume level, etc.

There are two voices to choose from: one male voice, “Paul”, and one female, “Kate”.

So….the million-dollar question: do the voices sound like robots?

The male voice does. The female voice, while I haven’t used it much yet, sounds much better. But don’t take my word for it. Listen for yourself:

As you can hear, this guy doesn’t really work too well.

But “Kate” sounds much better:

So, after I’ve bashed “Paul” to smithereens, you probably think I don’t think much of this feature. But in fact I do like it. During development, I usually have to take the time to do a rough, quick voiceover recording for all my slides so I can confirm that my design is ‘flowing’ and my voiceover script is good. I can only tell if I hear it, in synch with the onscreen visuals. So this is a great time-saver in that regard. Hopefully it will prove more useful in future projects.

What do you think? Will you be using this feature? Am I being too picky?

var myLoader:Loader = new Loader();
myLoader.load(new URLRequest(”myCaptivate.swf”);
myLoader.width = 400;
myLoader.height = 300;
addChild(myLoader);

The result will be that the Captivate gets loaded but you won’t see it. You can hear it so long as you have sound in it. But you won’t see it. It doesn’t get rendered.

But if you have the same exact code as above, but without modifying the width/height properties of the Loader instance, then it renders fine.

So when the boss told me to edit the Camtasia-produced modules, I initially thought, “Cool. I’ll finally get around to learning how Camtasia works beyond just ‘hit record, stop, and then save as an flv’. 

Well, I was wrong. Not quite. I now know all of Camtasia’s features. It only takes about 30 minutes to get intimately familiar with it if you are comfortable with timeline-based apps or any video editing software. The problem with Camtasia is editing is basically not possible. Yeah, you can split video files, slap ‘callouts’ (ie, graphics and text) over top of the videos, and a few other minor features, but that’s about it. And if, during recording, the recordee screws up, you can’t edit it. Not unless the recordee was kind enough to return their cursor/app to the exact spot they were at before screwing up, and then redid it correctly.

Camtasia is cool if you’re a one-person show and you need to quickly slap together powerpoint and/or video captures of your screen, and you’re fine with mistakes or the agony of not being able to edit. 

As much as I complain about Captivate, after spending some time with Camtasia, I have a newfound appreciation for it.

Yeah, the bloated BMP screen capture backgrounds, the transparent caption bug, the bloated filesize, and overall bugginess gets on my nerves. But at least I’m able to edit and maintain things that are created with it. Can’t say that about Camtasia.

Do you agree?

Click here to view the example swf.

There are three things you must know to use this variable:

1. The slide numbers are based on their index number in the array that Captivate uses internally to keep track of them, and thus, they are zero-based. Just like actionscript arrays. So slide 1 is really slide 0 to Captivate.
2. If you simply use the rdcmndGotoSlide variable to jump to a specific slide, it’ll do it. But the movie will be paused. The rdcmndGotoSlide variable should really be named rdcmndGotoSlideAndPause : ) You can see it in the code sample here, taken from one of the buttons:

   /***********************************************
   * Jumps the Captivate Movie to Slide 3, pauses, then resumes
   ***********************************************/
   three_btn.onRelease = function() {
   myLoader_cld.content.rdcmndGotoSlide = 2; //zero-based array
   myLoader_cld.content.rdcmndPause = 1;
   myLoader_cld.content.rdcmndResume = 1;
   }

3. The problem is, just like in a previous post where I ran into this same scenario, you have to programmatically pause it, even though it’s already paused, in order for the Resume variable to work. I can see how this would be the case as it’s not like the Captivate programmers (or should I say RoboDemo programmers?) were anticipating people using this variable since they have never documented it.

Hopefully, this opens up some new possibilities for you. I am currently in the process of working on an xml-based navigation menu that uses this same variable in order to provide a quick, elegant, and very flexible way for loading/unloading multiple Captivate movies.

Also, for further reading (with code sample), consult Andrew Chemey’s article here.

Here is a screenshot of one:

Transparent Captions Still Result in Fuzzy Text

UPDATE: The screenshots in this article were taken with Snagit. The .gif output of the image above results in the black text above looking much sharper than the white/blue image below, but trust me when I say that in reality the white/blue looks much better!

(There are workarounds for this problem. The most popular one seems to be to highlight the text using the background color. This particular page says you only need to highlight one character with a gray highlight color, but I tried it and all I got was a single character with a gray highlight : (

Since I wanted to get away from the plain white background and go with a blue background (closer to what the client had originally provided me), I wound up doing the highlight workaround and using the same color as the background color for the highlight. But this is a real pain because every single piece of text has to be highlighted. The result is not crystal clear when loading into a flash-wrapper (as usual), but it’s still way better and is acceptable:

You can't tell, but the text is highlighted with the same blue as the background!

I’m kinda thinking that a better way to go about this is to simply create a custom caption and just using that. I’ll give it a try and post the .bmp files for it. It’ll be a snap to simply change the color of the .bmp files so they’ll be reusable. And the result should be much easier and better than having to go through every line of text and adding highlights to it. Ridiculous!

Published SWF Files

Filesize Comparison

Summary

To my ears, the encoding speed set to 0 sounds the best. And amazingly, it yields the lowest filesize. So far, it seems that a setting of 48-44-0 is the best for voiceover-based Captivate movies. I’ll do some further testing this time will large, real movies that contain slide data and a lot of audio (including some music), for the next post.

More information about the testing methodology can be found in part one of the series.

Encoding Frequency

There are three encoding frequency settings available in Captivate:

For this test, I settled on the following settings for each and simply changed the encoding frequency.

Encoding Bitrate: 48kbps
Encoding Speed: 5 (the default)

As with the last test, each swf was published with the three settings shown on the slide:

Published SWF Files

Published File Size Comparison

As you can see, no matter which encoding frequency is selected the published swf is roughly the same file size. However, if you listen closely you’ll hear that the clarity is slightly better when using the 44.10khz setting. This is not so evident in comparison to the 22khz sample, but definitely if you first listen to the 11khz and then the 44khz. So, it seems that it makes no sense, based on my little test here, to ever drop the encoding frequency to below the default setting of 44khz. I guess I’ll have to try with a larger audio file to see if that makes a difference? Or should I redo these tests with a source audio file that has a short musical intro followed by voiceover audio? Perhaps that would yield more definitive results? If anyone with in-depth knowledge of the meanings behind these settings reads this please comment and/or email me if you can explain some of this stuff better so I can include it here.

Summary

For years I’ve always seemed to settle on using an encoding bitrate of 48kbps. Not due to any real testing other than some quick, under-tight-deadline-pressure, testing. To my ears, this comparison seems to confirm that 48kbps is the proper setting for voiceover audio as it yields good clarity as well as good file size. Listen to the 128kbps sample, followed immediately by the 48kbps sample, and then the 32kbps sample. You’ll hear a definite difference between the three, but the 48kbps is still very good. The 32kbps is somewhat muffled. I don’t think any students/users would know the difference between the upper two, but the 32kbps is muffled enough that it would bother me over time.

In the next part of this series I’ll demonstrate how varying the encoding speed setting effects things.

Comparison Details

While I’m no scientist, I think I adhered to a logical way of approaching this. I of course used the same machine to publish each clip, I used the same exact .cp file for each file (I simply went into the Publish window’s Audio settings and decreased the encoding bitrate, then double-clicked on the single text caption in the movie (residing on the first slide (of two) and set to display throughout project), and then published.

For the audio file, I used the same audio clip that I got from a public domain audio book website. I simply downloaded the full clip, in .ogg format, from the page above and then opened in Audacity to export the first 8 to 10 seconds of it. I exported to .wav format. I of course used the same exact audio file for each published output (again – I used the same exact .cp file repeatedly for each test).

Here are the results for you to compare with your ears:

And, the file sizes:

Captivate Audio Settings File Size Comparison

No, the 16 and 24 bit version filesizes being higher than the higher-quality ones is not a typo. At first I was so surprised that I went and re-checked and re-published. So basically from what I can see there is no point in ever going below 32kbps as you’re gaining filesize and losing quality.

Where I’ll Go From Here

Obviously encoding bitrate is just one of the 3 parameters that can be configured, with the other two being encoding frequency and encoding speed. I will be following this post with some new tests that compare those settings. Eventually, I hope to compile a definitive table and a final recommendation for exactly what settings in Captivate deliver the absolute best ‘value’ in terms of filesize-to-quality ratio. Keep in mind that I am concerned strictly with voiceover audio. I would assume that is what anyone else would care about when it comes to Captivate as well.

Please leave a comment if you have suggestions, or know of an unbiased, definitive comparison that perhaps I missed in my search, or if you have any tips for how I should approach the next batch of tests.

UPDATE: I’ve continued on with the testing. Here is a link to Part Two.

Because the client needed their navigation menu links to target specific frames in particularly long Captivate swf’s, I had to use the rdcmndGotoFrameAndResume variable which I had never had to use before. Frankly, I never bothered using any of the ‘frame-based’ variables before because I never needed to – you really shouldn’t ever have a Captivate swf that is so long that you need to do that. It’s best to modularize everything into individual swf files that are more granular. It’s more flexible and easier to maintain that way. But…back to my point -

I ran into a problem where I banged my head against the wall for 2 hours trying to figure out why this code wasn’t working:

contentContainer_mc.rdcmndGotoFrameAndResume = evt.target.selectedNode.attributes.frame; //the target frame was stated in the XML file…pretty slick actually

There was more to it of course but basically, when the user clicked on particular links in the navigation tree menu, I needed the currently loaded Captivate swf’s playhead to go to the specific frame stated in the XML file’s ‘frame’ attribute.

The result at first (and for 2 hours!), no matter what I tried, was that the playhead would go to the intended frame as hoped, but it would be paused. It wouldn’t ‘resume’ playing. Since there is no ‘rdcmndPlay’ variable I tried rdcmndResume every which way possible. No luck.

Then I stopped, took a breath, and figured it out. You have to insert a pause BEFORE the resume command is issued! Makes sense, but shouldn’t they just have a rdcmndGotoAndPlay variable? These variables are nuts.

So the working solution:

contentContainer_mc.rdcmndPause = 1;
contentContainer_mc.rdcmndGotoFrameAndResume = evt.target.selectedNode.attributes.frame;
contentContainer_mc.rdcmndResume = 1;

Now here’s what’s interesting – the rdcmndGotoFrameAndResume, before I came up with the above solution, was acting like a toggle – so if I clicked on a nav link it would go to the targeted frame but be paused. If I clicked on it again, it would resume playing. Strange? Or am I just too burned out from editing so many crap html sites the past 2 months….