Đồ án Xây dựng chương trình xử lý âm thanh số

Mục lục

 

 

phần I: giới thiệu chung

1. Giới thiệu chung 1

2. Đặt vấn đề 1

3. Chủ đề của luận án 2

phần ii: cơ sở lý thuyết

Chương 1: lý thuyết xử lý tín hiệu số 3

1. Tín hiệu số 3

2. Xử lý tín hiệu số (DSP - Digital Signal Processing) 3

2.1. Phép biến đổi Z 4

2.2. Biến đổi Fourier rời rạc (DFT - Discrete Fourier Transform) 6

2.3. Lọc tín hiệu 6

2.4. Hàm cửa sổ 7

2.5. Phép biến đổi nhanh Fourier (FFT - Fast Fourier Transform) 8

2.6. Cepstrum 9

Chương 2: giới thiệu chung về âm thanh số 10

1. Âm thanh và đặc tính của âm thanh 10

1.1. Sóng âm và cảm giác âm 10

1.2. Độ cao của âm 10

1.3. Âm lượng của âm (độ to của âm) 10

1.4. Âm sắc của âm 11

2. Âm thanh số 11

2.1. Nguyên lý 11

2.2. Tần số và cường độ 12

3. Định dạng dữ liệu 13

4. Khuôn dạng lưu trữ 15

phần III: giải pháp xử lý

Chương 3: khuôn dạng tệp âm thanh 17

1. Khuôn dạng lưu trữ 17

1.1. Au/ Snd 17

1.2. Voc 19

1.3. Wave/ Riff 23

1.4. Aiff/ Aiff-C/ Aif/ Snd 27

1.5. IFF/8 SVX 30

1.6. MIDI 33

1.7. Mod/ Sam 36

1.8. MPEG 39

1.9. VBA , VBase ADPCM (.VBA) 42

1.10. VCE, NMS VCE (.VCE) 42

1.11. TXT 42

1.12. SMP, SampleVision (.Smp) 43

1.13. VOX 43

1.14. PCM, PCM Raw Data (.PCM) 44

1.15. DWD , DiamondWare Digitized (.DWD) 44

1.16. RA, RealAudio 3.0 (.RA) 44

2. Thao tác với tệp âm thanh 44

2.1. Thu thanh tạo tệp âm thanh 44

2.2. Soạn thảo 45

2.3. Phát âm 45

Chương 4: Hàm cửa sổ và lọc tín hiệu 46

1. Hàm cửa sổ 46

1.1. Rectangular 46

1.2. Hamming 47

1.3. Hanning 47

1.4. Triangle (Bartlett) 47

1.5. Black man 48

1.6. Flat top 48

1.7. Exponent down 48

2. Lọc tín hiệu 49

Chương 5: FFt và cepstrum 50

1. FFT (Fast Fourier Transform) 50

1.1. Nguyên lý 50

1.2. FFT trong âm thanh số 50

2. Cepstrum 51

phần iV: thiết kế và cài đặt

Chương 6: Phương pháp thiết kế 53

1. Khái quát chức năng 53

2. Cơ chế thực hiện 54

Chương 7: Thao tác với tệp âm thanh 55

1. Truy nhập tệp Wave 55

2. Truy nhập tệp Voc 56

3. Cấu hình dữ liệu 57

4. Soạn thảo 58

4.1. Nguyên lý 58

4.2. Thao tác dưới dạng trực quan 59

4.3. Cơ chế thực hiện 61

5. Phát thanh 64

5.1. Thu thanh 64

5.2. Phát thanh 64

Chương 8: Phân tích tín hiệu 66

1. Phổ biên độ 66

Hàm cửa sổ (Windows) 69

2. Cepstrum 74

3. Một vài trợ giúp khác 79

3.1. Xác định tần số trội (tần số trung bình vùng biên độ đỉnh) 79

3.2. Tính phổ của mẫu cho trước 80

Chương 9: Hướng dẫn sử dụng 81

1. Giao diện chương trình 81

2. Tuỳ chọn chức năng 82

phần v: Đánh giá chương trình

1. Đánh giá chương trình 83

2. Hướng phát triển 83

3. Kết luận 84

Phụ lục A: Giải thích thuật ngữ 85

Phụ lục B: Tài liệu tham khảo 86

 

 

doc87 trang | Chia sẻ: netpro | Lượt xem: 5847 | Lượt tải: 1download
Bạn đang xem trước 20 trang tài liệu Đồ án Xây dựng chương trình xử lý âm thanh số, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
uyên được tham chiếu tới như IFF/8SVX. Dạng 8SVX đã được thiết kế cho việc điều khiển các nhạc cụ âm nhạc đã được số hoá. Dạng 8SVX có thể chứa một chuỗi các khúc. Sau đây là một vài trong số đó: Tên Mô tả VHDR Thông tin về khuôn dạng âm thanh NAME Tên của âm thanh (c) Thông tin về quyền tác giả AUTH Tác giả ANNO Phần chú thích BODY Dữ liệu âm thanh ATAK Attack RLSE Release Đọc tệp IFF Theo lý thuyết, các khúc trong một container được đưa đến có thể xuất hiện theo hầu hết bất cứ thứ tự nào. Điều này tạo nên sự phức tạp khi đọc một tệp IFF tuỳ ý. Nói chung, ta cần đọc các thông tin về định dạng dữ liệu (khúc VHDR) trước khi đọc các dữ liệu âm thanh (khúc BODY). Tuy nhiên, trong thực tế ta thường viết thông tin về định dạng dữ liệu (khúc VHDR) trước dữ liệu âm thanh (khúc BODY). Do đó, chỉ cần đọc trực tiếp tệp và xử lý các khúc ngay trong quá trình đọc. Khúc FORM Một tệp IFF chứa một FORM container đơn, mà nó chứa mọi khúc khác trong tệp, và khúc ngoài cùng nhất luôn là khúc FORM. Và để xử lý khúc FORM chỉ cần đánh dấu nó như một container và sau đó xử lý theo dạng container. Khúc VHDR Khúc VHDR chứa các thông tin cơ bản về khuôn dạng của dữ liệu âm thanh. Thông thường, IFF/8SVX được thiết kế như một khuôn dạng về nhạc cụ cho bản nhạc trong quá trình phát. Một tệp IFF/8SVX đơn chứa quá trình thu thanh của một nhạc cụ đơn. Khuôn dạng của khúc VHDR: Kích thước Mô tả 4 Các mẫu "one-shot" cho nốt nhạc cao nhất 4 Lặp lại các mẫu cho nốt nhạc cao nhất 4 Các mẫu trong mỗi chu kỳ cho nốt nhạc cao nhất 2 Các mẫu trong mỗi giây 1 Octaves trong khúc BODY 1 Phương thức mã hoá (0: PCM, 1: mã hoá dạng Fibonacci, 2: mã hoá dạng Exponential) 4 Âm lượng (65,536= mức âm lượng cao nhất) Một âm thanh IFF/8SVX bao gồm một phân đoạn "one-shot" khởi đầu và tiếp theo là phân đoạn "repeat". Khi được phát như một nhạc cụ, phân đoạn lặp có thể được lặp cho tới cuối nốt nhạc. Khi IFF/8SVX được sử dụng cho một quá trình thu thanh đơn giản, thậm chí như một nhạc cụ, độ dài phân đoạn lặp được thiết lập về 0. Quá trình phát một nhạc cụ số yêu cầu biến đổi âm thanh để tạo ra các nốt nhạc khác nhau. Với IFF/8SVX, có 2 kỹ thuật được sử dụng. Công cụ cơ bản là phát âm thanh theo các tần số (speed) khác nhau. Nếu ta biết cường độ (pitch) của nốt nhạc đã thu thanh và cường độ của nốt nhạc mà ta mong muốn, ta có thể điều chỉnh tần số phát lại để có thể đạt được bất cứ cường độ mong muốn nào. Các tệp IFF/8SVX cho phép lưu trữ một chuỗi các quá trình thu thanh của cùng một nhạc cụ tại các cường độ khác nhau nên ta có thể chọn quá trình thu thanh gần nhất với cường độ mong muốn, giảm tối đa sai số. Trường thứ 3 trong bảng trên là cường độ của nốt nhạc thu thanh cao nhất. Khúc BODY lưu trữ các nốt nhạc đã được thu thanh theo kiểu kế tiếp (nốt này tiếp theo nốt khác) mà bắt đầu là nốt có cường độ cao nhất. Mỗi nốt kế tiếp là một quãng 8 (octave) thấp hơn về cường độ so với nốt kế trước và được thu thanh tại tần số lấy mẫu khác. Ngoài ra, trường thứ 4 (số mẫu trong mỗi giây) được bỏ qua đối với các quá trình thu thanh nhạc cụ bởi vì thông tin về cường độ được lấy ra. Với các âm thanh thu thanh đơn giản, thông tin trong VHDR là không cần hay không được sử dụng. Trong trường hợp này, số vòng lặp các mẫu, các mẫu trong mỗi chu kỳ, và các trường octave được thiết lập về 0. Các tệp IFF/8SVX luôn là dạng mono. Để lựa chọn bộ giải mã, cần đảm bảo rằng khúc VHDR đã được đọc, sau đó sử dụng mã dạng này. Hơn nữa, phần lớn các tệp IFF/8SVX sử dụng dữ liệu âm thanh dạng PCM 8-bit. Khúc BODY Khúc BODY lưu trữ dữ liệu âm thanh đã được nén hiện thời. Các dữ liệu âm thanh được đọc từ khúc này. Các khúc văn bản Một loạt các khúc cần tới các phần chú thích dạng văn bản. Các khúc này có thể xuất hiện trong bất cứ dạng tệp IFF nào (bao gồm cả Aiff và Aiff-C). Mọi khúc này có cùng một khuôn dạng cơ bản; chúng chứa một chuỗi ký tự ASCII. 1.6. MIDI Mặc dù có thể lưu trữ một bài hát như dạng thu thanh Wave hay Au, nhưng có 2 lý do chính cho việc phải có các khuôn dạng âm nhạc riêng biệt. Trước hết đó là kích thước. Việc lưu trữ một dẫy các nốt nhạc sẽ tiện lợi hơn cho quá trình phát so với việc lưu trữ quá trình thu thanh toàn bộ bài hát. Lý do thứ hai là rất dễ dàng trong việc thay đổi. Nếu ta có một quá trình thu thanh buổi hoà âm, rất khó khăn trong việc tách biệt và thay đổi một nhạc cụ đơn, nhưng nếu được lưu trữ dưới dạng một dẫy các nốt nhạc thì ta sẽ dễ dàng soạn thảo nó. Các tệp MIDI chuẩn Một tệp MIDI là một chuỗi các khúc. Các khúc này có cùng một khuôn dạng chung giống như các khúc được sử dụng trong các tệp Aiff, Iff, và Wave. Mỗi khúc có 4 ký tự phân loại, một mã độ dài kích thước 4-byte (trong khuôn dạng MSB), và một vài dữ liệu. Tuy nhiên, khác với các khuôn dạng khác, các khúc MIDI không xếp chồng. Hiện nay, chỉ có 2 loại khúc. Khúc MThd chứa thông tin về header nói chung; và khúc MTrk chứa một rãnh đơn. Khúc MThd xuất hiện tại phần đầu của mọi tệp MIDI, và đây là dấu hiệu để định danh một tệp MIDI chuẩn. Khúc MIDI Header Khúc MThd chứa một chút các sự kiện cơ sở về tệp MIDI. Mọi giá trị này được lưu trữ trong khuôn dạng MSB. Sau đây là nội dung của khúc MIDI MThd: Bytes Mô tả 2 Dạng tệp 2 Số các rãnh 2 Khuôn dạng thời gian Có 3 loại tệp MIDI, chúng được phân loại tuỳ theo cách xử lý các rãnh: Tệp dạng 0 chỉ chứa duy nhất một rãnh. Một cách rõ ràng, đây là tệp dễ nhất để có thể phát, nên đây là dạng thông dụng cho các tệp quảng cáo. Tệp dạng 1 chứa rất nhiều rãnh mà chúng được phát một cách đồng thời. Một chương trình dùng để phát các tệp dạng 1 phải bằng cách nào đó san phẳng dữ liệu thành các dòng sự kiện đơn trước khi phát. Tệp dạng 2 chứa nhiều rãnh nhưng không thừa nhận bất cứ sự liên hệ nào giữa các rãnh. Nói chung, các tệp dạng 2 là không phổ biến. Các rãnh MIDI Chú ý rằng một rãnh là khác so với một kênh MIDI. Mặc dù đây là dạng chung cho các tệp multi-track để có thể phát mỗi rãnh trên một kênh khác nhau, và trong quá trình tổ hợp một bản nhạc có thể sử dụng số các rãnh tuỳ ý để có thể phát các rãnh trên các kênh khác nhau theo bất cứ kiểu mẫu nào. Mỗi rãnh MIDI là một danh sách các sự kiện, mà mỗi sự kiện có một “delta time” đặt trước. Mỗi khúc trong một tệp MIDI có một độ dài đã được ấn định, nên cần thận trọng khi rãnh hoá số các bytes được đọc để ta có thể biết khi nào dữ liệu rãnh kết thúc. Nếu đây không phải rãnh đầu tiên, thì cần phải đảm bảo rằng các sự kiện mới đã hoàn toàn được chèn vào trong bộ nhớ danh sách các sự kiện. Giống như bất kỳ danh sách mã chèn nào, quá trình chèn một sự kiện MIDI yêu cầu hai trường hợp sau: một, nếu sự kiện vào phần đầu của danh sách (trong trường hợp này cần phải cập nhật đầu đọc danh sách); hai, nếu sự kiện vào giữa danh sách (trong trường hợp này một container trỏ khác nhận sự cập nhật). Điều này làm tăng sự phức tạp bởi sự cần thiết chèn nó vào tại vị trí tạm thời chính xác và điều chỉnh các độ trễ một cách thích hợp. Ngoài ra, để duy trì không gian, các tệp MIDI sử dụng các số nguyên biến độ dài để lưu trữ các “delta times” và các giá trị tới hạn khác. Điều này cho phép các giá trị nhỏ (như giá trị 0) có thể được lưu trữ trong một byte đơn đồng thời cho phép các giá trị đạt tới 32 bits. Delta times Các sự kiện MIDI xuất hiện tại một số thời điểm xác định. Có 2 cách để đánh dấu các thông tin này: Lưu trữ thời gian tuyệt đối tại mỗi thời điểm mà sự kiện xuất hiện, hay có thể lưu trữ các quãng thời gian giữa các sự kiện. Mỗi sự kiện được đặt trước bởi một số chỉ ra số các ticks để tách biệt nó với sự kiện trước đó. Khoảng tồn tại chính xác của một tick phụ thuộc vào khuôn dạng thời gian đã được ấn định trong header, và cũng có thể được thay đổi bởi các sự kiện riêng biệt trong tệp. Các sự kiện MIDI Một sự kiện MIDI là một gói các dữ liệu mà nó chỉ rõ một số các sự kiện âm nhạc, như việc nhấn và nhả phím. Byte đầu tiên của gói là byte trạng thái, mà nó định rõ dạng của sự kiện, và đôi khi, là kênh truyền. Các bytes trạng thái thường xuyên có thiết lập bit cao. Còn lại là các byte dữ liệu, mà chúng không bao giờ có thiết lập bit cao. Sự phân biệt này là rất quan trọng. Theo cách chung, các kênh truyền MIDI được đánh số từ 1 tới 16, và các nhạc cụ MIDI là từ 1 tới 128. Tuy nhiên, các mã hoá số xắp hàng từ 0 tới 15 và 0 tới 127 một cách tương ứng. Ta sẽ thêm hay bớt 1 khi chuyển đổi giữa các mã số hoá và ngôn ngữ MIDI. Running Status Để tạo "wire protocol" thêm hiệu quả, MIDI sử dụng một kỹ thuật gọi là “running status”, kỹ thuật này bỏ qua các bytes trạng thái lặp. Khi đọc một tệp MIDI, nếu gặp một byte dữ liệu, trong khi ta đang cần một byte trạng thái, thì ta dùng lại trạng thái trước đó. Để tạo cho kỹ thuật này thêm hữu hiệu, có một quy ước rằng một “note-on event” với một vận tốc (velocity) thiết lập về 0 cũng giống như một “note-off event” với một vận tốc ngầm định là 64. Như vậy, một dẫy dài các notes trên một kênh truyền đơn có thể được kiểm soát với chỉ 2 bytes cho mỗi sự kiện. Quản lý các sự kiện MIDI Các tệp MIDI thường được lưu trữ như các rãnh đơn. Mặc dù các sự kiện trong mỗi rãnh được lưu trữ theo thứ tự tạm thời, luồng sự kiện mà nó nhận được để phát là một tổ hợp của các rãnh này. Hơn nữa, các sự kiện trong mỗi rãnh (như những sự thay đổi về nhịp độ) tác động lên quá trình phát lại của các sự kiện trong các rãnh khác. Cho các tệp dạng 1, cần phải đọc mọi sự kiện vào bộ nhớ trước khi phát chúng. Để đạt được điều này, cần lưu trữ một danh sách liên kết đơn của các sự kiện MIDI. Phần lớn các sự kiện gồm một byte trạng thái và một cặp byte dữ liệu. Và cũng cần phải lưu trữ giá trị độ trễ và số rãnh mà sự kiện này xuất hiện. Vài sự kiện MIDI riêng biệt có thể chứa một lượng tuỳ ý các dữ liệu, nên cần thêm một cấu trúc phụ để nắm giữ dữ liệu đó khi cần đến. Phần lớn các sự kiện MIDI có độ dài cố định. Ví dụ như một “note-on event” có 2 bytes dữ liệu tiếp theo các bytes trạng thái. Khuôn dạng MIDI Khuôn dạng MID là các tệp điều khiển âm thanh trong multimedia. MIDI là một hệ thống hoàn chỉnh không chỉ có khuôn dạng xác định mà còn có các tín hiệu và hệ thống phần cứng. Các tệp MIDI lưu giữ một dòng các lệnh cho các hệ thống tổng hợp (synthesizer) MIDI. Các tệp được xây dựng từ các khúc (chunks). Có hai loại khúc: header chunk và track chunk. Mỗi tệp MIDI gồm một header chunk và một hoặc nhiều track chunk. Mỗi khúc có 4 byte để nhận dạng. Các dấu hiệu theo sau 4 byte xác định độ dài dữ liệu trong khúc (không kể 8 byte dữ liệu mô tả), cho phép một khúc dài 4GB. Header chunk Bắt đầu bằng các ký tự “MThd” trong dạng mã ASCII, header chunk thường có độ dài 16byte, mã hoá như 06 00 00 00 theo khuôn dạng "little-endian" (Intel) trong tệp MIDI. 8byte đầu của header chunk theo dạng word biểu diễn phạm vi dữ liệu trong tệp. 0, (trên đĩa 00 00): tệp định nghĩa một rãnh đa kênh đơn. 1, (trên đĩa 01 00): tệp giữ một hoặc nhiều rãnh được chơi cùng một lúc. 2, (trên đĩa 02 00): tệp nén một hoặc nhiều mẫu rãnh đơn mà chúng độc lập với quá trình chơi liên tiếp. Vị trí từ tiếp theo (byte thứ 11 và 12) biểu thị số track chunk riêng biệt được chứa trong tệp. Khuôn dạng này cho phép tới 65.535 chunk dữ liệu trong một tệp. Từ cuối cùng trong header chunk (byte thứ 13 và 14) xác định gía trị trung bình của delta-time trong một track chunk. Dữ liệu trong các byte đó lấy một trong hai dạng. Khi bit MSB = 0 thì 15 bit thấp hơn biểu thị số tick trong một phần tư nốt nhạc. Khi bit MSB = 1 nó biểu diễn thời gian trong một time code và byte thấp hơn biểu thị số tick trong một khung SMPTE. Track chunk Bắt đầu với “MTrk” trong dạng mã ASCII, một track chunk bắt đầu với 8byte nhận dạng (4byte như “MTrk”, 4byte sau biểu diễn độ dài) theo sau là một track event. Mỗi track event có hai phần, một biến độ dài delta time (1 tới 4 byte) mô tả thời gian trước sự kiện và bản thân sự kiện. Sự kiện có thể là một trong số các dạng sau: một sự kiện MIDI (đơn giản là một bản tin về kênh truyền MIDI), một bản tin dành riêng của hệ thống (gọi là sysex event), hoặc một Meta event, không phải thông tin cho bộ tuần tự. Một bản tin dành riêng của hệ thống là một chuỗi dữ liệu có dạng ba phần: một byte nhận dạng, thường là F0(Hex) hoặc F7(Hex), theo sau là một tới ba byte biểu diễn độ dài chuỗi dữ liệu và bản thân chuỗi dữ liệu. Một Meta event gồm bốn phần: byte đầu tiên thường là FF(Hex), tiếp theo là mã kiểu 1byte. Tiếp theo là một biến biểu diễn độ dài của dữ liệu trong Meta event. Phần cuối cùng là dữ liệu Meta event. 1.7. Mod/ Sam Mặc dù MIDI là một dạng lưu trữ nhạc tốt, nhưng nó cũng có một vài vấn đề. Khởi đầu, MIDI đã được phát triển cho việc kết nối với nhiều loại phần cứng về nhạc. Một bộ tổng hợp sẽ chỉ đáp ứng cho một tập ấn định các âm thanh nhạc cụ, và mỗi bộ tổng hợp là khác nhau. Thậm chí, mỗi nhạc cụ với cùng một tên nhưng lại nghe có vẻ khác nhau, nên nhiều tệp MIDI chỉ nghe chuẩn trên một vài bộ tổng hợp nào đó. Chính vì vậy, người ta sử dụng thêm dạng tệp Mod. Bằng cách bao gồm các âm thanh nhạc cụ đã được thu thanh, các tệp Mod độc lập với các tính năng của bất cứ bộ tổng hợp hay card âm thanh nào. Chính vì vậy, các tệp Mod nghe có vẻ như giống nhau trên mọi hệ thống. Khác với MIDI, các tệp Mod được cấu trúc dựa quanh các beat. Mỗi beat tương ứng với một quãng thời gian và nó hoàn toàn mô tả những gì xẩy ra trong quãng đó. Một kết quả khác là các tệp Mod có thể chỉ phát một số giới hạn các nốt nhạc đồng thời. Mặc dù điều này có thể là một trở ngại cho các nhà soạn nhạc, nhưng nó lại là một ưu điểm cho những người lập trình, những người khai thác giới hạn này để cung cấp quá trình phát lại thêm xác thực. Các tệp Mod không thể được định danh một cách xác thực giống như một vài dạng khác. Dạng biến thể phổ biến Pro Tracker chứa 4-byte ký hiệu, nhưng lại không định vị tại phần đầu của tệp. Các dạng biến thể Mod khác không những sử dụng các dấu hiệu khác nhau, mà lại định vị chúng tại các vị trí khác nhau trong tệp. Khuôn dạng chung của Mod Khuôn dạng tệp Mod có thể được coi như một dạng nén mới. Nó định danh một chuỗi các mẫu hình lặp trong phần nhạc nên việc lưu trữ trở nên rất gọn nhẹ. Ví dụ, nó lưu trữ nốt nhạc đã thu thanh cho mỗi nhạc cụ, mà nó sẽ được mở rộng thành một chuỗi các âm thanh trong quá trình phát lại. Nó cũng lưu trữ các mẫu hình, các phân đoạn ngắn của bản nhạc mà chúng có thể được lặp hay phát lại theo bất cứ trình tự nào để tạo sự thuận lợi cho các chuỗi lặp nốt nhạc. Các tệp Mod chung nhất cho phép tới 31 âm thanh nhạc cụ khác nhau. Mỗi âm thanh được đặc trưng bởi các mẫu đã được số hoá với một phân đoạn lặp tuỳ chọn, cùng với một âm lượng ngầm định và tham số “finetune”. Tham số này cho phép tần số phát lại chính xác (và cường độ) có thể được điều chỉnh trên mỗi nhạc cụ cơ bản. Timing Đơn vị thời gian chuẩn được sử dụng trong một tệp Mod là “tick”, thường là 1/50 giây. (Tốc độ này tương ứng với tần số vẽ lại theo chiều dọc trong phiên bản European/PAL của Amiga. Một vài tệp Mod không chuẩn có thể lấy giá trị 1/60 giây, tương ứng với phiên bản US/NTSC của Amiga. Rất nhiều trình phát các tệp Mod cho phép điều chỉnh tần số tick). Tệp Mod cho phép một chuỗi các thay đổi về âm thanh xuất hiện trong mỗi tick. Ví dụ như, một nốt nhạc được phát với sự rung sẽ có âm lượng của nó được điều chỉnh trên mỗi tick. Tuy nhiên, những sự thay đôỉ về nốt nhạc có thể chỉ xuất hiện tại phần đầu của mỗi beat mới. Thông thường, một beat là 6 ticks, mặc dù giá trị này cho phép được điều chỉnh tuỳ ý. Các beats cũng được quy chiếu tới như các hàng, bởi vì rất nhiều trình soạn thảo tệp Mod hiển thị mỗi beat trên một hàng của phần hiển thị văn bản. Notes Mỗi beat là một tập hoàn chỉnh các nốt nhạc(notes). Mỗi nốt nhạc bao gồm một số nhạc cụ, một thời đoạn (period), và một mã tác động. (Một vài khuôn dạng biến thể khác cũng lưu trữ trong mỗi nốt nhạc mức âm lượng). Số nhạc cụ và thời đoạn tương ứng một cách trực tiếp với phần cứng về âm thanh của Amiga. Nếu cả số nhạc cụ và thời đoạn là 0, thì nốt nhạc trước đó nên tiếp tục được phát. Nếu chỉ một trong hai số này bằng 0, thì một nốt nhạc mới sẽ bắt đầu nhưng giá trị 0 sẽ được thay thế bởi giá trị trước đó. Beats Một beat bao gồm một sự định rõ nốt nhạc riêng cho mỗi kênh. Thông thường có 4 kênh, nhưng các dạng biến thể khác có thể có 6 hay 8 kênh. Ngoài ra, mỗi beat còn có một khoảng xác định, thường là 6 ticks, mặc dù khoảng này có thể được thiết lập lại. Patterns Các tệp Mod được thiết kế cho quá trình lưu trữ âm nhạc, mà chúng có các phân đoạn lặp. Một mẫu hình (pattern) lưu trữ tới 64 beats. Tại mỗi tần số lấy mẫu phát lại bình thường, nó chỉ phát nhạc trong vòng hơn 7 giây. Một tệp Mod có thể có tới 64 mẫu hình. Một vài dạng Mod khác không lưu trữ các mẫu hình, mà chúng lưu trữ một danh sách liên tiếp các beats. Playlist Playlist là một danh sách chứa tới 128 số mẫu hình. Nói chung, một trình phát một tệp Mod phức tạp hơn so với trình phát các khuôn dạng Wave và AIFF, mặc dù không phức tạp như trình phát MIDI. Cấu trúc chung của một tệp Mod như sau: Độ dài Mô tả 20 Tên bài hát 30 cho mỗi nhạc cụ Dữ liệu về nhạc cụ 1 Độ dài của playlist 1 Số các mẫu hình (chỉ trong các tệp cũ) 128 Playlist 4 Signature 1024 cho mỗi mẫu hình Các mẫu hình Tiếp theo là dữ liệu về mẫu hình nhạc cụ. Phần "Signature" được sử dụng để chỉ ra khuôn dạng chính xác của tệp. Nhưng phần này không xuất hiện tại cùng một định vị trong mọi khuôn dạng Mod. Sau đây là một vài trong số các ký hiệu chung nhất: Kí hiệu Mô tả M.K Chữ ký chung nhất. M!K! Giống như dạng trên, nhưng có nhiều hơn 64 mẫu hình. FLT4 Tương tự như M!K! FLT8 Mỗi beat có 8 kênh 6CHN Mỗi beat có 6 kênh 8CHN Mỗi beat có 8 kênh 1.8. MPEG (Moving Pictures Expert Group) Đây là một chuẩn mà ISO đã phát triển (5/1988) cho việc nén một chuỗi các hình ảnh video. Mặc dù các chuẩn MPEG là rất nổi tiếng cho việc nén các hình ảnh video, nhưng chúng cũng đáp ứng cho việc nén các âm với chất lượng cao. Hiện nay, có 3 dạng chuẩn MPEG chính: MPEG-1, MPEG-2, MPEG-3. Sự phân biệt giữa các tệp MPEG âm thanh và hình ảnh video là rất quan trọng. Các chuẩn MPEG xác định 3 khuôn dạng lưu trữ. Một tệp có thể chứa một dòng hình ảnh (video stream), một dòng âm thanh (audio stream), hay một dòng hệ thống (system stream) là dòng mà nó được chèn vào xen kẽ một vài tổ hợp của các dòng âm thanh và hình ảnh. Cả 3 dạng tệp này đều được sử dụng rộng rãi. Nói chung chuẩn MPEG khác so với vài chuẩn khác. ở đây, ta chỉ xét tới khuôn dạng của một dòng bit (bitstream) MPEG, và cách mã hoá dòng bit đó chứ không chỉ ra kỹ thuật nén. Một cách chủ yếu, một dòng bit âm MPEG định rõ giá trị tần số của âm thanh và cách giá trị đó thay đổi theo thời gian. Theo cách để lưu trữ khoảng trống, bộ nén sẽ loại bỏ thông tin một cách có lựa chọn. Chuẩn chỉ rõ cách thông tin giữ lại được mã hoá và bộ giải mã có thể cấu trúc các mẫu âm PCM từ dòng bit MPEG. Bằng cách đặt lại quá trình xử lý mã hóa không xác định, các bộ cài đặt có thể tự do sử dụng một chuỗi các kỹ thuật để quyết định xem thông tin nào là quan trọng. Những kỹ thuật này có thể bao gồm các bộ mã hoá đơn giản cho các ứng dụng chất lượng thấp hơn, và các bộ mã hoá được chi tiết hoá cho các dạng âm thanh riêng biệt (ví dụ như quá trình nén chất lượng cao cho dàn nhạc có thể khác với quá trình nén chất lượng cao cho tiếng nói). Cấu trúc chung Giống như nhiều kỹ thuật nén định hướng phần cứng, dữ liệu đã được nén MPEG được định nghĩa như một dòng các bit. Một dòng bit MPEG bao gồm các khung (frame) dữ liệu nén. Mỗi khung chứa một "frame header" mà nó xác định khuôn dạng dữ liệu đó. Để giải mã dữ liệu, cần phải rãnh hoá các bytes vào, định danh và phân tích các "frame header", và sử dụng thông tin trong các header để giải nén các khung riêng biệt. Frame Header của MPEG Một frame header luôn là 32 bits và được xắp hàng trên một byte đường biên. 12 bits đầu tiên đều là 1, cho sự đồng bộ hoá; các bits còn lại được chỉ ra trong bảng sau. 12 bits giá trị 1 là "syncword". Nếu bộ giải mã mất rãnh nơi mà nó đang định vị, thì nó có thể tìm về phía trước cho "syncword" tiếp theo và định vị lại từ đó. MPEG frame Header: Byte Bits Mô tả 0 8 Cho sự đồng bộ, mọi giá trị đều bằng 1 1 4 Cho sự đồng bộ, mọi giá trị đều bằng 1 1 ID: 0 chỉ ra rằng các phần mở rông MPEG-2 đang được sử dụng 2 Tầng: 11=tầng 1, 10=tầng 2, 01=tầng 3, 00=dự trữ 1 Bit bảo vệ: 0 nếu CRC được kèm vào 2 4 Chỉ số tần số bit 2 Chỉ số tần số mẫu 1 Chèn thêm: 1 nếu có một khe phụ 1 Private 3 2 Chế độ: 00=stereo, 01=joint stereo, 10=dual channel, 11=mono 2 Sự mở rộng chế độ: dải tần thấp nhất cho âm thanh dạng stereo về cường độ 1 Bản quyền: 1, nếu có 1 Nguồn gốc: 1, nếu đây là bản gốc 2 Nhấn mạnh Các syncword giả có thể gây khó khăn cho bộ giải mã trong việc đồng bộ lại một cách đáng tin cậy. Mặc dù chuẩn này đảm bảo rằng syncword giả sẽ không xuất hiện trong một dòng âm thích hợp, chúng có thể xuất hiện nếu dữ liệu mã hoá bị các lỗi gây hư hại. Nếu bộ giải mã biết thông tin phụ về dòng bit vào (ví dụ như nó có thể đã biết để trông chờ một dòng bit MPEG-1 Layer 1), nó có thể sử dụng các bits header phụ này như một syncword mở rộng. Chuẩn này cũng cung cấp một dạng mã hoá vòng CRC để được lưu trữ theo sau header. CRC cung cấp một dạng kiểm tra lỗi cho header và phần lớn các dữ liệu âm thanh nhạy cảm đã được mã hoá. Nếu quá trình kiểm tra CRC bị trượt, thì bộ giải mã có thể bỏ qua khung này (làm trầm đầu vào, hay tạo bản sao của khung trước đó để che dữ liệu đã mất), đồng bộ lại, và tiếp tục với khung thích hợp tiếp theo. Các mã hoá về tần số lấy mẫu của MPEG : MPEG - 1 MPEG - 2 Mã hoá Tần số lấy mẫu Tần số lấy mẫu 00 44,100 22,050 01 48,000 24,000 10 32,000 16,000 11 Reserved Reserved Frame header chỉ ra tần số lấy mẫu của dữ liệu âm thanh không bị nén (samples/giây) và tần số của dữ liệu đã nén (bits/giây). Các giá trị này được lưu trữ ở phần header của mỗi khung. Mặc dù nó không đồng nhất cho các bộ mã hoá trong việc thay đổi tần số lấy mẫu giữa các khung, nhưng nó khá hợp lý trong việc thay đổi tốc độ bit (bit rate) giữa các khung. Bằng cách thay đổi tốc độ bit giữa các khung, MPEG có thể sử dụng các tốc độ bit hiện thời (trong bảng mã hoá tốc độ bit sau). Trong một vài trường hợp, tốc độ bit "free" có thể được sử dụng mặc dù chúng có một vài giới hạn. Ngoài ra, để tránh làm sai các "syncword", không nên sử dụng giá trị toàn 1. Bảng các mã hoá tốc độ bit MPEG: Mã hoá Tốc độ bit MPEG-1 Tốc độ bit MPEG-2 Tầng 1 Tầng 2 Tầng 3 Tầng 1 Tầng 2 Tầng 3 0000 Free Free Free Free Free Free 0001 32 32 32 32 8 8 0010 64 48 40 48 16 16 0011 96 56 48 56 24 24 0100 128 64 56 64 32 32 0101 160 80 64 80 40 40 0110 192 96 80 96 48 48 0111 224 112 96 112 56 56 1000 256 128 112 128 64 64 1001 288 160 128 144 80 80 1010 320 192 160 160 96 96 1011 352 224 192 176 112 112 1100 384 256 224 192 128 128 1101 416 320 256 224 144 144 1110 448 384 320 256 160 160 1111 * * * * * * MPEG-1 đáp ứng cho 4 thiết lập về kênh truyền. Các chế độ âm thanh nổi thông thường và kênh truyền kép có thể lưu trữ 2 dòng dữ liệu nén một cách độc lập. Thiết lập về âm thanh nổi được kết nối sử dụng ít dữ liệu nhất bằng cách chia sẻ một vài thông tin giữa 2 kênh. Điều này tạo thuận lợi cho các chương trình đáp ứng dạng âm thanh nổi có sự khác nhau giữa các kênh trái và phải là rất nhỏ. Các khe và khung (Slots và Frames) Các khung của MPEG được tính bằng các khe (slots). Với tầng 1, một khe là 4 bytes; với tầng 2 và 3 là 1 byte. Sự định vị của header tiếp theo là rất đơn giản, nên dễ dàng xác định tốc độ bit của dữ liệu vào, tần số lấy mẫu của âm ra, cũng như số các mẫu xuất hiện trong một gói: 384 mẫu cho tầng 1; và 1,152 mẫu cho tầng 2 và 3. Từ các số liệu này ta có thể tính độ dài trung bình của khung. Ngoài ra, mọi thông tin về header được lặp lại trong mỗi khung. Phần lớn thông tin naỳ cho phép thay đổi với mỗi khung (mặc dù các thông số về tầng, chỉ số, và tần số lấy mẫu không nên thay đổi). Bởi vì khi một tốc độ bit được thay đổi giữa các header, thì rất có thể sẽ tạo ra một sai số lớn. Một cách khác, để có thể sử dụng một tốc độ bit không chuẩn ta nên sử dụng một mã hoá "free bit rate". Dĩ nhiên, trong trường hợp này ta không thể tính toán trực tiếp độ dài khung, do đó, nên quy định rằng nếu tốc độ bit là "free" thì độ dài khung không được thay đổi (ngoại trừ cho khe đã được chỉ rõ của quá trình chèn thêm). Điều này cho phép tính toán độ dài khung đầu tiên bằng cách tìm kiếm trước cho header tiếp theo và sau đó sử dụng lại giá trị đó cho các khung được giữ lại. 1.9. VBA , VBase ADPCM (.VBA) Đây là dạng Dialogic VOX với một đầu đọc nhỏ, cho phép các phân đoạn được đánh dấu. Nó sẽ chỉ ghi dưới dạng âm 16-bit đơn, và giống như các dạng ADPCM khác, nó nén theo kiểu 4-bits/mẫu (tỷ lệ 4:1). Khác với dạng Dialogic VOX, thông tin về tần số lấy mẫu được giữ lại với tệp. 1.10. VCE, NMS VCE (.VCE) Natural MicroSystems (NMS) ADPCM. Đây là dạng biến đổi G.721 ADPCM được sử dụng trong các

Các file đính kèm theo tài liệu này:

  • docXây dựng chương trình xử lý âm thanh số.doc