ทำไมมาสเตอร์อิมเมอร์ซีฟจึงผ่านโปรแกรมแก้ไขคลื่นเสียงแต่ไม่ผ่าน QC

ไฟล์ส่งมอบแบบอิมเมอร์ซีฟเปิดในโปรแกรมแก้ไขคลื่นเสียงได้ แสดงแทร็กสิบสองหรือสิบหกแทร็กที่ดูสมบูรณ์ดี เล่นออกมาแล้วฟังสมเหตุสมผล และก็ยังถูกปฏิเสธอยู่ดี เหตุผลนั้นอยู่ที่โครงสร้าง คือในไฟล์ BW64 ตัวเสียงกับเมตาดาตาเป็นสองสิ่งแยกกันที่ต้องตรงกันเป๊ะ ๆ และไม่มีอะไรในฟอร์แมตบังคับให้มันตรงกัน เรนเดอเรอร์นั้นแก้การอ้างอิง ส่วนโปรแกรมแก้ไขนั้นวาดแซมเปิล คนละงานกัน ซึ่งเป็นเหตุผลว่าทำไม QC ของ ADM จึงเป็นการตรวจความสมบูรณ์ของการอ้างอิง ไม่ใช่การนั่งฟัง ต่อไปนี้คือสิ่งที่มาตรฐานสองฉบับระบุไว้ จุดที่การอ้างอิงขาด และการตรวจแบบใดจับความผิดพลาดแบบใดได้

เสียงสามชนิด และทำไมการแยกแยะนี้จึงตัดสินทุกอย่าง

ปัญหาการส่งมอบงานอิมเมอร์ซีฟทุกเรื่องเริ่มจากความสับสนว่าแทร็กหนึ่งเป็นสิ่งใดในสามสิ่งนี้

เสียงแบบอิงช่อง กำหนดให้แต่ละแทร็กผูกกับตำแหน่งลำโพงที่ตายตัว สเตอริโอเป็นแบบอิงช่อง 5.1 ก็เช่นกัน เบด 7.1.4 ก็เช่นกัน ตำแหน่งถูกอบไว้ในตัวตนของช่องเลย คือแทร็ก 3 คือลำโพงกลาง และมันเป็นลำโพงกลางบนทุกระบบที่เล่นมัน ITU-R BS.2051 ทำให้เรื่องนี้เป็นทางการสำหรับระบบเสียงขั้นสูง โดยบรรยายผังลำโพงเป็นจำนวนชั้น Upper + Middle + Bottom คือ System A เป็น 0+2+0 (สเตอริโอ), System B เป็น 0+5+0 (5.1), System D เป็น 4+5+0, System J เป็น 4+7+0 และ System H เป็น 9+10+3 ซึ่งคือคอนฟิเกอเรชัน 22.2 ใน ADM นี่คือ typeDefinition ชื่อ DirectSpeakers และ typeLabel 0001

เสียงแบบอิงออบเจกต์ พาสัญญาณโมโน (หรือแพ็กหลายช่อง) มาพร้อมเมตาดาตาตำแหน่งที่เปลี่ยนไปตามเวลา เรนเดอเรอร์เป็นผู้ตัดสินว่าลำโพงจริงตัวใดจะสร้างเสียงนั้นขึ้นมา โดยอิงจากผังลำโพงที่มีอยู่ในห้อง ไม่มีอะไรในแทร็กที่สมมติถึงลำโพงตัวใดไว้ล่วงหน้า นี่คือ typeDefinition ชื่อ Objects และ typeLabel 0003

เสียงแบบอิงซีน ซึ่งในทางปฏิบัติคือ Higher-Order Ambisonics เข้ารหัสสนามเสียงทั้งสนามเป็นองค์ประกอบฮาร์มอนิกทรงกลม ไม่มีองค์ประกอบใดที่สอดคล้องกับทิศทางใดโดยลำพัง ทิศทางเกิดขึ้นจากการรวมเชิงเส้น นี่คือ HOA และ typeLabel 0004 ADM ยังนิยาม Matrix (0002) สำหรับสัญญาณที่ผ่านเมทริกซ์อย่าง Mid-Side หรือ Lt/Rt และ Binaural (0005) ไว้ด้วย

การแยกแยะนี้ไม่ใช่เรื่องการจัดหมวดหมู่ ไฟล์ส่งมอบแบบอิงช่องนั้นบรรยายตัวเองได้มากพอที่จะรอดในสภาพไฟล์ WAV เปล่า ๆ คือถ้าลำดับช่องถูกต้องมันก็เล่นได้ ส่วนไฟล์ส่งมอบแบบอิงออบเจกต์หรืออิงซีนนั้นไร้ความหมายหากปราศจากเมตาดาตา เพราะตัวเสียงคือกองสตรีมโมโนที่แยกจากกันไม่ออก และ ADM คือสิ่งเดียวที่บอกเป็นอย่างอื่น ความไม่สมมาตรนั้นคือเหตุผลที่ BW64 และ ADM มีอยู่

BW64 มีอยู่เพราะตัวเลข 32-bit ตัวหนึ่ง

WAV แบบดั้งเดิมคือไฟล์ RIFF และ RIFF ซึ่งมาจากปี 1991 ใส่ฟิลด์ขนาดแบบ 32-bit ไว้หน้าทุก chunk สามสิบสองบิตระบุตำแหน่งได้ 4,294,967,296 ไบต์ หรือ 4 GB และนั่นคือเพดานแข็งทั้งของทั้งไฟล์และของ chunk ชื่อ data ที่อยู่ข้างใน

สำหรับสเตอริโอที่ 48 kHz / 24-bit อัตราข้อมูลคือ 288,000 ไบต์ต่อวินาที ดังนั้น 4 GB จึงราว 4 ชั่วโมง 8 นาที ซึ่งไม่เกี่ยวข้องอะไรเลย แต่สำหรับมาสเตอร์แบบอิงออบเจกต์ 128 แทร็กที่ 96 kHz / 24-bit อัตราคือ 36,864,000 ไบต์ต่อวินาที และ 4 GB คือ ไม่ถึงสองนาที หรือ 116.5 วินาที

มาสเตอร์อิมเมอร์ซีฟข้ามขีดจำกัดนั้นเป็นเรื่องปกติ และตัวเขียน WAV ที่ชนเพดานจะให้ผลออกมาเป็นไฟล์ที่ถูกตัดทิ้ง หรือไฟล์ที่ขนาดซึ่งประกาศไว้วนกลับไปเงียบ ๆ EBU จัดการเรื่องนี้ก่อนด้วย RF64 (EBU Tech 3306) ส่วน ITU รับมันไปต่อเป็นข้อแนะนำ ITU-R BS.2088 ซึ่งก็คือ BW64

กลไกค่าเฝ้าสัญญาณ 0xFFFFFFFF กับ chunk ชื่อ ds64

BS.2088 ระบุกลไกไว้ชัดเจน "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file" และฟิลด์ขนาด 32-bit เดิมกลายเป็นธงหลบหลีก "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

กลไกทั้งหมดมีเท่านั้น และควรพูดออกมาตรง ๆ ว่า BW64 ไม่ได้ขยายฟิลด์ขนาดของ RIFF ให้กว้างขึ้น มันเติม 0xFFFFFFFF ลงไปเป็นค่าเฝ้าสัญญาณ แล้วเอาขนาด 64-bit ที่แท้จริงไปไว้ใน chunk ชื่อ ds64 ซึ่งต้องอยู่เป็นอันแรกในไฟล์ ดังนั้นไฟล์ BW64 ที่เล็กกว่า 4 GB จึงเข้ากันได้ระดับไบต์กับตัวอ่าน WAV ในทุกแง่มุม ยกเว้นลายเซ็นสี่อักขระ เครื่องมือจำนวนมากรับมันได้ ส่วนบางตัวก็ดื้อไม่ยอมรับ

chunk ต่าง ๆ และอันที่แต่ละรายการยาว 40 ไบต์พอดี

ตาม BS.2088 ไฟล์ BW64 ควรมีอย่างน้อย ds64, fmt , chna, axml (โดยมี bxml และ sxml เป็นตัวพาเมตาดาตาทางเลือก) และตัวข้อมูลคลื่นเสียง

ds64 ต้องเป็น chunk แรกถัดจากลายเซ็น เพราะตัวอ่านจำเป็นต้องรู้ขนาดที่แท้จริงก่อนจะเดินไปอ่านอย่างอื่นได้ มันบรรจุครึ่งบน/ครึ่งล่างแบบ 32-bit ของขนาดทั้งไฟล์และขนาดของ data พร้อมตารางรายการ ChunkSize64 สำหรับ chunk อื่น ที่ใหญ่เกินขนาด เพราะ chunk axml ที่บรรยายออบเจกต์นับพันพร้อมออโตเมชันแม่นระดับแซมเปิลนั้น ตัวมันเองก็เข้าใกล้หรือเกิน 4 GB ได้

fmt คือ chunk รูปแบบ WAVE มาตรฐาน ได้แก่รูปแบบแซมเปิล อัตราสุ่มตัวอย่าง จำนวนช่อง จำนวนบิตต่อแซมเปิล และ block align มันคือคำแถลงที่มีอำนาจเพียงหนึ่งเดียวว่ามีกี่ช่องที่สานสลับกันอยู่ใน data ทุกสิ่งที่อยู่ถัดไปคือเมตาดาตาที่ พูดถึง ช่องเหล่านั้น และเมตาดาตานั้นโกหกได้

chna คือสะพานระหว่างแทร็กทางกายภาพกับ ADM ถัดจาก ckID, ckSize, numTracks ขนาด 2 ไบต์ และ numUIDs ขนาด 2 ไบต์ มันบรรจุอาร์เรย์แบนของรายการ audioID ที่มีความกว้างตายตัว โดยแต่ละรายการยาว 40 ไบต์พอดี

2 + 12 + 14 + 11 + 1 = 40 ความกว้างเหล่านี้ไม่ใช่คำแนะนำ มันคือ ASCII ความกว้างตายตัว และตัวเขียนที่ปล่อย UID ยาว 13 อักขระออกมาก็คือได้สร้างตารางที่เสียหาย ไม่ใช่ตารางที่แค่แปลกไปนิดหน่อย

ธรรมเนียมของ ID ก็สำคัญเช่นกัน ค่าตั้งแต่ 0x0FFF ลงมาอ้างถึงนิยามร่วมของ ADM คือรูปแบบช่องและแพ็กมาตรฐานที่นิยามไว้ล่วงหน้าแล้ว ส่วนค่าตั้งแต่ 0x1000 ขึ้นไปบ่งชี้นิยามที่กำหนดเองซึ่งต้องมีอยู่ใน axml โดย AP_00010003 คือ 5.1 ตามนิยามร่วมและไม่ต้องมี XML ส่วน AP_00031001 คือแพ็กออบเจกต์ที่กำหนดเองและต้องมี XML ไม่เช่นนั้นมันจะห้อยลอยอยู่

numUIDs มีมากกว่า numTracks ได้อย่างชอบธรรมด้วย เพราะแนวทางของ EBU ระบุไว้ว่าในกรณีที่ "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" ดังนั้น trackIndex เดียวจึงอาจปรากฏในหลายรายการ เครื่องมือ QC ที่สมมติว่าหนึ่งแทร็กมีหนึ่ง UID จะขึ้นธงว่าไฟล์ที่ถูกต้องนั้นเสีย

axml คือเอกสาร XML แบบ UTF-8 ที่บรรจุต้นไม้ <audioFormatExtended> นั่นคือ ADM และเป็นที่อยู่ของความผิดพลาดที่น่าสนใจแทบทั้งหมด ส่วน data คือ PCM สานสลับล้วน ๆ ไม่มีอะไรในนั้นรู้อะไรเกี่ยวกับออบเจกต์เลย

เรื่องลำดับ ds64 มาก่อนเสมอ และ fmt มาก่อน data แต่ axml วางอยู่ หลัง data ได้อย่างชอบธรรม และมักเป็นเช่นนั้น เพราะอย่างที่ BS.2088 ตั้งข้อสังเกตไว้ว่า ระหว่างการบันทึกนั้น "the XML metadata will likely be of an unknown length." ไฟล์ที่มี axml อยู่ท้ายไม่ใช่ไฟล์ที่ผิดรูป แต่ตัวอ่านที่สแกนแค่เมกะไบต์แรกจะรายงานว่าไม่มี ADM เลย นั่นอธิบายรายงานประเภท "ไฟล์ของผมไม่มีเมตาดาตา" ได้ในสัดส่วนที่น่าประหลาดใจ

ADM คือกราฟ และความผิดพลาดคือเส้นเชื่อมที่ขาด

ลำดับชั้นของ ITU-R BS.2076 ไล่จาก audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat โดยมี audioTrackUID เป็นใบไม้ปลายทางและเป็นสมาชิกเพียงตัวเดียวที่สอดคล้องกับแทร็กทางกายภาพ

นั่นคือกราฟของการอ้างอิง ไม่ใช่เอกสารที่ซ้อนกันเป็นชั้น และความผิดพลาดในการส่งมอบที่ร้ายแรงทุกกรณีคือเส้นเชื่อมที่ขาดในกราฟนั้น สิ่งที่ทำให้การอ้างอิงห้อยลอยเป็นอันตรายคือไม่มีพฤติกรรมเดียวที่แน่นอนเมื่อมันขาด เรนเดอเรอร์ที่กำลังแก้ audioPackFormatIDRef ซึ่งเรียกชื่อแพ็กที่ไม่มีอยู่ใน XML อาจยกเลิกการแจงและปฏิเสธไฟล์ อาจข้ามออบเจกต์นั้นแล้วเรนเดอร์ทุกอย่างที่เหลือจนได้มิกซ์ที่ขาดสเต็มไปเงียบ ๆ หรืออาจถอยไปใช้นิยามร่วม แล้วเจอ ID ในช่วงกำหนดเองตั้งแต่ 0x1000 ขึ้นไปที่ไม่มีอะไรตรงกัน แล้วแทนที่ด้วยความเงียบ ผลลัพธ์ทั้งสามแบบล้วนคือ "ไฟล์เปิดได้" มีเพียงแบบเดียวที่จับได้ด้วยการฟัง และจับได้ก็ต่อเมื่อคุณรู้ว่าตรงนั้นควรมีอะไรอยู่

ความผิดพลาดสี่แบบที่เป็นเหตุของการถูกปฏิเสธเกือบทั้งหมด

จำนวนแทร็กใน fmt ไม่ตรงกับ chna คือ fmt .nChannels บอก 16 แต่ chna.numTracks บอก 14 ไฟล์ขัดแย้งกันเองตั้งแต่สอง chunk แรกแล้ว ซึ่งมักเป็นการบาวน์ซที่เปลี่ยนจำนวนแทร็กหลังจากเขียนเมตาดาตาไปแล้ว หรือเครื่องมือที่ตัดแทร็กทิ้งโดยไม่เขียน chna ใหม่ การตรวจจับคือการแจงจำนวนเต็มสองตัวแล้วเทียบกัน ซึ่งเป็นการตรวจที่ถูกที่สุดในสายงาน และมันจับความผิดพลาดได้ในสัดส่วนที่น่าตกใจ ให้ตรวจไปพร้อมกันด้วยว่า trackIndex ทุกตัวอยู่ในช่วง 1 … fmt .nChannels

audioTrackUID ที่ไม่มีออบเจกต์ใดอ้างถึง UID ใน chna ที่ไม่มี audioObject ใดอ้างถึงหมายความว่ามีเสียงอยู่แต่จะไม่มีอะไรเรนเดอร์มันออกมา ส่วนกรณีกระจกเงาของมัน คือ audioTrackUIDRef ใน XML ที่ไม่มีรายการ chna ตรงกัน หมายความว่าเมตาดาตาคาดหวังแทร็กที่ไม่ได้อยู่ตรงนั้น ให้สร้างเซตของ UID จาก chna และเซตจาก axml แล้วหาผลต่างสมมาตร ซึ่งควรเป็นเซตว่าง EBU Tech 3392 ระบุเจตนาไว้ตรง ๆ ว่า "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

เวลาของบล็อกที่เดินย้อนกลับ BS.2076 ไม่กำกวมเลยว่า "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 รัดให้แน่นขึ้นเป็นความต่อเนื่องว่า "rtime + duration of an audioBlockFormat should match the rtime of the following block" โดยบล็อกแรกของออบเจกต์เริ่มที่ 00:00:00.00000 ไม่มีบล็อกใดสั้นกว่าหนึ่งแซมเปิล และผลรวมของ duration ต้องเท่ากับ audioObject แม่ ให้เดินไล่บล็อกตามลำดับในเอกสารแล้วยืนยันว่า rtime[n] + duration[n] == rtime[n+1] ความผิดพลาดมาในสามรูปแบบ คือช่องว่าง ซึ่งพฤติกรรมของเรนเดอเรอร์ไม่ถูกนิยามไว้ บางตัวค้างที่ตำแหน่งสุดท้ายขณะที่บางตัวปิดเสียง การซ้อนทับ ซึ่งบล็อกตีกันเอง และบล็อกที่เรียงผิดลำดับเวลา ซึ่งก็คือออโตเมชันกระโดดย้อนกลับกลางรายการ

เบดที่บรรยายไว้ใน XML แต่ไม่เคยถูกพิมพ์ลงดิสก์ XML ประกาศแพ็ก DirectSpeakers แบบ 7.1.4 คือสิบสองช่อง แต่มีเพียงเซตย่อย 5.1 ที่ถูกพิมพ์ออกมา หรือช่องความสูงถูกปิดเสียงตอนบาวน์ซแล้วพิมพ์ออกมาเป็นความเงียบดิจิทัล กราฟการอ้างอิงยังสมบูรณ์ ส่วนตัวเสียงไม่สมบูรณ์ การตรวจเชิงโครงสร้างจับเรื่องนี้ไม่ได้ คุณต้องวิเคราะห์ตัวเสียงจริง โดยวัดว่าทุกช่องที่แพ็ก DirectSpeakers อ้างสิทธิ์ไว้นั้นมีสัญญาณอยู่หรือไม่ ความเงียบดิจิทัลบนช่องเบดที่ประกาศไว้ไม่ใช่ความผิดพลาดโดยอัตโนมัติ เพราะมิกซ์ที่ชอบธรรมอาจปล่อยช่องบนหลังให้ว่างไว้ก็ได้ แต่มันคุ้มค่าเสมอที่จะให้คนตัดสิน

อะไรที่ถูกประกาศเกี่ยวกับความดังแบบอิมเมอร์ซีฟ และอะไรที่ไม่ถูกประกาศ

มีตัวเลขหนึ่งตัวที่ไม่รอดจากการย้ายออกจากสเตอริโอ และควรบอกว่าเพราะอะไร

BS.1770-5 (November 2023) คือฉบับปัจจุบัน ส่วน BS.1770-4 ถูกแทนที่แล้ว แม้มิเตอร์ที่ใช้งานกันอยู่ส่วนใหญ่ยังอ้างถึงมัน อัลกอริทึมแกนของมันถ่วงน้ำหนัก L, R และ C ที่ 1.0 และ Ls กับ Rs ที่ 1.41 (ราว +1.5 dB) ตัด LFE ออก และมีขอบเขต "from one to five channels" ส่วน BS.1770-5 ขยายเลยจากนั้นในภาคผนวก โดยครอบคลุมระบบเสียงขั้นสูงตาม BS.2051 และเสียงแบบอิงออบเจกต์ ซึ่งต้องถูก เรนเดอร์ ก่อนจึงจะวัดได้ ดังนั้นความดังแบบอิมเมอร์ซีฟจึงไม่ใช่คุณสมบัติของไฟล์แต่เป็นคุณสมบัติของการเรนเดอร์ และการเปลี่ยนผังลำโพงปลายทางก็เปลี่ยนตัวเลข ให้วัดการเรนเดอร์ที่เป็นไปตาม BS.2127 ไปยังผัง BS.2051 ที่มีชื่อเรียก ด้วยมิเตอร์ตาม BS.1770-5 แล้วบันทึกทั้งสามอย่างไว้ในโน้ตการส่งมอบ โดย BS.2127 นิยามเรนเดอเรอร์ ADM อ้างอิงไว้ และญาติโอเพนซอร์สของมันคือ EBU ADM Renderer (EBU Tech 3388) ซึ่งเป็นวิธีเชิงปฏิบัติในการได้ตัวเลขที่ทำซ้ำได้

ไม่มีบริการสตรีมมิงเพลงรายใดประกาศค่าเป้าหมายความดังแบบ integrated สำหรับการส่งมอบงานอิมเมอร์ซีฟ ตัวเลขหมุนเวียนกันอยู่ในเว็บบอร์ดและในเอกสารอบรมของผู้ขาย แต่ไม่มีตัวใดเป็นข้อกำหนดที่ถูกประกาศ และบทความนี้จะไม่พูดซ้ำราวกับว่ามันเป็นเช่นนั้น สิ่งที่ถูกประกาศคือค่าสำหรับสเตอริโอแบบอิงช่อง ได้แก่ค่าเป้าหมายแบบ integrated ที่ −14 LUFS ของ Spotify พร้อมเพดานทรูพีคที่ −1 dBTP ซึ่งเข้มขึ้นเป็น −2 dBTP เมื่อดังกว่า −14 LUFS และค่า −16 LUFS สำหรับดนตรีของ AES TD1008 (ส่วนค่า −18 LUFS ของมันใช้กับเนื้อหาที่นำโดยเสียงพูด และการระบุ −18 ว่าเป็นค่าเป้าหมายสำหรับดนตรีเป็นข้อผิดพลาดที่พบบ่อยและร้ายแรง)

Dolby Atmos เป็นเทคโนโลยีกรรมสิทธิ์ที่ต้องได้รับอนุญาตจาก Dolby Laboratories และ Sony 360 Reality Audio เป็นระบบกรรมสิทธิ์ที่สร้างบน MPEG-H ข้อกำหนดของทั้งสองถูกตั้งโดยเจ้าของ เปลี่ยนแปลงโดยไม่อิงตารางเวลาของ ITU หรือ EBU และไม่ถูกระบุไว้ที่นี่ ทั้งไม่มีการอ้างความเกี่ยวข้องหรือการรับรองใด ๆ ให้อ่านเอกสารฉบับปัจจุบันของผู้ให้สิทธิ์เอง

ตรวจอะไรบ้างก่อนส่ง

ตรวจเชิงโครงสร้างก่อน เพราะมันเร็วและมันทำให้ทุกอย่างที่อยู่ถัดไปเป็นโมฆะ

• สี่ไบต์แรกคือ BW64 หากอ่านได้เป็น RIFF แปลว่ามันคือ WAV ธรรมดาและเกิน 4 GB ไม่ได้
• ds64 เป็น chunk แรกถัดจากลายเซ็น ขนาด 64-bit ของมันตรงกับขนาดไฟล์และขนาด data บนดิสก์ และ chunk ที่ไม่ใช่ data ซึ่งใหญ่เกินขนาดทุกอันมีรายการ ChunkSize64 อยู่ในตาราง
• ระบุตำแหน่ง axml อย่างชัดแจ้ง รวมถึงตำแหน่งหลัง data ด้วย อย่าสรุปว่า "ไม่มี ADM" จากการสแกนที่ไม่ครบถ้วน
• อัตราสุ่มตัวอย่างและความลึกบิตใน fmt ตรงกับข้อกำหนดการส่งมอบเป๊ะ ๆ ห้ามแปลงอัตราสุ่มตัวอย่างหลังจากเขียน ADM แล้ว เพราะมันทำให้ rtime และ duration ทุกค่าที่แสดงเป็นแซมเปิลเป็นโมฆะ
• fmt .nChannels เท่ากับ chna.numTracks และ trackIndex ทุกตัวอยู่ในช่วงและเริ่มนับจาก 1
• ทุกรายการใน chna ยาว 40 ไบต์พอดี โดยฟิลด์ความกว้างตายตัวถูกเติมอย่างถูกต้อง และ packRef ทุกตัวตั้งแต่ 0x1000 ขึ้นไปแก้ไปยังนิยามที่กำหนดเองซึ่งมีอยู่ใน axml ได้
• audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef และ audioTrackUIDRef ทุกตัวแก้ได้หมด ไม่มีเส้นเชื่อมห้อยลอยเลยไม่ว่าทิศทางใด และไม่มีการอ้างอิงวนรอบ
• รูปแบบช่องที่มีหลายบล็อกมีทั้ง rtime และ duration บนทุกบล็อก บล็อกต่อเนื่องกันและเรียงทิศเดียว และออบเจกต์เริ่มที่ 00:00:00.00000
• ทุกช่องของเบดที่ประกาศไว้บรรจุสิ่งที่มันควรบรรจุ ให้สืบสวนความเงียบดิจิทัล
• ไทม์โค้ดเริ่มต้นใน bext สอดคล้องกันทั้งชุด และงานคอนฟอร์มแบบสเตอริโอกับไบนอรัลถูกเรนเดอร์ใหม่จากมาสเตอร์ฉบับ ปัจจุบัน งานคอนฟอร์มที่เร็วกว่าตัวแม่แบบอิมเมอร์ซีฟอยู่ 40 ms จะผ่านการตรวจว่ามีไฟล์อยู่ แต่ไม่ผ่านการฟังแบบซิงก์กัน
• ทำเช็กซัมของทุกไฟล์ที่ส่งมอบ เก็บรายการกำกับไว้ และจัดเก็บ ADM XML แยกจาก BW64 เพราะ XML ที่คุณ diff ได้นั้นมีค่ากว่าไฟล์ไบนารีที่คุณทำได้แค่แจงมันใหม่

BW64 และ ADM เป็นมาตรฐานเปิด ถูกประกาศ และอ่านได้อย่างเสรี ซึ่งคุ้มค่าที่จะใช้ประโยชน์ คือคุณอ่าน BS.2088 และ BS.2076 ด้วยตัวเองได้ แจง chunk chna ด้วยโค้ดสี่สิบบรรทัดได้ และตรวจสอบได้ว่าตัวส่งออกของผู้ขายเขียนอะไรออกมาจริง ๆ แทนที่จะเชื่อสิ่งที่กล่องข้อความของมันอ้าง การถูกปฏิเสธงานอิมเมอร์ซีฟโดยไม่จำเป็นแทบทั้งหมดคือความผิดพลาดด้านความสมบูรณ์ของการอ้างอิง ซึ่งตัวตรวจสอบจับได้ภายในเวลาไม่ถึงวินาที

ตัวตรวจ BW64/ADM ฟรีของ Mazufa ที่ mazufa.com/immersive-master-check แจงทั้งคอนเทนเนอร์และเมตาดาตาบนอุปกรณ์ของคุณเองทั้งหมดและไม่อัปโหลดอะไรเลย ซึ่งทำให้ใช้ได้กับวัสดุที่ตามสัญญาแล้วออกจากอาคารไม่ได้ ส่วนตัว Mazufa เองนั้นปล่อยผลงานได้ฟรี เก็บค่าคอมมิชชัน 0% และรับเฉพาะผู้ที่ได้รับคำเชิญ โดยมีคนอ่านใบสมัครที่สมบูรณ์ทุกใบ

แหล่งข้อมูล

ข้อแนะนำของ 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

เอกสารเทคนิคของ EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (และภาคผนวก), 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/

เอกสารของบริการ

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