Vì sao một bản master immersive qua được trình biên tập sóng âm nhưng trượt QC

Một bản giao nộp immersive có thể mở ra trong một trình biên tập sóng âm, hiện lên mười hai hoặc mười sáu track trông rất khỏe mạnh, phát ra nghe hợp lý, và vẫn bị từ chối. Lý do nằm ở cấu trúc: trong một tệp BW64, phần âm thanh và phần metadata là hai thứ tách rời phải khớp nhau tuyệt đối, và không có gì trong định dạng ép chúng phải khớp. Một renderer thì giải các tham chiếu. Một trình biên tập thì vẽ các mẫu. Hai công việc khác nhau — và đó là lý do QC cho ADM là việc kiểm tra tính toàn vẹn của tham chiếu, không phải việc ngồi nghe. Dưới đây là những gì hai tiêu chuẩn nói, chỗ nào các tham chiếu đứt, và phép kiểm tra nào bắt được lỗi nào.

Ba loại âm thanh, và vì sao sự phân biệt này quyết định mọi thứ

Mọi rắc rối khi giao nộp bản immersive đều bắt đầu từ việc nhầm lẫn xem một track thuộc loại nào trong ba loại.

Âm thanh theo kênh gán mỗi track cho một vị trí loa cố định. Stereo là theo kênh, 5.1 cũng vậy, một bed 7.1.4 cũng vậy. Vị trí được nướng sẵ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 chính thức hóa điều này cho các hệ thống âm thanh tiên tiến, mô tả các bố trí bằng số lượng lớp Upper + Middle + Bottom — 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, System H là 9+10+3, tức cấu hình 22.2. Trong ADM đây là typeDefinition DirectSpeakers, typeLabel 0001.

Âm thanh theo đối tượng mang một tín hiệu mono (hoặc một pack đa kênh) cộng với metadata vị trí thay đổi theo thời gian. Renderer quyết định những loa thật nào sẽ tái tạo nó, dựa trên bố trí đang có trong phòng. Không có gì ở track đó giả định trước một cái loa. Đây là typeDefinition Objects, typeLabel 0003.

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

Sự phân biệt này không phải chuyện phân loại học. Một bản giao nộp theo kênh tự mô tả đủ để sống sót dưới dạng một tệp WAV trần — cứ đúng thứ tự kênh là nó phát được. Một bản giao nộp theo đối tượng hay theo trường âm thì vô nghĩa nếu thiếu metadata: phần âm thanh chỉ là một đống luồng mono không phân biệt được với nhau, và ADM là thứ duy nhất nói khác đi. Chính sự bất đối xứng đó là lý do BW64 và ADM tồn tại.

BW64 tồn tại vì một con số 32-bit

WAV cổ điển là một tệp 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 đánh địa chỉ được 4,294,967,296 byte — 4 GB — và đó là trần cứng cho cả toàn bộ tệp lẫn chunk data bên trong nó.

Với stereo ở 48 kHz / 24-bit, tốc độ dữ liệu là 288,000 byte mỗi giây, nên 4 GB là khoảng 4 giờ 8 phút. Không đáng bận tâm. Với một bản master theo đối tượng 128 track ở 96 kHz / 24-bit, tốc độ là 36,864,000 byte mỗi giây, và 4 GB là chưa tới hai phút — 116.5 giây.

Các bản master immersive vượt giới hạn đó như cơm bữa, và một bộ ghi WAV chạm trần sẽ cho ra hoặc một tệp bị cắt cụt, hoặc một tệp có các kích thước khai báo đã âm thầm quay vòng. EBU xử lý chuyện này trước tiên bằng RF64 (EBU Tech 3306); ITU đưa nó đi tiếp thành Khuyến nghị ITU-R BS.2088 — BW64.

Mẹo cờ hiệu: 0xFFFFFFFF và một chunk ds64

BS.2088 nói rất rõ về cơ chế. “The ID ‘BW64’ is used instead of ‘RIFF’ in the first four bytes of the file”, và các trường kích thước 32-bit nguyên bản 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ó vậy, và cần nói thẳng ra: BW64 không nới rộng các trường kích thước của RIFF. Nó nhét 0xFFFFFFFF vào đó làm cờ hiệu và đặt các kích thước 64-bit thật vào một chunk ds64 bắt buộc phải nằm đầu tiên trong tệp. Vậy nên một tệp BW64 dưới 4 GB tương thích ở mức byte với một bộ đọc WAV về mọi phương diện, trừ chữ ký bốn ký tự. Nhiều công cụ chấp nhận nó; một số thì nhất quyết không.

Các chunk, và cái mà mỗi mục đúng bằng 40 byte

Theo BS.2088, một tệp BW64 được trông đợi chứa ít nhất ds64, fmt , chna, axml (với bxml và sxml là các vật mang metadata thay thế) và phần dữ liệu sóng âm.

ds64 phải là chunk đầu tiên sau chữ ký, vì một bộ đọc buộc phải biết các kích thước thật trước khi có thể đi qua bất cứ thứ gì khác. Nó mang các nửa thấp/cao 32-bit cho kích thước toàn tệp và kích thước data, cộng với một bảng các mục ChunkSize64 cho bất kỳ chunk quá khổ nào khác — một chunk axml mô tả hàng nghìn đối tượng với automation chính xác đến từng mẫu bản thân nó cũng có thể tiệm cận hoặc vượt 4 GB.

fmt là chunk định dạng WAVE tiêu chuẩn — định dạng mẫu, tần số lấy mẫu, số kênh, số bit trên mẫu, block align. Đây là tuyên bố có thẩm quyền duy nhất về việc có bao nhiêu kênh xen kẽ trong data. Mọi thứ phía sau đều là metadata nói về các kênh đó, và metadata thì có thể nói dối.

chna là cây cầu giữa các track vật lý và ADM. Sau ckID, ckSize, một numTracks 2 byte và một numUIDs 2 byte, nó chứa một mảng phẳng gồm các mục audioID có bề rộng cố định, mỗi mục đúng 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Các bề rộng này không phải lời khuyên: chúng là ASCII bề rộng cố định, và một bộ ghi phát ra một UID 13 ký tự đã tạo ra một bảng hỏng, chứ không phải một bảng hơi khác thường.

Quy ước về ID cũng quan trọng. Các giá trị từ 0x0FFF trở xuống trỏ tới các định nghĩa chung của ADM — những định dạng kênh và pack chuẩn, đã được định sẵn — còn từ 0x1000 trở lên báo hiệu các định nghĩa tùy biến bắt buộc phải có mặt trong axml. AP_00010003 là 5.1 theo định nghĩa chung và không cần XML; AP_00031001 là một pack đối tượng tùy biến và cần XML, nếu không nó lơ lửng.

numUIDs cũng có thể lớn hơn numTracks một cách chính đáng: hướng dẫn của EBU ghi rằng ở chỗ “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”, nên một trackIndex có thể xuất hiện ở nhiều mục. Các công cụ QC mặc định mỗi track một UID sẽ báo lỗi cho những tệp hoàn toàn đúng.

axml là một tài liệu XML UTF-8 chứa cây <audioFormatExtended>. Đó chính là ADM, và gần như toàn bộ những lỗi thú vị đều sống ở đó. data là PCM xen kẽ thuần túy; không có gì trong đó biết bất cứ điều gì về đối tượng.

Về thứ tự: ds64 luôn đầu tiên; fmt trước data. Nhưng axml hoàn toàn có thể nằm sau data, và thường là vậy, bởi vì — như BS.2088 nhận xét — trong lúc thu “the XML metadata will likely be of an unknown length.” Một tệp có axml ở đuôi không phải là tệp hỏng, nhưng một bộ đọc chỉ quét megabyte đầu tiên sẽ báo rằng chẳng có ADM nào cả. Điều đó lý giải một tỷ lệ đáng ngạc nhiên các báo cáo kiểu “tệp của tôi không có metadata”.

ADM là một đồ thị, và các lỗi là những cạnh đứt

Phân cấp của ITU-R BS.2076 chạy audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, với audioTrackUID là lá và là phần tử duy nhất ứng với một track vật lý.

Đó 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 lỗi giao nộp nghiêm trọng đều là một cạnh đứt trong đó. Điều khiến một tham chiếu lơ lửng trở nên nguy hiểm là không có một hành vi duy nhất khi nó đứt. Một renderer đang giải một audioPackFormatIDRef gọi tên một pack không có trong XML có thể hủy việc phân tích cú pháp và từ chối tệp; có thể bỏ qua đối tượng đó và render mọi thứ còn lại, cho ra một bản mix âm thầm thiếu một stem; hoặc có thể quay về các định nghĩa chung, gặp một ID nằm trong dải tùy biến từ 0x1000 trở lên mà không khớp được, và thay bằng sự im lặng. Cả ba kết cục đều là “tệp đã mở được”. Chỉ một trong số đó bị bắt bằng cách ngồi nghe, và chỉ khi bạn biết lẽ ra ở đó phải có gì.

Bốn lỗi chiếm phần lớn các ca bị từ chối

Số track trong fmt không khớp với chna. fmt .nChannels nói 16; chna.numTracks nói 14. Tệp đã tự mâu thuẫn với chính nó ngay từ hai chunk đầu tiên — thường là một bản bounce đã đổi số track sau khi metadata được soạn, hoặc một công cụ bỏ bớt track mà không ghi lại chna. Việc phát hiện chỉ là đọc hai số nguyên rồi so sánh: phép kiểm tra rẻ nhất trong toàn bộ quy trình, và nó bắt được một tỷ lệ lỗi đến mức giật mình. Cùng lúc hãy xác minh rằng mọi trackIndex nằm trong khoảng 1 … fmt .nChannels.

Một audioTrackUID không được đối tượng nào tham chiếu. Một UID trong chna mà không audioObject nào tham chiếu nghĩa là có âm thanh tồn tại nhưng sẽ chẳng được render; trường hợp gương của nó, một audioTrackUIDRef trong XML mà không có mục chna tương ứng, nghĩa là metadata trông đợi một track không hề có ở đó. Hãy dựng tập UID từ chna và tập UID từ axml rồi lấy hiệu đối xứng; nó phải rỗng. EBU Tech 3392 nêu thẳng chủ ý: “If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.”

Thời gian khối chạy ngược. 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 tính liền mạch — “rtime + duration of an audioBlockFormat should match the rtime of the following block” — với khối đầu tiên của một đối tượng bắt đầu ở 00:00:00.00000, không khối nào ngắn hơn một mẫu, và tổng các duration bằng đúng audioObject cha. Hãy đi qua các khối theo thứ tự tài liệu và khẳng định rtime[n] + duration[n] == rtime[n+1]. Lỗi có ba hình dạng: khoảng trống, nơi hành vi của renderer không được định nghĩa và có bộ giữ nguyên vị trí cuối trong khi bộ khác tắt tiếng; chồng lấn, nơi các khối đánh nhau; và các khối sai thứ tự thời gian, tức automation nhảy ngược giữa chương trình.

Một bed được mô tả trong XML nhưng chưa bao giờ được ghi ra đĩa. XML khai báo một pack DirectSpeakers 7.1.4 — mười hai kênh — nhưng chỉ tập con 5.1 được ghi ra, hoặc các kênh chiều cao bị tắt tiếng lúc bounce và được ghi ra dưới dạng im lặng số. Đồ thị tham chiếu thì nguyên vẹn; phần âm thanh thì không. Các phép kiểm tra cấu trúc không bắt được chuyện này: bạn cần phân tích phần âm thanh thực, đo xem mọi kênh mà một pack DirectSpeakers tuyên bố có chứa tín hiệu hay không. Im lặng số trên một kênh bed đã khai báo không tự động là lỗi — một bản mix chính đáng vẫn có thể để trống một kênh trên-sau — nhưng nó luôn đáng để một con người quyết định.

Cái gì được công bố về độ lớn immersive, và cái gì không

Có một con số không sống sót được khi rời khỏi stereo, và cần nói vì sao.

BS.1770-5 (November 2023) là bản hiện hành; BS.1770-4 đã bị thay thế, dù phần lớn thiết bị đo đang triển khai vẫn viện dẫn nó. Thuật toán lõi của nó đặt trọng số 1.0 cho L, R và C, 1.41 cho Ls và Rs (khoảng +1.5 dB), loại trừ LFE, và có phạm vi “from one to five channels”. BS.1770-5 mở rộng ra ngoài phạm vi đó trong các phụ lục, bao trùm các hệ thống âm thanh tiên tiến của BS.2051 và âm thanh theo đối tượng — thứ phải được render trước khi có thể đo được. Vì vậy độ lớn immersive không phải là thuộc tính của tệp mà là của một bản render, và đổi bố trí đích thì đổi con số. Hãy đo một bản render tuân thủ BS.2127 tới một bố trí BS.2051 có tên gọi bằng một máy đo BS.1770-5 rồi ghi cả ba vào ghi chú giao nộp; BS.2127 định nghĩa renderer ADM tham chiếu, còn người anh em mã nguồn mở của nó là EBU ADM Renderer (EBU Tech 3388) là cách thực tế để có một con số tái lập được.

Không dịch vụ phát trực tuyến âm nhạc nào công bố mức độ lớn tích hợp mục tiêu cho việc giao nộp immersive. Các con số lưu hành trên diễn đàn và trong tài liệu đào tạo của nhà cung cấp; không con số nào là một đặc tả được công bố, và bài này sẽ không nhắc lại chúng như thể chúng là vậy. Cái được công bố là dành cho stereo theo kênh — mức tích hợp mục tiêu −14 LUFS của Spotify với trần đỉnh thực −1 dBTP, siết xuống −2 dBTP khi to hơn −14 LUFS, và mức −16 LUFS cho âm nhạc của AES TD1008 (con số −18 LUFS của nó áp dụng cho nội dung thiên về lời nói, và nêu −18 như mức mục tiêu cho âm nhạc là một lỗi phổ biến và nghiêm trọng).

Dolby Atmos là công nghệ độc quyền, được cấp phép của Dolby Laboratories, còn Sony 360 Reality Audio là một hệ thống độc quyền dựng trên MPEG-H. Yêu cầu của chúng do chủ sở hữu đặt ra, thay đổi mà không cần đếm xỉa đến lịch trình của ITU hay EBU, và không được nêu ở đây; không có tuyên bố nào về liên kết hay chứng thực. Hãy đọc tài liệu hiện hành của chính bên cấp phép.

Cần kiểm tra gì trước khi gửi đi

Kiểm tra cấu trúc trước; chúng nhanh và chúng vô hiệu hóa mọi thứ phía sau.

• Bốn byte đầu là BW64. Nếu đọc ra RIFF thì đó là WAV thuần và không thể vượt 4 GB.
• ds64 là chunk đầu tiên sau chữ ký, các kích thước 64-bit của nó khớp với kích thước tệp và kích thước data trên đĩa, và mọi chunk quá khổ không phải data đều có một mục ChunkSize64 trong bảng.
• Định vị axml một cách tường minh, kể cả sau data — đừng bao giờ kết luận “không có ADM” từ một lần quét dở dang.
• Tần số lấy mẫu và độ sâu bit trong fmt khớp chính xác với đặc tả giao nộp. Không chuyển đổi tần số lấy mẫu sau khi đã soạn ADM — nó làm vô hiệu mọi rtime và duration biểu diễn bằng mẫu.
• fmt .nChannels bằng chna.numTracks; mọi trackIndex nằm trong khoảng và được đánh từ 1.
• Mỗi mục chna đúng 40 byte với các trường bề rộng cố định được đệm đúng, và mọi packRef từ 0x1000 trở lên đều giải được tới một định nghĩa tùy biến có mặt trong axml.
• Mọi audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef và audioTrackUIDRef đều giải được. Không cạnh lơ lửng nào, theo cả hai chiều, và không có tham chiếu vòng.
• Các channel format nhiều khối mang cả rtime lẫn duration trên mọi khối; các khối liền mạch và đơn điệu; các đối tượng bắt đầu ở 00:00:00.00000.
• Mọi kênh của một bed đã khai báo chứa đúng cái nó phải chứa. Hãy điều tra sự im lặng số.
• Timecode bắt đầu trong bext nhất quán trên toàn bộ bộ giao nộp, còn các bản conform stereo và binaural được render lại từ bản master hiện tại. Một bản conform sớm 40 ms so với bản immersive cha của nó sẽ qua được phép kiểm tra sự hiện diện của tệp và trượt một lần nghe đồng bộ.
• Tính checksum cho mọi thứ giao nộp, giữ bản kê, và lưu trữ ADM XML tách riêng khỏi BW64 — thứ XML mà bạn có thể diff về sau đáng giá hơn một tệp nhị phân mà bạn chỉ có thể phân tích lại.

BW64 và ADM là những tiêu chuẩn mở, được công bố, đọc được tự do, và điều đó đáng tận dụng: bạn có thể tự đọc BS.2088 và BS.2076, phân tích một chunk chna bằng bốn mươi dòng mã, và kiểm chứng xem bộ xuất của một nhà cung cấp thực sự đã ghi ra cái gì thay vì tin vào lời hộp thoại của nó. Gần như toàn bộ các ca từ chối immersive không đáng có đều là lỗi toàn vẹn tham chiếu mà một trình kiểm tra bắt được trong chưa đầy một giây.

Công cụ soi BW64/ADM miễn phí của Mazufa ở mazufa.com/immersive-master-check phân tích cả container lẫn metadata hoàn toàn trên thiết bị của bạn và không tải lên bất cứ thứ gì, khiến nó dùng được cho những chất liệu mà theo hợp đồng không được rời khỏi tòa nhà. Bản thân Mazufa thì miễn phí để phát hành, lấy 0% hoa hồng, và chỉ nhận theo lời mời với việc con người xét duyệt mọi hồ sơ hoàn chỉnh.

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.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

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/publications/tech3388
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and 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
• libbw64 reference implementation — https://github.com/ebu/libbw64

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 của dịch vụ

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