TTS, Forced Alignment و Word Sync

وقتی timestamp شبیه «حقیقت» به نظر می‌رسد

یک پاراگراف واحد را در دو مرورگر با TTS اجرا می‌کنیم. مرورگر A برای بعضی کلمات boundary با charIndex می‌دهد؛ مرورگر B فقط boundary در سطح جمله دارد. هم‌زمان، یک forced aligner روی فایل صوتی جداگانه زمان هر token را تخمین زده، اما نزدیک یک علامت نگارشی ۱۸۰ میلی‌ثانیه drift دیده می‌شود. اگر UI بدون سؤال بعدی همان token را highlight کند، دارد precision جعل می‌کند.

هدف این درس ساخت Speech Timing & Word Synchronization Contract v1 است: متن و token باید identity مشخص داشته باشند؛ هر timing باید source و timebase معلوم داشته باشد؛ confidence و drift باید جدا ثبت شوند؛ و وقتی word-level evidence قابل دفاع نیست، سیستم باید به sentence/cue fallback برود، نه اینکه timestamp ضعیف را به «sync دقیق» ارتقا دهد.

مسیر درس و مرز مالکیت

MKN-010 مالک TTS، Forced Alignment و Word Sync است. MKN-007 پیش‌نیاز سخت مفهومی و MKN-009 پیش‌نیاز نرم است. این درس scheduler درس قبل را طراحی نمی‌کند و accessibility کل تجربه چندرسانه‌ایِ MKN-011 را هم جذب نمی‌کند. سؤال ما محدود است: برای ادعای هم‌زمانی یک token با audio، چه evidence لازم است و وقتی evidence ضعیف شد چگونه granularity را کاهش دهیم؟

برای مسیر Foundation، field map و یک baseline کامل داریم. در مسیر Repair فقط بُعد خراب‌شده ــ مثلاً text_version یا drift_ms ــ isolate می‌شود. در مسیر Experienced، label نهایی حذف می‌شود و learner باید از evidence، state و fallback دفاع کند. سه checkpoint اصلی: F1 مرز مالکیت، F2 رد shortcut اشتباه، F3 recompute در transfer با narration انسانی است.

مدل ذهنی: text version → token → timing sources → timebase → confidence/drift → sync یا fallback

زنجیره تصمیم این است:

text version → token map → TTS boundary | forced alignment | timed-text cue → normalize timebase → confidence + drift checks → word sync | sentence/cue fallback → human review

اول باید بدانیم audio برای کدام نسخه متن است. بعد tokenها و offsetهای character را از همان نسخه تولید می‌کنیم. timing source می‌تواند browser event، forced-alignment estimate یا timed-text cue باشد؛ این منابع هم‌معنی نیستند. قبل از مقایسه، همه زمان‌ها باید به یک timebase برگردند. سپس confidence و drift بررسی می‌شود. اگر word-level evidence ضعیف است ولی cue سالم داریم، fallback معتبر است. اگر نه word evidence داریم و نه fallback قابل دفاع، state باید HOLD بماند.

قرارداد پایه: شانزده بُعدی که باید قابل audit باشند

utterance_id و text_version مشخص می‌کنند کدام متن و کدام اجرای گفتار موضوع evidence است. token_id، char_start و char_length identity بخش متن را نگه می‌دارند. audio_asset_ref audio را به evidence وصل می‌کند. timing_source منشأ timing را ثبت می‌کند. start_ms، end_ms و elapsed_ms زمان‌های normalize‌شده‌اند. confidence میزان اتکای forced alignment یا mapping را نگه می‌دارد. cue_id fallback زمانی را به timed text متصل می‌کند. drift_ms اختلاف منبع یا expected position را نشان می‌دهد. sync_state تصمیم فعلی، fallback_mode granularity جایگزین و review_owner مسئول review است.

در این نسخه‌ی آموزشی MAKNOW، thresholdهای محلی Lab عبارت‌اند از confidence حداقل 0.85 و drift word-level حداکثر 120 ms. این اعداد استاندارد وب نیستند؛ صرفاً rule طراحی همین artifact برای تمرین deterministic هستند.

توضیح عمیق: FACT، INFERENCE و DESIGN را قاطی نکن

Web Speech API — FACT. رویداد boundary وقتی utterance به word یا sentence boundary می‌رسد قابل ارائه است، اما فقط اگر speech engine آن را فراهم کند. charIndex موقعیت گفتار را در متن اصلی به‌صورت تقریبی نشان می‌دهد و تضمین نمی‌کند دقیقاً ابتدای کلمه باشد. charLength و elapsedTime نیز در صورت نبود پشتیبانی می‌توانند 0 باشند.

W3C Timed Text — FACT. timed text متنی است که با timing information مرتبط است و برای caption/subtitle و دیگر جریان‌های synchronized media استفاده می‌شود. cue یک representation زمانی مفید است، نه تضمین word alignment.

Product interpretation — INFERENCE. پس browser boundary event، forced-aligner timestamp و timed-text cue سه نوع evidence با کیفیت و granularity متفاوت‌اند. وجود timestamp به‌تنهایی برای word highlight کافی نیست.

MAKNOW policy — DESIGN. threshold confidence/drift، state machine و انتخاب fallback در این درس authority محلی هستند. منبع خارجی مجوز نمی‌دهد که یک estimate را به «حقیقت قطعی» تبدیل کنیم.

مثال‌های حل‌شده: baseline، shortcut اشتباه و transfer

Baseline. برای token alignment، forced aligner confidence برابر 0.94 و drift برابر 52 ms دارد؛ mapping text version نیز exact است. word-level evidence قابل دفاع است. اما token مجاور punctuation با confidence 0.91، drift 180 ms دارد. همان token باید به cue-level fallback برود. نتیجه کل utterance یک تصمیم mixed granularity است، نه «همه کلمات دقیق‌اند».

Shortcut اشتباه. browser word boundary حذف می‌شود و تیم می‌گوید charIndex=0 یعنی کلمه اول در زمان صفر. این استنتاج نامعتبر است؛ مقدار صفر می‌تواند ناشی از عدم پشتیبانی باشد. اگر forced alignment word-level هم در دسترس نباشد، قرارداد باید به sentence/cue fallback برود.

Transfer. TTS با narration انسانی جایگزین شده و یک phrase paraphrase شده است. چون audio_asset_ref عوض شده، offsetهای مطلقِ فایل TTS قبلی خودبه‌خود معتبر نمی‌مانند. منظور از حفظ timing در بخش‌های بدون تغییر فقط timingهایی است که نسبت به همان audio انسانی جدید دوباره validate/recompute شده‌اند یا cueهای معتبرِ همان asset جدید هستند. segment تغییرکرده باید remap شود و اگر alignment confidence پایین است، فقط همان segment به cue fallback تنزل می‌یابد.

Failure Modeهایی که باید fail-closed شوند

اگر text_version audio با token map یکی نیست، word timing را استفاده نکن. اگر timing_source معلوم نیست، precision ادعا نکن. اگر timebase مبهم است، start_ms دو منبع را مستقیماً مقایسه نکن. اگر confidence زیر threshold است یا drift از limit عبور می‌کند، word-level state را downgrade کن. اگر cue fallback لازم است ولی cue_id نداریم، release را به زور ادامه نده. اگر review_owner خالی است، نتیجه هنوز review-ready نیست. و در transfer هرگز baseline decision را oracle نکن.

stateهایی مثل UNKNOWN, DRIFTED, FALLBACK_REQUIRED و HOLD شکست سیستم نیستند؛ آن‌ها از جعل precision جلوگیری می‌کنند.

گزینه‌ها و Trade-offها: browser events، forced alignment و timed-text cues

Browser TTS events برای feedback هم‌زمان با synthesis همان engine کم‌هزینه‌اند، اما support و granularity می‌تواند متفاوت باشد. Forced Alignment می‌تواند روی audio ضبط‌شده یا فایل خروجی timing word-level بدهد، ولی estimate است و به متن، pronunciation و مدل وابسته می‌ماند. Timed-text cues معمولاً granularity پایین‌تری دارند، اما برای fallback پایدار و قابل audit مناسب‌اند.

بهترین معماری همیشه دقیق‌ترین granularity نیست. اگر word timing maintenance زیادی می‌خواهد یا evidence در بعضی engines قابل دفاع نیست، sentence/cue highlighting می‌تواند UX باثبات‌تری باشد. تصمیم باید با provenance و state توضیح داده شود، نه با یک score مبهم.

پل Experienced: synchronization را state machine ببین

در محصول واقعی، هر token می‌تواند state مستقل داشته باشد: WORD_ELIGIBLE, DRIFTED, LOW_CONFIDENCE, CUE_FALLBACK, TEXT_VERSION_MISMATCH یا REVIEW_REQUIRED. تغییر voice، punctuation، text edit یا regenerated audio فقط segmentهای وابسته را invalidate می‌کند؛ لازم نیست همیشه کل utterance را دور بریزیم. این نگاه، partial regeneration و selective re-alignment را ممکن می‌کند.

Automation می‌تواند version equality، numeric threshold، cue presence و deterministic drift را بررسی کند. اما معنای اینکه paraphrase هنوز همان instructional content است یا review نهایی acceptable است، نباید پشت PASS خودکار پنهان شود.

تمرین هدایت‌شده و مستقل

1. fixture baseline را باز کن و برای هر row مشخص کن timing_source چیست و text_version به کدام audio وصل است. ۲. token drifted را پیدا کن و بدون تغییر threshold توضیح بده چرا word-level sync برای آن قابل دفاع نیست. ۳. fixture بدون browser boundary را اجرا کن و fallback را از evidence تعیین کن. ۴. سپس transfer narration انسانی را بررسی کن؛ segment paraphrase‌شده را remap کن و برای بخش‌های بدون تغییر فقط timingهایی را نگه دار که نسبت به audio انسانی جدید دوباره معتبر شده‌اند؛ offsetهای مطلق TTS قبلی را reuse نکن.

در تمرین مستقل، label نهایی حذف می‌شود. باید Contract را از fieldها بازسازی کنی و state را از evidence استخراج کنی، نه از نام fixture.

Verification Evidence: چه چیزی باید قابل بازتولید باشد؟

Reviewer باید بتواند بدون reasoning پنهان این زنجیره را بازتولید کند: text version برابر است؟ token offsets متعلق به همان متن‌اند؟ timing source چیست؟ timebase normalize شده؟ confidence و drift در محدوده‌اند؟ اگر word sync رد شد، cue/sentence evidence وجود دارد؟ owner مشخص است؟

Lab آفلاین برای این منظور failure probeهای remove browser boundary support, 180 ms drift, text version mismatch, missing timebase, low confidence, missing cue, missing owner و transfer oracle reuse را اجرا می‌کند.

ارزیابی و Transfer: narration انسانی با یک paraphrase

ارزیابی چهار بخش دارد: مرز درس را بازیابی کن؛ Contract baseline را بساز؛ mutation حذف boundary support را diagnose کن؛ و سپس TTS را با narration انسانی دارای یک paraphrase جایگزین کن. در transfer، baseline label ممنوع است. segment تغییرکرده باید token mapping جدید، confidence و fallback خودش را بگیرد؛ segmentهای بدون تغییر نیز فقط timingهایی را نگه می‌دارند که برای audio_asset_ref جدید دوباره validate شده‌اند. یک offset مطلق از فایل TTS قبلی، حتی با متن یکسان، evidence معتبر برای فایل انسانی جدید نیست.

پاسخ خوب لزوماً WORD_SYNC_REVIEW_REQUIRED نیست. اگر evidence فقط mixed granularity را پشتیبانی کند، همان نتیجه درست‌تر است.

منابع، تازگی و مرز authority

Web Speech API و W3C Timed Text در ۱۳ سپتامبر ۲۰۲۶ دوباره با منابع اصلی بررسی شدند. Web Speech document فعلی همچنان وابستگی boundary event به engine، تقریبی بودن charIndex و امکان مقدار 0 برای fieldهای unsupported را تصریح می‌کند. W3C Timed Text نیز timed text را برای متن time-associated و synchronized-media workflows نگه می‌دارد. این claimها تا 2027-01-01 یا زودتر در صورت تغییر materially semantics دوباره بررسی می‌شوند.

thresholdهای 0.85 و 120 ms، stateها و fallback rules DESIGN authority محلی MAKNOW هستند؛ آن‌ها را به W3C نسبت نده.