RE: approaches to recording

Harald,

The lack of real-time delivery is not normally an issue for speech
recognition systems, because they run many times faster than real time,
and can catch up quickly once the data is available.  So if the delays
are short enough, the user will not perceive them.  And if the delays
are longer, well... then speech recognition will take a long time.
People are used to stuff being slow on the internet, aren't they?

 

-          Jim

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Friday, October 12, 2012 11:35 AM
To: public-media-capture@w3.org
Subject: Re: approaches to recording

 

On 10/11/2012 12:50 AM, Jim Barnett wrote:

	I just want to observe that lossless streaming is what we (= the
contact center and speech industry) want for  talking to a speech
recognition system.  It would be ideal if PeerConnection supported it.
Failing that, it would be nice if the Recorder supported it,  but in a
pinch we figure that we can use the track-level API to deliver buffers
of speech data and let the JS code set up the TCP/IP connection.  

	 

Of course lossless streaming (truly guaranteed delivery) implies
non-real-time streaming (or, more formally, having to deal with the
possibility that delivery will be delayed beyond real-time), given that
the Internet is a lossy medium.

To another thread: Yes, having the constructor for the recorder take a
MIME type parameter would imply that you set the codec to be used. I
think we all agree that the data coming out of a recording interface is
encoded.

           Harald