We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
In the Speech-To-Text service, improve that output generated by speaker_labels option.
I have a major call center use case that requires text transcription of 2 distinct voices, a call center rep. and a customer. I need to group the transcribed text by each of these 2 people. The speaker_labels feature returns a list of time ranges, identifying a word in each time range as belonging to one particular speaker. To aggregate the words into sentences and paragraphs, the service consumer must pick words out by timestamp and reconstruct the text for each caller. This is a very clumsy and error-prone task for the consumer. The service should provide blocks of text by speaker, thus eliminating this burden on the caller. This could happen in a couple of different ways:
1) label each set of words from a specific speaker, sort of like reading a movie script OR 2) list all the text for one speaker, then all the text for the next speaker, etc.
Either 1) or 2) would be an improvement over the way speaker_labels output is currently provided.
Since speaker_labels is still in beta, this would be an opportune time in the lifecycle of that feature to implement this improvement. I am more than willing to participate in the testing of an improved speaker_labels feature.
Do not place IBM confidential, company confidential, or personal information into any field.