BW64 และ ADM: คู่มืออ้างอิงทางเทคนิคสำหรับการส่งมอบเสียงอิมเมอร์ซีฟ

เขียนสำหรับวิศวกรเสียงที่ต้องเตรียมมาสเตอร์แบบวัตถุ (object-based) หรือแบบฉาก (scene-based) และสำหรับนักดนตรีที่ถูกยื่นคำว่า "ไฟล์อิมเมอร์ซีฟ" มาให้แล้วบอกให้ทำให้ผ่าน QC โดยไม่มีใครอธิบายว่าไฟล์นั้นข้างในเป็นอย่างไร

คำตอบสั้นที่สุด

Audio Definition Model หรือ ADM คือมาตรฐานเมทาดาทาแบบเปิดตามข้อแนะนำ ITU-R BS.2076 ซึ่งอธิบายว่าแทร็กเสียงแต่ละแทร็กในไฟล์ คืออะไร — เป็นช่องลำโพงตายตัว เป็นวัตถุที่เคลื่อนที่ได้ หรือเป็นองค์ประกอบแอมบิโซนิก — และแทร็กเหล่านั้นประกอบกันขึ้นเป็นรายการเสียงอย่างไร ADM ถูกบรรจุอยู่ในรูป XML ภายในคอนเทนเนอร์ BW64 ตามข้อแนะนำ ITU-R BS.2088 ซึ่งเป็นส่วนขยาย 64 บิตของ RIFF/WAVE ที่ทำให้หลุดพ้นจากเพดาน 4 GB ของ WAV แบบเดิม เหตุผลที่งานอิมเมอร์ซีฟตก QC ซ้ำแล้วซ้ำเล่าไม่ใช่เพราะเสียงไม่เพราะ แต่เพราะ "เสียง" กับ "เมทาดาทา" เป็นของสองสิ่งที่ต้องตรงกันเป๊ะ และไม่มีอะไรในรูปแบบไฟล์บังคับให้มันตรงกัน จำนวนแทร็กใน fmt ที่ขัดกับตาราง chna ค่า audioTrackUID ที่ไม่มีวัตถุใดอ้างถึง บล็อกเวลาที่เดินถอยหลัง หรือเบดที่ประกาศไว้ใน XML แต่ไม่เคยถูกพิมพ์ลงดิสก์จริง — ทั้งหมดนี้เงียบสนิทเมื่อเปิดดูในโปรแกรมตัดต่อคลื่นเสียง และเป็นอันตรายถึงชีวิตสำหรับตัวเรนเดอร์ การตรวจ ADM จึงเป็นงานตรวจความสมบูรณ์ของการอ้างอิง ไม่ใช่งานนั่งฟัง

1. วงปี่พาทย์: ตัวอย่างที่อธิบายเสียงแบบวัตถุได้ดีที่สุดในบริบทไทย

ก่อนจะพูดถึงคอนเทนเนอร์ ต้องพูดถึงแบบจำลองก่อน ปัญหาการส่งมอบงานอิมเมอร์ซีฟเกือบทุกกรณีเริ่มจากความสับสนว่าแทร็กหนึ่งแทร็กนั้น "เป็นอะไร" ในสามแบบต่อไปนี้

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

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

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

เสียงแบบช่องสัญญาณบอกไฟล์ว่าลำโพงอยู่ตรงไหน เสียงแบบวัตถุปฏิเสธที่จะเดา และเสียงแบบฉากบรรยายสนามเสียงแทนที่จะบรรยายแหล่งกำเนิด

1.1 ทำไมวงปี่พาทย์จึงเป็นกรณีศึกษาที่ตรงจุด

วงปี่พาทย์มีการจัดวางที่เป็นแบบแผน ไม่ใช่การนั่งตามใจชอบ ระนาดเอกอยู่แถวหน้าในฐานะผู้นำทำนอง ระนาดทุ้มอยู่คู่กันแต่ทำหน้าที่หยอกล้อสอดแทรก ฆ้องวงใหญ่วางเนื้อทำนองหลักเป็นแกนกลางของวง ฆ้องวงเล็กเก็บรายละเอียดในทางเก็บ ปี่ในเป่านำทำนองด้วยเสียงต่อเนื่องที่กินพื้นที่ความถี่กลาง และเครื่องหนัง — ตะโพนกับกลองทัด — คุมจังหวะหน้าทับอยู่อีกฝั่งหนึ่ง ทุกชิ้นมีตำแหน่งที่ผู้ฟังชาวไทยคาดหวังได้ ถ้ามิกซ์สลับตำแหน่งระนาดเอกกับฆ้องวงใหญ่ คนที่โตมากับวงจะรู้ทันทีว่าผิด แม้จะบอกไม่ถูกว่าผิดตรงไหน

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

นี่ไม่ใช่รายละเอียดเชิงกวี มันมีผลกับการเขียน ADM โดยตรง มีทางเลือกสามทางและแต่ละทางมีราคาของมัน

1. ปฏิบัติต่อฆ้องวงเป็นวัตถุเดียวแบบจุด เขียน audioBlockFormat เดียวที่ตำแหน่งคงที่ วิธีนี้ง่ายที่สุดและผิดที่สุด เพราะมันทิ้งลักษณะเฉพาะทางกายภาพของเครื่องดนตรีไปทั้งหมด
2. ปฏิบัติต่อฆ้องวงเป็นวัตถุเดียวที่มีขนาด ใช้พารามิเตอร์ width depth และ height ใน audioBlockFormat เพื่อบอกเรนเดอร์ว่าแหล่งกำเนิดนี้กว้าง ไม่ใช่จุด บวกกับค่า diffuseness เล็กน้อย วิธีนี้สมเหตุสมผลสำหรับการบันทึกด้วยไมค์คู่เดียวเหนือวงฆ้อง
3. ปฏิบัติต่อฆ้องวงเป็นแพ็กของวัตถุหลายตัว โดยแบ่งวงฆ้องออกเป็นส่วนโค้งหลายส่วน ปิดไมค์แต่ละส่วน แล้วให้แต่ละส่วนเป็น audioObject ที่มี azimuth ต่างกัน ทั้งหมดรวมอยู่ใน audioPackFormat เดียวกันแบบซ้อน (nested pack) เพื่อให้ตัวเรนเดอร์และเครื่องมือตัดต่อยังมองว่ามันเป็นเครื่องดนตรีชิ้นเดียว

ทางเลือกที่สามคือทางที่ให้ผลตรงกับความจริงมากที่สุด และมันเปิดกับดักทางเทคนิคที่คนไทยจะเจอก่อนใคร: ค่า azimuth วนรอบ 360 องศา ADM ระบุ azimuth ในช่วง −180 ถึง +180 องศา เมื่อแหล่งกำเนิดเสียงเคลื่อนผ่านด้านหลังผู้ฟัง ค่าจะกระโดดจาก +180 ไปเป็น −180 ถ้าผู้เขียนออโตเมชันสร้างค่าเชิงเส้นระหว่างสองบล็อกโดยไม่จัดการการวนรอบ วัตถุจะไม่ได้เดินต่อไปด้านหลัง แต่จะกวาดผ่านหน้าผู้ฟังทั้ง 360 องศาในเวลาชั่วพริบตา ผลลัพธ์คือเสียงระนาดหรือฆ้องที่วิ่งข้ามหัวผู้ฟังแบบไม่มีเหตุผล ซึ่งเป็นข้อผิดพลาดที่มองไม่เห็นในไฟล์ XML และได้ยินชัดเจนในหูฟังไบนอรัล

เครื่องดนตรีที่ล้อมรอบตัวผู้บรรเลงเป็นบททดสอบที่ซื่อสัตย์ที่สุดของเสียงแบบวัตถุ เพราะมันบังคับให้ผู้เขียนเมทาดาทาตอบคำถามว่า "แหล่งกำเนิดเสียงนี้อยู่ตรงไหน" ในแบบที่ตอบว่า "ตรงกลางเวที" ไม่ได้

1.2 โขน: วงนิ่ง ผู้แสดงเคลื่อน

การแสดงโขนให้โครงสร้างที่แยกสองแบบออกจากกันอย่างสะอาด วงปี่พาทย์นั่งอยู่ข้างเวที ตำแหน่งคงที่ตลอดการแสดง ส่วนผู้แสดงเคลื่อนที่ไปทั่วพื้นที่ ในภาษา ADM นี่แปลว่า

• วงดนตรีคือชุดของ audioObject ที่มี audioBlockFormat เดียวต่อหนึ่ง audioChannelFormat — วัตถุนิ่ง ไม่ต้องมีออโตเมชัน หรือจะทำเป็นเบดแบบ DirectSpeakers ที่ครอบคลุมทิศทางของวงก็ได้ถ้ารูปแบบการส่งมอบต้องการ
• ผู้แสดงคือ audioObject ที่มีลำดับบล็อกจำนวนมาก แต่ละบล็อกมี rtime และ duration และตำแหน่งที่เปลี่ยนไปตามการเคลื่อนไหวบนเวที

ความผิดพลาดที่พบบ่อยในงานลักษณะนี้คือ ผู้ทำงานเผลอใส่ออโตเมชันให้วงดนตรีด้วย เพราะเครื่องมือสร้างบล็อกอัตโนมัติทุกเฟรม ผลคือไฟล์ที่มี audioBlockFormat หลายหมื่นบล็อกสำหรับวัตถุที่ไม่เคยขยับ ทำให้ axml บวมโดยไม่จำเป็น และเพิ่มโอกาสที่บล็อกใดบล็อกหนึ่งจะมีเวลาที่ไม่ต่อเนื่อง ถ้าวัตถุไม่เคลื่อน ให้มันมีบล็อกเดียว

1.3 วัด ขบวนแห่ และการสวดมนต์: เมื่อแหล่งกำเนิดเสียงคือกลุ่มคน

บริบทวัดให้โจทย์ที่ต่างออกไปอีกแบบ

การสวดมนต์ของพระสงฆ์ในศาลา ไม่ใช่แหล่งกำเนิดแบบจุด และก็ไม่ใช่วัตถุที่เคลื่อนที่ มันคือกลุ่มเสียงที่กว้าง มีความสอดคล้องกันเชิงเวลาสูง (ทุกคนสวดพร้อมกัน) แต่กระจายตัวเชิงพื้นที่ และห้องมีส่วนร่วมกับเสียงอย่างมาก การเขียนกลุ่มพระเป็นวัตถุจุดเดียวจะให้ผลที่ฟังแล้วแคบผิดธรรมชาติทันที ทางเลือกที่ตรงกว่าคือใช้วัตถุเดียวที่ตั้งค่า width กว้างและ diffuseness สูง หรือถ้าเป็นการบันทึกภาคสนาม ให้ใช้เสียงแบบฉาก (HOA) จับทั้งสนามเสียงรวมทั้งเสียงสะท้อนของศาลาไปเลย แล้วค่อยวางวัตถุเฉพาะจุด เช่น เสียงระฆังหรือเสียงพระผู้นำสวด ทับลงไปเป็นชั้นวัตถุ

ลานวัดที่มีขบวนแห่ เป็นกรณีที่ทั้งวงเคลื่อนที่ไปพร้อมกัน วงกลองยาวหรือวงปี่พาทย์ที่เดินในขบวนไม่ได้เคลื่อนแยกกันเป็นอิสระ มันรักษารูปวงของมันไว้แล้วเคลื่อนทั้งก้อน ADM รองรับกรณีนี้ได้ตรง ๆ ด้วยการซ้อน audioObject: สร้างวัตถุแม่หนึ่งตัวแทนขบวน แล้วให้วัตถุลูกแต่ละตัว (แต่ละเครื่องดนตรี) อยู่ภายใต้มัน แต่ข้อควรระวังคือ ADM ไม่มีแนวคิด "ตำแหน่งสัมพัทธ์" ที่วัตถุลูกสืบทอดจากวัตถุแม่โดยอัตโนมัติ — ตำแหน่งใน audioBlockFormat เป็นตำแหน่งสัมบูรณ์เสมอ ดังนั้นถ้าขบวนเคลื่อน ออโตเมชันของวัตถุลูกทุกตัวต้องถูกเขียนใหม่ทั้งหมด การซ้อนวัตถุช่วยเรื่องความหมายเชิงบรรณาธิการและการเปิด-ปิดเป็นกลุ่ม ไม่ได้ช่วยลดปริมาณข้อมูลตำแหน่ง ผู้ที่คิดว่ามันช่วยจะได้ไฟล์ที่ขบวนแห่ยืนนิ่งอยู่กับที่

1.4 หมอลำและลูกทุ่ง: เมื่อพื้นที่อะคูสติกคือทุ่งนา

งานแสดงกลางแจ้งของหมอลำและลูกทุ่งพลิกสมมติฐานของอิมเมอร์ซีฟกลับหัว ในห้องมิกซ์ ผู้ฟังอยู่ตรงจุดฟังที่กำหนดไว้และเวทีอยู่ข้างหน้า ในงานวัดหรืองานลานกลางแจ้ง ผู้ฟังอยู่ข้างในเหตุการณ์ เสียงมาจากลำโพงหลักหน้าเวที จากลำโพงหน่วง (delay tower) ที่อยู่กลางฝูงชน จากเสียงคนรอบตัว จากลำโพงประกาศ และจากพื้นที่เปิดที่แทบไม่มีเสียงสะท้อนกลับมาเลยนอกจากจากพื้นดิน

การผลิตงานอิมเมอร์ซีฟจากวัสดุแบบนี้จึงมักเป็นงานผสมสองแบบ: ชั้นเสียงแบบฉาก (HOA) ที่บันทึกบรรยากาศจริงจากกลางฝูงชน บวกกับชั้นวัตถุที่เป็นมัลติแทร็กจากเวที ข้อผิดพลาดที่ตามมาคือความสอดคล้องเชิงเวลา — ไมค์บรรยากาศที่ห่างจากเวที 40 เมตรจะได้ยินเสียงช้ากว่าสัญญาณจากมิกเซอร์อย่างมีนัยสำคัญ ถ้าไม่จัดการ ไฟล์จะผ่าน QC เชิงโครงสร้างทุกข้อและฟังแล้วเบลอ ADM ช่วยอะไรตรงนี้ไม่ได้เลย มันบันทึกได้แค่ว่าคุณตั้งใจให้เสียงอยู่ตรงไหน ไม่ได้บอกว่าเสียงมาถึงเมื่อไร

2. BW64: มันคืออะไร และมีไว้ทำไมกันแน่

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

ลองคิดเลขดู สำหรับสเตอริโอที่ 48 kHz / 24 บิต อัตราข้อมูลคือ 2 ช่อง × 3 ไบต์ × 48,000 = 288,000 ไบต์ต่อวินาที ดังนั้น 4 GB คือ 4,294,967,296 ÷ 288,000 ≈ 14,913 วินาที หรือราว 4 ชั่วโมง 8 นาที ไม่มีใครชนเพดานนี้

ทีนี้ลองคิดกับงานจริงในบริบทไทย สมมติมาสเตอร์การแสดงโขนที่ประกอบด้วยเบด 7.1.4 จำนวน 12 ช่อง บวกวัตถุอีก 16 ตัวสำหรับเครื่องดนตรีในวงปี่พาทย์และผู้แสดง รวมเป็น 28 แทร็ก ที่ 48 kHz / 24 บิต อัตราข้อมูลคือ 28 × 3 × 48,000 = 4,032,000 ไบต์ต่อวินาที และ 4,294,967,296 ÷ 4,032,000 ≈ 1,065 วินาที หรือ 17 นาที 45 วินาที การแสดงโขนหนึ่งตอนยาวกว่านั้นแทบทุกครั้ง

ถ้าขยับขึ้นเป็น 96 kHz / 24 บิต ที่ 28 แทร็กเท่าเดิม อัตราข้อมูลเป็น 8,064,000 ไบต์ต่อวินาที และเพดานหล่นลงมาเหลือ 532 วินาที หรือ 8 นาที 52 วินาที — สั้นกว่าเพลงลูกทุ่งแบบเต็มชุดที่บันทึกสดต่อเนื่อง และในกรณีสุดขั้วอย่างมาสเตอร์แบบวัตถุ 128 แทร็กที่ 96 kHz / 24 บิต อัตราข้อมูลคือ 36,864,000 ไบต์ต่อวินาที เพดาน 4 GB มาถึงใน 116.5 วินาที คือไม่ถึงสองนาที

เมื่อโปรแกรมเขียน WAV ชนเพดานนี้ ผลลัพธ์คือไฟล์ที่ถูกตัดปลาย หรือไฟล์ที่ค่าขนาดที่ประกาศไว้วนกลับเป็นค่าน้อยอย่างเงียบ ๆ ไม่มีคำเตือน

EBU แก้ปัญหานี้ก่อนด้วย RF64 (EBU Tech 3306) จากนั้น ITU รับงานนั้นมาต่อยอดเป็น ข้อแนะนำ ITU-R BS.2088 ชื่อเต็มว่า Long-form file format for the international exchange of audio programme materials with metadata หรือที่เรียกกันว่า BW64 BS.2088 อธิบายกลไกไว้ชัดเจน:

"The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file" — ITU-R BS.2088

และ:

"If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead." — ITU-R BS.2088

แปลเป็นภาษาที่ตรงไปตรงมา: BW64 ไม่ได้ขยายฟิลด์ขนาดของ RIFF ให้กว้างขึ้น แต่เติมค่า 0xFFFFFFFF ลงไปเป็นค่าสัญญาณ (sentinel) แล้วเก็บขนาดจริงแบบ 64 บิตไว้ใน chunk ชื่อ ds64 ซึ่งต้องอยู่เป็นลำดับแรกในไฟล์

BW64 คือรุ่นที่สามของสายพันธุ์เดียวกัน RIFF/WAVE ให้คอนเทนเนอร์แบบ chunk มา Broadcast Wave (BWF, EBU Tech 3285) เพิ่ม chunk ชื่อ bext ที่เก็บผู้สร้าง ไทม์โค้ดอ้างอิง และประวัติการเข้ารหัส BW64 เก็บทั้งหมดนั้นไว้ เพิ่มการระบุที่อยู่แบบ 64 บิต และเพิ่ม chunk ที่ใช้บรรทุก ADM

ไฟล์ BW64 ที่มีขนาดต่ำกว่า 4 GB นั้นเข้ากันได้ระดับไบต์กับตัวอ่าน WAV ทุกประการยกเว้นลายเซ็นสี่ตัวอักษรที่หัวไฟล์ เครื่องมือจำนวนมากยอมรับมัน และบางตัวก็ดื้อไม่ยอม

3. โครงสร้าง chunk อย่างละเอียด

ตาม BS.2088 ไฟล์ BW64 ควรมีอย่างน้อย <ds64-ck> <fmt-ck> <chna-ck> <axml-ck> (โดยมี <bxml-ck> และ <sxml-ck> เป็นตัวบรรทุกเมทาดาทาทางเลือก) และ <wave-data>

3.1 ds64 — ตารางขนาด 64 บิต

ต้องเป็น chunk แรกถัดจากลายเซ็น BW64 เพราะตัวอ่านจำเป็นต้องรู้ขนาดจริงก่อนจึงจะเดินสำรวจอย่างอื่นได้ ฟิลด์ของมันคือครึ่งบนและครึ่งล่างขนาด 32 บิตของค่า 64 บิต

ฟิลด์ table[] สำคัญกว่าที่หน้าตาบอก chunk ชื่อ axml ที่อธิบายวัตถุนับพันตัวพร้อมออโตเมชันระดับแซมเปิลสามารถโตจนเข้าใกล้หรือเกิน 4 GB ได้ด้วยตัวมันเอง และตารางนี้คือช่องทางเดียวที่ chunk อื่นนอกจาก data จะประกาศขนาดแบบ 64 บิตได้

3.2 fmt — คำอธิบายตัวเสียงจริง

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

3.3 chna — ตารางจัดสรรช่องสัญญาณ

chna คือสะพานระหว่างแทร็กจริงกับ ADM มันเริ่มด้วย

• ckID — 4 ไบต์ ค่า 'chna'
• ckSize — 4 ไบต์
• numTracks — 2 ไบต์ จำนวนแทร็กในไฟล์
• numUIDs — 2 ไบต์ จำนวนรายการ audioTrackUID ที่ตามมา

จากนั้นเป็นอาร์เรย์แบนของรายการ audioID ที่มีความกว้างตายตัว แต่ละรายการมีขนาด 40 ไบต์พอดี

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

ลองคิดขนาดจริงของ chunk นี้กับตัวอย่างโขน 28 แทร็กข้างบน ถ้าแต่ละแทร็กมี UID เดียว จำนวน numUIDs = 28 ขนาดของ chunk ทั้งก้อนคือ ส่วนหัว 8 ไบต์ (ckID + ckSize) บวกฟิลด์นับ 4 ไบต์ (numTracks + numUIDs) บวก 40 × 28 = 1,120 ไบต์ รวม 1,132 ไบต์ ซึ่งเล็กจนไม่มีนัยสำคัญเมื่อเทียบกับ data แต่ถ้าผิดไปแม้ไบต์เดียว ทั้งตารางหลังจุดนั้นจะอ่านไม่ออก

สิ่งสำคัญที่ต้องเข้าใจคือ ตำแหน่งของรายการที่ n คำนวณด้วยเลขคณิต ไม่ใช่ด้วยการค้นหา ตัวแยกวิเคราะห์อ่านรายการที่ n ที่ออฟเซ็ต 12 + 40 × (n − 1) นับจากต้น chunk นี่คือเหตุผลที่ความกว้างตายตัวเป็นเรื่องคอขาดบาดตาย ไม่มีตัวคั่น ไม่มีความยาวนำหน้า มีแต่ตารางที่ต้องลงล็อกพอดีทุกช่อง

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

track UID คือหมายเลขประจำตัวที่ไฟล์ออกให้กับตัวตนของแทร็กจริงหนึ่งแทร็ก และมันมีอยู่เพื่อให้แทร็กหนึ่งเปลี่ยนสิ่งที่มันบรรทุกกลางรายการได้อย่างถูกต้องตามกติกา

ประเด็นหลังนี่เองคือเหตุผลที่ 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 จะรายงานว่าไฟล์ที่ถูกต้องนั้นเสีย

ในบริบทไทย กรณีนี้เกิดจริงบ่อยกว่าที่คิด งานแสดงที่มีทั้งช่วงบรรเลงและช่วงขับร้องมักใช้แทร็กเดียวกันซ้ำ เช่น แทร็กที่ช่วงแรกเป็นเสียงปี่ในซึ่งเป็นวัตถุที่ตำแหน่งคงที่ข้างเวที แล้วช่วงหลังกลายเป็นเสียงผู้ขับร้องที่เดินไปมา สองบทบาทนี้เป็นคนละนิยาม จึงต้องเป็นคนละ UID บนแทร็กเดียวกัน

3.4 axml — ตัว ADM เอง

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

3.5 data — PCM อินเทอร์ลีฟ

แซมเปิลอินเทอร์ลีฟธรรมดา เหมือนใน WAV ทุกประการ ไม่มีอะไรใน data ที่รู้เรื่องวัตถุเลยแม้แต่น้อย

3.6 ลำดับของ chunk

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

4. ตัวอักษรไทยใน ADM: ที่ไหนใส่ได้ ที่ไหนใส่ไม่ได้

นี่คือหัวข้อที่คนทำงานภาษาไทยต้องอ่านให้จบ เพราะมันเป็นจุดที่เครื่องมือฝั่งตะวันตกไม่เคยถูกทดสอบ

กฎมีอยู่สองข้อและมันขัดกันในความรู้สึกของผู้ใช้:

1. ฟิลด์ชื่อใน axml รับตัวอักษรไทยได้เต็มที่ axml เป็น XML ที่เข้ารหัส UTF-8 ดังนั้นแอตทริบิวต์อย่าง audioProgrammeName audioContentName audioObjectName และ audioChannelFormatName ใส่คำว่า ระนาดเอก หรือ ฆ้องวงใหญ่ ได้อย่างถูกต้องสมบูรณ์ ไม่ต้องถอดเป็นอักษรโรมัน ไม่ต้องใช้ entity reference นี่คือที่ที่ชื่อภาษาไทยควรอยู่
2. ฟิลด์รหัสใน chna รับตัวอักษรไทยไม่ได้เด็ดขาด ฟิลด์ UID trackRef และ packRef เป็น ASCII ความกว้างตายตัว รูปแบบของมันถูกกำหนดมาแล้วว่าเป็น ATU_ AT_ AP_ ตามด้วยเลขฐานสิบหก ไม่มีช่องว่างให้ชื่อที่มนุษย์อ่านรู้เรื่องเลย ไม่ว่าภาษาใด

เหตุผลเชิงเลขคณิตชัดเจนมาก อักษรไทยทุกตัวอยู่ในช่วง U+0E00 ถึง U+0E7F ซึ่งอยู่ในช่วง U+0800–U+FFFF ของ UTF-8 จึงกินพื้นที่ 3 ไบต์ต่อหนึ่งจุดรหัส (code point) เสมอ และเครื่องหมายประกอบ — สระบน สระล่าง และวรรณยุกต์ — เป็นจุดรหัสแยกต่างหาก จึงกิน 3 ไบต์เพิ่มอีกตัวละ 3 ไบต์ ไม่ใช่ของแถมฟรี

ลองนับจริงกับชื่อเครื่องดนตรีในวงปี่พาทย์:

สังเกตสองบรรทัดที่บอกอะไรมากที่สุด

คำว่า ฆ้อง ตาเห็นเป็นสามช่อง — ฆ ที่มีไม้โทอยู่ข้างบน แล้ว อ แล้ว ง — แต่เป็นสี่จุดรหัส (ฆ U+0E06, ้ U+0E49, อ U+0E2D, ง U+0E07) และเป็น 12 ไบต์พอดีเป๊ะ กินฟิลด์ UID ทั้งฟิลด์โดยไม่เหลือที่ให้อะไรอีกเลย นี่คือกับดักที่แย่ที่สุดเท่าที่จะเป็นไปได้ เพราะเครื่องมือที่ตรวจความยาวแบบหยาบ ๆ ด้วยการนับไบต์จะบอกว่า "ผ่าน" ทั้งที่ค่าที่ได้ไม่ใช่ audioTrackUID ที่ถูกรูปแบบเลยแม้แต่น้อย

ส่วนคำว่า ฆ้องวงใหญ่ ซึ่งตาเห็นเป็นเจ็ดช่อง กลับเป็นสิบจุดรหัสและ 30 ไบต์ เพราะมีทั้งไม้โทบน ฆ และไม้เอกบน ญ เป็นจุดรหัสของมันเอง ถ้ามีคนเขียนค่านี้ลงในฟิลด์ UID ที่กว้าง 12 ไบต์ มันจะล้นออกไป 18 ไบต์

ผลของการล้นคืออะไร ไม่ใช่ข้อความแสดงข้อผิดพลาดที่อ่านง่าย แต่คือการที่ทั้งตารางเลื่อนออกจากตำแหน่ง ถ้ารายการที่หนึ่งควรกว้าง 40 ไบต์แต่กลายเป็น 58 ไบต์ ตัวแยกวิเคราะห์ที่คำนวณตำแหน่งของรายการที่สองจากสูตร 12 + 40 × (2 − 1) = ออฟเซ็ต 52 จะเริ่มอ่านรายการที่สองจากกลางฟิลด์ packRef ของรายการที่หนึ่ง ตั้งแต่จุดนั้นเป็นต้นไป ทุกรายการในตารางจะเป็นขยะ และเนื่องจากฟิลด์เหล่านี้ไม่มีรหัสตรวจสอบและไม่มีตัวคั่น จึงไม่มีทางที่ตัวอ่านจะรู้ตัวว่ามันหลุดกริดไปแล้ว ผลลัพธ์ที่พบจริงคือ ไฟล์ที่เปิดได้ อ่าน numTracks ได้ถูก แต่ทุก UID หลังรายการแรกเป็นการอ้างอิงลอยทั้งหมด

วิธีทำที่ถูกต้อง คือแยกสองเรื่องนี้ออกจากกันให้เด็ดขาด รหัสอยู่ใน chna ชื่ออยู่ใน axml และเชื่อมกันด้วยรหัส ตัวอย่างเช่น แทร็กที่หนึ่งของมาสเตอร์วงปี่พาทย์:

• ใน chna: trackIndex = 1, UID = ATU_00000001, trackRef = AT_00031001_01, packRef = AP_00031001
• ใน axml: <audioObject audioObjectID="AO_1001" audioObjectName="ระนาดเอก"> และ <audioChannelFormat audioChannelFormatName="ระนาดเอก" typeLabel="0003">

ค่า ATU_00000001 มี 12 ตัวอักษร ASCII พอดี AT_00031001_01 มี 14 ตัวอักษรพอดี AP_00031001 มี 11 ตัวอักษรพอดี ทุกฟิลด์ลงล็อก ส่วนชื่อไทยอยู่ใน XML ที่รับ UTF-8 ได้ไม่จำกัดความยาว

มีข้อควรระวังเพิ่มอีกสองข้อสำหรับข้อความไทยใน axml

การเรียงลำดับของเครื่องหมายประกอบ คำไทยที่ตาเห็นเหมือนกันอาจเข้ารหัสต่างกันได้ถ้าลำดับของสระกับวรรณยุกต์สลับกัน เช่น พยัญชนะ + สระ + วรรณยุกต์ กับ พยัญชนะ + วรรณยุกต์ + สระ อาจแสดงผลคล้ายกันในบางฟอนต์แต่เป็นสายอักขระคนละสาย การเปรียบเทียบชื่อแบบไบต์ต่อไบต์ระหว่างไฟล์ ADM กับใบส่งงานจะไม่ตรงกัน ทางแก้คือทำ Unicode normalization เป็น NFC ทั้งระบบก่อนเขียนไฟล์ แล้วใช้รูปแบบเดียวกันทุกที่

ช่องว่างและวรรคตอน ภาษาไทยไม่เว้นวรรคระหว่างคำ ตัวตัดคำอัตโนมัติในเครื่องมือฝั่งตะวันตกจึงมักตัดชื่อไทยผิดที่หรือไม่ตัดเลย นี่ไม่กระทบความถูกต้องของไฟล์ แต่กระทบการแสดงผลในรายงาน QC และในระบบปลายทาง ถ้าจำเป็นต้องให้ตัดบรรทัดสวย ให้ใส่ช่องว่างจริงระหว่างคำในฟิลด์ชื่อแทนการหวังพึ่งตัวตัดคำ

5. โมเดลวัตถุของ ADM

ITU-R BS.2076 แบ่งแบบจำลองออกเป็นสองซีก ซีก format นั้น "describes the technical nature of the audio so it can be decoded or rendered correctly" และเขียนล่วงหน้าได้ก่อนที่จะมีเสียงจริงด้วยซ้ำ ส่วนซีก content อธิบาย "the language of dialogue, the loudness, etc." และจะสมบูรณ์ได้ก็ต่อเมื่อมีสัญญาณจริงแล้ว การรู้ว่าองค์ประกอบหนึ่งอยู่ซีกไหนช่วยบอกว่าข้อผิดพลาดนั้นเกิดขึ้นในขั้นตอนใดของการผลิต

ลำดับชั้นจากบนลงล่าง:

• audioProgramme — งานที่ส่งมอบทั้งชุดหนึ่งชุด อ้างถึง audioContent หนึ่งรายการขึ้นไป
• audioContent — องค์ประกอบของรายการที่มีความหมายเชิงบรรณาธิการ เช่น สเต็มบทพูด สเต็มดนตรี หรือเวอร์ชันภาษาหนึ่ง อ้างถึง audioObject หนึ่งรายการขึ้นไป
• audioObject — จุดเชื่อมระหว่างเจตนาเชิงบรรณาธิการกับรูปแบบทางเทคนิค มันถือเวลาเริ่มและระยะเวลา และอ้างถึง audioPackFormat ศูนย์รายการขึ้นไป audioObject ซ้อนศูนย์รายการขึ้นไป และ audioTrackUID ศูนย์รายการขึ้นไป นี่คือจุดที่เนื้อหาพบกับตัวเสียง
• audioPackFormat — กลุ่มของช่องที่อยู่ด้วยกัน เช่น เบด 7.1.4 คู่สเตอริโอ หรือชุด HOA อันดับหนึ่ง อ้างถึง audioChannelFormat และซ้อนแพ็กอื่นได้
• audioChannelFormat — พฤติกรรมของหนึ่งช่องตลอดเวลา บรรจุ audioBlockFormat หนึ่งบล็อกขึ้นไป
• audioBlockFormat — หน่วยเล็กที่สุด สำหรับชนิด Objects จะมีตำแหน่ง (azimuth/elevation/distance หรือแบบคาร์ทีเซียน X/Y/Z) เกน ขนาด ความฟุ้ง พร้อม rtime และ duration วัตถุนิ่งมีบล็อกเดียว วัตถุที่เคลื่อนมีลำดับบล็อก
• audioTrackUID — ใบสุดท้ายของต้นไม้ และเป็นองค์ประกอบเดียวที่ตรงกับแทร็กจริงบนดิสก์ มีแอตทริบิวต์ sampleRate และ bitDepth เป็นทางเลือก และอ้างถึง audioTrackFormat กับ audioPackFormat

audioStreamFormat และ audioTrackFormat อยู่ระหว่าง channel format กับ track UID และอธิบายการเข้ารหัสสตรีม BS.2076-3 ระบุว่าสำหรับ PCM นั้นสององค์ประกอบนี้แทบไม่มีความหมาย — "the audioStreamFormat and the audioTrackFormat should be omitted" — แต่ตัวอ่าน "should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" องค์ประกอบเหล่านั้น ทั้งสองรูปแบบจึงถูกกติกา ตัวตรวจสอบที่ยืนกรานว่าต้องเป็นแบบใดแบบหนึ่งคือตัวตรวจสอบที่ผิดกับอีกแบบ

ADM คือกราฟของการอ้างอิง ไม่ใช่เอกสารซ้อนชั้น และความล้มเหลวร้ายแรงทุกครั้งในการส่งมอบคือเส้นเชื่อมที่ขาดในกราฟนั้น

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

6. การเรนเดอร์: จากวัตถุไปสู่ลำโพงจริง

ข้อแนะนำ ITU-R BS.2127 นิยามตัวเรนเดอร์ ADM อ้างอิงสำหรับระบบเสียงขั้นสูง มันคือคำตอบของคำถามว่า "วัตถุที่ตำแหน่ง azimuth −30 องศา elevation +20 องศา จะออกจากลำโพงตัวไหนบ้างและดังเท่าไร" เมื่อการจัดวางลำโพงจริงคือระบบใดระบบหนึ่งใน BS.2051 ญาติโอเพนซอร์สของมันคือ EBU ADM Renderer (EBU Tech 3388) ซึ่งเป็นวิธีที่ปฏิบัติได้จริงที่สุดในการได้ผลลัพธ์ที่ทำซ้ำได้

ประเด็นสำคัญที่คนมักพลาด: ไฟล์ ADM ไม่มีเสียงอิมเมอร์ซีฟอยู่ในตัวมัน มันมีวัตถุกับคำสั่ง เสียงอิมเมอร์ซีฟเกิดขึ้นตอนเรนเดอร์ และเปลี่ยนไปตามการจัดวางเป้าหมาย มาสเตอร์เดียวกันที่เรนเดอร์ลงระบบ B (0+5+0) กับระบบ J (4+7+0) ไม่ได้ให้ผลต่างกันแค่ "มีเสียงด้านบนเพิ่ม" — การกระจายพลังงานของวัตถุทุกตัวเปลี่ยนไปหมด เพราะอัลกอริทึมแพนต้องหาชุดลำโพงที่ล้อมรอบทิศทางเป้าหมายจากชุดลำโพงที่มีอยู่จริง

สำหรับกรณีฆ้องวงที่พูดถึงในหัวข้อ 1 นี่มีผลจับต้องได้ ถ้าคุณเขียนฆ้องวงเป็นวัตถุหลายตัวเรียงเป็นส่วนโค้ง เมื่อเรนเดอร์ลงระบบที่มีลำโพงหนาแน่น ส่วนโค้งจะยังคงเป็นส่วนโค้ง แต่เมื่อเรนเดอร์ลงระบบ 0+5+0 วัตถุหลายตัวที่อยู่ใกล้กันในเชิงมุมจะถูกยุบรวมไปที่ลำโพงคู่เดียวกัน และความรู้สึกว่าเสียงล้อมรอบผู้บรรเลงจะหายไปเกือบหมด นี่ไม่ใช่ข้อผิดพลาด มันคือพฤติกรรมที่ถูกต้องของการเรนเดอร์ลงระบบที่มีความละเอียดเชิงพื้นที่น้อยกว่า แต่มันหมายความว่าคุณต้องตรวจฟังผลบนการจัดวางที่ปลายทางจะใช้จริง ไม่ใช่บนการจัดวางที่คุณเขียนงานมา

7. ความดัง (loudness) ของเนื้อหาอิมเมอร์ซีฟ

ตรงนี้ต้องแยกให้ชัดระหว่างสิ่งที่ เผยแพร่เป็นข้อกำหนดแล้ว กับสิ่งที่ เล่ากันต่อ ๆ มา

7.1 สิ่งที่ ITU-R BS.1770 กำหนดไว้จริง

ฉบับที่บังคับใช้อยู่ปัจจุบันคือ BS.1770-5 (พฤศจิกายน 2023) ฉบับ BS.1770-4 (ตุลาคม 2015) ถูกแทนที่ไปแล้ว แม้ว่ามันจะยังเป็นฉบับที่มิเตอร์ส่วนใหญ่ที่ติดตั้งใช้งานอยู่อ้างถึงก็ตาม เวลาระบุมาตรฐานในใบส่งงาน ให้ระบุ -5 เสมอ

กลไกที่ควรรู้:

• K-weighting เป็นฟิลเตอร์สองขั้น: ฟิลเตอร์ไฮเชลฟ์ (เรียกว่า "head" filter ซึ่งจำลองทรงกลมแข็ง) ตามด้วยไฮพาส RLB
• เกนของเส้นโค้ง K-weighting ที่ 1 kHz คือ +0.698 dB (เชิงเส้น 1.0836)
• การวัดใช้บล็อกขนาด 400 มิลลิวินาที ซ้อนทับกัน 75%
• เกตสัมบูรณ์: ทิ้งบล็อกที่ต่ำกว่า −70 LUFS
• เกตสัมพัทธ์: คำนวณจากค่าเฉลี่ยของบล็อกที่ รอดจากเกตสัมบูรณ์ แล้วเลื่อนลง −10 LU มันไม่ใช่ค่าเฉลี่ยแบบไม่ผ่านเกต ความต่างข้อนี้สำคัญ และถูกเขียนผิดบ่อยมาก
• ความดังระยะสั้น (short-term) ใช้หน้าต่าง 3 วินาที และ ความดังชั่วขณะ (momentary) ใช้ 400 มิลลิวินาที ตาม EBU Tech 3341
• Loudness Range (LRA) ตาม EBU Tech 3342 ใช้เกตสัมพัทธ์ที่ −20 LU ไม่ใช่ −10 LU การใช้ −10 กับ LRA เป็นบั๊กที่พบบ่อยในการนำไปใช้จริง
• True peak วัดบนสัญญาณที่ผ่านการโอเวอร์แซมเปิล (อย่างน้อย 4 เท่าตาม BS.1770 และ 8 เท่าจะดีกว่า) ค่าพีคของแซมเปิลไม่เท่ากับ true peak — พีคระหว่างแซมเปิลเกินค่าแซมเปิลที่สูงที่สุดได้

น้ำหนักช่องในอัลกอริทึมแกนกลางคือ 1.0 (0 dB) สำหรับ L, R และ C และ 1.41 (ประมาณ +1.5 dB) สำหรับ Ls และ Rs โดยไม่นับ LFE อัลกอริทึมพื้นฐานมีขอบเขต "from one to five channels" ส่วน BS.1770-5 ขยายเกินขอบเขตนี้ในภาคผนวก ครอบคลุมระบบเสียงขั้นสูงของ BS.2051 — ลำโพงที่วางในตำแหน่งอิสระและช่องความสูง — และเสียงแบบวัตถุ ซึ่ง ต้องถูกเรนเดอร์ก่อนจึงจะวัดได้

ความดังของงานอิมเมอร์ซีฟไม่ใช่คุณสมบัติของไฟล์ แต่เป็นคุณสมบัติของการเรนเดอร์ครั้งหนึ่ง และการเปลี่ยนการจัดวางเป้าหมายทำให้ตัวเลขเปลี่ยน

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

7.2 สิ่งที่เผยแพร่แล้วสำหรับดนตรี

สำหรับดนตรีสเตอริโอแบบช่องสัญญาณ Spotify เผยแพร่เป้าหมายความดังรวมที่ −14 LUFS และเพดาน true peak ที่ −1 dBTP โดยรัดขึ้นเป็น −2 dBTP ถ้ามาสเตอร์ดังกว่า −14 LUFS (ที่มา: support.spotify.com) เอกสาร AES TD1008 แนะนำ −16 LUFS สำหรับดนตรี ส่วนตัวเลข −18 LUFS ในเอกสารเดียวกันนั้นใช้กับเนื้อหาที่นำด้วยเสียงพูด เช่น ข่าว รายการสนทนา และละคร การอ้าง −18 ว่าเป็นเป้าหมายสำหรับดนตรีเป็นความผิดพลาดที่พบบ่อยและร้ายแรง ส่วน EBU R 128 กำหนดเป้าหมายรายการสำหรับงานกระจายเสียงที่ −23 LUFS ซึ่งเป็นแนวปฏิบัติของงานกระจายเสียง ไม่ใช่ข้อกำหนดของบริการสตรีมมิงเพลง

Spotify ยังระบุด้วยว่า "Positive gain is applied to softer masters so the loudness level is -14 dB LUFS" แต่ในขณะเดียวกันก็ระบุว่า "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality." กล่าวคือ มาสเตอร์ที่เบาแต่มีพีคสูงอาจ ไม่ ถูกดันขึ้นจนถึงเป้าหมาย ดังนั้นอย่าเขียนว่า "มาสเตอร์ที่เบาจะไม่ถูกดันขึ้น" เพราะผิด และอย่าเขียนว่า "มาสเตอร์ที่เบาจะถูกดันขึ้นถึงเป้าหมายเสมอ" เพราะก็ผิดเช่นกัน

7.3 สิ่งที่ยังไม่มีใครเผยแพร่

ไม่มีบริการสตรีมมิงเพลงรายใดเผยแพร่เป้าหมายความดังรวมสำหรับการส่งมอบงานอิมเมอร์ซีฟ ตัวเลขต่าง ๆ ลอยอยู่ในเว็บบอร์ดและในเอกสารฝึกอบรมของผู้ขายซอฟต์แวร์ บางตัวฟังดูสมเหตุสมผลและบางตัวก็อาจถูกด้วยซ้ำ แต่ไม่มีตัวไหนเป็นข้อกำหนดที่เผยแพร่แล้ว เอกสารนี้จะไม่ทำซ้ำตัวเลขเหล่านั้นราวกับว่ามันเป็นข้อกำหนด

ในทำนองเดียวกัน สำหรับสเตอริโอ Apple Music, YouTube Music, Amazon Music, TIDAL และ Deezer ไม่ได้เผยแพร่เป้าหมายการปรับความดังใด ๆ

บล็อกที่ต้องระบุกำกับ: เล่ากันแพร่หลาย แต่บริการไม่ได้เผยแพร่ ตัวเลขที่มักถูกอ้างถึงคือ Apple ประมาณ −16, YouTube Music ประมาณ −14, Amazon ประมาณ −14, TIDAL ประมาณ −14 และ Deezer ประมาณ −15 ตัวเลขเหล่านี้ ไม่ใช่ข้อกำหนดที่บริการเหล่านั้นเผยแพร่ ห้ามใช้คำนวณค่าเกนที่จะถูกปรับ และห้ามอ้างเป็นสเปกในใบส่งงาน

ถ้าคุณต้องการตัวเลขความดังของงานอิมเมอร์ซีฟที่ปกป้องได้ในวันนี้ วิธีเดียวคือ วัดการเรนเดอร์ที่เป็นไปตาม BS.2127 ลงการจัดวางตาม BS.2051 ที่ระบุชื่อชัดเจน ด้วยมิเตอร์ที่เป็นไปตาม BS.1770-5 แล้วบันทึกทั้งสามอย่างไว้ในใบส่งงาน

7.4 เรื่องระบบเชิงพาณิชย์

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

8. ข้อผิดพลาด QC ที่พบบ่อย และวิธีตรวจจับแต่ละข้อ

8.1 จำนวนช่องใน fmt ไม่ตรงกับ chna

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

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

8.2 track UID กำพร้า

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

8.3 บล็อกฟอร์แมตที่ขาดเวลาหรือเวลาไม่เดินหน้า

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 ไม่มีบล็อกใดสั้นกว่าหนึ่งแซมเปิล และผลรวมของระยะเวลาต้องตรงกับ audioObject แม่

วิธีตรวจ: สำหรับ audioChannelFormat แต่ละตัว เดินไล่บล็อกตามลำดับในเอกสารแล้วยืนยันว่า rtime[n] + duration[n] == rtime[n+1] ความล้มเหลวมักตกอยู่ในสามรูปแบบ: ช่องว่าง (พฤติกรรมของเรนเดอร์ไม่นิยาม บางตัวค้างตำแหน่งเดิม บางตัวปิดเสียง) การซ้อนทับ (บล็อกแย่งกัน) และบล็อกที่เรียงผิดลำดับเวลา (ออโตเมชันที่กระโดดถอยหลังกลางรายการ)

ในงานที่มีการเคลื่อนที่มาก เช่น ผู้แสดงโขนหรือขบวนแห่ ความหนาแน่นของบล็อกจะสูงและโอกาสเจอปัญหานี้ก็สูงตาม โดยเฉพาะเมื่อมีการตัดต่อหรือย้ายคลิปหลังจากเขียนออโตเมชันแล้ว

8.4 อัตราแซมเปิลหรือความลึกบิตไม่ตรง

audioTrackUID อาจมีแอตทริบิวต์ sampleRate และ bitDepth เมื่อค่าเหล่านี้ขัดกับ fmt คุณมีคำกล่าวอ้างสองอย่างเกี่ยวกับตัวเสียงเดียวกัน จุดยืนของ EBU Tech 3392 คือค่าเหล่านี้ "Should be ignored if available from the audio essence" — แต่ไม่ใช่ทุกเรนเดอร์ที่ทำตามคำแนะนำนั้น และไฟล์ที่บอกว่า 48000 ตรงหนึ่งและ 96000 อีกตรงหนึ่งจะถูกตีความต่างกันโดยเครื่องมือต่างตัว

แยกกันอีกเรื่อง: ให้ยืนยันว่าอัตราแซมเปิลตรงกับที่ข้อกำหนดการส่งมอบขอ การแปลงอัตราแซมเปิลหลังจากเขียน ADM แล้วทำให้ rtime และ duration ทุกค่าที่แสดงเป็นจำนวนแซมเปิลใช้ไม่ได้ทั้งหมด

วิธีตรวจ: เทียบ fmt กับแอตทริบิวต์ sampleRate/bitDepth ทุกตัวใน XML แล้วรายงานทุกความไม่ตรงกันแม้ในทางทฤษฎีจะยอมรับได้

8.5 ไฟล์สเตอริโอหรือไบนอรัลประกอบขาดหาย หรือไม่ตรงเวลา

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

วิธีตรวจ: เทียบระยะเวลาระดับแซมเปิล เทียบไทม์โค้ดเริ่มต้นจาก bext และทำสหสัมพันธ์ไขว้ระหว่างไฟล์ประกอบกับการเรนเดอร์ของมาสเตอร์ ถ้าไฟล์ประกอบใดไม่สามารถสร้างซ้ำได้จากมาสเตอร์ปัจจุบัน ให้ถือว่าน่าสงสัยและเรนเดอร์ใหม่ อย่าเสียเวลาตรวจซ้ำ

8.6 เมทาดาทาบรรยายเบดที่ไม่มีอยู่ในไฟล์

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

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

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

คอนเทนเนอร์ถูกต้องสมบูรณ์ได้ XML สมบูรณ์รูปแบบได้ และงานที่ส่งก็ยังผิดได้ การตรวจช่องเบดที่ว่างมีวิธีเดียวคือไปดูแซมเปิล

เครื่องมือตรวจ BW64/ADM แบบใช้งานผ่านเบราว์เซอร์ที่ mazufa.com แยกวิเคราะห์ทั้งคอนเทนเนอร์และเมทาดาทาบนเครื่องของคุณเองทั้งหมดโดยไม่อัปโหลดอะไรเลย ซึ่งทำให้ใช้กับวัสดุที่ตามสัญญาแล้วออกจากสถานที่ไม่ได้

9. ความจริงเรื่องห้องอัดในประเทศไทย

ต้องพูดกันตรง ๆ: ห้องอัดและห้องมิกซ์ในประเทศไทยแทบไม่มีระบบมอนิเตอร์อิมเมอร์ซีฟ ห้องที่ติดตั้งลำโพงตามการจัดวางของ BS.2051 อย่างครบถ้วนและผ่านการปรับแต่งเชิงอะคูสติกอย่างถูกต้องมีอยู่น้อยมาก และส่วนใหญ่ผูกกับงานภาพยนตร์หรืองานโฆษณา ไม่ใช่งานดนตรี วิศวกรเสียงชาวไทยส่วนใหญ่ที่ต้องส่งงานอิมเมอร์ซีฟจึงทำงานในสภาพที่ ตรวจฟังผลลัพธ์จริงไม่ได้

ข้อเท็จจริงนี้เปลี่ยนคำถามที่เอกสารฉบับนี้ควรตอบ ถ้าคุณตรวจฟังไม่ได้ สิ่งที่คุณควบคุมได้คืออะไร คำตอบคือสามอย่าง และทั้งสามอย่างเป็นเรื่องที่ตรวจสอบได้ด้วยเครื่อง

หนึ่ง: ความถูกต้องของโครงสร้างไฟล์ ทุกข้อในหัวข้อ 8 ตรวจได้โดยไม่ต้องฟังอะไรเลย จำนวนช่องตรงกันไหม UID กำพร้าไหม เวลาของบล็อกต่อเนื่องไหม การอ้างอิงลอยไหม นี่คือส่วนที่ห้องมิกซ์ราคาหลายล้านไม่ได้ช่วยอะไรเลย และคนที่นั่งอยู่หน้าจอในห้องเล็ก ๆ ทำได้ดีเท่ากันทุกประการ

สอง: ความถูกต้องของเมทาดาทาเชิงความหมาย ชื่อวัตถุถูกต้องและสะกดถูกไหม ชื่อไทยอยู่ใน axml ไม่ใช่ chna ใช่ไหม การแบ่ง audioContent สะท้อนสเต็มจริงไหม typeLabel ของแต่ละ audioChannelFormat ตรงกับ audioPackFormat แม่ไหม เรื่องเหล่านี้เป็นงานอ่านและงานคิด ไม่ใช่งานฟัง

สาม: การตรวจฟังแบบไบนอรัล ที่รู้ข้อจำกัดของมัน การเรนเดอร์เป็นไบนอรัลด้วยตัวเรนเดอร์ที่เป็นไปตาม BS.2127 แล้วฟังผ่านหูฟังไม่ได้ทดแทนห้องที่ติดตั้งลำโพงจริง มันไม่บอกคุณว่าโทนเสียงจะเป็นอย่างไรบนระบบจริง และการรับรู้ความสูงผ่าน HRTF ทั่วไปนั้นแปรผันตามคนฟังอย่างมาก แต่มันบอกคุณได้แน่นอนหลายอย่าง: วัตถุอยู่ผิดข้างไหม ออโตเมชันกระโดดผิดที่ไหม (นั่นคือกับดัก azimuth วนรอบในหัวข้อ 1.1) วัตถุที่ควรอยู่นิ่งขยับไหม สเต็มไหนหายไปทั้งสเต็มไหม ข้อผิดพลาดระดับ "ผิดชัด ๆ" จับได้ครบด้วยหูฟัง ส่วนข้อผิดพลาดระดับ "โทนไม่ถูกใจ" จับไม่ได้ — และในสถานการณ์ที่ตรวจฟังไม่ได้จริง การจับให้ครบแค่ระดับแรกก็เป็นเป้าหมายที่สมเหตุสมผลและซื่อสัตย์

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

10. เช็กลิสต์การส่งมอบ

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

คอนเทนเนอร์

1. สี่ไบต์แรกคือ BW64 ถ้าเป็น RIFF แสดงว่าเป็น WAV ธรรมดาและเกิน 4 GB ไม่ได้
2. ds64 เป็น chunk แรกถัดจากลายเซ็น และขนาด 64 บิตของมันตรงกับขนาดไฟล์จริงและขนาด data จริงบนดิสก์
3. chunk ที่ไม่ใช่ data ที่ใหญ่เกิน 4 GB มีรายการ ChunkSize64 อยู่ในตารางของ ds64
4. ค้นหา axml อย่างชัดเจน รวมถึงตำแหน่งหลัง data อย่าสรุปว่า "ไม่มี ADM" จากการสแกนบางส่วน

ตัวเสียง

1. อัตราแซมเปิลและความลึกบิตใน fmt ตรงกับข้อกำหนดการส่งมอบเป๊ะ ไม่มีการแปลงอัตราแซมเปิลหลังเขียน ADM
2. fmt.nChannels เท่ากับ chna.numTracks
3. trackIndex ทุกค่าใน chna อยู่ในช่วงและเริ่มนับจาก 1

ความสมบูรณ์ของ chna

1. ทุกรายการมีขนาด 40 ไบต์พอดี ฟิลด์ความกว้างตายตัวเติมช่องว่างถูกต้อง
2. packRef ทุกค่าที่ 0x1000 ขึ้นไปแก้ไปหานิยามที่สร้างเองซึ่งมีอยู่จริงใน axml
3. trackIndex ที่ซ้ำกันเป็นความตั้งใจ (แทร็กเปลี่ยนนิยามอย่างถูกกติกา) ไม่ใช่ข้อผิดพลาดจากการทำซ้ำ
4. ไม่มีอักขระที่ไม่ใช่ ASCII อยู่ในฟิลด์ UID trackRef หรือ packRef แม้แต่ตัวเดียว ตรวจโดยยืนยันว่าทุกไบต์ในทั้งสามฟิลด์มีค่าน้อยกว่า 0x80

กราฟ ADM

1. audioContentIDRef audioObjectIDRef audioPackFormatIDRef audioChannelFormatIDRef และ audioTrackUIDRef ทุกค่าแก้ได้ ไม่มีเส้นเชื่อมลอยแม้แต่เส้นเดียว
2. ไม่มี audioTrackUID กำพร้าทั้งสองทิศทาง
3. ไม่มีองค์ประกอบที่อ้างวนหรืออ้างตัวเอง
4. typeLabel ของ audioChannelFormat แต่ละตัวตรงกับ audioPackFormat แม่
5. ชื่อภาษาไทยผ่าน Unicode normalization เป็น NFC แล้ว และเหมือนกันทุกตัวอักษรกับที่ระบุในใบส่งงาน

เวลา

1. channel format ที่มีหลายบล็อกมีทั้ง rtime และ duration ครบทุกบล็อก
2. บล็อกต่อเนื่องและเดินหน้าอย่างเดียว ผลรวมของระยะเวลาตรงกับระยะเวลาของ audioObject แม่
3. วัตถุเริ่มที่ 00:00:00.00000
4. ค่า azimuth ที่เคลื่อนผ่านด้านหลังผู้ฟังจัดการการวนรอบ ±180 องศาอย่างถูกต้อง

เนื้อหา

1. ทุกช่องของเบดที่ประกาศไว้มีสิ่งที่ควรมี ตรวจสอบความเงียบดิจิทัลทุกครั้ง
2. จำนวนวัตถุและการตั้งค่าเบดตรงกับข้อกำหนดการส่งมอบ
3. ไทม์โค้ดเริ่มต้นใน bext ถูกต้องและตรงกันทุกไฟล์ในชุดที่ส่ง

การเรนเดอร์และไฟล์ประกอบ

1. ไฟล์สเตอริโอและไบนอรัลถูกเรนเดอร์ใหม่จากมาสเตอร์ ปัจจุบัน ไม่ใช่ยกมาจากรอบก่อน
2. ระยะเวลาและไทม์โค้ดเริ่มต้นตรงกับมาสเตอร์ระดับแซมเปิล
3. วัดความดังบนการเรนเดอร์ที่ระบุชื่อ ลงการจัดวางที่ระบุชื่อ ด้วยตัวเรนเดอร์ที่ระบุชื่อ และบันทึกทั้งสามอย่างในใบส่งงาน

ความสามารถในการทำซ้ำ

1. ทำเช็กซัมทุกไฟล์ที่ส่งและเก็บรายการไว้
2. เก็บเซสชันและ ADM XML แยกจาก BW64 ไฟล์ XML ที่คุณ diff ได้มีค่ามากกว่าไฟล์ไบนารีที่คุณทำได้แค่แยกวิเคราะห์ใหม่

งานอิมเมอร์ซีฟไม่ได้เสร็จเมื่อฟังแล้วดี มันเสร็จเมื่อเครื่องที่ไม่เคยได้ยินมันเลยพิสูจน์ได้ว่าการอ้างอิงทุกเส้นแก้ได้

11. ปิดท้าย

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

การจัดจำหน่ายของ Mazufa ไม่มีค่าใช้จ่าย — ไม่มีค่าอัปโหลด ไม่มีค่าสมาชิกรายเดือน ไม่มีค่าธรรมเนียมต่อผลงาน — หักเพียง 5% จากค่าลิขสิทธิ์ที่ได้รับ และใบสมัครที่สมบูรณ์ทุกใบผ่านการพิจารณาโดยมนุษย์

แหล่งอ้างอิง

ข้อแนะนำของ 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
• หน้าหลักของ ITU-R BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

เอกสารทางเทคนิคของ 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/docs/tech/tech3388.pdf และ 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 (มิเตอร์), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• 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
• เอกสารของ EBU ADM Renderer (EAR), ส่วน BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 การนำไปใช้อ้างอิง — https://github.com/ebu/libbw64
• 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/

เอกสารของผู้ให้บริการ

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

Unicode

• Unicode Standard Annex #15, Unicode Normalization Forms — https://unicode.org/reports/tr15/
• Unicode Character Database, ช่วง Thai (U+0E00–U+0E7F) — https://www.unicode.org/charts/PDF/U0E00.pdf

ทบทวนล่าสุดเดือนกันยายน 2026 มาตรฐานมีการปรับปรุงแก้ไข ตรวจสอบหน้าเว็บของ ITU และ EBU ข้างต้นเพื่อยืนยันฉบับปัจจุบันเสมอก่อนอ้างอิงหมายเลขข้อ