लेबल लगाइएको ट्रान्सक्रिप्टलाई दुवै उत्तर सही चाहिन्छ। लेबल शब्दहरूको माथि बस्ने भएकाले, गलत लेबल पाठ नछुइकन सच्याउन सकिन्छ।
बैठकको ट्रान्सक्रिप्टले एकैपटक दुई प्रश्नको उत्तर दिन्छ: के भनियो, र कसले भन्यो। पाठकले एउटा काम मात्र देख्छ: प्रत्येक पंक्तिको छेउमा एउटा नाम। तर त्यसको मुनि दुई समस्या हुन्छन्, जसका आफ्नै इनपुट र आफ्नै असफल हुने तरिकाहरू छन्।
वाक् पहिचानले शब्दहरू सुन्छ। यसले अडियोलाई पाठमा बदल्छ, र राम्रोसँग चल्दा प्रत्येक शब्दको सुरु र अन्त्यको समय पनि दिन्छ। वाक्यको बीचमा आवाज बदलियो कि बदलिएन भन्ने कुरासँग यसलाई सरोकार हुँदैन; यसको काम वाक्य सही बनाउनु हो।
वक्ता डायराइजेसनले आवाजहरू सुन्छ। यसलाई कुनै शब्द थाहा हुँदैन। यसको काम समय-रेखालाई बारीमा विभाजन गर्नु र कुन बारी एउटै व्यक्तिको हो भन्नु हो: वक्ता 1, वक्ता 2। यो शब्द “diary” बाट लिइएको हो, र यसले आउटपुटको राम्रो चित्र दिन्छ: कसले कहिले बोलेको थियो भन्ने लग।
यसँग मिल्दाजुल्दा तीनवटा शब्द प्रायः गडबडिन्छन्। डायराइजेसनले कसलाई चिनेर होइन, कसले कहिले बोल्यो भन्छ। वक्ता पहिचानले दर्ता गरिएका आवाजहरूको सेटबाट छनोट गरेर, बोलीको कुन भाग कुन चिनिएको व्यक्तिको हो भन्छ। वक्ता प्रमाणीकरणले हो वा होइन भन्ने प्रश्नको उत्तर दिन्छ: के यो आवाज साँच्चै व्यक्ति X को हो? तीनलाई छुट्याएर हेरेपछि विक्रेताका दाबीहरू बुझ्न सजिलो हुन्छ, किनभने “वक्ता लेबल” भन्नाले बारीको सिमानाको कच्चा अनुमानदेखि एउटै व्यक्तिलाई एउटा रेकर्डिङबाट अर्कोमा पछ्याउने नामसम्म केही पनि हुन सक्छ। ती लेबलले के वाचा गर्न सक्छन् र सक्दैनन् भनी हेर्न, डायराइजरभित्र हेर्नुपर्छ।
अधिकांश डायराइजेसन प्रणालीहरू तीन चरणमा काम गर्छन्, जसमध्ये कुनै पनि भाषासँग सम्बन्धित हुँदैन।
प्रत्येक चरण आफैँमा गलत हुन सक्छ। शान्त वक्ता छुट्न सक्छ। मिल्दोजुल्दो दुई आवाज मिसिन सक्छन्। शान्तबाट उत्साहित अवस्थामा सर्ने एउटै व्यक्ति दुई भागमा बाँडिन सक्छ।
यस क्षेत्रमा यी सबैलाई डायराइजेसन एरर रेट, DER, ले नाप्छ: बोलीको समयमध्ये छुटेको, गलत रूपमा बोली भनी पहिचान भएको, वा गलत वक्तालाई दिइएको भागको हिस्सा, सामान्यतया हरेक सिमानाको वरिपरि करिब एक सेकेन्डको चौथाइ क्षमाको क्षेत्र (collar) सहित। यो क्षेत्र किन चाहिन्छ भने मानिस वा मेसिन, कसैले पनि वक्ता परिवर्तनलाई मिलिसेकेन्डसम्म ठेगान लगाउन सक्दैन। डायराइजरलाई एक्लै नाप्दा त्यो सहनशीलता ठीक हुन्छ। ट्रान्सक्रिप्टका लागि भने ठीक हुँदैन, किनभने एक सेकेन्डको चौथाइ विचलित भएको सिमाना एउटा शब्दमा पर्छ।
यहीँ दुई समस्या भेट्छन्, र लेबल लगाइएको ट्रान्सक्रिप्टको गुणस्तर यहीँ तय हुन्छ। डायराइजरले आफ्ना सिमाना केही अशुद्धताका साथ राख्छ, प्रायः दुवैतिर एक सेकेन्डको अंश। वाक् पहिचानकर्ताले शब्दहरू उही समय-रेखामा राख्छ। दुवैलाई सरल रूपमा एकअर्कामाथि राख्दा सिमाना शब्दभित्र पर्छ, र “भोलि” शब्दको आधा भाग वक्ता 1 को र बाँकी आधा वक्ता 2 को हुन्छ।
लेबल सही हुनुअघि केही समयसम्म गलत पनि हुन सक्छ। डायराइजरले जति धेरै अडियो सुन्छ, त्यति नै आफ्ना समूहप्रति बढी निश्चित हुन्छ, त्यसैले सुरुको लेबल पछि आउने कुराको मापदण्डमा गलत देखिन सक्छ। लाइभ ट्रान्सक्रिप्टमा पंक्ति देखाइसकेपछि पनि लेबल संशोधन हुन सक्छ: VocalStack को realtime API ले transcript.amended फ्रेम पठाउँछ, जसले पक्का भइसकेको पंक्तिको पाठ वा वक्तालाई ठाउँमै सच्याउँछ, ताकि पाठकले विरोधाभास होइन, संशोधन देख्छ।
सबैभन्दा सही र स्थिर लेबल पनि एउटा संख्या मात्र हो। संख्याले कुराकानी पछ्याउन पुग्छ; तर मानिसहरू पढ्न चाहन्छन् नाम।
लेबल दुई तरिकाले नाम बन्छ, र ती एकअर्कामा आधारित छन्।
पहिलो हो एउटै रेकर्डिङभित्र नामकरण। ट्रान्सक्रिप्सनले भेटेको हरेक वक्ताले 0 बाट गणना गरिएको सूचकांक पाउँछ। पहुँच भएको जोसुकैले रेकर्डिङको बेला वा पछि प्रत्येक वक्ताको नाम राख्न सक्छ। नाम शब्दहरूको माथिको तह हो, त्यसैले पाठ नछुइकन यसलाई राख्न, बदल्न वा हटाउन सकिन्छ। API मार्फत यो name सहित PUT /v1/recordings/{id}/speakers/{idx} हो; खाली नामले यसलाई हटाउँछ। जसको speaker -1 हुन्छ, त्यस पंक्तिमा लेबल हुँदैन: या त लेबल बन्द थियो, या लाइभ ड्राफ्टमा पंक्तिलाई अझै वक्तासँग जोडिएको छैन।
दोस्रो हो रेकर्डिङहरूभरि पहिचान, जुन पहिलो खण्डको पहिचान समस्या हो। डायराइजरले दुई आवाज फरक छन् भन्न मात्र सक्छ, तिनीहरू को हुन् भन्न कहिल्यै सक्दैन। “फरक” बाट “यो अना हो” सम्म पुग्न प्रणालीलाई सन्दर्भ चाहिन्छ: एउटा बचत गरिएको आवाज, जुन त्यही एक व्यक्तिको रेकर्डिङबाट लिइएको हुन्छ। सफा बोलीका कम्तीमा तीस सेकेन्ड चाहिन्छ, र केही मिनेट भएमा झन् राम्रो। नमुना त्यही रेकर्डिङहरूजस्तो सुनिनुपर्छ जसँग यसलाई मिलाइनेछ: एउटै व्यक्ति ल्यापटप माइक्रोफोन र स्टेज माइक्रोफोनमा रेकर्ड भएको भए, एउटै तरिकाले रेकर्ड भएका दुई अपरिचितभन्दा मेसिनलाई कम मिल्दो लाग्न सक्छ। एक पटक आवाज बचत भएपछि, ट्रान्सक्रिप्सनले सुनेको हरेक वक्तालाई त्यससँग तुलना गरिन्छ, र मिलेमा नाम ट्रान्सक्रिप्टमा आउँछ। VocalStack मा यो Voices अन्तर्गत बस्छ; फाइल ट्रान्सक्रिप्सन र ड्यासबोर्डका लाइभ सत्रहरूले तपाईंका बचत गरिएका आवाजहरू स्वतः मिलाउँछन्, र realtime API सत्रले identifyVoices मा तपाईंले सूचीबद्ध गरेका आवाजहरूमात्र पहिचान गर्छ।
बचत गरिएको आवाज बायोमेट्रिक डेटा हो: यसले कुनै पनि रेकर्डिङमा व्यक्तिलाई चिन्न सक्छ, र VocalStack मा यो व्यक्तिका वाक्य बोलेर पढ्न सक्ने क्लोनको रूपमा पनि काम गर्छ। ड्यासबोर्डले आवाज बचत गर्नुअघि त्यो व्यक्तिको अनुमति छ भनी पुष्टि गर्न सोध्छ, र आवाज जुनसुकै बेला मेटाउन सकिन्छ।
यी सबै कुरा लेबल चाहिन्छ भन्ने अनुमानमा आधारित छन्। धेरैजसो अवस्थामा चाहिँदैन।
व्याख्यान पढ्ने एक जना व्यक्तिलाई हरेक पंक्तिअघि “वक्ता 1” चाहिँदैन। माइक्रोफोन कसको हातमा छ भन्ने श्रोतालाई पहिले नै थाहा हुन्छ। त्यसैले वक्ता-लेबल सेटिङका तीन स्थिति छन्, र ती realtime सत्र, प्रसारण, ट्रान्सक्रिप्सन र रेकर्डिङ सबैमा उस्तै हुन्छन्।
auto)। एकभन्दा बढी आवाज सुनिएपछि पंक्तिहरूमा वक्ताको लेबल लगाइन्छ; एक वक्ताको रेकर्डिङ सादा पाठमै रहन्छ, र ढिलो सामेल हुने दोस्रो आवाज पनि समात्छ। ड्यासबोर्डको नयाँ लाइभ ट्रान्सक्रिप्सन फारम यही स्थितिबाट सुरु हुन्छ।फाइल अपलोडले पनि उही speakerLabels विकल्प लिन्छ, र realtime API ले प्रवाहको बीचमै यसलाई बदल्न दिन्छ; विवरण API सन्दर्भ मा छन्। वक्ता छुट्याउने र नामकरणले बिलमा कहिल्यै थप गर्दैन (मूल्य पृष्ठ मा दर तालिका छ), त्यसैले छनोट पाठकले के देख्नुपर्छ भन्नेमा निर्भर गर्छ, त्यसको लागत कति हुन्छ भन्नेमा होइन।
सक्रिय गर्दा डायराइजेसन राम्रो हुन्छ, तर जादू होइन। अझै पनि दुई अवस्थाले यसलाई हराउँछन्।
पहिलो हो ओभरल्याप। जब दुई जना एकसाथ बोल्छन्, अडियोको एउटै भागमा दुई आवाज हुन्छन्। ओभरल्याप बुझ्ने डायराइजर अनुसन्धानमा छ, र बिस्तारै उत्पादनहरूमा पनि आइरहेका छन्: जस्तै end-to-end neural diarization (EEND) ले “को बोल्दै छ” लाई एउटै उत्तरको सट्टा एकसाथका हाँ-वा-होइन प्रश्नहरूको सेटका रूपमा हेर्छ। तर धेरैजसो उत्पादन प्रणालीहरूले अझै एउटा अन्तरालमा एक वक्ता तोक्छन्, र माथिको वाक् पहिचानकर्ताले एकैपटक एउटा आवाज मात्र ट्रान्सक्रिप्ट गर्छ। तातो प्यानलमा एकै समयमा बोलिने कुराकानी (crosstalk) यस क्षेत्रको सबैभन्दा कठिन अडियो हो, र हरेक विक्रेताका लेबल त्यहाँ झन् खराब हुन्छन्। यो भाग, भरोसासाथ भन्न सकिन्छ, पछि सबैले उद्धरण गर्न चाहने हिस्सा पनि हो।
दोस्रो हो धेरै मिल्दाजुल्दा आवाजहरू। दाजुभाइ-दिदीबहिनीले एकअर्काबाट भरोसासाथ अलग गर्न नसकिने गरी नजिक एम्बेडिङ उत्पादन गर्न सक्छन्, विशेषगरी जब तिनीहरू एक घन्टासम्म छोटा बारी साटिरहन्छन्। टेलिफोन अडियोले यो सबैका लागि झन् बिग्रन्छ: न्यारोब्यान्ड लाइन 8 kHz मा नमुना लिइन्छ र लगभग 3.4 kHz भन्दा माथि केही पनि बोक्दैन, तर एउटा आवाजलाई अर्कोबाट छुट्याउने धेरै कुरा त्यस सीमाभन्दा माथि हुन्छन्। एउटै फोन लाइनमा रहेका दुई व्यक्ति डायराइजरलाई तपाईंलाई लाग्नेभन्दा बढी उस्तै लाग्छन्।
दुवै समस्याको सबैभन्दा व्यावहारिक उपाय कुनै पनि मोडेलभन्दा अगाडि हुन्छ: प्रत्येक व्यक्तिलाई आफ्नै माइक्रोफोन दिनुहोस्। प्रति वक्ता एउटा च्यानल भएमा, डायराइजेसन “कुन च्यानल चर्को छ?” भनी सोध्ने काममा सीमित हुन्छ, ओभरल्याप एउटा धमिलो ट्र्याकको सट्टा दुईवटा सफा ट्र्याक बन्छ, र एम्बेडिङलाई कठिन काम गर्न कहिल्यै लगाइँदैन। एउटा टेबल माइक्रोफोन सस्तो हुन्छ र लगभग सधैँ तपाईंसँग भएको कुरा हो, त्यसैले यो लेखको बाँकी भाग अस्तित्वमा छ।
यी दुवै सीमा पाठकसम्म जस्ताको तस्तै पुग्नुपर्दैन। लेबल शब्दहरूको माथिको तह भएकाले, गलत लेबलले कहिल्यै पाठ गुमाउँदैन: रेकर्डिङमा वक्ताका नाम जुनसुकै बेला राख्न वा हटाउन सकिन्छ, र लाइभ ट्रान्सक्रिप्सनमा होस्टले चलिरहँदा पनि कुनै शब्द वा पंक्ति फेरि लेख्न सक्छ, जहाँ हरेक सुधार चिन्ह लगाइएको र फिर्ता लिन मिल्ने हुन्छ।
शब्दहरूको पक्षका लागि, शब्द त्रुटि दर (word error rate) ले के नाप्छ र के छुटाउँछ ले सुधार तहहरूको विस्तृत विवरण दिन्छ; WER वाक् पहिचानकर्ताका लागि त्यस्तै हो जस्तै DER डायराइजरका लागि हो, र ट्रान्सक्रिप्टलाई दुवै कम हुनुपर्छ।