Functional Attributes/Basic Operational Theory

• Powered by state-of-the-art IBM ViaVoice speech recognition technology
• Provides speech recognition and conversion to text at the request of a client application (not provided as part of WizzScribe) through the server API.
• Rich set of COM/DCOM interfaces, which support OLE automation. Clients can be implemented using any automation supported languages including C/C++ or Visual Basic. DCOM provides the transport layer so that a client can access the server remotely. The following types of services are available through the API:
  
  
  • creating and managing speech user profiles
  • personalizing speech profiles
  • transcribing audio to text
  • basic server management
  • results log reporting
  
  
• Processes variety of audio inputs and convert them directly to text
• Ability to continually improve recognition accuracy over time to achieve optimum results
• Supports acoustic adaptation so audio can be captured in different environments
• Ability to add custom words and custom pronunciations to the vocabulary
• Ability to adapt word usage depending on context
• Handles user enrollments, create and manage user profiles, and support custom pronunciations for each user.
• Supports scalability that allows multiple WizzScribe Servers to handle large volumes of audio processing. When used for dictation applications, multiple WizzScribe Servers can be easily configured to share user profiles and provide scalability for customers that require faster turnaround. A configuration utility provides easy setup for access to speech user profiles shared on a network.

Voice audio is captured by a workflow application running in a Client system. The audio file, in .wav format, can originate from a variety of devices ranging from noise- canceling microphones for optimum recognition to digital recorders or telephones' and in some cases even mobile phones although there may be a substantial degradation of accuracy at this end of the input device range.

Next, the workflow application submits a request for transcription to WizzScribe to begin processing, using the application programming interfaces (APIs) provided. An example of information critical to this client/server request is the user associated with the .wav file. The server maintains a database of user profiles, containing the user's name (a single user may use multiple profiles for different acoustic environments or enrollments) and the language used for the transcription (each enrollment may have only one language associated with it.)
A client workflow application may be Attached to multiple servers and in this instance workload balancing across these servers is a responsibility of the client application.

Once the client/server session is established, the server accepts the .wav file and transcribes it into text. This text is then returned to the workflow application on the client, where it can be forwarded to reviewers for editing and then returned to the workflow application, from where the text can be made available to the user.
Typically, a single server is used to handle transcription loads for small to medium sized transcription services. For larger installations, where the volume of transcriptions requests is high and the turnaround time is essential, the user workflow application in the client machine can be modified to manage multiple transcription servers. Each server machine is treated as a separate operational entity and user profiles can be associated with a single server or applied to multiple servers.