BW64 và ADM: tài liệu tham chiếu kỹ thuật cho giao nộp âm thanh nhập vai

Viết cho kỹ sư đang chuẩn bị bản master theo đối tượng (object-based) hoặc theo khung cảnh (scene-based), và cho nhạc sĩ vừa được giao một "file nhập vai" kèm yêu cầu phải qua được QC.

Câu trả lời ngắn

ADM (Audio Definition Model — mô hình định nghĩa âm thanh) là một chuẩn siêu dữ liệu mở, Khuyến nghị ITU-R BS.2076, mô tả mỗi track trong file là cái gì: một kênh loa cố định, một đối tượng chuyển động, hay một thành phần Ambisonics — và các track đó ghép lại thành chương trình ra sao. Nó được mang dưới dạng XML bên trong vùng chứa BW64 (Khuyến nghị ITU-R BS.2088), một mở rộng 64-bit của RIFF/WAVE nhằm vượt trần 4 GB của WAV cổ điển. Lý do giao nộp nhập vai liên tục trượt QC rất đơn giản: âm thanh và siêu dữ liệu là hai thứ tách rời phải khớp nhau tuyệt đối, và không có gì trong định dạng file bắt chúng phải khớp. Số kênh trong fmt lệch với bảng chna, một audioTrackUID không đối tượng nào tham chiếu tới, một block format có thời gian chạy ngược, một bed được mô tả trong XML nhưng chưa bao giờ được in ra đĩa — mọi lỗi đó đều câm lặng trước một trình biên tập dạng sóng và đều chí mạng với bộ kết xuất. Kiểm tra ADM là kiểm tra tính toàn vẹn tham chiếu, không phải là ngồi nghe.

1. Ba loại âm thanh, và vì sao phân biệt được chúng là quyết định hết

Trước khi bàn tới vùng chứa, phải bàn tới mô hình. Gần như mọi rắc rối giao nộp nhập vai đều bắt đầu từ chỗ không rõ một track thực ra thuộc loại nào trong ba loại sau.

Âm thanh theo kênh (channel-based). Mỗi track gán cho một vị trí loa cố định. Stereo là theo kênh. 5.1 cũng vậy, và cái "bed" 7.1.4 cũng vậy. Vị trí đã nướng chín vào chính danh tính của kênh: track 3 là loa center, và nó là loa center trên mọi hệ thống phát nó. ITU-R BS.2051 chuẩn hoá điều này cho các hệ thống âm thanh tiên tiến, mô tả bố trí loa theo số lượng ở ba lớp Trên + Giữa + Dưới: System A là 0+2+0 (stereo), System B là 0+5+0 (5.1), System D là 4+5+0, System J là 4+7+0, và System H là 9+10+3, tức cấu hình 22.2. Trong ADM, nội dung theo kênh dùng typeDefinition DirectSpeakers, typeLabel 0001.

Âm thanh theo đối tượng (object-based). Mang một tín hiệu mono (hoặc một pack đa kênh) cộng với siêu dữ liệu vị trí biến thiên theo thời gian. Bộ kết xuất mới là bên quyết định loa thật nào sẽ tái tạo nó và tái tạo thế nào, dựa trên bố trí loa thực có trong phòng. Không có gì trong track giả định trước một cái loa. Đây là typeDefinition Objects, typeLabel 0003.

Âm thanh theo khung cảnh (scene-based), trên thực tế là Ambisonics bậc cao (HOA), mã hoá toàn bộ trường âm thành một tập thành phần hàm điều hoà cầu. Không thành phần nào tự nó ứng với một hướng; hướng chỉ xuất hiện từ tổ hợp tuyến tính. Đây là typeDefinition HOA, typeLabel 0004. ADM còn định nghĩa Matrix (0002) cho tín hiệu ma trận hoá như Mid-Side hay Lt/Rt, và Binaural (0005) cho cặp đã sẵn sàng cho tai nghe.

Âm thanh theo kênh nói cho file biết loa nằm ở đâu; âm thanh theo đối tượng từ chối đoán; âm thanh theo khung cảnh mô tả trường âm chứ không mô tả nguồn.

Đây không phải phân loại cho vui. Một bản giao theo kênh tự mô tả đủ để sống sót dưới dạng WAV trần: xếp đúng thứ tự kênh là nó phát được. Một bản giao theo đối tượng hoặc theo khung cảnh thì vô nghĩa nếu thiếu siêu dữ liệu: phần audio chỉ là một đống stream mono không phân biệt, và ADM là thứ duy nhất nói khác đi. Chính sự bất đối xứng đó là toàn bộ lý do BW64 và ADM tồn tại, và là toàn bộ lý do QC nhập vai khó hơn QC stereo.

2. Nhã nhạc cung đình Huế: trường hợp "đối tượng cộng bed" có bố cục được quy định sẵn

Nếu cần một ví dụ Việt Nam để giải thích vì sao mô hình lai bed cộng đối tượng là mô hình đúng, thì nhã nhạc cung đình Huế là ví dụ sạch nhất.

Nhã nhạc là nhạc nghi lễ cung đình. Hai đặc điểm của nó rơi thẳng vào ADM. Thứ nhất, biên chế dàn nhạc và cách bố trí nhạc công không tuỳ hứng: nó được qui định theo lễ, theo ban (đại nhạc với kèn và trống ở một bên, tiểu nhạc với đàn dây và sáo ở bên kia), và vị trí ngồi là một phần của quy cách chứ không phải lựa chọn của người thu. Thứ hai, nhã nhạc được diễn trong không gian kiến trúc thật — một sân điện, một sân đền, một mặt bằng có tường bao và mái — và âm học của không gian đó là một phần của bản nhạc, không phải hiệu ứng thêm vào sau.

Ánh xạ sang ADM gần như một-đối-một:

• Bed (DirectSpeakers, 0001) mang trường âm của chính không gian: hồi âm của sân, tiếng vọng từ tường, tiếng gió và tiếng người ở xa. Đây là thứ không có nguồn định vị được, và ép nó thành đối tượng là sai về bản chất.
• Các đối tượng (Objects, 0003) mang từng nhạc cụ ở vị trí quy định của nó: trống chiến, kèn bóp, đàn nhị, đàn tỳ bà, sáo. Vì bố cục đã được quy định trước, toạ độ azimuth/elevation của mỗi đối tượng không phải là quyết định thẩm mỹ tuỳ tiện của kỹ sư — nó là một dữ kiện có thể tra được, ghi được vào ghi chú giao nộp, và bảo vệ được trước người phản biện.

Điểm mấu chốt về mặt kỹ thuật: một dàn nhã nhạc có bố cục cố định vẫn không nên bị bẹp thành bed thuần tuý. Bed 7.1.4 đặt trống chiến vào loa nào? Không loa nào cả, vì trống chiến không nằm ở vị trí một cái loa. Nó nằm ở một góc phương vị cụ thể, ở một khoảng cách cụ thể, trên một mặt sân cụ thể. Bed buộc bạn phải làm tròn vị trí đó về lưới loa gần nhất, rồi bản làm tròn ấy đóng băng vĩnh viễn vào file. Đối tượng thì giữ nguyên toạ độ và để bộ kết xuất làm tròn tại thời điểm phát, theo đúng bố trí loa mà người nghe thực sự có.

Với một bản thu nhã nhạc điển hình — bed 7.1.4 (12 kênh) cộng 24 đối tượng nhạc cụ, tổng 36 track — hãy nhớ con số này lại, vì mục 7 sẽ dùng nó để cho thấy trần 4 GB bị phá trong bao lâu.

3. Ca trù: hai đối tượng, một phòng, và cái trống chầu nằm ở chỗ người nghe

Ở cực đối lập với nhã nhạc là ca trù, và ca trù chứa một dữ kiện không gian mà stereo về nguyên tắc không biểu diễn nổi.

Biên chế tối giản: một đào nương vừa hát vừa gõ phách, một kép đàn chơi đàn đáy, và một quan viên cầm trống chầu. Hai nguồn đầu là hai đối tượng bình thường — hai vị trí trong phòng, gần nhau, ổn định. Nguồn thứ ba mới là chỗ thú vị.

Trống chầu không do người biểu diễn đánh. Nó do người nghe đánh, từ chính chỗ người nghe ngồi. Quan viên là khán giả; tiếng trống chầu là lời bình phẩm của khán giả chen vào bản nhạc, đánh theo khổ, khen chê ngay trong lúc diễn. Về mặt hình học âm thanh, đây là một nguồn nằm ở vị trí điểm nghe, không nằm trên sân khấu.

Stereo không có chỗ để đặt thứ đó. Trường stereo là một cung nằm giữa hai loa, ở phía trước người nghe; mọi thứ nó có thể mô tả đều nằm "đằng kia". Một nguồn phát ra từ đúng chỗ người nghe đang ngồi thì trong stereo chỉ còn hai lựa chọn: đẩy nó ra trước cùng với hai nhạc công (sai), hoặc trải nó thành mono giữa (cũng sai, và làm nó to lên bất thường). Cả hai đều biến quan hệ nghi thức giữa quan viên và chiếu hát thành một thứ khác hẳn.

Âm thanh theo đối tượng thì làm được, và làm bằng đúng cơ chế đã có sẵn. Trong audioBlockFormat của đối tượng trống chầu, bạn đặt vị trí ở gần gốc toạ độ nghe, đặt distance rất nhỏ, và tăng width/height/depth (các tham số kích thước đối tượng trong ADM) để bộ kết xuất trải nó rộng thay vì ghim nó vào một loa đơn lẻ. Kết quả trên hệ thống 4+5+0 là tiếng trống bao quanh người nghe thay vì đến từ trước mặt — tức là đúng thứ đã xảy ra trong phòng.

Ca trù là ví dụ hiếm hoi mà giá trị của âm thanh theo đối tượng không nằm ở "hoành tráng hơn", mà nằm ở chỗ nó là cách duy nhất để không nói dối về vị trí một nhạc cụ.

Về dung lượng, ca trù đi theo hướng ngược lại với nhã nhạc: ba track mono 48 kHz/24-bit chạy ở 3 × 3 × 48 000 = 432 000 byte mỗi giây. Trần 4 GB (4 294 967 296 byte) tương ứng 4 294 967 296 ÷ 432 000 ≈ 9 942 giây, tức khoảng 2 giờ 45 phút. Một canh hát ca trù không chạm tới đó. Nghĩa là: ca trù không cần BW64 vì lý do dung lượng — nó cần BW64 vì lý do siêu dữ liệu. Đây là chỗ nhiều người nhầm: BW64 không phải chỉ là "WAV cho file to", nó là vùng chứa duy nhất được chuẩn hoá để mang chna và axml.

4. Múa rối nước: hình học nguồn âm bị che khuất, có thật

Múa rối nước cho một bài toán mà rất ít thể loại nào trên thế giới cho sẵn: nguồn âm nằm ở nơi khán giả không nhìn thấy được, và điều đó là cố ý.

Sân khấu là mặt nước. Con rối chuyển động trên mặt nước, phía trước. Nghệ nhân điều khiển đứng dưới nước, sau tấm mành của thuỷ đình. Dàn nhạc và người hát cũng ở sau mành. Nghĩa là: hình ảnh ở phía trước, âm thanh phát ra từ phía sau một vật cản, và khán giả không thấy được nguồn.

Trong ADM, đây là ba nhóm đối tượng khác nhau về bản chất chứ không chỉ khác về vị trí:

1. Đối tượng ở sau mành — trống, mõ, sáo, nhị, giọng hát, tiếng gọi của nghệ nhân. Vị trí thật của chúng là sau và hơi cao hơn mặt nước. Chúng bị lọc bởi tấm mành và bởi khoảng nước ở giữa; đặc trưng phổ của chúng đã bị chính hình học đó thay đổi trước khi tới micro.
2. Đối tượng trên mặt nước — tiếng rối chạm nước, tiếng nước bắn, tiếng pháo. Những cái này ở phía trước, thấp, gần mặt phẳng ngang hoặc thấp hơn.
3. Bed — hồi âm của thuỷ đình và của mặt nước, cộng phản ứng khán giả.

Sai lầm điển hình khi làm bản nhập vai cho múa rối nước là kéo dàn nhạc ra trước cho "khớp với hình". Nhưng nó không khớp với hình: trong buổi diễn thật, âm thanh không đến từ chỗ con rối. Sự tách rời giữa cái được thấy và cái được nghe chính là hiệu quả sân khấu. Nếu bản kết xuất đặt tiếng hát vào cùng chỗ với con rối, nó đã phá đúng thứ mà thể loại này xây dựng nên. Ghi chú giao nộp cho một bản như vậy nên nói rõ điều đó, vì người QC ở nơi khác gần như chắc chắn sẽ coi việc "âm thanh không ở phía trước" là một lỗi cần sửa.

Về dung lượng: 16 track ở 48 kHz/32-bit float là 16 × 4 × 48 000 = 3 072 000 byte/giây; 4 294 967 296 ÷ 3 072 000 ≈ 1 398 giây, tức 23 phút 18 giây. Một chương trình rối nước đầy đủ vượt qua mốc đó dễ dàng.

5. Chèo, hát bội và sân đình: khán giả ở nhiều phía

Chèo và hát bội truyền thống không diễn trong một khán phòng có hướng nhìn duy nhất. Chúng diễn ở sân đình, ở sân chùa, ở khoảng đất trống giữa làng, với khán giả ngồi và đứng ở ba, bốn phía. Diễn viên xoay người trong lúc hát; dàn nhạc (trống đế, trống cơm, nhị, sáo, thanh la) ngồi ở mép chiếu, thường lệch một bên chứ không ở giữa.

Điều này đặt ra một câu hỏi mà stereo không bao giờ phải trả lời: người nghe của bản thu là ai, đứng ở đâu?

Trong ADM bạn buộc phải chọn, và chọn một cách tường minh. Có hai lời giải hợp lệ và chúng cho ra hai file khác nhau:

• Điểm nghe cố định trong đám đông. Bạn chọn một vị trí khán giả cụ thể và dựng toàn bộ đồ hình đối tượng quanh vị trí đó. Diễn viên khi xoay lưng sẽ nghe khác đi — và bạn mô tả điều đó bằng chuỗi audioBlockFormat thay đổi vị trí và gain theo thời gian, chứ không bằng cách tự động hoá pan cho "hay tai".
• Điểm nghe trung tâm, khán giả bao quanh. Bạn đặt điểm nghe ở giữa chiếu diễn. Lúc này khán giả trở thành một phần của bed bao quanh, còn diễn viên và dàn nhạc là đối tượng. Đây là bản dựng "đứng trong buổi diễn" chứ không phải "ngồi xem buổi diễn".

Cả hai đều đúng. Cái sai là không quyết định, rồi trộn lẫn hai logic trong cùng một file — điều xảy ra rất thường xuyên khi một bản dựng được sửa nhiều lần bởi nhiều người.

Bối cảnh rước và hội đình còn đẩy xa hơn: trống cái, trống bản và kèn di chuyển xuyên qua đám đông. Đây là trường hợp mà đối tượng chuyển động thực sự là mô tả đúng chứ không phải hiệu ứng — một chuỗi audioBlockFormat với rtime và duration liền mạch, azimuth quét qua, distance giảm rồi tăng. Và đây cũng là chỗ dễ tạo ra lỗi thời gian nhất, vì tự động hoá dài thì dễ có khe hở hoặc chồng lấn giữa các block.

6. BW64: nó là gì và chính xác vì sao nó tồn tại

WAV cổ điển là file RIFF. RIFF, có từ 1991, đặt trước mỗi chunk một trường kích thước 32-bit. Ba mươi hai bit địa chỉ hoá được 4 294 967 296 byte — 4 GB — và đó là trần cứng cho cả file lẫn cho chunk data bên trong.

Với stereo 48 kHz/24-bit, tốc độ dữ liệu là 2 × 3 × 48 000 = 288 000 byte/giây, nên 4 GB tương đương 4 294 967 296 ÷ 288 000 ≈ 14 913 giây, tức khoảng 4 giờ 8 phút: không liên quan gì tới thực tế.

Với bản nhã nhạc 36 track ở 96 kHz/24-bit ở mục 2, tốc độ là 36 × 3 × 96 000 = 10 368 000 byte/giây. Trần 4 GB rơi vào 4 294 967 296 ÷ 10 368 000 ≈ 414,25 giây — 6 phút 54 giây. Một bài nhã nhạc dài hơn thế là chuyện bình thường; một phiên thu liền mạch thì luôn dài hơn thế.

Với một master 128 track ở 96 kHz/24-bit, tốc độ là 36 864 000 byte/giây và 4 GB là 116,5 giây — chưa tới hai phút.

Một trình ghi WAV chạm trần sẽ cho ra hoặc một file bị cắt cụt, hoặc một file mà các trường kích thước khai báo đã âm thầm quấn vòng.

EBU xử lý việc này trước bằng RF64 (EBU Tech 3306). ITU sau đó đưa công trình ấy thành Khuyến nghị ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — tức BW64. BS.2088 nói rõ cơ chế: "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", và các trường 32-bit cũ trở thành cờ thoát — "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

Toàn bộ mẹo chỉ có thế, và đáng nói thẳng:

BW64 không nới rộng các trường kích thước của RIFF; nó nhét 0xFFFFFFFF vào đó như một giá trị canh, rồi đặt kích thước 64-bit thật vào chunk ds64 — chunk bắt buộc phải nằm đầu file.

Nên hiểu BW64 là thế hệ thứ ba của một dòng dõi duy nhất. RIFF/WAVE cho vùng chứa chia chunk. Broadcast Wave (BWF, EBU Tech 3285) thêm chunk bext — originator, tham chiếu timecode, coding history — biến WAV thành định dạng trao đổi phát sóng. BW64 giữ toàn bộ những thứ đó, thêm địa chỉ hoá 64-bit, và thêm các chunk mang ADM. Một file BW64 dưới 4 GB tương thích từng byte với trình đọc WAV ở mọi khía cạnh trừ bốn ký tự chữ ký file; nhiều công cụ chấp nhận nó, và một số thì nhất định không.

7. Bố cục chunk, tính đến từng byte

Theo BS.2088, một file BW64 được kỳ vọng chứa ít nhất <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (với <bxml-ck> và <sxml-ck> là các phương án mang siêu dữ liệu thay thế) và <wave-data>.

ds64 — bảng kích thước 64-bit

Phải là chunk đầu tiên sau chữ ký BW64, vì trình đọc phải biết kích thước thật trước khi có thể đi qua bất cứ thứ gì khác. Các trường của nó là các nửa 32-bit của những đại lượng 64-bit:

table[] quan trọng hơn vẻ ngoài của nó. Một chunk axml mô tả hàng nghìn đối tượng với tự động hoá chính xác tới mẫu hoàn toàn có thể tiệm cận hoặc vượt 4 GB; bảng này là cách duy nhất để một chunk không phải data khai báo kích thước 64-bit.

fmt — mô tả bản thể tín hiệu

Chunk format chuẩn của WAVE: định dạng mẫu, tần số lấy mẫu, số kênh, số bit mỗi mẫu, block align. Đây là phát biểu duy nhất có thẩm quyền về việc thực sự có bao nhiêu kênh xen kẽ trong data. Mọi thứ phía sau chỉ là siêu dữ liệu về các kênh đó, và siêu dữ liệu thì có thể nói dối.

chna — bảng cấp phát kênh, và số học 40 byte

chna là cầu nối giữa track vật lý và ADM. Nó mở đầu bằng:

• ckID — 4 byte, 'chna'
• ckSize — 4 byte
• numTracks — 2 byte, số track trong file
• numUIDs — 2 byte, số mục audioTrackUID theo sau

Rồi tới một mảng phẳng các mục audioID có bề rộng cố định. Mỗi mục dài đúng 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Con số này kiểm chứng được ngay trên chuỗi ví dụ: ATU_00000001 đúng 12 ký tự, AT_00031001_01 đúng 14 ký tự, AP_00031001 đúng 11 ký tự.

Từ đó suy ra vài phép tính tiện dùng khi đọc file bằng tay. Bản ca trù ba đối tượng ở mục 3 có numTracks = 3 và, nếu mỗi track giữ nguyên định nghĩa suốt file, numUIDs = 3 — phần thân của chna là 3 × 40 = 120 byte, và cả chunk là 8 (header) + 4 (numTracks + numUIDs) + 120 = 132 byte. Bản nhã nhạc 36 track cho 36 × 40 = 1 440 byte thân và 1 452 byte cả chunk. Nếu ckSize bạn đọc được không bằng 4 + 40 × numUIDs, file đã hỏng và không cần đọc tiếp.

Các bề rộng trường không phải khuyến nghị; chúng là ASCII bề rộng cố định, và một trình ghi phát ra UID 13 ký tự đã tạo ra một bảng hỏng chứ không phải một bảng hơi lạ.

Cũng cần nhớ quy ước ID: giá trị từ 0x0FFF trở xuống trỏ tới common definitions của ADM — các channel format và pack format chuẩn đã định nghĩa sẵn — còn từ 0x1000 trở lên là định nghĩa tuỳ biến và bắt buộc phải có mặt trong chunk axml. AP_00010003 là 5.1 theo common definition và không cần XML; AP_00031001 là một pack đối tượng tuỳ biến và cần XML, nếu không nó là tham chiếu treo.

audioTrackUID là số hiệu mà file cấp cho danh tính của một track vật lý, và nó tồn tại chính là để một track có quyền đổi nội dung mà nó mang ở giữa chừng chương trình.

Đó là lý do numUIDs có thể lớn hơn numTracks. Hướng dẫn của EBU nói rõ rằng khi "the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition." Một trackIndex vì thế có thể xuất hiện trong nhiều mục. Trường hợp này rất thực tế với một chương trình rối nước ghép nhiều tích: track 9 mang tiếng nhị ở tích một và tiếng sáo ở tích hai. Công cụ QC nào giả định mỗi track chỉ có một UID sẽ báo lỗi một file hoàn toàn đúng.

axml — chính là ADM

Một tài liệu XML, UTF-8, chứa cây <audioFormatExtended>. Đây là ADM. Nó là văn bản, đọc được, và gần như toàn bộ những hỏng hóc đáng quan tâm đều nằm trong đó.

data — PCM xen kẽ

Mẫu xen kẽ thuần tuý, y hệt WAV. Không có gì trong data biết gì về đối tượng.

Thứ tự. ds64 luôn đầu tiên. fmt trước data. axml hoàn toàn có quyền nằm sau data, và thường là như vậy, vì — như BS.2088 nhận xét — trong lúc ghi "the XML metadata will likely be of an unknown length." Một file có axml ở đuôi không hề dị dạng; nhưng một trình đọc chỉ quét một megabyte đầu sẽ báo là không có ADM nào cả. Riêng dữ kiện này giải thích một tỷ lệ đáng ngạc nhiên các báo cáo kiểu "file của tôi không có siêu dữ liệu".

8. Dấu tiếng Việt: hợp lệ trong axml, tuyệt đối không được vào chna

Đây là điểm mà một kỹ sư Việt Nam gặp và một kỹ sư viết tiếng Anh không bao giờ gặp, và nó phải được nói bằng con số.

Trong axml, dấu tiếng Việt hoàn toàn hợp lệ. Chunk axml mang XML mã hoá UTF-8, và các thuộc tính audioProgrammeName, audioContentName, audioObjectName, audioChannelFormatName là trường văn bản tự do. audioObjectName="Đàn đáy" là hợp lệ. audioProgrammeName="Nhã nhạc cung đình Huế" là hợp lệ.

Trong chna, dấu tiếng Việt là lỗi cấu trúc. Các trường UID, trackRef, packRef là ASCII bề rộng cố định, đo bằng byte, không phải bằng ký tự. Đây là chỗ tiếng Việt phá vỡ giả định mà người viết trình ghi thường có, vì trong tiếng Việt một ký tự thường không bằng một byte.

Số học cụ thể, kiểm chứng được bằng bất kỳ thư viện Unicode nào:

• ế (U+1EBF, LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE) ở dạng dựng sẵn NFC là 1 ký tự, 3 byte UTF-8: E1 BA BF.
• Cùng ký tự đó ở dạng phân rã NFD là e (U+0065) + dấu mũ tổ hợp (U+0302) + dấu sắc tổ hợp (U+0301) = 3 ký tự, 5 byte (1 + 2 + 2).
• ã là 2 byte ở NFC, 3 byte ở NFD. à, á, ì cũng vậy. ạ là 3 byte ở NFC và 3 byte ở NFD. đ và Đ là 2 byte ở cả hai dạng (chúng không có phân rã chuẩn tắc).

Ghép lại thành chuỗi thật:

Giờ đặt điều đó vào trường 12 byte của UID. Giả sử một trình ghi tự chế cố sinh UID "có nghĩa" là ATU_Nhãnhạc. Đếm ký tự thì đó là 11 — nghe như vừa khít trong 12. Nhưng đếm byte: ATU_ là 4 byte ASCII, N h là 2, ã là 2, n h là 2, ạ là 3, c là 1 → 14 byte. Chuỗi tràn trường 12 byte đúng 2 byte, và hai byte đó không biến mất: chúng đè lên hai byte đầu của trường trackRef ngay sau nó. Kết quả là mọi mục chna từ đó trở đi lệch khung, packRef đọc ra rác, và trình phân tích hoặc báo file hỏng hoặc — tệ hơn — đọc ra một pack ID hợp lệ nhưng sai. Nếu chuỗi ấy được chuẩn hoá về NFD trước khi ghi, nó thành 15 byte và tràn 3 byte.

Quy tắc rút ra, ngắn gọn và không có ngoại lệ:

1. ID trong chna chỉ dùng ASCII và chỉ theo đúng khuôn ATU_, AT_, AP_ cộng chữ số hex. Tên có nghĩa thuộc về axml, không thuộc về chna.
2. Chuẩn hoá mọi trường tên trong axml về NFC trước khi ghi, và ghi điều đó vào tài liệu giao nộp. NFC ngắn hơn, và quan trọng hơn: nếu một phần chuỗi ở NFC còn phần khác ở NFD, hai chuỗi trông giống hệt nhau trên màn hình sẽ không so sánh bằng nhau, và mọi tra cứu theo tên sẽ trượt.
3. Không dùng tên tiếng Việt có dấu làm khoá đối chiếu giữa các hệ thống. Khoá là ID; tên chỉ để người đọc.
4. Kiểm tra rằng khai báo mã hoá của XML là UTF-8 và file thực sự là UTF-8. Một chunk axml bị ghi bằng CP1258 hoặc Latin-1 sẽ khiến ế thành ký tự thay thế hoặc khiến toàn bộ tài liệu không phân tích được.

Một công cụ soi BW64/ADM miễn phí chạy trên trình duyệt tại mazufa.com phân tích cả vùng chứa lẫn siêu dữ liệu ngay trên máy của bạn và không tải gì lên, nên dùng được với vật liệu mà theo hợp đồng không được rời khỏi phòng thu.

9. Mô hình đối tượng ADM

ITU-R BS.2076 chia mô hình làm hai nửa. Nửa format "describes the technical nature of the audio so it can be decoded or rendered correctly" và có thể được soạn trước khi có bất kỳ âm thanh nào. Nửa content mô tả "the language of dialogue, the loudness, etc." và chỉ hoàn tất được khi đã có tín hiệu. Biết một phần tử thuộc nửa nào sẽ cho bạn biết công đoạn sản xuất nào đã sinh ra lỗi.

Cây phân cấp, từ trên xuống:

• audioProgramme — một bản trình bày hoàn chỉnh để giao. Tham chiếu một hoặc nhiều audioContent.
• audioContent — một thành phần có nghĩa biên tập: stem lời hát, stem nhạc cụ, một phiên bản ngôn ngữ. Tham chiếu một hoặc nhiều audioObject.
• audioObject — chỗ nối giữa ý đồ biên tập và định dạng kỹ thuật. Mang thời điểm bắt đầu và thời lượng, tham chiếu không hoặc nhiều audioPackFormat, không hoặc nhiều audioObject lồng nhau, và không hoặc nhiều audioTrackUID. Đây là nơi nội dung gặp bản thể tín hiệu.
• audioPackFormat — nhóm kênh thuộc về nhau: một bed 7.1.4, một cặp stereo, một tập HOA của một bậc nhất định. Tham chiếu các audioChannelFormat và có thể lồng pack khác.
• audioChannelFormat — hành vi của một kênh theo thời gian. Chứa một hoặc nhiều audioBlockFormat.
• audioBlockFormat — đơn vị nguyên tử. Với Objects: vị trí (azimuth/elevation/distance hoặc Descartes X/Y/Z), gain, kích thước, độ khuếch tán, cộng rtime và duration. Một đối tượng tĩnh là một block; một đối tượng chuyển động là một chuỗi block.
• audioTrackUID — lá, và là phần tử duy nhất ứng với một track vật lý. Mang tuỳ chọn thuộc tính sampleRate, bitDepth, và tham chiếu một audioTrackFormat cùng một audioPackFormat.

audioStreamFormat và audioTrackFormat nằm giữa channel format và track UID, mô tả mã hoá luồng. BS.2076-3 lưu ý rằng với PCM chúng gần như thừa — "the audioStreamFormat and the audioTrackFormat should be omitted" — nhưng trình đọc "should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" chúng. Cả hai hình dạng đều hợp lệ. Trình kiểm tra nào khăng khăng một kiểu là đang sai với kiểu kia.

ADM là một đồ thị các tham chiếu, không phải một tài liệu lồng nhau, và mọi hỏng hóc giao nộp nghiêm trọng đều là một cạnh đứt trong đồ thị đó.

Chuyện gì thực sự xảy ra khi một tham chiếu bị treo. Không có một hành vi duy nhất — và đó chính là vấn đề. Một bộ kết xuất gặp audioPackFormatIDRef trỏ tới pack không có trong XML có thể huỷ việc phân tích và từ chối file; có thể bỏ qua đối tượng đó và kết xuất phần còn lại, cho ra một bản trộn lặng lẽ thiếu một stem; hoặc có thể lùi về common definitions, thấy một ID nằm trong dải tuỳ biến 0x1000+ không khớp gì, và thay bằng im lặng. Cả ba đều là "file mở được". Chỉ một trong ba bị phát hiện khi ngồi nghe, và chỉ khi bạn tình cờ biết lẽ ra phải có gì ở đó. Đây là lý do QC ADM buộc phải tự động hoá: tai người không nghe được một sự vắng mặt mà nó chưa từng được báo trước.

10. Kết xuất: BS.2127 đưa ADM về các bố trí BS.2051

Một file ADM không tự phát ra tiếng. Nó phải được kết xuất về một bố trí loa cụ thể, và ITU-R BS.2127 định nghĩa bộ kết xuất ADM tham chiếu cho các hệ thống âm thanh tiên tiến của BS.2051. Bản triển khai nguồn mở tương ứng, EBU ADM Renderer (EBU Tech 3388), là cách thực tế để có một kết quả tái lập được.

Hệ quả với công việc hằng ngày:

• "Bản mix nhập vai" không phải một tín hiệu. Nó là một mô tả cộng với một bộ kết xuất cộng một bố trí. Đổi bố trí đích thì đổi tín hiệu ra.
• Bản nhã nhạc ở mục 2 kết xuất về System D (4+5+0) và về System J (4+7+0) sẽ không giống nhau, và đó không phải lỗi. Với System H (9+10+3), cùng một file cho một hình ảnh không gian chi tiết hơn hẳn — chính vì các đối tượng vẫn giữ toạ độ thật thay vì bị làm tròn từ trước.
• Điểm nghe của quan viên trong ví dụ ca trù ở mục 3 phụ thuộc mạnh vào việc bố trí đích có lớp loa trên hay không và có loa sau đủ gần hay không. Trên System A (0+2+0, stereo), bộ kết xuất buộc phải gập nó về phía trước — và đó chính là giới hạn đã nói ở mục 3, giờ được phát biểu bằng ngôn ngữ chuẩn.

Vì thế, mọi phát biểu về một bản nhập vai đều phải kèm ba thứ: bố trí nào, bộ kết xuất nào, phiên bản nào. Một ghi chú giao nộp chỉ ghi "immersive mix" là chưa nói gì cả.

11. Độ lớn nội dung nhập vai theo BS.1770-5

Ở đây cần tách rạch ròi giữa cái được công bố và cái được lưu truyền.

BS.1770 quy định gì. BS.1770 định nghĩa K-weighting: một bộ lọc high-shelf ("head" filter, mô hình một quả cầu cứng) nối tiếp một bộ high-pass RLB. Độ lợi của đường cong tại 1 kHz là +0,698 dB (tuyến tính 1,0836). Phép đo dùng block gating 400 ms chồng lấn 75 %, một cổng tuyệt đối loại bỏ các block dưới −70 LKFS, và một cổng tương đối tính từ trung bình của các block đã sống sót qua cổng tuyệt đối, rồi dịch đi −10 LU. Cổng tương đối tính từ các block sống sót, không phải từ trung bình chưa gating — đây là chỗ các bản triển khai làm sai đủ thường xuyên để đáng nhắc lại.

Trọng số kênh trong thuật toán lõi là 1,0 (0 dB) cho L, R, C và 1,41 (≈ +1,5 dB) cho Ls, Rs, còn LFE bị loại khỏi phép đo. Thuật toán nền được định phạm vi "from one to five channels". BS.1770-5 (11/2023) là phiên bản đang có hiệu lực; BS.1770-4 (10/2015) đã bị thay thế, dù đó vẫn là phiên bản mà phần lớn máy đo đang triển khai trích dẫn. BS.1770 có sáu phiên bản: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015), -5 (11/2023). BS.1770-5 mở rộng ra ngoài phạm vi năm kênh trong các phụ lục, phủ các hệ thống tiên tiến của BS.2051 — loa đặt tuỳ ý và kênh độ cao — cùng âm thanh theo đối tượng, thứ bắt buộc phải được kết xuất trước khi đo được.

Độ lớn nhập vai không phải thuộc tính của file; nó là thuộc tính của một bản kết xuất, và đổi bố trí đích là đổi con số.

Đó là khác biệt bản chất so với stereo. Một master stereo có một giá trị độ lớn. Một master theo đối tượng có bao nhiêu giá trị thì tuỳ số bố trí đích, và cách nêu con số một cách trung thực là nêu kèm bố trí đã đo và bộ kết xuất đã dùng.

Các tài liệu EBU liên quan. EBU Tech 3341 định nghĩa hành vi máy đo (momentary 400 ms, short-term 3 s). EBU Tech 3342 định nghĩa Loudness Range, dùng cổng tương đối −20 LU — không phải −10 LU; dùng −10 cho LRA là một lỗi triển khai phổ biến. EBU R 128 đặt mục tiêu chương trình phát sóng ở −23 LUFS; R 128 là thực hành chuẩn hoá cho phát sóng, không phải spec cho phát trực tuyến âm nhạc.

Cái gì được công bố cho âm nhạc. Với nhạc stereo theo kênh, Spotify công bố mục tiêu tích hợp −14 LUFS và trần true peak −1 dBTP, siết còn −2 dBTP với master to hơn −14 LUFS. AES TD1008 khuyến nghị −16 LUFS cho âm nhạc; con số −18 LUFS trong TD1008 áp dụng cho nội dung dẫn dắt bằng lời nói (tin tức, toạ đàm, kịch), và nêu −18 như mục tiêu cho âm nhạc là một sai lầm phổ biến và nghiêm trọng.

Cái gì không được công bố. Không dịch vụ phát nhạc trực tuyến nào công bố mục tiêu độ lớn tích hợp cho giao nộp nhập vai. Nhiều con số lưu truyền rộng trên diễn đàn và trong tài liệu đào tạo của nhà cung cấp; vài con số nghe hợp lý và một số có lẽ đúng. Không con số nào trong đó là một đặc tả được công bố, và tài liệu này sẽ không nhắc lại chúng như thể chúng là spec. Apple Music, YouTube Music, Amazon Music, TIDAL và Deezer cũng không công bố mục tiêu chuẩn hoá cho stereo — các con số thường được trích cho những dịch vụ này là được đưa tin rộng rãi nhưng không do dịch vụ công bố, và không bao giờ nên dùng chúng để tính ra một mức thay đổi gain.

Phát sóng và điện ảnh được ghi chép tốt hơn âm nhạc, đơn giản vì các đài phát công bố tài liệu. Nếu hôm nay bạn cần một con số độ lớn nhập vai bảo vệ được, hãy đo một bản kết xuất tuân thủ BS.2127 về một bố trí BS.2051 có tên gọi cụ thể, bằng một máy đo BS.1770-5, và ghi cả ba thứ vào ghi chú giao nộp.

Về các hệ thống độc quyền. Dolby Atmos là công nghệ độc quyền có cấp phép của Dolby Laboratories, và Sony 360 Reality Audio là hệ thống độc quyền xây trên MPEG-H. Yêu cầu giao nộp của chúng do chủ sở hữu đặt ra và thay đổi không theo lịch của ITU hay EBU. Không có gì trong tài liệu này là phát biểu về yêu cầu của các công ty đó, và không tuyên bố hay ngụ ý bất kỳ liên kết, chứng nhận hay xác nhận nào. Ở đâu bên cấp phép công bố yêu cầu, hãy đọc và trích chính tài liệu hiện hành của họ.

12. Vị trí trung thực: phòng thu Việt Nam gần như không có monitoring nhập vai

Cần nói thẳng, vì nó thay đổi bản chất lời khuyên trong tài liệu này.

Ở Việt Nam, số phòng thu có hệ thống nghe nhập vai được căn chỉnh — kể cả 4+5+0, chứ chưa nói tới 4+7+0 hay 9+10+3 — là rất nhỏ. Phần lớn công việc âm nhạc, kể cả công việc chất lượng cao, được làm trên monitor stereo trong phòng đã xử lý âm học một phần. Đó là dữ kiện, không phải lời chê.

Hệ quả rất cụ thể:

• Bạn có thể sẽ giao một file mà bạn chưa từng nghe ở dạng nó sẽ được phát. Nghe binaural qua tai nghe hữu ích để bắt lỗi thô (đối tượng nằm sai bán cầu, một stem hoàn toàn im lặng), nhưng nó không phải là nghe trên hệ thống loa và không thay thế được.
• Vì vậy, giá trị bạn kiểm soát được nằm ở chỗ khác: giao nộp đúng, siêu dữ liệu đúng, và khả năng chứng minh một file đúng mà không cần nghe nó.
• Điều này khiến các phép kiểm tra cấu trúc ở mục 7, 9 và 13 quan trọng hơn nhiều so với ở một thị trường có phòng nghe sẵn. Chúng là thứ duy nhất cho bạn bằng chứng.
• Nó cũng khiến việc ghi chú giao nộp trở thành sản phẩm thật sự: bố trí đã đo, bộ kết xuất, phiên bản, chuẩn hoá Unicode của trường tên, checksum. Người ở đầu bên kia có phòng nghe; bạn có tài liệu. Tài liệu là thứ bắc cầu.
• Về mặt sáng tạo, hệ quả là nên nghiêng về mô tả trung thực vị trí thật thay vì dựng hiệu ứng không gian mà bạn không kiểm chứng được. Nhã nhạc, ca trù, rối nước đều có vị trí thật để mô tả. Mô tả đúng cái có thật là chiến lược an toàn nhất khi bạn không nghe được kết quả.

13. Các lỗi QC thường gặp và cách phát hiện từng lỗi

13.1 Lệch số kênh giữa fmt và chna. fmt.nChannels nói 16; chna.numTracks nói 14. File tự mâu thuẫn ngay từ hai chunk đầu. Thường do một lần bounce làm đổi số track sau khi siêu dữ liệu đã soạn xong, hoặc do một công cụ bỏ bớt track mà không ghi lại chna. Phát hiện: phân tích cả hai chunk và so hai số nguyên. Đây là phép kiểm rẻ nhất trong toàn bộ quy trình và bắt được một tỷ lệ lỗi đáng kinh ngạc. Đồng thời kiểm tra mọi trackIndex trong chna nằm trong khoảng 1 … fmt.nChannels.

13.2 UID mồ côi. Một UID có trong chna mà không audioObject nào tham chiếu, hoặc một audioTrackUIDRef trong XML không có mục chna tương ứng. Trường hợp đầu nghĩa là có audio mà không gì kết xuất nó; trường hợp sau nghĩa là siêu dữ liệu chờ một track không tồn tại. Phát hiện: dựng tập UID từ chna và tập UID từ axml, lấy hiệu đối xứng — phải rỗng. EBU Tech 3392 nêu rõ ý định: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

13.3 Block format thiếu thời gian hoặc thời gian không đơn điệu. BS.2076 không mập mờ: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 siết thêm thành quy tắc liền mạch — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — với block đầu tiên của một đối tượng bắt đầu ở 00:00:00.00000, không block nào ngắn hơn một mẫu, và tổng thời lượng khớp với audioObject cha. Phát hiện: với mỗi audioChannelFormat, duyệt các block theo thứ tự tài liệu và khẳng định rtime[n] + duration[n] == rtime[n+1]. Lỗi rơi vào ba dạng: khe hở (hành vi bộ kết xuất không xác định — có bộ giữ vị trí cuối, có bộ tắt tiếng), chồng lấn, và block sai thứ tự thời gian. Đám rước ở mục 5 là ứng viên số một cho lỗi này, vì nó là chuỗi block dài nhất trong file.

13.4 Sai tần số lấy mẫu hoặc độ sâu bit. audioTrackUID có thể mang thuộc tính sampleRate và bitDepth. Khi chúng mâu thuẫn với fmt , bạn có hai khẳng định về cùng một bản thể tín hiệu. Quan điểm của EBU Tech 3392 là chúng "Should be ignored if available from the audio essence" — nhưng không phải bộ kết xuất nào cũng theo, và một file ghi 48 000 ở chỗ này, 96 000 ở chỗ kia sẽ được các công cụ khác nhau hiểu khác nhau. Ngoài ra, hãy xác nhận tần số đúng như đặc tả giao nộp yêu cầu: đổi tần số lấy mẫu sau khi đã soạn ADM làm vô hiệu mọi rtime và duration biểu diễn theo mẫu.

13.5 Bản conform stereo hoặc binaural thiếu, hoặc lệch. Phần lớn giao nộp nhập vai yêu cầu một bản conform stereo (và thường cả binaural) đi kèm master nhập vai. Lỗi lặp lại không phải là thiếu — thiếu thì thấy ngay — mà là trôi: bản conform được kết xuất từ phiên bản cũ hơn, lệch vài frame, hoặc có start timecode khác. Một file stereo sớm 40 ms so với bản nhập vai mẹ sẽ qua được phép kiểm "có file" và trượt phép nghe đồng bộ. Phát hiện: so thời lượng tới từng mẫu, so start timecode từ bext, và tương quan chéo bản conform với một bản null render của master. Coi mọi conform không suy ra được từ master hiện hành là đáng ngờ, và kết xuất lại thay vì kiểm lại.

13.6 Siêu dữ liệu mô tả một bed không có trong file. XML khai một pack DirectSpeakers 7.1.4 — mười hai kênh — nhưng chỉ tập con 5.1 được in ra, hoặc các kênh độ cao bị tắt tiếng lúc bounce và in ra thành im lặng số. Đồ thị tham chiếu nguyên vẹn; phần âm thanh thì không. Phát hiện: kiểm tra cấu trúc không bắt được lỗi này. Cần phân tích bản thể tín hiệu: với mỗi kênh mà một pack DirectSpeakers khai báo, đo xem track có tín hiệu hay không. Im lặng số trên một kênh bed đã khai không tự động là lỗi — một bản mix hợp lệ có thể để trống kênh top-rear — nhưng luôn đáng để một con người quyết định.

Với bối cảnh Việt Nam, lỗi 13.6 là lỗi nguy hiểm nhất trong danh sách, chính vì lý do ở mục 12: nếu không có phòng nghe, bạn không phát hiện được bằng tai một bed thiếu bốn kênh độ cao.

Vùng chứa có thể hoàn toàn hợp lệ, XML hoàn toàn đúng cú pháp, mà bản giao vẫn sai; cách duy nhất để kiểm một kênh bed rỗng là nhìn vào các mẫu.

14. Danh sách kiểm tra giao nộp

Làm theo thứ tự. Kiểm tra cấu trúc trước — chúng nhanh và chúng vô hiệu hoá mọi thứ phía sau.

Vùng chứa

1. Bốn byte đầu là BW64. Nếu là RIFF, đó là WAV thường và không vượt được 4 GB.
2. ds64 là chunk đầu tiên sau chữ ký, và các kích thước 64-bit của nó khớp kích thước thật của file và của data trên đĩa.
3. Mọi chunk không phải data mà quá khổ đều có mục ChunkSize64 trong bảng ds64.
4. Định vị axml một cách tường minh, kể cả khi nó nằm sau data. Đừng kết luận "không có ADM" từ một lần quét cục bộ.

Bản thể tín hiệu

1. Tần số lấy mẫu và độ sâu bit trong fmt khớp chính xác đặc tả giao nộp. Không chuyển tần số sau khi soạn ADM.
2. fmt.nChannels bằng chna.numTracks.
3. Mọi trackIndex trong chna nằm trong khoảng hợp lệ và đếm từ 1.

Toàn vẹn chna

1. Mỗi mục đúng 40 byte, các trường bề rộng cố định được đệm đúng; ckSize bằng 4 + 40 × numUIDs.
2. Mọi packRef từ 0x1000 trở lên phân giải được về một định nghĩa tuỳ biến có trong axml.
3. Các trackIndex lặp lại là có chủ ý (một track đổi định nghĩa hợp lệ), không phải lỗi nhân bản.
4. Không có byte nào ngoài ASCII trong UID, trackRef, packRef. Kiểm bằng byte, không kiểm bằng ký tự.

Đồ thị ADM

1. Mọi audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef và audioTrackUIDRef đều phân giải được. Không cạnh treo.
2. Không có audioTrackUID mồ côi theo cả hai chiều.
3. Không có phần tử vòng hoặc tự tham chiếu.
4. typeLabel trên mỗi audioChannelFormat khớp audioPackFormat cha.
5. Mọi trường tên trong axml là UTF-8 hợp lệ và đã chuẩn hoá NFC nhất quán.

Thời gian

1. Channel format nhiều block mang cả rtime lẫn duration trên từng block.
2. Các block liền mạch và đơn điệu tăng; tổng thời lượng khớp audioObject cha.
3. Đối tượng bắt đầu ở 00:00:00.00000.

Nội dung

1. Mọi kênh của một bed đã khai chứa đúng thứ nó phải chứa; điều tra mọi im lặng số.
2. Số lượng đối tượng và cấu hình bed khớp đặc tả giao nộp.
3. bext start timecode đúng và nhất quán trên toàn bộ bộ file giao nộp.

Kết xuất và conform

1. Conform stereo và binaural được kết xuất lại từ master hiện hành, không mang từ bản cũ sang.
2. Thời lượng và start timecode khớp master tới từng mẫu.
3. Độ lớn được đo trên một bản kết xuất có tên, về một bố trí có tên, bằng một bộ kết xuất có tên — cả ba ghi vào ghi chú giao nộp.

Khả năng tái lập

1. Checksum mọi file giao nộp và giữ lại bản kê.
2. Lưu trữ phiên làm việc và bản ADM XML tách riêng khỏi file BW64; XML mà bạn diff được về sau đáng giá hơn nhiều so với một khối nhị phân chỉ có thể phân tích lại.

Một bản giao nhập vai không hoàn tất khi nó nghe ổn; nó hoàn tất khi một cái máy chưa từng nghe nó có thể chứng minh mọi tham chiếu của nó phân giải được.

15. Kết

BW64 và ADM là những chuẩn mở, đã công bố, đọc được tự do. Điều đó hiếm ở góc này của ngành và đáng tận dụng: bạn có thể tự đọc BS.2088 và BS.2076, tự phân tích một chunk chna bằng bốn mươi dòng mã, và kiểm chứng bộ xuất file của một nhà cung cấp thực sự đã ghi gì thay vì tin vào hộp thoại của nó.

Với nhạc Việt Nam, phần thưởng cụ thể hơn thế. Nhã nhạc có bố cục quy định sẵn; ca trù có một nhạc cụ nằm ở đúng chỗ người nghe; rối nước có nguồn âm sau tấm mành; chèo và hát bội có khán giả ở nhiều phía. Đó đều là những dữ kiện không gian có thật mà stereo buộc phải bỏ đi và mô hình theo đối tượng ghi lại được nguyên vẹn. Ngay cả khi bạn chưa nghe được kết quả trong một phòng đúng chuẩn, bạn vẫn có thể mô tả những dữ kiện đó một cách chính xác, và có thể chứng minh rằng file mình giao đã mô tả đúng.

Phát hành qua Mazufa là miễn phí — không phí tải lên, không phí thuê bao, không phí theo bản phát hành — với 5% khấu trừ trên tiền bản quyền nhận được, và mọi hồ sơ hoàn chỉnh đều được một con người xét duyệt.

Nguồn

Khuyến nghị ITU-R

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.2076-2 (10/2019), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (11/2023), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf
• Trang khuyến nghị ITU-R BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

Tài liệu kỹ thuật EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (và các phụ lục), Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/docs/tech/tech3388.pdf và https://tech.ebu.ch/publications/tech3388
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (máy đo), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — chunk CHNA — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 và ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• Tài liệu EBU ADM Renderer (EAR), phần BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• Bản triển khai tham chiếu libbw64 — https://github.com/ebu/libbw64
• Bản triển khai tham chiếu libadm — https://github.com/ebu/libadm

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

Tài liệu dịch vụ

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/

Unicode

• Unicode Standard Annex #15, Unicode Normalization Forms (NFC/NFD) — https://www.unicode.org/reports/tr15/
• Bảng mã Unicode, khối Latin Extended Additional (chứa U+1EA0–U+1EF9, các chữ cái tiếng Việt) — https://www.unicode.org/charts/PDF/U1E00.pdf

Rà soát lần cuối tháng 9 năm 2026. Các chuẩn đều được sửa đổi; hãy luôn kiểm tra các trang ITU và EBU ở trên để biết phiên bản hiện hành trước khi trích số hiệu điều khoản.