Nhiệm vụ: Nghiên cứu tổng hợp phần mềm chất lượng cao giọng nói con người trên trình duyệt

Tiến độ nghiên cứu

Chúng tôi đã kiểm tra giả thuyết rằng đối với bài toán của chúng tôi, nên tồn tại một ví dụ có tính ứng dụng thực tế dạng:

bản ghi âm thanh/âm tiết thực tế → phân tích tự động → quỹ đạo tham số nhỏ gọn của bộ tạo tín hiệu vạn năng → tổng hợp ngược âm thanh có thể nhận dạng

Tại sao một ví dụ như vậy có vẻ tồn tại

1. Tổng hợp thủ tục (procedural synthesis) tự thân nó đã tồn tại. Web Audio cung cấp bộ dao động, tiếng ồn, bộ lọc và AudioWorklet; Pink Trombone hiển thị đường thanh quản vật lý gốc trên trình duyệt; các bản demo dạng formant cho phép tạo ra các âm giống nguyên âm riêng lẻ từ một số lượng nhỏ tham số.

2. Biểu diễn dạng sóng (waveform) thông thường rất lớn. Khoảng 1 giây ghi âm từ micro có thể chiếm khoảng 200 KB trong Float32Array. Ngay cả sau khi nén mạnh bằng μ-law @ 8 kHz, nó vẫn còn khoảng 11 KB và hơn 10.000 giá trị mỗi giây, mặc dù giọng nói vẫn được cảm nhận bình thường. Điều này tạo ra trực giác mạnh mẽ rằng cấu trúc âm thanh được cảm nhận phải có một biểu diễn nhỏ gọn hơn đáng kể.

3. Có rất nhiều phương pháp phân tích giọng nói trong tài liệu. LPC, phân tích nguồn-bộ lọc (source-filter analysis), theo dõi formant, ước lượng phổ bao (spectral-envelope estimation), vocoder, phân tích bằng tổng hợp (analysis-by-synthesis), v.v. Qua tên gọi và mô tả, chúng trông rất gần với cơ chế cần thiết.

4. LLM ban đầu đánh giá bài toán quá lạc quan. Sơ đồ khái niệm có vẻ đơn giản: generator + parameters + target sound + optimizer. Điều này tạo ra ấn tượng sai lầm rằng việc ánh xạ ngược thực tế (inverse mapping) lẽ ra đã phải được giải quyết từ lâu và có sẵn trong các dự án mã nguồn mở.

Những gì đã tìm thấy

Demo Formant/Web Audio

Có rất nhiều ví dụ trong đó nguồn sawtooth/impulse đi qua một vài bộ lọc thông dải (band-pass filters) để tạo ra âm thanh giống nguyên âm.

Điều này chỉ chứng minh việc tạo trực tiếp từ các tham số đã biết trước. Những ví dụ như vậy không cung cấp cơ chế giải mã ngược mà chúng ta cần.

Pink Trombone / Modular Pink Trombone

Đây là một trong những bộ tạo thú vị nhất được tìm thấy vì:

• âm thanh được tạo ra theo thủ tục;
• phần lõi không bắt buộc phải thao tác với các chữ cái;
• trạng thái thanh quản có thể thay đổi liên tục;
• mã thực thi hoạt động trong trình duyệt;
• có thể nhận được các âm trung gian nằm ngoài từ điển cố định.

Nhưng đối với bài toán của chúng tôi, nó thiếu điều quan trọng nhất:

• không tìm thấy cơ chế recording → tract trajectory;
• không tự động khôi phục quỹ đạo tham số từ âm A thực tế hoặc bất kỳ âm thanh nào khác;
• chất lượng của bản tổng hợp vẫn mang tính tổng hợp rõ rệt và không thể hiện giọng nói tự nhiên ngay cả khi điều khiển thủ công.

Nói cách khác, Pink Trombone cung cấp một bộ tạo, chứ không phải bộ giải mã.

Các triển khai kiểu Klatt và Klatt

Không phải là định hướng kiến trúc cho bài toán của chúng tôi.

Lý do:

• nhiều triển khai đã xây dựng giao diện xung quanh âm vị (phonemes), ARPABET, các cài đặt sẵn (presets) và quy tắc ngôn ngữ;
• ngôn ngữ và chữ cái trở thành một phần của kiến trúc lõi;
• các tham số thường được làm thủ công (handcrafted);
• chất lượng gần giống các bộ tổng hợp cũ;
• không có ánh xạ ngược vạn năng từ âm thanh bất kỳ sang tham số;
• không có minh họa về việc tự động khôi phục giọng nói thực tế chất lượng cao.

Đối với chúng tôi, đây là một lớp quá hẹp: chúng tôi đang tìm kiếm cơ chế giải mã âm thanh vạn năng, chứ không phải bảng âm vị.

LPC / Phân tích nguồn-bộ lọc (Source-filter analysis)

Cho phép đánh giá các đặc điểm riêng lẻ: phổ bao, các cộng hưởng, nguồn kích thích, v.v.

Nhưng không tìm thấy trường hợp end-to-end nào mà các đặc điểm này tự động chuyển đổi thành một chương trình điều khiển nhỏ gọn của một bộ tạo đủ vạn năng, sau đó tái tạo ra âm thanh gần giống với bản gốc.

Tức là đây chỉ là các phần riêng lẻ của giải pháp, chứ chưa phải là một hệ thống hoàn chỉnh.

Phân tích bằng tổng hợp (Analysis-by-synthesis)

Đã tìm thấy các công trình nghiên cứu trong đó các tham số của bộ tổng hợp được tinh chỉnh theo giọng nói tự nhiên thông qua tối ưu hóa.

Điều này hữu ích không phải như một giải pháp sẵn có, mà như sự xác nhận về độ phức tạp kỹ thuật: ánh xạ ngược có tính phi tuyến, không rõ ràng và đòi hỏi phải tìm kiếm trong không gian tham số lớn.

Đồng thời, không tìm thấy giải pháp vạn năng thân thiện với trình duyệt nào có chất lượng cần thiết.

TTS thần kinh / Mô hình codec (Neural TTS / codec models)

Chất lượng cao, nhưng đây là một lớp giải pháp khác:

• biểu diễn bên trong được ẩn bên trong mô hình đã huấn luyện;
• không có VoiceState vạn năng rõ ràng có thể điều khiển được;
• không thể sử dụng hệ thống như một bộ tạo vật lý/thủ tục trong suốt (transparent);
• điều này không đáp ứng mục tiêu nghiên cứu là giải mã âm thanh thành một chương trình điều khiển nhỏ gọn, dễ hiểu.

Những gì không thể tìm thấy

Không tìm thấy bất kỳ ví dụ kỹ thuật mã nguồn mở thuyết phục nào đồng thời thỏa mãn các điều kiện sau:

1. Lấy bản ghi thực tế của một âm thanh cụ thể hoặc một âm tiết ngắn.
2. Không yêu cầu phải biết trước chữ cái/âm vị/ngôn ngữ.
3. Tự động khôi phục quỹ đạo thời gian nhỏ gọn của các tham số.
4. Sử dụng bộ tạo thủ tục vạn năng thay vì bộ giải mã neural TTS/codec.
5. Tổng hợp ngược âm thanh với chất lượng ít nhất đủ cho giọng nói bình thường có thể nhận dạng và tốt hơn đáng kể so với các bộ tổng hợp vật lý dạng demo.
6. Cho phép xem và nghiên cứu việc triển khai giải mã.
7. Có thể chuyển đổi thực tế sang ngăn xếp trình duyệt (browser stack).

Đây hiện là kết quả âm tính chính của nghiên cứu.

Tại sao bài toán lại phức tạp về mặt kỹ thuật

Bài toán ngược không có duy nhất một nghiệm

Một dạng sóng đầu ra tương tự có thể đạt được bởi các trạng thái bên trong khác nhau của bộ tạo. Không thể chỉ đơn giản khôi phục một cách duy nhất một tập hợp tham số "đúng" từ bản ghi âm.

Cần có thước đo cảm nhận, không chỉ là lỗi dạng sóng (waveform error)

Hai dạng sóng có thể có sự khác biệt lớn giữa các mẫu (sample-by-sample) nhưng nghe gần như giống hệt nhau. Ngược lại, một lỗi nhỏ trong vùng thời gian hoặc phổ quan trọng có thể thay đổi mạnh mẽ cảm nhận.

Điều này có nghĩa là hàm sai số bình phương trung bình (MSE) thông thường không phải là hàm mục tiêu đầy đủ.

Cần tìm quỹ đạo, không phải một véc-tơ

Âm thanh là một quá trình động. Nguồn kích thích, các cộng hưởng, tiếng ồn, độ tấn công (attack), sự đóng mở, kênh mũi và các tham số khác đều thay đổi.

Do đó, biến tìm kiếm thực tế là một chương trình tham số theo thời gian, chứ không phải một điểm tĩnh đơn lẻ.

Bản thân bộ tạo có thể không có khả năng tái tạo âm thanh mong muốn

Nếu mô hình được chọn không đủ biểu cảm, sẽ không có trình tối ưu hóa nào khôi phục được âm thanh gốc. Bộ tạo càng biểu cảm, không gian tham số càng lớn và việc tìm kiếm ngược càng phức tạp.

Giọng nói phức tạp hơn một vài formant

Đối với giọng nói chất lượng cao, các cơ chế như nguồn thanh môn (glottal source), độ nghiêng phổ (spectral tilt), tiếng thở (aspiration), tiếng động hỗn loạn (turbulence), kháng cộng hưởng (antiresonances), sự ghép nối qua mũi (nasal coupling), độ rung/rẩy (jitter/shimmer), động lực học thanh quản, tương tác nguồn-bộ lọc và các cơ chế khác có thể rất quan trọng.

Việc bổ sung từng cơ chế giúp cải thiện tính biểu cảm nhưng đồng thời làm phức tạp thêm quá trình giải mã.

Tinh chỉnh thủ công không thể mở rộng quy mô

Việc tự chỉnh sửa tham số của một chữ A thủ công là có thể thực hiện được. Việc khôi phục vạn năng một âm thanh bất kỳ bằng phương pháp này là bất khả thi.

Điều này giống như việc chọn thủ công một màu chính xác thông qua CMYK mà không cần chuyển đổi từ màu mục tiêu sang tham số: bạn có thể đạt được một vài ví dụ riêng lẻ, nhưng nó không giải quyết được bài toán tổng quát.

Phát biểu lại vấn đề cốt lõi một cách chính xác hơn

Nhiệm vụ chính giờ đây không được định nghĩa là "tạo ra bộ tổng hợp các chữ cái tiếng Nga" hay "chọn các cài đặt sẵn tốt".

Nó mang tính vạn năng hơn:

Học cách tự động tìm kiếm một chương trình tham số thời gian nhỏ gọn cho một bộ tạo đủ vạn năng đối với một âm thanh thực tế cho trước.

Chữ cái, âm vị và ngôn ngữ chỉ nên là các danh mục khả dĩ nằm trên không gian âm thanh đã tìm thấy, chứ không phải là một phần của phần lõi.

Meta-kết luận về việc làm việc với LLM

Trường hợp này cho thấy một rủi ro cụ thể: LLM dễ dàng nhầm lẫn sự phân rã kiến trúc rõ ràng với độ phức tạp kỹ thuật thấp.

Một số mô hình ban đầu mô tả bài toán là đơn giản về mặt thực tế vì tất cả các thành phần đều quen thuộc khi xét riêng lẻ: Web Audio, bộ lọc, phép nội suy, tối ưu hóa.

Nhưng sự hiện diện của các thành phần dễ hiểu không chứng minh sự tồn tại của một hệ thống hoạt động được tạo từ chúng.

Chỉ khi cố gắng tìm kiếm một trường hợp end-to-end có thể tái tạo cụ thể mới cho thấy rằng ánh xạ ngược quan trọng trong số các giải pháp được tìm thấy thực sự không tồn tại.

Để tiếp tục công việc, tính khả thi về mặt kỹ thuật cần phải được kiểm chứng thông qua các thí nghiệm chứng minh tính khả thi (proof-of-feasibility) tối thiểu thay vì dựa vào sự tự tin của LLM.

Làm rõ kết quả tìm kiếm các triển việc hiện thực hóa hiện có

Việc tìm kiếm các dự án bên ngoài chủ yếu là cần thiết để trả lời một câu hỏi:

không gian của lời nói thực tế của con người nằm trong không gian âm thanh mà một trình tạo thủ tục nhỏ gọn có thể tái tạo đến mức độ nào.

Hiện tại vẫn chưa tìm thấy sự xác nhận trực tiếp cho điều này.

Những gì đã biết chắc chắn

AudioContext có khả năng tái tạo chất lượng cao bất kỳ âm thanh kỹ thuật số nào được ghi lại trước đó nếu cung cấp cho nó toàn bộ mảng mẫu (samples). Điều này có nghĩa là vấn đề không nằm ở trình duyệt như một môi trường phát lại.

Vấn đề nằm ở sự biểu diễn.

Dạng sóng (waveform) đầy đủ có tính phổ quát nhưng tốn kém: ngay cả một giây giọng nói bị nén mạnh vẫn là một chuỗi gồm hàng nghìn giá trị. Mô hình của chúng tôi thay thế chuỗi này bằng một kịch bản nhỏ gọn gồm các tham số và lệnh có ý nghĩa theo thời gian.

Do đó, ranh giới đang được nghiên cứu trông như thế này:

waveform đầy đủ ← nhiều dữ liệu hơn / tính phổ quát cao hơn ... VoiceScenario cấu trúc → ít dữ liệu hơn / khả năng điều khiển cao hơn

Chúng ta cần hiểu trên trục này, chất lượng đủ cho lời nói tự nhiên xuất hiện ở đâu.

Tại sao các dự án tìm thấy không đưa ra câu trả lời

Pink Trombone và các mô hình vật lý tương tự cho thấy rằng có thể tạo ra một phần của không gian giống giọng nói bằng thủ tục, nhưng:

• chúng không phổ quát;
• chủ yếu thể hiện các trạng thái giống nguyên âm và khả năng phát âm hạn chế;
• âm thanh vẫn mang tính máy tính;
• không có sự minh họa đầy đủ về các âm tiết và lời nói liên tục chất lượng cao;
• không có bộ giải mã ngược bản ghi → kịch bản nhỏ gọn.

Các bản demo định dạng (formant) thậm chí còn hẹp hơn: chúng hiển thị các âm thanh tĩnh riêng lẻ hoặc gần như tĩnh, nhưng không trả lời câu hỏi về việc bao phủ lời nói thực tế.

Các hệ thống giống Klatt không phải là tiêu chuẩn tham chiếu cho kiến trúc của chúng tôi, bởi vì chúng đã dựa trên các cài đặt sẵn về âm vị/ngôn ngữ và không giải quyết việc giải mã phổ quát của âm thanh tùy ý.

Các hệ thống TTS/codec thần kinh thể hiện chất lượng cao, nhưng ẩn đi phần biểu diễn bên trong và không cung cấp một kịch bản minh bạch, có thể điều khiển để khám phá và chỉnh sửa.

Kết luận mới

Việc không tìm thấy ví dụ nào không có nghĩa là trình tạo dựa trên kịch bản nhỏ gọn không thể tiếp cận lời nói của con người. Nó chỉ có nghĩa là chúng ta chưa có bằng chứng bên ngoài về mức chất lượng cần thiết.

Do đó, con đường thực tế tiếp theo không phải là tiếp tục tìm kiếm vô tận các giải pháp thay thế, mà là đo lường các giới hạn của mô hình chính chúng ta:

1. cải tiến trình tạo trực tiếp;
2. xây dựng một trình chỉnh sửa kịch bản trực quan để đẩy nhanh quá trình điều chỉnh thủ công;
3. tạo ra một bộ giải mã ngược và kiểm tra nó trước tiên trên dữ liệu tổng hợp của chính chúng ta với ground truth đã biết;
4. sau đó chuyển nó sang các bản ghi âm của con người;
5. dần dần tăng độ biểu cảm của phần biểu diễn và đo lường mức độ cải thiện chất lượng mà mỗi cơ chế bổ sung mang lại.

Đối tượng nghiên cứu chính bây giờ là sự đánh đổi giữa tính nhỏ gọn của mô tả cấu trúc và chất lượng cảm nhận (perceptual quality).

Giới hạn vật lý cơ bản để tái tạo giọng nói chất lượng cao và các mốc tham chiếu cho tiếng Nga đã được nghiên cứu.

Các kết luận chính:

• Một kênh âm thanh duy nhất (mono) là đủ để tái tạo giọng nói con người: tại một điểm trong không gian, áp suất không khí được mô tả bằng một hàm thời gian vô hướng duy nhất. Stereo cần thiết cho các đặc trưng không gian, chứ không phải cho âm sắc hoặc khả năng dễ hiểu của âm vị giọng nói.
• Tiếng nói băng thông rộng ITU (wideband speech): khoảng 50–7000 Hz. Theo định lý Nyquist, để giữ lại dải này cần tần số lấy mẫu >14 kHz; tiêu chuẩn thực tế là 16 kHz. Điều này cho ra raw PCM 16-bit mono = 16.000 * 16 = 256 kbps.
• Tiếng nói siêu băng thông rộng ITU (super-wideband): 50–14.000 Hz; tần số lấy mẫu thực tế >=32 kHz, raw PCM 16-bit mono = 512 kbps. 48 kHz/16-bit mono = 768 kbps và đã bao phủ toàn bộ dải thính giác của con người rộng hơn nhiều so với mức thường cần cho giọng nói.
• Đối với giọng nói nén, Opus RFC 6716 chỉ định các mức tối ưu (sweet spots): 8–12 kbps cho tiếng nói băng hẹp (narrowband), 16–20 kbps cho tiếng nói băng rộng (wideband), 28–40 kbps cho tiếng nói toàn dải (fullband).
• G.722 xác định tiếng nói băng rộng chất lượng cao 50–7000 Hz ở mức 64 kbps (codec SB-ADPCM cũ); Opus hiện đại đạt được hiệu suất chủ quan tương đương hoặc tốt hơn với bitrate thấp hơn đáng kể.
• OpenSTT của Nga (~20 nghìn giờ) sử dụng mono, 16 kHz, int16 làm định dạng thực tế chính; cấu hình MP3 trước đây của họ là 16 kHz mono 32 kbps. Đây là một mốc cơ sở thực nghiệm hữu ích của tiếng Nga, dù không phải là mức tối thiểu cơ bản.

Điều quan trọng là phải phân biệt giữa bitrate lưu trữ/truyền tải và độ phức tạp của bộ tổng hợp: một kênh âm thanh đầu ra duy nhất có thể được tạo ra từ nhiều nguồn/bộ lọc bên trong (nguồn thanh môn, tiếng thở, tiếng xát, cộng hưởng, nhánh mũi, v.v.). Số lượng thành phần DSP bên trong không bằng số lượng kênh âm thanh đầu ra.

Web Speech API / SpeechSynthesis như một lớp giải pháp riêng biệt

Trong quá trình tìm kiếm các triển khai hiện có, SpeechSynthesis tích hợp sẵn của trình duyệt đã được kiểm tra.

Ví dụ tối thiểu:

const utterance = new SpeechSynthesisUtterance('Xin chào, đây là tổng hợp giọng nói!');
utterance.lang = 'vi-VN';
const voices = speechSynthesis.getVoices();
utterance.voice = voices.find(v => v.lang === 'vi-VN');
speechSynthesis.speak(utterance);

Mã này cho thấy một thực tế quan trọng: trình duyệt hiện đại đã có khả năng tái tạo giọng nói con người khá bình thường từ văn bản mà không cần triển khai DSP của riêng chúng ta.

Nhưng về mặt kiến trúc, đây là một lớp hệ thống hoàn toàn khác và nó không phù hợp với nhiệm vụ chính của chúng ta.

API thực sự làm gì

SpeechSynthesisUtterance nhận văn bản và các cài đặt như ngôn ngữ/giọng đọc, sau đó truyền chúng đến công cụ giọng nói tích hợp sẵn của trình duyệt/hệ điều hành.

Sơ đồ quy ước:

text
→ SpeechSynthesisUtterance
→ language / voice selection
→ hidden TTS engine
→ audio

Kết quả có sẵn cho người dùng, nhưng chương trình tạo âm thanh bên trong thì không.

Hạn chế nghiêm trọng 1. Không có quyền điều khiển trực tiếp bản thân âm thanh

API chấp nhận văn bản, chứ không phải quỹ đạo phát âm hoặc âm học.

Ví dụ:

mama

thường được phát âm bình thường.

Nhưng nỗ lực viết:

mmmmmmaaamama

không có nghĩa đối với công cụ là:

giữ /m/
→ chuyển đổi mượt mà sang /a/
→ tiếp tục âm tiết

Công cụ diễn giải chuỗi là văn bản và có thể bắt đầu đọc nó giống như một chuỗi tên chữ cái hoặc âm tiết:

em-em-em-em... a... ma-ma...

Tương tự:

shhhhhhhh

có thể biến thành thứ gì đó như:

sha-sha-sha-sha...

Nghĩa là thông qua API này, bạn không thể thiết lập một cách đáng tin cậy:

• thời lượng của một phụ âm cụ thể;
• việc giữ một âm vị;
• sự chuyển đổi mượt mà giữa các âm thanh;
• hình dạng của quá trình chuyển đổi phát âm;
• một quỹ đạo thời gian riêng biệt cho tiếng ồn, tạo giọng (voicing), các vóc dáng (formant) và các tham số khác.

Do đó, API hầu như không phù hợp cho các thí nghiệm kiểu:

M ─────────→ A

nơi chính sự chuyển đổi đó là đối tượng nghiên cứu.

Hạn chế nghiêm trọng 2. Ca hát và cấu trúc thời gian tùy ý

Vì đầu vào là văn bản chứ không phải kịch bản âm thanh, bạn không thể tự do xác định:

• kéo dài các âm thanh riêng lẻ;
• thời lượng âm tiết tùy ý;
• quỹ đạo giai điệu của từng âm thanh;
• các chuyển đổi thanh nhạc;
• nhịp điệu phi tiêu chuẩn;
• việc "hát" bình thường thông qua việc điều khiển âm vị trực tiếp.

Thay đổi rate hoặc pitch tổng quát không giải quyết được vấn đề này: nó thay đổi hành vi của toàn bộ phát ngôn, chứ không cung cấp quyền kiểm soát các sự kiện âm thanh bên trong.

Hạn chế nghiêm trọng 3. Gắn kết ngôn ngữ

SpeechSynthesisUtterance dựa vào lang và một voice cụ thể.

Điều này có nghĩa là công cụ mong đợi văn bản nằm trong khuôn khổ của một hệ thống ngôn ngữ nhất định.

Các vấn đề phát sinh bao gồm:

• trộn nhiều ngôn ngữ trong một cụm từ duy nhất;
• các âm thanh xuyên ngôn ngữ tùy ý;
• từ nhân tạo;
• chuỗi ký tự phi tiêu chuẩn;
• các âm thanh hoàn toàn không phải là từ của ngôn ngữ đó.

Ngay cả khi công cụ cố gắng phát âm một cái gì đó, nó vẫn làm thông qua các quy tắc diễn giải văn bản của riêng mình, chứ không phải như một trình tạo vạn năng cho âm thanh tùy ý.

Hạn chế nghiêm trọng 4. Giới hạn bởi mô hình ngôn ngữ phát âm

Chính xác hơn là không chỉ nói về "từ điển" theo nghĩa đen, mà là về một giới hạn rộng hơn:

công cụ biết cách phát âm những gì nó có thể diễn giải trong khuôn khổ mô hình ngôn ngữ phát âm của chính nó.

Nghĩa là, nó có thể cố gắng đọc một chuỗi không xác định, nhưng đó vẫn sẽ là sự diễn giải dưới dạng văn bản chứ không phải là bản tái tạo trực tiếp của một đối tượng âm học đã cho.

Đối với nhiệm vụ của chúng ta, điều này có tầm quan trọng cơ bản.

Chúng ta cần một cơ chế ở cấp độ:

sound scenario
→ exact parameter trajectories
→ sound

trong khi ở đây sử dụng:

text
→ hidden linguistic interpretation
→ hidden TTS model
→ sound

Hạn chế nghiêm trọng 5. Hộp đen (Black box)

Ngay cả khi công cụ phát âm một từ với chất lượng rất cao, nó cũng không xuất ra mô tả cấu trúc về việc chính xác thì âm thanh được xây dựng như thế nào.

Không có sẵn biểu diễn kiểu:

initial state
+ timeline
+ source parameters
+ noise parameters
+ resonances
+ transitions

Do đó, SpeechSynthesis không giúp giải quyết nhiệm vụ nghiên cứu cốt lõi:

có được một mô tả nhỏ gọn có thể điều khiển được về âm thanh và có thể chuyển đổi qua lại giữa âm thanh và mô tả đó.

Nó chỉ thể hiện khả năng của hệ thống trong việc tái tạo giọng nói hay từ văn bản.

Tại sao việc ghi lại điều này vẫn hữu ích

Bất chấp sự không phù hợp về kiến trúc đối với nhiệm vụ của chúng ta, SpeechSynthesis vẫn hữu ích khi được xem xét như một tùy chọn có sẵn riêng biệt cho các dự án khác.

Nếu nhiệm vụ chỉ đơn giản là:

text → normal speech

thì API trình duyệt có thể hoàn toàn đáp ứng mà không cần trình tổng hợp của riêng mình.

Nó đặc biệt hữu ích khi:

• không bắt buộc phải điều khiển các âm vị riêng lẻ;
• không cần âm thanh phi tiêu chuẩn;
• không cần ca hát;
• không cần giải mã hoặc quyền truy cập vào biểu diễn bên trong;
• TTS thông thường bằng ngôn ngữ được hỗ trợ là đủ.

Tổng kết cho dự án của chúng ta

SpeechSynthesis cho thấy giọng nói chất lượng cao trong trình duyệt dưới dạng kết quả cuối cùng đã có sẵn ngay từ bây giờ.

Nhưng nó không phù hợp với chúng ta về mặt kiến trúc bởi vì:

1. đầu vào là văn bản, không phải kịch bản âm thanh;
2. không có khả năng kiểm soát chính xác cấu trúc thời gian bên trong của âm thanh;
3. không có khả năng kiểm soát thích hợp thời lượng của các âm vị riêng lẻ;
4. kém phù hợp cho việc ca hát và các quỹ đạo thanh nhạc tùy ý;
5. phụ thuộc vào ngôn ngữ và công cụ giọng nói cụ thể;
6. không phải là trình tạo vạn năng cho các âm thanh tùy ý;
7. không làm lộ biểu diễn bên trong;
8. không giải quyết bài toán ngược sound → scenario.

Do đó, đối với nhiệm vụ nghiên cứu của chúng ta, đây không phải là đối thủ cạnh tranh của VoiceScenario, mà là một công cụ TTS có sẵn riêng biệt cho một lớp tác vụ hẹp hơn rất nhiều.