Posted: November 25 2003 at 4:56pm | IP Logged

I've been testing an Osprey-100 with Windows Media Encoder 9.  While the capture seems to work fine, there seems to be a difference of opinion about how to interpret what constitutes a 'script' in WME9.  When a multi-line caption is captured, WME considers a separate script to have been captured for each line of the caption.  When the captured video is played back in WM Player 9, the first line of the caption flashes in the caption area very briefly, then is replaced by the next line.

Has anyone else seen this, and are there any known fixes?

Posted: December 19 2003 at 11:04am | IP Logged

Yes, this is a known problem with Windows Media Encoder that it only displays a single line of CC text at a time.  To address this you can use a free tool that will capture a separate CC text stream which can then be incorporated into a *.SAMI file.  You can download the tool from the ViewCast website, ftp://ftp.viewcast.com/pub/tools/captioning/2.0/

Good luck with your project,

-Steve

Posted: December 20 2003 at 11:42pm | IP Logged

It doesn't appear that this approach will work with streaming video.  Do you know if Microsoft is aware of the problem?

Posted: January 01 2004 at 12:21pm | IP Logged

Steve,

  When I tried the captioning tool you suggested, it was unable to detect my Osprey card, though other software (e.g., CC Demonstration, WME9) could see it.  Any idea what the problem might be?

Thanks,

DVDman

Posted: January 05 2004 at 12:14pm | IP Logged

The cc capture tool does work with VOD and live streaming.  What version of the Osprey drive are you using?  If it is 3.0.0 or later (and I'm guessing that it is, otherwise it WME doesn't recognize the Osprey as a scripting device) then you may want to consider utilizing version 2.2.2 of the drivers as the utility only works with that version or earlier.

I'm sorry that I didn't remember that when I recommended that you try the cc app.

I'm afraid I can't speak to Microsoft's awareness of the problem of their CC scripting only revealing one line of text at a time.  I will, however, look in to some other ways of getting around this problem and let you know what I come up with.   I'm hoping a customized player can be used or perpahs two instances of WME and a SAMI file will adress this...

More to come!

Posted: January 13 2004 at 4:56pm | IP Logged

Glad to hear that you found a resolution.  How do you determine the minimum duration?  What prevents the CC from lagging way behind the audio/video by having it displayed for a minimum period of time?

Another thought I had on this subject was the possibility of using a custom player skin that has more space in the cc data area so that multiple lines of cc data would be displayed at once.  It may address both issues, that way.

-S.

Posted: January 13 2004 at 7:33pm | IP Logged

Well, there's a published standard that says the minimum display duration for any caption should be 2 seconds.  It goes on to recommend a word-per-minute rate of about 160 wpm for middle schoolers, up to 240 wpm or so for average adult readers

While that's great guidance if you're writing your own captions, it's a bit less helpful if you're encoding captions from existing material.  So what I did was combine captions that fall within a desired 'minimum display' period into a single caption.  When I find a caption that's outside that period, I write out the combined caption as a single script that is displayed all at once at the original start time of the first caption.  The process begins all over again with the first caption outside the time period.

The net effect is that the longer combined captions are displayed for at least the minimum specified period.  The next caption is displayed at its original start time, so there's no cumulative time lag.  You do lose a bit of sychronicity with the audio track, and that will probably be disconcerting to a viewer with normal hearing who watches the cc version.  But a hearing-impaired individual will find the result to be much more usable.  Since that was my goal, I'm pretty happy with the compromise.  Hope my customer is too. 

By the way, I installed v2.2 of the driver and captured SAMI files too, and really liked the results (they were actually very similar to those my program produces).  But that approach would require capturing each tape twice, and then do much of the manual processing my approach requires.  The cost of that approach is too high for my application.

Posted: January 14 2004 at 9:21am | IP Logged

I like your approach, it's well thought out and the best part is that there is no cumulative lag, which was the first thing I thought about.  You wouldn't want the cc data to end up 5 minutes behind at the end of a long stream.

On a separate note re SAMI files using the cc2streams tool, using Osprey's SimulStream allows you to capture the audio/video stream and cc data stream simultaneously.  More info about SimulStream can be found at http://www.viewcast.com/simulstream_main.html.

I played with a customized player and didn't have good results, so the solution you're using now, or creating a SAMI file, seem to be the best way to go about it for now!

-S.