नेविगेशन पर जाएँ

ट्रांसक्रिप्ट और कमिट रणनीतियां

यह गाइड बताती है कि ElevenLabs Realtime स्पीच टू टेक्स्ट API के साथ ट्रांसक्रिप्ट और कमिट रणनीतियों को कैसे संभालें।

कैसे करें गाइड · मानता है कि आपने क्लाइंट-साइड या सर्वर-साइड स्ट्रीमिंग गाइड पूरी कर ली है।

ओवरव्यू

ऑडियो ट्रांसक्राइब करते समय, आपको आंशिक और कमिट किए गए ट्रांसक्रिप्ट मिलेंगे।

  • आंशिक ट्रांसक्रिप्ट - ट्रांसक्रिप्शन के अंतरिम परिणाम
  • कमिट किए गए ट्रांसक्रिप्ट - ट्रांसक्रिप्शन सेगमेंट के अंतिम परिणाम, जो “commit” मैसेज मिलने पर भेजे जाते हैं। एक सेशन में कई कमिट किए गए ट्रांसक्रिप्ट हो सकते हैं।

कमिट ट्रांसक्रिप्ट में वैकल्पिक रूप से शब्द-स्तरीय टाइमस्टैम्प हो सकते हैं। ये केवल तब मिलते हैं, जब “include timestamps” विकल्प true पर सेट हो।

# Initialize the connection
connection = await elevenlabs.speech_to_text.realtime.connect(RealtimeUrlOptions(
model_id="scribe_v2_realtime",
include_timestamps=True, # Include this to receive the RealtimeEvents.COMMITTED_TRANSCRIPT_WITH_TIMESTAMPS event with word-level timestamps
))

कमिट रणनीतियां

WebSocket के ज़रिए ऑडियो चंक्स भेजते समय, ट्रांसक्रिप्ट सेगमेंट दो तरीकों से कमिट किए जा सकते हैं: मैन्युअल कमिट या वॉइस एक्टिविटी डिटेक्शन (VAD)।

मैन्युअल कमिट

मैन्युअल कमिट रणनीति के साथ, आप तय करते हैं कि ट्रांसक्रिप्ट सेगमेंट कब कमिट करने हैं। यह डिफ़ॉल्ट रूप से इस्तेमाल की जाने वाली रणनीति है। किसी सेगमेंट को कमिट करने पर प्रोसेस किया गया जमा हुआ ट्रांसक्रिप्ट साफ़ हो जाता है और कॉन्टेक्स्ट खोए बिना नया सेगमेंट शुरू हो जाता है। लेटेंसी बेहतर करने के लिए हर 20-30 सेकंड में कमिट करना अच्छा तरीका है। अगर आप मैन्युअल रूप से कमिट नहीं भी करते हैं, तो मॉडल लगभग 36 सेकंड के जमा हुए ऑडियो के बाद अपने-आप कमिट कर देता है।

सर्वोत्तम नतीजों के लिए, साइलेंस पीरियड के दौरान या टर्न मॉडल जैसे किसी अन्य तार्किक बिंदु पर कमिट करें।

ऑडियो के पहले 2 सेकंड भेजे जाने के बाद ट्रांसक्रिप्ट प्रोसेसिंग शुरू होती है।
await connection.send({
"audio_base_64": audio_base_64,
"sample_rate": 16000,
})
# When ready to finalize the segment
await connection.commit()

कम समय में लगातार कई बार मैन्युअल रूप से कमिट करने से मॉडल की परफ़ॉर्मेंस घट सकती है।

पिछला टेक्स्ट कॉन्टेक्स्ट भेजना

ट्रांसक्रिप्शन के लिए ऑडियो भेजते समय, मॉडल को स्पीच का कॉन्टेक्स्ट समझने में मदद करने के लिए आप पहले ऑडियो चंक के साथ पिछला टेक्स्ट कॉन्टेक्स्ट भेज सकते हैं। यह कुछ स्थितियों में उपयोगी है:

  • कन्वर्सेशनल AI इस्तेमाल के मामलों के लिए एजेंट टेक्स्ट - इससे मॉडल बातचीत का कॉन्टेक्स्ट आसानी से समझता है और बेहतर ट्रांसक्रिप्शन तैयार करता है।
  • नेटवर्क त्रुटि के बाद फिर से कनेक्ट करना - इससे मॉडल पिछले टेक्स्ट को मार्गदर्शन के रूप में इस्तेमाल करके ट्रांसक्राइब करना जारी रख सकता है।
  • सामान्य संदर्भ जानकारी - ट्रांसक्रिप्शन किस बारे में होगा, इसका छोटा विवरण मॉडल को कॉन्टेक्स्ट समझने में मदद करता है।

previous_text कॉन्टेक्स्ट केवल connection.send() के ज़रिए पहला ऑडियो चंक भेजते समय भेजा जा सकता है। इसे बाद के चंक्स में भेजने पर त्रुटि आएगी। पिछला टेक्स्ट तब सबसे अच्छा काम करता है, जब वह 50 वर्णों से कम हो।

await connection.send({
"audio_base_64": audio_base_64,
"previous_text": "The previous text context",
})

वॉइस एक्टिविटी डिटेक्शन (VAD)

VAD रणनीति के साथ, ट्रांसक्रिप्शन इंजन स्पीच और साइलेंस सेगमेंट का अपने-आप पता लगाता है। साइलेंस थ्रेशोल्ड पूरा होने पर, ट्रांसक्रिप्शन इंजन ट्रांसक्रिप्ट सेगमेंट को अपने-आप कमिट कर देगा।

क्लाइंट-साइड इंटीग्रेशन में माइक्रोफ़ोन से ऑडियो ट्रांसक्राइब करते समय, VAD रणनीति इस्तेमाल करने की सलाह दी जाती है।

vad_silence_threshold_secs 0.192 से 3.0 सेकंड स्वीकार करता है। JavaScript और React SDK केवल 0.3 से 3.0 स्वीकार करते हैं।

import { Scribe, AudioFormat, CommitStrategy } from "@elevenlabs/client";
const connection = Scribe.connect({
token: "sutkn_1234567890",
modelId: "scribe_v2_realtime",
audioFormat: AudioFormat.PCM_16000,
commitStrategy: CommitStrategy.VAD,
vadSilenceThresholdSecs: 1.5,
vadThreshold: 0.4,
minSpeechDurationMs: 100,
minSilenceDurationMs: 100,
});

बैकग्राउंड ऑडियो फ़िल्टर करना

आस-पास की बातचीत जैसी बैकग्राउंड स्पीच और परिवेशी शोर से होने वाले गलत एक्टिवेशन कम करने के लिए filter_background_audio=true क्वेरी पैरामीटर सेट करें। फ़िल्टरिंग चालू होने पर, वॉइस एक्टिविटी डिटेक्शन बैकग्राउंड स्पीच को अनदेखा करने के लिए ट्यून किए गए मॉडल का इस्तेमाल करता है और, जब तक आप खुद इसे सेट न करें, vad_threshold डिफ़ॉल्ट रूप से 0.15 होता है।

filter_background_audio को include_timestamps के साथ नहीं जोड़ा जा सकता। अगर आप दोनों सेट करते हैं, तो सर्वर invalid_request त्रुटि भेजता है और कनेक्शन बंद कर देता है।

फ़िल्टरिंग से बिलिंग नहीं बदलती: फ़िल्टर जिस ऑडियो को अनदेखा करता है, वह भी शामिल है और आपके स्ट्रीम किए गए सभी ऑडियो का बिल बनता है।

साइलेंस के दौरान कनेक्शन चालू रखना

कोई मैसेज न आने पर आधिकारिक SDK कनेक्शन नहीं छोड़ते, इसलिए ज़्यादातर इंटीग्रेशन में इसकी ज़रूरत नहीं होती। अगर आपका खुद का WebSocket क्लाइंट, या बीच में मौजूद प्रॉक्सी या लोड बैलेंसर, कुछ समय तक फ्रेम न आने पर कनेक्शन बंद कर देता है, तो कनेक्ट करते समय वैकल्पिक keepalive_interval_ms क्वेरी पैरामीटर भेजें। यह लंबे साइलेंस के दौरान महत्वपूर्ण है, जैसे 10-15 सेकंड के पॉज़ वाली फ़ोन कॉल में। हर इंटरवल में लगभग एक बार, सर्वर keepalive partial_transcript भेजता है: अगर मौजूदा सेगमेंट में कोई अनकमिटेड टेक्स्ट नहीं है तो खाली (text: ""), या अगर है तो नवीनतम आंशिक टेक्स्ट दोबारा भेजता है।

Keepalive कोई लगातार चलने वाला पिंग नहीं है: आपको ऑडियो स्ट्रीम करते रहना होगा (साइलेंस फ्रेम भी ठीक हैं)। अगर आप ऑडियो भेजना बंद कर देते हैं, तो कोई keepalive नहीं भेजा जाता और सर्वर क्लाइंट के किसी भी मैसेज के बिना 15 सेकंड बाद कनेक्शन बंद कर देता है। यह सर्वर सीमा कॉन्फ़िगर नहीं की जा सकती।

  • 500 और 10000 (मिलीसेकंड) के बीच का पूर्णांक स्वीकार करता है। यह डिफ़ॉल्ट रूप से बंद है; मौजूदा व्यवहार बनाए रखने के लिए पैरामीटर छोड़ दें।
  • सीमा से बाहर या गैर-पूर्णांक वैल्यू होने पर सर्वर invalid_request त्रुटि भेजता है और कनेक्शन बंद कर देता है।
  • Keepalive आपके भेजे गए साइलेंट ऑडियो को मॉडल द्वारा वास्तव में प्रोसेस किए जाने पर आधारित होते हैं, किसी लगातार चलने वाले टाइमर पर नहीं, इसलिए ये यह भी पुष्टि करते हैं कि ट्रांसक्रिप्शन पाथ चालू है।
  • ऑडियो लगभग 1-सेकंड के चंक्स में प्रोसेस होता है, इसलिए keepalive इस कैडेंस के अनुसार राउंड किए गए इंटरवल में आते हैं (उदाहरण के लिए, 1000 लगभग हर सेकंड और 3000 लगभग हर 3 सेकंड में ट्रिगर होता है)। सेशन का पहला keepalive शुरू होने के लगभग 2 सेकंड बाद आता है, क्योंकि सर्वर ट्रांसक्राइब करने से पहले पहले ~2 सेकंड के ऑडियो को बफ़र करता है। पर्याप्त मार्जिन रखने के लिए अपना इंटरवल अपने रीड टाइमआउट के लगभग एक-तिहाई या उससे कम रखें।
  • Keepalive का text केवल तब खाली होता है, जब मौजूदा सेगमेंट में अभी कोई अनकमिटेड टेक्स्ट नहीं है। अगर स्पीच के बाद लेकिन कमिट से पहले पॉज़ होता है — जो filter_background_audio=true या बिना कमिट वाले मैन्युअल कमिट मोड में सबसे अधिक दिखता है — तो keepalive इसके बजाय नवीनतम आंशिक टेक्स्ट दोहराता है, इसलिए यह अंतरिम टेक्स्ट को कभी खाली नहीं करता। कमिट के बाद, नया स्पीच आने तक keepalive फिर से खाली हो जाते हैं।
  • commit_strategy=manual और commit_strategy=vad दोनों के साथ, और filter_background_audio=true के साथ काम करता है। आप जो ऑडियो पहले से स्ट्रीम कर रहे हैं, उसके अलावा बिलिंग पर कोई असर नहीं पड़ता।
  • session_started मैसेज का config, keepalive_interval_ms वापस दिखाता है (बंद होने पर null)।

खाली partial_transcript (text: "") का अर्थ है “मौजूदा सेगमेंट में कोई स्पीच नहीं है।” पॉज़ के दौरान दोहराया गया, समान partial_transcript भी keepalive है — क्लाइंट को दोहराव के लिए अलग हैंडलिंग करने के बजाय आंशिक ट्रांसक्रिप्ट को वैसे ही रेंडर करना चाहिए जैसे वे पहले से करते हैं।

WebSocket URL में पैरामीटर जोड़ें:

wss://api.elevenlabs.io/v1/speech-to-text/realtime?model_id=scribe_v2_realtime&commit_strategy=vad&keepalive_interval_ms=1000

समर्थित ऑडियो फ़ॉर्मैट

फ़ॉर्मैटसैंपल रेटविवरण
pcm_80008 kHz16-बिट PCM, लिटिल-एंडियन
pcm_1600016 kHz16-बिट PCM, लिटिल-एंडियन (अनुशंसित)
pcm_2205022.05 kHz16-बिट PCM, लिटिल-एंडियन
pcm_2400024 kHz16-बिट PCM, लिटिल-एंडियन
pcm_4410044.1 kHz16-बिट PCM, लिटिल-एंडियन
pcm_4800048 kHz16-बिट PCM, लिटिल-एंडियन
ulaw_80008 kHz8-बिट μ-law एन्कोडिंग

सर्वोत्तम तरीके

ऑडियो क्वालिटी

  • बेहतरीन नतीजों के लिए, क्वालिटी और बैंडविड्थ के बेहतर संतुलन हेतु 16kHz सैंपल रेट इस्तेमाल करें।
  • कम से कम बैकग्राउंड शोर के साथ साफ़ ऑडियो इनपुट सुनिश्चित करें।
  • क्लिपिंग से बचने के लिए उपयुक्त माइक्रोफ़ोन गेन इस्तेमाल करें।
  • फ़िलहाल केवल मोनो ऑडियो समर्थित है।

चंक साइज़

  • सहज स्ट्रीमिंग के लिए 0.1 - 1 सेकंड लंबे ऑडियो चंक्स भेजें।
  • छोटे चंक्स से लेटेंसी कम होती है, लेकिन ओवरहेड बढ़ता है।
  • बड़े चंक्स ज़्यादा कुशल होते हैं, लेकिन लेटेंसी बढ़ा सकते हैं।

अगले चरण