Nền tảng lý thuyết của dự án được tập hợp trong khái niệm chính ["uchitsya-legko.rf — học đọc như giải mã mã chữ viết"](/concepts/uchitsya-legko-rf-obuchenie-chteniyu-kak-deshifrovke-pismennogo-koda). Đây là điểm trung tâm của dự án: mô tả mô hình chung, trạng thái hiện tại và liên kết các khái niệm cụ thể.

Hiện tại, dự án đang ở giai đoạn **Ý tưởng (Idea)**. Lý thuyết cơ bản về việc đọc như một quá trình khôi phục thông tin từ mã chữ viết đã được hình thành. Các thực thể thông tin làm nền tảng cho việc học đã được ghi nhận: đối tượng và tình huống, khái niệm, hình ảnh, từ nói, âm thanh, từ viết, chữ cái và các phần cấu trúc lớn hơn của từ.

Các thành phần chính của lý thuyết:

- [Đọc là nhận diện từ và khôi phục ý nghĩa, chứ không phải là phát âm tuần tự các chữ cái](/concepts/chtenie-eto-raspoznavanie-slova-i-vosstanovlenie-smysla).
- [Từ viết liên kết nhiều biểu hiện của cùng một nội dung](/concepts/pismennoe-slovo-svyazyvaet-neskolko-predstavleniy).
- [Học đọc phải đi từ điểm tựa đã biết đến mã chưa biết](/concepts/obuchenie-chteniyu-ot-izvestnyh-opor-k-neizvestnomu-kodu).
- [Từ vựng nói là cơ sở nhận diện khi học đọc](/concepts/ustnyy-slovar-baza-raspoznavaniya-pri-obuchenii-chteniyu).
- [Từ dài phải được làm rõ thông qua các phần cấu trúc quen thuộc](/concepts/dlinnoe-slovo-cherez-znakomye-strukturnye-chasti).
- [Các gợi ý phải biến mất dần khi các mối liên hệ được làm chủ](/concepts/podskazki-dolzhny-postepenno-ischezat).

Hướng đi thực tế là một hệ thống tương tác, trong đó trẻ bắt đầu với các đối tượng và từ ngữ dễ nhận biết, xác nhận âm thanh của chúng, làm quen với cách viết, phát hiện các yếu tố lặp lại của mã chữ viết và sau đó áp dụng các sự tương ứng tìm được để giải mã các từ mới.

Nguyên tắc quan trọng: hệ thống không được đòi hỏi trẻ phải tiếp thu đồng thời nhiều cấp độ chưa biết. Nếu trẻ chưa biết khái niệm, từ nói, âm thanh và chữ cái của nó, thì từ đó không phù hợp để làm tài liệu bắt đầu. Bài tập tiếp theo phải dựa trên kiến thức đã được xác nhận của riêng đứa trẻ đó.

Giai đoạn tiếp theo của dự án là biến lý thuyết thành cơ chế tương tác tối thiểu và kiểm tra tiêu chí chính: liệu trẻ có khả năng chuyển các mối liên hệ đã thành thạo sang các từ chưa từng gặp trước đó, chứ không chỉ ghi nhớ các ví dụ được hiển thị.

Một dự án học đọc tương tác dưới dạng giải mã dần dần mã chữ viết thông qua các ý nghĩa, hình ảnh và từ ngữ phát âm mà trẻ đã quen thuộc.

uchitsya-legko.rf

## Mối liên hệ với nhiệm vụ chính

Nhiệm vụ cha là [nghiên cứu tổng hợp tham số phổ quát các âm thanh và chuyển đổi tiếng Nga](/tasks/cmtzfmwqs07rwqw0q6l7d5izg).

Kiến trúc kịch bản và hướng đi của nhiệm vụ chính trông có vẻ đầy hứa hẹn. Rủi ro chính hiện tại nằm ở tầng thấp hơn: **bản thân DSP vẫn tái tạo giọng nghe quá giống máy tính**.

Nhiệm vụ này nên nghiên cứu riêng biệt về khả năng và hạn chế của việc tạo hình lập trình âm thanh con người đáng tin cậy trong trình duyệt.

## Câu hỏi chính

> Những phương pháp hiện có và các bản triển khai trên trình duyệt nào có khả năng tái tạo theo chương trình, tất định và không cần runtime-generative TTS ít nhất một vài âm thanh giọng nói hoặc âm tiết của con người đủ gần với giọng thật?

Chúng ta quan tâm trước hết đến chất lượng của bộ máy âm học, chứ không phải pipeline chuyển đổi văn bản thành giọng nói (text-to-speech).

## Cần tìm kiếm những gì

### 1. Demo thực tế trên trình duyệt

Tìm các dự án chạy hoàn toàn hoặc gần như hoàn toàn trong trình duyệt thông qua:

* Web Audio API;
* AudioWorklet;
* WebAssembly;
* JavaScript / TypeScript;
* DSP trên trình duyệt bằng C/C++/Rust qua WASM.

Lý tưởng nhất là có một bản live demo nơi bạn có thể nghe kết quả mà không cần cài đặt một stack TTS lớn.

Tối thiểu là dự án tái tạo chất lượng một vài nguyên âm, phụ âm, âm tiết hoặc âm thanh ngắn của con người.

### 2. Mã nguồn

Ưu tiên các dự án mã nguồn mở, đặc biệt trên GitHub/GitLab.

Đối với mỗi dự án hữu ích, cần tìm hiểu:

* sử dụng DSP nào;
* cách mô hình hóa nguồn giọng nói;
* cách mô hình hóa hiện tượng nhiễu loạn (turbulence);
* cách mô hình hóa đường phát âm (vocal tract);
* có sử dụng cộng hưởng (resonances), phản cộng hưởng (antiresonances), ống dẫn sóng (waveguide), mô hình ống (tube model), mô hình LF, dòng thanh môn (glottal flow), tiếng thở (aspiration), độ nghiêng phổ (spectral tilt), v.v. không;
* những tham số nào được điều khiển theo thời gian;
* mô hình có tính tất định đến mức nào;
* có thể đặt quỹ đạo tham số chưa từng gặp trước đó không.

### 3. Không giới hạn ở các dự án TTS lời nói

Cũng tìm kiếm:

* physical vocal synthesis;
* singing voice synthesis;
* vocal tract simulation;
* glottal source synthesis;
* vocal effects / vocal modeling;
* voice instruments;
* research demos;
* browser audio experiments;
* speech production simulators.

Dự án có thể hoàn toàn không làm việc với chữ cái hay ngôn ngữ — điều đó thậm chí còn được ưu tiên hơn nếu nó tạo ra âm thanh con người hay.

## Điều gì được coi là anti-pattern cho nhiệm vụ này

### Các hệ thống có phần nhân được xây dựng xung quanh chữ cái/âm vị/âm tiết

Ví dụ, một dự án giống Klatt tự nó không thú vị nếu API chính của nó là một từ điển các âm vị quen thuộc, ARPABET, các âm tiết hoặc các quy tắc tổng hợp sẵn có của một ngôn ngữ cụ thể.

Bạn có thể nghiên cứu các thành phần DSP của nó, nhưng không coi hệ hình đó làm định hướng kiến trúc.

### TTS tạo sinh

Không xem xét làm giải pháp:

* VITS;
* diffusion TTS;
* transformer/LLM TTS;
* voice cloning;
* large speech models;
* các mô hình khác tạo ra waveform hoặc codec token từ phân phối đã học.

Chúng chỉ có thể được sử dụng làm chuẩn so sánh chất lượng bên ngoài.

Lý do: hệ thống được nghiên cứu phải có khả năng xây dựng **một âm thanh mới chưa từng gặp trước đó**, thông qua một chương trình tham số được chỉ định rõ ràng.

### Pink Trombone như là câu trả lời cuối cùng

Pink Trombone hữu ích về mặt kiến trúc, nhưng âm thanh của nó quá rõ ràng là tổng hợp. Cần phải hiểu những cơ chế nào còn thiếu giữa một mô hình vật lý như vậy và một giọng nói con người thuyết phục.

## Câu hỏi nghiên cứu

1. Những phương pháp hoàn toàn bằng phần mềm, không tạo sinh nào hiện nay mang lại giọng nói tự nhiên nhất?
2. Phương pháp nào trong số đó có thể chạy thời gian thực (realtime) trong trình duyệt?
3. Chúng ta có thể tiến xa đến đâu với các mô hình source-filter?
4. Các mô hình đường phát âm dạng ống/waveguide mang lại gì so với tập hợp các bộ cộng hưởng?
5. Mô hình dòng thanh môn chính xác quan trọng đến mức nào?
6. Những cơ chế phổ quát nào đặc biệt ảnh hưởng đến cảm giác "giọng nói sống động":
   * spectral tilt;
   * aspiration;
   * breathiness;
   * jitter/shimmer;
   * source-filter interaction;
   * antiresonances;
   * nasal tract;
   * broadband turbulence;
   * nonlinearities;
   * radiation model;
   * dynamic vocal tract?
7. Cơ chế nào có thể được triển khai như các tọa độ `VoiceState` phổ quát thay vì các chế độ âm vị chuyên biệt?
8. Những giới hạn nào của trình duyệt là đáng kể: sample rate, kích thước khối AudioWorklet, độ trễ WASM, độ ổn định của bộ lọc, CPU?
9. Có bản demo nào được công bố mà một số âm tiết hoặc cử chỉ giọng nói nghe tự nhiên hơn rõ rệt so với Pink Trombone mà không dùng mạng nơ-ron không?
10. Những gì tìm được có thể được chuyển đổi thực tế vào VoiceSynthesizer hiện tại không?

## Phương pháp làm việc

Đối với mỗi ứng viên tìm được, ghi lại:

* liên kết live demo;
* liên kết mã nguồn;
* loại mô hình;
* có chạy được trong trình duyệt không;
* chất lượng chủ quan;
* thực tế làm được những âm thanh gì;
* có điều khiển tham số tự do không;
* có thể đặt quỹ đạo mới không;
* cơ chế nào có tiềm năng hữu ích cho engine của chúng ta;
* đã phát hiện ra những giới hạn nào.

Sau phần tổng quan, chọn 2–5 phương pháp DSP có triển vọng nhất và thực hiện so sánh kỹ thuật riêng biệt với kiến trúc hiện tại.

## Kết quả mong đợi

* tổng quan về các dự án native trình duyệt hoặc có khả năng chạy trên trình duyệt hiện có;
* danh sách các live demo tốt nhất;
* bản đồ các cơ chế DSP được sử dụng;
* giải thích tại sao một số mô hình nghe giống máy tính trong khi những mô hình khác tự nhiên hơn;
* danh sách các cơ chế phổ quát đáng thêm vào `VoiceControlState`/DSP hiện tại;
* kế hoạch cải tiến engine thử nghiệm;
* kết luận về giới hạn thực tế của tổng hợp hoàn toàn bằng phần mềm trên trình duyệt mà không cần TTS tạo sinh.

Tìm kiếm và nghiên cứu các dự án trên trình duyệt và các phương pháp DSP có thể tái tạo ít nhất một vài âm tiết hoặc âm thanh giọng nói của con người với chất lượng cao theo cách lập trình, không dùng TTS tạo sinh và không gắn kết phần nhân với chữ cái/âm tiết.

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

## Mục tiêu

Xây dựng trình chỉnh sửa kịch bản bộ tổng hợp trực quan để ngừng việc sửa đổi mã nguồn cho mỗi lần lợt lặp và chuyển công việc lên cấp độ của chính `VoiceScenario`.

## Trình chỉnh sửa cần có khả năng gì

- tải tệp JSON kịch bản hiện có;
- tạo kịch bản từ đầu;
- chỉnh sửa trạng thái ban đầu;
- chỉnh sửa các lệnh trên dòng thời gian chung (`set`, `animate` và các thao tác được hỗ trợ khác);
- thay đổi thời lượng, mức độ, tần số, thông số tiếng ồn, độ cộng hưởng và các thông số có sẵn khác;
- phát kết quả ngay sau khi thay đổi;
- lưu và xuất tệp JSON đã sửa đổi;
- chuyển đổi nhanh chóng giữa các biến thể.

## Con người là Trình kiểm định nhận thức (Perceptual Validator)

Chất lượng kết quả cho đến nay vẫn được đánh giá bằng tai đáng tin cậy nhất bởi con người. Do đó, trình chỉnh sửa nên giảm thiểu tối đa chu kỳ:

`thay đổi thông số → phát → nghe kết quả → thay đổi lại`.

Mục tiêu là loại bỏ việc bắt buộc chỉnh sửa mã nguồn của AI khỏi chu kỳ này.

## Tự động hóa thông qua Tác nhân AI

Lớp tiếp theo của trình chỉnh sửa:

1. con người tải lên/ghi lại âm thanh chuẩn;
2. hệ thống nhận nhật ký phân tích của âm thanh đó;
3. `VoiceScenario` hiện tại được phát và xây dựng nhật ký của nó;
4. khi nhấn nút, cả hai nhật ký cùng với JSON hiện tại được gửi cho tác nhân AI;
5. tác nhân so sánh chúng và trả về JSON kịch bản đã sửa đổi;
6. trình chỉnh sửa áp dụng biến thể;
7. con người kiểm tra lại bằng tai.

AI ở đây không phải là trọng tài cuối cùng về chất lượng — nó giúp tìm kiếm các thay đổi trong không gian thông số có cấu trúc, trong khi con người vẫn đóng vai trò là người kiểm tra chất lượng cảm nhận (perceptual quality).

## Kiểm tra riêng chất lượng nhật ký

Có giả thuyết cho rằng các nhật ký phân tích hiện tại bị nén quá mức và làm mất các đặc điểm mà con người có thể nghe thấy. Cần có khả năng tăng độ phân giải phân tích và so sánh xem điều này có cải thiện khả năng đề xuất các thay đổi hữu ích của AI hay không.

## Chế độ nghiên cứu quan trọng

Không vứt bỏ những âm thanh hữu ích vô tình tìm thấy.

Nếu khi tìm kiếm `Ha` mà lại tạo ra được `Va` dễ nhận biết hoặc một phân đoạn giọng nói mong muốn khác:

- lưu kịch bản thành một kết quả riêng biệt;
- lưu cả biến thể gốc và biến thể đã sửa đổi;
- ghi lại những thay đổi thông số nào đã dẫn đến sự chuyển đổi đó;
- sử dụng điều này làm kiến thức về cấu trúc của không gian tham số.

## Tiêu chí kết quả

Trình chỉnh sửa phải làm cho các vòng lặp âm thanh trở nên tiết kiệm chi phí hơn đáng kể: con người có thể tự mình thay đổi và kiểm tra các kịch bản, còn AI làm việc với JSON/nhật ký thay vì phải liên tục thay đổi mã nguồn.

Tăng tốc quá trình tìm kiếm âm thanh chất lượng thủ công: chỉnh sửa kịch bản trực quan, phát ngay lập tức và có khả năng gửi nhật ký chuẩn và tổng hợp cho tác nhân AI để nhận lại JSON đã sửa đổi.

Xây dựng Trình chỉnh sửa trực quan VoiceScenario và vòng lặp Con người ↔ AI

## Mục tiêu

Kiểm tra giả thuyết về tính khả nghịch thực tế của mô hình tham số của chúng ta:

`VoiceScenario → bộ tạo → âm thanh`

và ngược lại:

`âm thanh → bộ giải mã → VoiceScenario`.

## Nguyên tắc kiểm tra chính

Bắt đầu không phải bằng giọng nói của con người, mà bằng các kịch bản của riêng chúng ta, nơi câu trả lời đúng đã được biết trước.

Đối với kịch bản `S`:

`S → G(S) = X`

sau đó:

`X → D(X) = S'`

Tiêu chí nghiêm ngặt đầu tiên:

> nếu bộ giải mã không có khả năng khôi phục ổn định các kịch bản gốc từ âm thanh do chính bộ tạo của chúng ta tạo ra, thì việc nói về giải mã giọng nói thực tế là quá sớm.

Cần kiểm tra trên toàn bộ tập hợp các kịch bản khác nhau có sẵn, chứ không phải trên một trường hợp thành công duy nhất.

## Giai đoạn 1. Ground truth tổng hợp

Thu thập một tập hợp các kịch bản hiện có và mới:

- âm thanh giọng nói duy trì;
- tiếng ồn;
- âm bật nổ;
- các chuyển đổi;
- âm tiết/phân đoạn;
- từ ngắn.

Đối với mỗi mục, hãy lưu trữ:

- JSON gốc;
- âm thanh được tạo chính xác;
- nhật ký phân tích chi tiết;
- kết quả của bộ giải mã;
- sự khác biệt giữa kịch bản gốc và kịch bản được khôi phục;
- kết quả tổng hợp lại từ kịch bản được khôi phục.

Chúng ta cần hiểu những tham số nào được khôi phục một cách ổn định, những tham số nào không rõ ràng và độ phân giải nhật ký nào là cần thiết.

## Giai đoạn 2. Kiểm tra tổng hợp lại

Không đủ chỉ để nhận được một JSON tươngージ. Kịch bản được khôi phục cần được phát lại:

`S → X → D(X)=S' → G(S')=X'`

Và so sánh:

- cấu trúc kịch bản;
- các đặc điểm phân tích của `X` và `X'`;
- nhận thức thính giác của con người.

## Giai đoạn 3. Chuyển sang giọng nói của con người

Chỉ sau khi hoạt động ổn định trên dữ liệu tổng hợp của chính mình mới chuyển sang ghi âm con người.

Mục tiêu ở đây không nhất thiết phải khôi phục một kịch bản vật lý "thực sự" nào đó của con người mà chúng ta không có. Tiêu chí thực tế:

> bộ giải mã tạo ra một `VoiceScenario` mà khi phát lại sẽ tạo ra âm thanh giống con người có thể nhận biết và khá gần gũi.

## Câu hỏi lớn chưa có lời giải

Không gian giọng nói của con người được bao phủ đến mức nào bởi không gian âm thanh hiện tại của bộ tạo của chúng ta.

`AudioContext` về mặt kỹ thuật có khả năng tái tạo bất kỳ dạng sóng kỹ thuật số nào nếu được cung cấp đầy đủ một mảng các mẫu. Nhưng hệ thống của chúng ta chủ đích thay thế hàng nghìn mẫu bằng một mô tả cấu trúc nhỏ gọn.

Do đó, chúng ta không nghiên cứu khả năng tái tạo nói chung, mà là ranh giới:

> **độ phức tạp tối thiểu nào của biểu diễn cấu trúc là đủ cho chất lượng giọng nói con người có thể chấp nhận được?**

## Sự phát triển có thể có của mô hình

Nếu `VoiceScenario` hiện tại là chưa đủ, không coi đó là sự bác bỏ tự động cách tiếp cận này. Khảo sát việc tăng dần tính biểu cảm:

- mô hình nguồn phong phú hơn;
- cộng hưởng/phản cộng hưởng bổ sung;
- nhiễu loạn/tiếng ồn (turbulence/noise);
- chi tiết phổ cục bộ;
- các điểm điều khiển thời gian dày đặc hơn;
- các thành phần phần dư (residual) ngắn nếu cần.

Giới hạn cuối cùng, biểu diễn có thể tiệm cận với dạng sóng. Mục tiêu thực tế là tìm ra điểm mà chất lượng đã đủ, trong khi mô tả vẫn nhỏ gọn hơn đáng kể và có cấu trúc hơn một mảng các mẫu.

## Mối liên hệ với trình chỉnh sửa

Ngay cả một bộ giải mã không hoàn hảo cũng có thể hữu ích nếu nó tạo ra một kịch bản nháp tốt:

`bản ghi → VoiceScenario nháp → trình chỉnh sửa trực quan/AI → con người tinh chỉnh bằng tai`.

## Tiêu chí thành công

1. Bộ giải mã khôi phục ổn định các kịch bản của chính nó ít nhất trên một tập hợp giới hạn các lớp âm thanh.
2. Quá trình tổng hợp lại từ kịch bản được khôi phục gần gũi về mặt nhận thức với âm thanh tổng hợp gốc.
3. Rõ ràng dữ liệu nào bị mất trong quá trình phân tích hiện tại và liệu có cần giảm độ nén nhật ký hay không.
4. Trên các bản ghi thực tế, ít nhất thu được các kịch bản khởi đầu hữu ích.
5. Có thể ước tính sự phụ thuộc `chất lượng ↔ độ phức tạp/kích thước biểu diễn` và tiến gần đến ranh giới thực tế của hệ thống.

Kiểm tra xem kịch bản của bộ tạo có thể được khôi phục tự động từ âm thanh được ghi lại hay không, trước tiên trên các ví dụ tổng hợp của riêng chúng tôi với ground truth đã biết, sau đó là trên giọng nói của con người.

Khảo sát bộ giải mã ngược: âm thanh → VoiceScenario

## Mục tiêu

Khảo sát không phải sự tương ứng tức thời dạng `parameter[t] -> sample[t]`, mà là tính nhân quả theo thời gian trong chuỗi:

`VoiceControlState(t) -> trạng thái DSP nội bộ -> PCM -> đặc trưng âm học trên cửa sổ thời gian`.

Cần phải hiểu **tham số điều khiển nào thực sự ảnh hưởng đến cái gì**, sau bao lâu ảnh hưởng đó xuất hiện, kéo dài trong bao lâu và những đặc特征 quan sát được nào cho phép khôi phục nó.

Điều này là cần thiết để giải mã ngược chính xác `Sound -> VoiceScenario`.

---

## Bối cảnh và Vấn đề

`VoiceScenario` hiện tại thiết lập các tham số điều khiển, nhưng PCM đầu ra được tạo ra bởi một hệ thống động với trạng thái nội bộ:

- `voicePhase`;
- `resonator1.low`, `resonator1.band`;
- `resonator2.low`, `resonator2.band`;
- `resonator3.low`, `resonator3.band`;
- trạng thái PRNG;
- automation đang hoạt động.

Do đó, ngay cả các tham số điều khiển không đổi cũng tạo ra một dạng sóng phức tạp, tần số cao.

Ví dụ:

- `f0Hz` không đổi không có nghĩa là dạng sóng không đổi — nó thiết lập tốc độ quay của `voicePhase`;
- `noiseLevel` không đổi điều khiển biên độ của nguồn ngẫu nhiên thay đổi mỗi mẫu (sample);
- `resonance*` không đổi điều khiển các bộ lọc có trạng thái (stateful-filter) mà trạng thái nội bộ của chúng thay đổi mỗi mẫu;
- các đặc trưng quan sát được (`RMS`, `spectralFlatness`, `dominantFrequency`, v.v.) phụ thuộc đồng thời vào nhiều tham số điều khiển và lịch sử DSP.

Do đó, các heuristic trực tiếp như:

`RMS -> sourceLevel`

`dominantFrequency -> f0Hz`

không phải là mô hình biến đổi ngược chính xác.

---

## Giả thuyết chính

Đối với giọng nói và bộ tổng hợp này, chúng ta cần phân tích **không phải một mẫu riêng lẻ hay một khung log riêng lẻ**, mà là một cửa sổ thời gian.

Thay vì:

`parameter[t] -> sample[t]`

hãy khảo sát:

`parameter trajectory[t0:t1] -> audio response[t0:t1+Δ]`

trong đó `Δ` là độ trễ phản ứng có thể có và/hoặc thời gian suy giảm của trạng thái DSP nội bộ.

Các thang đo cửa sổ làm việc để kiểm tra:

- 5 ms;
- 10 ms;
- 20 ms;
- 30 ms;
- 50 ms;
- 100 ms nếu cần thiết.

Đối với mỗi tham số, cần xác định ở thang đo thời gian nào ảnh hưởng của nó được quan sát ổn định nhất.

---

## Những gì cần khảo sát cho mỗi tham số VoiceControlState

Tối thiểu:

- `sourceLevel`
- `periodicity`
- `noiseLevel`
- `f0Hz`
- `glottalOpenPhase`
- `glottalReturnPhase`
- `resonance1Freq`
- `resonance1Bandwidth`
- `resonance1Gain`
- `resonance2Freq`
- `resonance2Bandwidth`
- `resonance2Gain`
- `resonance3Freq`
- `resonance3Bandwidth`
- `resonance3Gain`
- `outputLevel`

Đối với mỗi tham số, xác định:

1. **Độ nhạy** — sự thay đổi của nó ảnh hưởng mạnh đến mức nào đối với PCM và các đặc trưng.
2. **Độ trễ** — sau bao lâu kể từ khi thay đổi điều khiển thì ảnh hưởng này có thể quan sát được.
3. **Thời gian suy giảm** — hiệu ứng duy trì trong bao lâu sau khi tham số thay đổi.
4. **Tính cục bộ** — liệu tham số có chủ yếu ảnh hưởng đến dải phổ/đặc tính thời gian cụ thể hay ảnh hưởng toàn cục.
5. **Tính đơn nghĩa** — liệu hiệu ứng quan sát được có thể phân biệt sự thay đổi của tham số này với tham số khác hay không.
6. **Tương tác** — cặp tham số nào tạo ra hiệu ứng phi cộng tính.

---

## Thí nghiệm 1: Quét đơn tham số (Parameter sweep)

Đối với mỗi tham số:

1. Cố định tất cả các tham số khác ở một trạng thái cơ sở (baseline).
2. Chỉ thay đổi tham số đang khảo sát theo lưới giá trị.
3. Với mỗi giá trị, tổng hợp PCM có cùng thời lượng.
4. Thu thập đồng thời:
   - toàn bộ `VoiceControlState(t)`;
   - dấu vết (trace) DSP nội bộ;
   - PCM;
   - các đặc trưng âm học theo cửa sổ.
5. So sánh kết quả với baseline.

Ví dụ cho `f0Hz`:

- 80 Hz
- 100 Hz
- 120 Hz
- 150 Hz
- 180 Hz
- 220 Hz
- 300 Hz

Ví dụ cho `resonance1Freq`:

- cố định nguồn và các bộ cộng hưởng khác;
- chỉ dịch chuyển `resonance1Freq`;
- xem đỉnh phổ nào thực sự di chuyển và di chuyển như thế nào.

---

## Thí nghiệm 2: Thay đổi bậc thang theo thời gian

Kiểm tra phản ứng động của hệ thống.

Ví dụ:

`t < 100 ms: resonance1Freq = 600`

`t >= 100 ms: resonance1Freq = 800`

Phân tích các cửa sổ:

- 60–80 ms
- 80–100 ms
- 100–120 ms
- 120–140 ms
- 140–160 ms
- 160–200 ms

Mục tiêu:

- xác định thời điểm bắt đầu thay đổi có thể quan sát được;
- đo độ trễ;
- hiểu hình dạng của quá trình quá độ;
- đo thời gian ổn định.

Lặp lại cho các tham số khác.

---

## Thí nghiệm 3: Nhiễu động xung / ngắn hạn

Đối với các tham số có trạng thái (stateful), việc đo bộ nhớ của hệ thống là cực kỳ quan trọng.

Sơ đồ:

`baseline -> parameter + δ trong khoảng thời gian ngắn -> baseline`

Ví dụ:

- 100 ms baseline;
- 10–20 ms thay đổi;
- quay lại baseline;
- quan sát thêm 100–200 ms.

Đo lường:

- hiệu ứng xuất hiện nhanh đến mức nào;
- nó có được duy trì sau khi tham số quay lại hay không;
- DSP mất bao nhiêu thời gian để quay lại trạng thái ban đầu.

Đối với các bộ cộng hưởng, điều này sẽ cho thấy thời gian bộ nhớ thực tế của các trạng thái `low/band`.

---

## Thí nghiệm 4: Các cặp tham số

Sau khi quét đơn, kiểm tra sự tương tác cho ít nhất các cặp có liên quan nhất:

- `sourceLevel × outputLevel`
- `periodicity × noiseLevel`
- `f0Hz × glottalOpenPhase`
- `f0Hz × glottalReturnPhase`
- `resonanceFreq × resonanceGain`
- `resonanceFreq × resonanceBandwidth`
- `sourceLevel × resonanceGain`

Mục tiêu — hiểu xem các hiệu ứng của tham số có thể được coi là độc lập hay cần được khôi phục đồng thời.

---

## Dữ liệu cần ghi nhật ký (Log)

### Mức điều khiển

- tất cả các giá trị `VoiceControlState(t)`;
- automation đang hoạt động;
- thời điểm của mỗi lệnh `set` / `animate`.

### Dấu vết DSP nội bộ (Internal DSP trace)

Tối thiểu:

- `voicePhase`;
- `periodicSource`;
- `noiseSource`;
- `excitation`;
- `resonator1.low` / `resonator1.band`;
- `resonator2.low` / `resonator2.band`;
- `resonator3.low` / `resonator3.band`;
- đầu ra riêng của mỗi bộ cộng hưởng trước khi tổng hợp;
- `value` trước khi clamp;
- `value` sau khi clamp.

### Đặc trưng âm học theo cửa sổ

Tối thiểu:

- RMS / năng lượng;
- tỷ lệ cắt qua không (zero crossing rate);
- hàm tự tương quan (autocorrelation);
- ước tính cao độ (pitch estimate);
- ước tính tính chu kỳ;
- trọng tâm phổ (spectral centroid);
- độ phẳng phổ (spectral flatness);
- các đỉnh phổ;
- năng lượng theo dải tần;
- các đỉnh dạng formant / bao phổ;
- LPC nếu cần.

Quan trọng: coi `dominantFrequency` chỉ là một trong các đặc trưng phổ, chứ không phải là `f0Hz` trực tiếp.

---

## Cửa sổ thời gian và Tần suất ghi nhật ký

Cần kiểm tra riêng ảnh hưởng của việc giới hạn tốc độ (throttling).

Log hiện tại có thể ẩn cấu trúc thời gian quan trọng. Do đó, để nghiên cứu, tốt nhất là có dấu vết nội bộ thường xuyên nhất có thể, sau đó mới tổng hợp theo chương trình thành các cửa sổ.

Phương pháp khuyến nghị:

- DSP trace — càng gần mức mẫu (sample-level) càng tốt hoặc với việc giảm mẫu (decimation) có kiểm soát;
- đặc trưng âm học — tính toán trên các cửa sổ 5/10/20/30/50 ms;
- độ chồng lấp cửa sổ (overlap): 50–75% để phân tích thời gian mượt mà;
- không trộn lẫn tần số thu thập dữ liệu và kích thước cửa sổ phân tích.

---

## Kết quả mong đợi

Xây dựng bản đồ thực nghiệm:

`VoiceControl parameter -> observable consequences`

Đối với mỗi tham số, ghi lại:

- những đặc trưng nào phản ứng;
- hướng phản ứng;
- quy mô phản ứng;
- độ trễ;
- thời gian duy trì bộ nhớ;
- sự phụ thuộc vào các tham số khác;
- mức độ có thể khôi phục tham số từ âm thanh.

Nên trình bày dưới dạng bảng như sau:

| Control | Đặc trưng quan sát được | Độ trễ | Cửa sổ | Tính đơn nghĩa | Ghi chú |
|---|---|---:|---:|---|---|
| f0Hz | autocorrelation peak, harmonic spacing | ... | ... | cao/trung bình/... | ... |
| resonance1Freq | spectral envelope / peak shift | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |

---

## Tiêu chí kết quả

Sau khi nghiên cứu, cần phải làm rõ:

1. Những tham số `VoiceControlState` nào có thể được khôi phục trực tiếp từ âm thanh.
2. Những tham số nào chỉ có thể được khôi phục khi kết hợp với các tham số khác.
3. Những tham số nào hoàn toàn không thể quan sát được bằng tập đặc trưng hiện tại.
4. Cần bổ sung những đặc trưng bổ sung nào vào logger.
5. Decoder cần ngữ cảnh thời gian nào cho mỗi lớp tham số.
6. Có thể xây dựng decoder như một phép biến đổi phân tích/heuristic hay cần phương pháp tối ưu hóa/học máy.

Kết quả chính không chỉ là một decoder mới, mà là **mô hình tương ứng được xác thực về mặt vật lý và thực nghiệm giữa không gian điều khiển của bộ tổng hợp và âm thanh có thể quan sát được theo thời gian**.

Xây dựng bản đồ thực nghiệm về cách các thay đổi của tham số điều khiển theo thời gian thể hiện trong PCM và các đặc trưng âm học, có tính đến độ trễ và bộ nhớ của DSP.

Khảo sát tính nhân quả theo thời gian của VoiceControlState → DSP → đặc trưng âm học

## Mục tiêu

Tạo ra một giao diện trực quan mới không phải để chỉnh sửa mang tính thẩm mỹ cho một `VoiceScenario` đã có sẵn, mà là một **phòng thí nghiệm tổng hợp giọng nói thử nghiệm**.

Nhiệm vụ chính của giao diện là cho phép khám phá thủ công:

- những tham số tổng hợp nào;
- theo trình tự nào;
- vào những thời điểm nào;
- với những giá trị và quy luật thay đổi nào

tạo ra kết quả âm thanh này hay kết quả âm thanh khác.

Chúng ta KHÔNG giả định trước rằng chúng ta biết kịch bản chính xác cho một âm thanh cụ thể. Giao diện này cần thiết chính là để tìm kiếm: người dùng di chuyển các điểm thời gian và tham số, nghe kết quả, sau đó các âm thanh thú vị tìm được có thể được lưu lại và chuyển đi cùng với nhật ký/kịch bản để phân tích tiếp theo.

---

## Mô hình giao diện chung

Giao diện nên được tổ chức như một biểu đồ thời gian đa rãnh, có logic tương đồng đồng thời với:

- các rãnh tự động hóa (automation lanes) trong DAW;
- trình chỉnh sửa khung hình chính (keyframe editor);
- biểu đồ Gantt nhưng chỉ theo nghĩa là trục thời gian chung và đồng bộ hóa sự kiện.

Đây KHÔNG phải là biểu đồ Gantt cổ điển cũng không phải là danh sách các lệnh `set/animate`.

### Tọa độ

Đối với mỗi rãnh:

- trục ngang = thời gian;
- trục dọc = giá trị tham số;
- tham số được đặt bởi một tập hợp các điểm có thể chỉnh sửa `(time, value)`;
- có thể kéo điểm theo chiều ngang để thay đổi thời điểm sự kiện;
- có thể kéo điểm theo chiều dọc để thay đổi giá trị;
- quy luật chuyển đổi giữa các điểm được thiết lập.

UI có thể chuẩn hóa thang đo dọc về `0..1`, nhưng giá trị vật lý của tham số phải giữ nguyên phạm vi và đơn vị của riêng nó (`Hz`, gain, v.v.).

---

## Thời lượng âm thanh tổng thể riêng biệt

Cần có một tham số độc lập về **tổng thời lượng kịch bản**.

Điều này mang tính nguyên tắc: các tham số điều khiển có thể được thiết lập hoặc thay đổi chỉ ở phần đầu, nhưng trạng thái thu được phải tiếp tục phát ra âm thanh trong thời gian dài.

Ví dụ về mô hình ngữ nghĩa:

- thiết lập ngắn trạng thái và giữ âm `AAAAA` dài;
- các sự kiện sớm hình thành `MA`, sau đó trạng thái tiếp tục giữ `AAAAAAA` trong thời gian dài;
- sau điểm keyframe cuối cùng, giá trị của mỗi điều khiển tiếp tục được giữ cho đến tổng thời lượng của kịch bản.

Thời lượng không được tự động cắt bớt theo điểm điều khiển cuối cùng.

---

## Phát lại vòng lặp (Cyclic Playback)

Bắt buộc phải trang bị công tắc **"Lặp lại" (Loop)**.

Ở chế độ lặp lại:

- kịch bản được phát lại ngay lập tức sau khi kết thúc;
- người dùng không cần phải nhấn Play mỗi lần;
- các thay đổi về tham số/điểm phải có hiệu lực trong chu kỳ phát lại tiếp theo;
- người dùng có thể di chuyển một điểm hoặc giá trị và nghe thấy một vài biến thể kết quả qua một vài lần lặp liên tiếp.

Đây là chế độ quan trọng để tìm kiếm âm thanh thủ công.

---

## Các rãnh tham số

Ở giai đoạn đầu, trình chỉnh sửa phải hoạt động với tất cả các tham số hiện có của `VoiceControlState`.

Đối với mỗi rãnh, cần nhìn thấy:

- tên control;
- giá trị vật lý của nó;
- vị trí được chuẩn hóa trong thang đo dọc;
- các điểm keyframe;
- việc giữ giá trị giữa các sự kiện;
- hình dạng chuyển đổi giữa các điểm.

Trình chỉnh sửa phải hiển thị quỹ đạo thời gian thực tế của tham số, chứ không chỉ các phân đoạn `animate` hoạt động.

---

## Các loại chuyển đổi và bộ biến đổi

Kiến trúc phải được thiết kế ngay từ đầu sao cho giữa các điểm không chỉ tồn tại một loại `animate` duy nhất.

Cần có một mô hình mở rộng về **bộ biến đổi / bộ điều chế** khoảng thời gian.

Tối thiểu phải dự trù khả năng có các loại khác nhau trong tương lai:

- hold / giá trị không đổi;
- linear transition (chuyển đổi tuyến tính);
- bezier transition (chuyển đổi Bezier);
- bộ điều chế định kỳ;
- điều chế hình sin theo công thức;
- xung / burst;
- nhịp đập lặp đi lặp lại;
- điều chế nhiễu hoặc ngẫu nhiên khác;
- các hàm thời gian khác.

Nghĩa là, trong tương lai, trên dòng thời gian không chỉ có thể đặt keyframe mà còn cả **bộ biến đổi**, tạo ra một quỹ đạo tham số phức tạp trong khoảng thời gian đã cho.

Ví dụ ý nghĩa: tham số có thể có một cơ sở ổn định, nhưng bên trên nó tại một khoảng thời gian sẽ có sự điều chế định kỳ hoạt động.

---

## Mối liên hệ với sinh lý học giọng nói

Kiến trúc của trình chỉnh sửa không thể được thiết kế theo kiểu mỗi control hoàn toàn độc lập về mặt vật lý.

Con người chỉ có một cơ quan phát âm:

- một lưỡi;
- một cấu hình môi;
- một khoang miệng;
- một ống thanh quản;
- một hệ thống dây thanh quản và luồng không khí.

Không thể đồng thời đặt các trạng thái cấu âm loại trừ lẫn nhau như thể tồn tại hai ngôn ngữ độc lập hoặc hai hình dạng miệng độc lập.

Trong khi DSP hiện tại hoạt động trong không gian âm học (`f0`, tính tuần hoàn, nhiễu, cộng hưởng, gain, v.v.), trình chỉnh sửa phải được thiết kế để trong tương lai có thể đưa vào **các bộ biến đổi sinh lý/cấu âm được ghép nối**, điều khiển đồng thời nhiều control DSP một cách đồng bộ.

Ví dụ về các bộ biến đổi ngữ nghĩa có thể xuất hiện sau:

- mở/đóng miệng;
- thay đổi vị trí lưỡi;
- tích lũy và giải phóng (release) áp suất;
- tiếng nổ ngắn (burst);
- luồng không khí ổn định;
- rung/đập cơ quan cấu âm cho âm `R`;
- chuyển đổi giữa các trạng thái cấu âm.

Quan trọng: đây không phải là yêu cầu phải triển khai ngay lập tức một mô hình sinh lý học đầy đủ. Yêu cầu là **không đóng lại khả năng đó bằng kiến trúc**.

---

## Ý nghĩa đặc biệt của cấu trúc thời gian

Trình chỉnh sửa phải xuất phát từ thực tế là âm thanh chỉ có ý nghĩa trong thời gian.

Ví dụ, một phụ âm tắc không phải là một giá trị tham số duy nhất, mà là một chuỗi các pha:

- chuẩn bị/đóng;
- tích lũy;
- release (giải phóng);
- burst (nổ);
- phần đuôi nhiễu hoặc giọng nói;
- chuyển sang âm thanh tiếp theo.

Và một âm thanh kéo dài có thể là kết quả của một trạng thái ổn định được giữ trong thời gian dài sau một quá trình chuyển đổi đầu vào ngắn.

Do đó, người dùng phải nhìn thấy và chỉnh sửa **thành phần các pha theo thời gian**, chứ không chỉ là một danh sách các con số.

---

## Những gì cần lưu trữ

Thí nghiệm đã tìm thấy phải có khả năng tái tạo.

Cần có khả năng lưu trữ:

- tổng thời lượng;
- tất cả các rãnh và keyframe;
- các loại chuyển đổi/bộ biến đổi;
- các tham số của chúng;
- `VoiceScenario` cuối cùng hoặc biểu diễn có thể biên dịch;
- siêu dữ liệu thí nghiệm nếu cần thiết.

`VoiceScenario` hiện tại có thể được sử dụng như một runtime/định dạng thực thi, nhưng UI không được giới hạn bởi hình thức tập trung vào lệnh hiện tại của nó. Cho phép sử dụng một định dạng thử nghiệm/keyframe riêng biệt được biên dịch thành biểu diễn runtime.

---

## Mối liên hệ với runtime hiện có

Trình chỉnh sửa phải sử dụng cùng một runtime chung `VoiceScenario` được sử dụng bởi bộ tổng hợp và bộ trực quan hóa, sau khi tái cấu trúc thích hợp.

Không thể có ngữ nghĩa thực thi tham số riêng biệt chỉ bên trong UI.

Âm thanh thực tế và các quỹ đạo được hiển thị thực tế phải xuất phát từ một máy trạng thái (state machine) duy nhất.

---

## Điều gì KHÔNG phải là mục tiêu của giai đoạn đầu

Hiện tại không yêu cầu:

- tự động đoán âm thanh chính xác;
- tự động xây dựng một âm vị (phoneme);
- thêm các chỉ số âm học mới chỉ vì mục đích trực quan hóa;
- xây dựng ngay lập tức một mô hình sinh lý học đầy đủ của cơ quan phát âm;
- thay thế bộ giải mã (decoder).

Mục tiêu ứng dụng đầu tiên là **đơn giản hóa tối đa việc thử nghiệm thủ công**:

1. nhanh chóng sắp xếp các điểm thời gian;
2. thay đổi các giá trị;
3. nghe kết quả trong vòng lặp;
4. hiểu trình tự các hành động của chính mình;
5. lưu các tùy chọn thành công;
6. chuyển giao kịch bản tìm được và nhật ký của nó để phân tích thêm.

---

## Tiêu chí kết quả

Người dùng có thể mở phòng thí nghiệm, đặt tổng thời lượng, bật `Lặp lại` (Cyclic), sắp xếp và di chuyển các điểm keyframe của một vài tham số dọc theo trục thời gian chung và liên tục nghe thấy sự thay đổi ảnh hưởng như thế nào đến âm thanh.

Giao diện nên giúp ích chính xác trong việc **tìm kiếm các âm thanh chưa biết trước**, chứ không yêu cầu phải hiểu trước xem cần viết JSON gì.

Trình chỉnh sửa đa rãnh tương tác để thử nghiệm thủ công với các thông số tổng hợp theo thời gian, nghe lặp lại và tìm kiếm các âm thanh thú vị.

Tạo phòng thí nghiệm trực quan kịch bản thời gian VoiceSynthesizer

## Bối cảnh

Hiện tại chúng ta chưa xây dựng bộ tổng hợp mới và cũng không cố gắng nhận diện ngay chữ cái/âm vị. Mục tiêu của giai đoạn này là hiểu một cách nền tảng **chính xác những gì chúng ta có thể đo lường một cách đảm bảo từ bản ghi âm microphone**, bằng những phương pháp nào và với độ chính xác thời gian/tần số ra sao.

Giả thuyết làm việc: trước hết cần xây dựng một decoder/analyzer tốt như một thiết bị đo đạc, tìm ra các đặc trưng ổn định của các âm thanh quen thuộc và chỉ sau đó mới đi theo chiều ngược lại — xây dựng các bộ tạo (generators) tái tạo lại các đặc trưng này.

---

## Mô hình tín hiệu cơ bản

Tại `sampleRate = 48 kHz`, một giây PCM đơn (mono) tương ứng với 48.000 mẫu (samples) liên tiếp.

Mỗi sample là một giá trị biên độ tức thời cuối cùng. Sau khi trộn các nguồn bên trong, thông tin về việc **chính xác các thành phần nào tạo nên một sample riêng lẻ** đã bị mất đi.

Ví dụ, cùng một kết quả cuối cùng có thể thu được từ các tổng bên trong khác nhau. Do đó, việc khôi phục ngược lại các nguyên nhân riêng lẻ từ một sample duy nhất là bất khả thi.

Thông tin hữu ích chỉ xuất hiện khi phân tích **quỹ đạo theo thời gian**.

Cần phân biệt rõ:

- `x[n]` — độ lệch hiện tại của waveform;
- `Δx[n] = x[n] - x[n-1]` — hướng và tốc độ thay đổi;
- `Δ²x[n]` — sự thay đổi tốc độ / độ dốc của mặt sóng (transient);
- cấu trúc thời gian dài hạn;
- cấu trúc tần số.

Một số `0` đơn lẻ không có nghĩa là sự im lặng: bên trong dao động, đó có thể là thời điểm đi qua điểm cân bằng với tốc độ lớn. Sự nghỉ ngơi là một chuỗi kéo dài gần mốc số 0 mà không có sự thay đổi đáng kể.

---

## Những gì có thể đo lường trực tiếp trong miền thời gian

Ngay trước khi dùng FFT, chúng ta đã có thể tính toán các đặc trưng một cách đảm bảo trên các cửa sổ ngắn:

- RMS / năng lượng tổng;
- peak amplitude (biên độ đỉnh);
- mean absolute amplitude (biên độ tuyệt đối trung bình);
- zero crossing rate (tỷ lệ cắt qua số không);
- `mean(|Δx|)` — tốc độ thay đổi trung bình của waveform;
- `max(|Δx|)` — độ dốc của mặt sóng mạnh nhất;
- sai phân bậc hai / độ "gia tốc" cục bộ;
- variance (phương sai);
- crest factor (hệ số đỉnh);
- autocorrelation (tự tương quan) và các cực đại của nó;
- thời lượng của các đoạn im lặng / năng lượng thấp;
- onset / sự xuất hiện đột ngột của năng lượng;
- decay / sự suy giảm sau sự kiện.

Các chỉ số này tiềm năng đã phân tách các loại cơ chế khác nhau:

- âm có thanh (voiced) kéo dài;
- đoạn tiếng ồn/âm sát (fricative/noise) kéo dài;
- âm nổ ngắn (burst/plosive);
- khoảng lặng/đóng (silence/closure);
- sự rung định kỳ (periodic tremor).

---

## Phân tích tần số

Tần số không được lưu trữ trong PCM dưới dạng một trường riêng biệt. Nó được tính toán từ tính lặp lại của waveform.

Đối với một cửa sổ có độ dài `N` mẫu, có thể sử dụng:

- Fourier/FFT — các thành phần chu kỳ nào hiện diện;
- autocorrelation — waveform tự giống chính nó tại độ trễ (lag) nào;
- filter bank — năng lượng trong các dải tần được định nghĩa trước.

Đối với FFT, sự đánh đổi là rất quan trọng:

- cửa sổ dài → độ phân giải tần số tốt, định vị thời gian kém;
- cửa sổ ngắn → định vị thời gian tốt, độ phân giải tần số thô hơn.

Ví dụ:

- 1 s → khoảng 1 Hz;
- 100 ms → khoảng 10 Hz;
- 20 ms → khoảng 50 Hz;
- 10 ms → khoảng 100 Hz.

Đối với giọng nói, có lẽ sẽ cần phân tích đa tỷ lệ (multi-scale): nhận diện burst nhanh ở 5–10 ms, pitch/formants ở 20–50 ms, cấu trúc ổn định dài hạn ở 100+ ms.

---

## Các kênh tần số / bộ lọc thính giác (auditory filter bank)

Thay vì hàng nghìn FFT bins, việc xây dựng một tập hợp giới hạn các dải tri giác (perceptual bands) sẽ hợp lý hơn, ví dụ 24–40 dải theo thang đo logarit/ERB.

Ý tưởng cơ bản:

`PCM -> cửa sổ ngắn -> FFT/filter bank -> năng lượng của mỗi dải theo thời gian`.

Chúng ta nhận được một tập hợp các kênh cố định:

`Band 1 energy(t)`
`Band 2 energy(t)`
`...`

Số lượng kênh là cố định, trong khi mức độ hoạt động trong các kênh đó biến động theo thời gian.

Lớp trực quan đầu tiên có thể là biểu đồ nhiệt (heatmap):

- X = thời gian;
- Y = dải tần số;
- độ sáng = năng lượng.

Không cần phải mã hóa ngay nhiều chỉ số bằng độ dày hoặc màu sắc của một đường cong duy nhất. Giá trị dọc cơ bản của kênh có thể đơn giản là năng lượng được chuẩn hóa `0..1`.

---

## Sự khác biệt quan trọng: Tổng năng lượng và sự phân bố của nó

`Uint8 0..255` là định dạng của một sample tức thời, chứ không phải là "ngân sách năng lượng" giữa các dải.

Để phân tích, sẽ hữu ích hơn nếu tách biệt:

- `totalEnergy` của cửa sổ;
- phân bố năng lượng tương đối giữa các dải.

Ví dụ:

`Frame { totalEnergy, bands[] }`

trong đó khi chuẩn hóa, ta có thể có:

`sum(bands) ≈ 1`.

Điều này cho phép chúng ta nhìn nhận độc lập:

- tín hiệu mạnh đến mức nào nhìn chung;
- năng lượng đã dịch chuyển về phần nào của phổ tần số.

---

## Tìm kiếm các nhóm phổ (spectral groups)

Không nên cứng nhắc lấy `top N` dải mạnh nhất.

Một sơ đồ hợp lý hơn:

1. tính toán tất cả các dải;
2. loại bỏ các giá trị nằm dưới ngưỡng tiếng ồn thích ứng (noise floor/threshold);
3. tìm các cực đại cục bộ;
4. gộp các dải hoạt động liền kề thành các nhóm phổ;
5. liên kết các nhóm tương tự giữa các cửa sổ thời gian liền kề.

Bằng cách này, từ các kênh cảm biến cố định, ta thu được các đối tượng phổ trôi nổi (spectral objects):

- tần số trung tâm (center frequency);
- độ rộng băng thông (bandwidth);
- năng lượng;
- thời lượng;
- độ ổn định;
- onset/decay;
- tính chất chu kỳ / giống tiếng ồn (periodic/noise-like character).

Điều này gần gũi hơn với cách hệ thống thính giác nhóm các thành phần thành các đối tượng, hơn là việc chỉ chọn đơn giản mười bins mạnh nhất.

---

## Giả thuyết về các cơ chế phát âm

Thay vì hàng chục điều khiển dạng vô hướng (scalar controls) của bộ tổng hợp trong tương lai, đề xuất là hãy tư duy theo các cơ chế hoặc bộ tạo mang ý nghĩa sinh lý/âm học riêng biệt.

Ví dụ:

- frication/constriction (xát/hẹp) — cơ chế tiếng ồn kéo dài;
- plosive release (nổ) — burst cực ngắn sau khi đóng/tích áp suất;
- voicing (hữu thanh) — nguồn chu kỳ ổn định;
- trill (rung) — các ngắt quãng/điều chế tựa chu kỳ lặp đi lặp lại;
- nasal coupling (cộng hưởng mũi) — cấu trúc phổ đặc trưng;
- guttural mechanism (cơ chế họng) — loại kích thích/cộng hưởng riêng biệt.

Ý tưởng chủ chốt: các cơ chế phải khác nhau **không chỉ ở biên độ**, mà ở các đặc trưng quan sát được:

- thời lượng đặc trưng;
- dải tần số;
- tính chu kỳ (periodicity);
- onset/decay;
- độ rộng phổ;
- độ ổn định;
- tính lặp lại theo thời gian.

Khi đó, decoder tiềm năng sẽ có thể tách chúng ra khỏi PCM chung dựa trên các chữ ký động học (dynamic signatures).

---

## Kế hoạch thí nghiệm

Ban đầu chỉ làm việc với microphone và các ngữ liệu phát âm đã biết.

Thứ tự thực hiện:

1. Ghi âm các đoạn ngắn 0.5–1.5 s.
2. Phát âm các âm thanh/âm tiết/từ đã biết.
3. Xây dựng các chỉ số thời gian và tần số.
4. Tìm kiếm trực quan các chữ ký ổn định.
5. Kiểm tra các chữ ký tương tự ở các từ khác và các bối cảnh lân cận.
6. Kiểm tra khả năng phân biệt giữa các lớp gần nhau (`С/Ш` [S/Sh], `П/Т/К` [P/T/K], hữu thanh/vô thanh, v.v.).
7. Không gọi một mẫu (pattern) là "chữ cái" cho đến khi nó chuyển dịch được giữa các bối cảnh khác nhau.
8. Đạt được khả năng phân biệt cao trước hết cho một người, một microphone và trong các điều kiện có kiểm soát.
9. Chỉ sau đó mới thiết kế bộ tạo ngược lại (reverse generator).

Decoder phải trở thành một thiết bị đo đạc và sau đó là bài kiểm tra tự động cho bộ tạo:

`human audio -> decoder -> mechanism signature`

`synthetic audio -> decoder -> mechanism signature`

Việc so sánh được thực hiện trong không gian các đặc trưng đo lường được, chứ không chỉ mang tính chủ quan "giống/không giống".

---

## Tiêu chí chính của giai đoạn hiện tại

Không phải nhận dạng văn bản và cũng không phải tổng hợp giọng nói.

Chúng ta cần hiểu rõ:

> những đặc trưng nào mà chúng ta thực sự có thể đo lường một cách ổn định và tái lặp từ PCM, trên các thang thời gian nào, và những đặc trưng nào cho phép phân biệt các cơ chế giọng nói ổn định.

Ở giai đoạn này, việc xác nhận tính đo lường được và khả năng phân biệt quan trọng hơn việc thêm các thực thể mới vào bộ tạo.

Nghiên cứu lý thuyết về các thuộc tính của PCM và tín hiệu giọng nói mà chúng ta có thể đảm bảo đo lường được theo thời gian và tần số trước khi thiết kế bộ tạo tín hiệu mới.

Nhiệm vụ

Nghiên cứu các đặc trưng đo lường được của tín hiệu giọng nói trước khi xây dựng bộ tổng hợp mới

Tạo phòng thí nghiệm trực quan kịch bản thời gian VoiceSynthesizer

Khảo sát tính nhân quả theo thời gian của VoiceControlState → DSP → đặc trưng âm học

Khảo sát bộ giải mã ngược: âm thanh → VoiceScenario

Xây dựng Trình chỉnh sửa trực quan VoiceScenario và vòng lặp Con người ↔ AI

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