ตัวแปลงสัญญาณเสียงที่ดีที่สุด และวิธีสร้างกระบวนการบีบอัดตามการรับรู้ที่ปลอดภัย

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

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

ควรเลือกตัวแปลงสัญญาณเสียงชนิดใด

ฟอร์แมต	ประเภทการบีบอัด	กรณีใช้งานที่เหมาะที่สุด	ข้อจำกัดสำคัญ
Opus	สูญเสียข้อมูล	เสียงพูด เพลง สตรีมมิง และเสียงที่ต้องการความหน่วงต่ำอย่างมีประสิทธิภาพ	ต้องตรวจสอบการรองรับคอนเทนเนอร์และอุปกรณ์ปลายทาง การเข้ารหัสใหม่อาจทำให้เมทาดาทาสูญหาย
AAC-LC	สูญเสียข้อมูล	รองรับอุปกรณ์หลากหลายและเข้ากันได้ดีกับ MP4	ประสิทธิภาพขึ้นอยู่กับตัวเข้ารหัสและอัตราบิต ส่วนรูปแบบอัตราบิตต่ำต้องประเมินแยกต่างหาก
MP3	สูญเสียข้อมูล	เครื่องเล่นรุ่นเก่า ไฟล์ดาวน์โหลดทั่วไป และสภาพแวดล้อมที่เน้นความเข้ากันได้ซึ่งเป็นที่ยอมรับมานาน	โดยทั่วไปมีประสิทธิภาพการบีบอัดต่ำกว่าตัวแปลงสัญญาณสมัยใหม่เมื่อเทียบที่คุณภาพเสียงที่ผู้ฟังรับรู้ใกล้เคียงกัน
FLAC	ไม่สูญเสียข้อมูล	การเก็บถาวร การส่งมอบมาสเตอร์ และการรักษาตัวอย่างเสียง PCM	ไฟล์ยังมีขนาดใหญ่กว่ารูปแบบเข้ารหัสตามการรับรู้อย่างชัดเจน และยังต้องจัดการเมทาดาทาอย่างระมัดระวัง
ALAC	ไม่สูญเสียข้อมูล	งานเสียงแบบไม่สูญเสียข้อมูลในกระบวนการทำงานที่เน้นระบบของ Apple	คอนเทนเนอร์ MP4 อาจมีโครงสร้างที่ไม่สามารถถ่ายทอดไปยังฟอร์แมตอื่นได้อย่างตรงไปตรงมา
WAV / PCM	โดยทั่วไปเป็น PCM ที่ไม่ได้บีบอัด	การตัดต่อ การแลกเปลี่ยนข้อมูล สัญญาณทดสอบ และการเข้าถึงตัวอย่างเสียงโดยตรง	ไฟล์มีขนาดใหญ่ และ WAV อาจมีส่วนข้อมูล RIFF ที่ไม่ใช่เสียงแต่มีความสำคัญ

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

ความแตกต่างระหว่างตัวแปลงสัญญาณ (codec) ตัวเข้ารหัส (encoder) และคอนเทนเนอร์ (container) เป็นเรื่องสำคัญ Opus คือตัวแปลงสัญญาณ ส่วน libopus เป็นชุดโปรแกรมเข้ารหัสที่ใช้กันแพร่หลาย ขณะที่ Ogg, WebM และการตั้งค่า MP4 ที่รองรับสามารถเป็นคอนเทนเนอร์ได้ โดยทั่วไป AAC จะอยู่ใน MP4/M4A นามสกุล .m4a เพียงอย่างเดียวไม่ได้บอกว่าเสียงภายในเป็น AAC หรือ ALAC แบบไม่สูญเสียข้อมูล ควรตรวจสอบสตรีมจริงแทนการอนุมานคุณภาพหรือการเข้ารหัสจากชื่อไฟล์ คู่มือตัวแปลงสัญญาณเสียงของ MDN อธิบายความแตกต่างระหว่างฟอร์แมตกับคอนเทนเนอร์ ส่วน RFC 6716 เป็นข้อกำหนดของ Opus

เหตุใดอัตราบิตเพียงอย่างเดียวจึงบอกคุณภาพเสียงไม่ได้

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

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

จุดเริ่มต้นที่มีประโยชน์สำหรับการทดลองคือประมาณ 128–192 kbit/s สำหรับเพลงสเตอริโอที่เข้ารหัสด้วย Opus และอัตราที่ต่ำกว่ามากสำหรับเสียงพูดโมโน โดยปรับตามเนื้อหาและข้อกำหนดการเล่นจริง ตัวเลขเหล่านี้เป็นพารามิเตอร์สำหรับค้นหาค่าที่เหมาะสม ไม่ใช่เกณฑ์ที่รับประกันว่าผู้ฟังจะแยกความต่างไม่ออก สำหรับสตรีมมิงอัตราบิตต่ำ เทคโนโลยีอย่าง xHE-AAC ก็ควรได้รับการประเมินเมื่อสภาพแวดล้อมสำหรับใช้งานรองรับ ตัวแปลงสัญญาณเสียงแบบโครงข่ายประสาทที่เกิดขึ้นใหม่อาจน่าสนใจสำหรับระบบเสียงพูดเฉพาะทางหรืองานวิจัย แต่บทความวิชาการหรือการสาธิตไม่ได้พิสูจน์ว่าสามารถนำมาแทนฟอร์แมตเผยแพร่เสียงที่รองรับอย่างแพร่หลายได้ทันที

ใช้ FFprobe ระบุข้อมูลต้นทาง และใช้ FFmpeg เข้ารหัสไฟล์ทดสอบ

เริ่มจากตรวจสอบสตรีมเสียงจริง อัตราการสุ่มตัวอย่าง จำนวนช่องสัญญาณ และระยะเวลา วิธีนี้ช่วยไม่ให้สันนิษฐานว่าคอนเทนเนอร์ทุกชนิดที่คล้าย MP4 มีเสียงอยู่ภายใน หรือไฟล์ทุกไฟล์ที่มีนามสกุลรู้จักกันดีจะถอดรหัสได้

ffprobe -v error -select_streams a -show_entries stream=codec_name,sample_rate,channels,channel_layout:format=duration -of json input.m4a

สำหรับไฟล์ WAV ที่มีโครงสร้างไม่ซับซ้อน มีสิทธิ์นำมาประมวลผล และทราบแน่ชัดว่าส่วนข้อมูลเพิ่มเติมสามารถทิ้งได้ คำสั่งต่อไปนี้เป็นตัวอย่างการเข้ารหัส Opus คุณภาพสูง:

ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a libopus -b:a 160k -vbr on -compression_level 10 -application audio output.opus

หากต้องการเผยแพร่ในรูปแบบที่เข้ากันได้กับ MP4 อย่างกว้างขวาง สามารถสร้างไฟล์ทดสอบ AAC-LC ด้วยตัวเข้ารหัส AAC ที่มากับ FFmpeg:

ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a aac -b:a 192k output.m4a

หากต้องการเสียงแบบไม่สูญเสียข้อมูล:

ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a flac -compression_level 8 output.flac

ทั้งหมดนี้เป็นเพียงตัวอย่างสำหรับไฟล์เดียว ไม่ใช่กระบวนการแปลงไฟล์เป็นชุดที่ปลอดภัย คำสั่งเหล่านี้ไม่ได้พิสูจน์ว่าฟิลด์เมทาดาทาทั้งหมด สตรีมเสริม จุดคิว หรือส่วนข้อมูลในคอนเทนเนอร์ยังอยู่ครบ สำหรับคำสั่งแบบไม่สูญเสียข้อมูล ควรตรวจสอบความเทียบเท่าของ PCM หลังถอดรหัสภายใต้รูปแบบการแสดงตัวอย่างเสียงเดียวกันก่อนยืนยันว่าการแปลงเสียงสามารถย้อนกลับได้ เอกสารตัวแปลงสัญญาณของ FFmpeg อธิบายการเข้ารหัสด้วย libopus รวมถึงตัวเลือก VBR และระดับความซับซ้อน ส่วนการเล่นเสียงในเบราว์เซอร์ต้องทดสอบคู่ของตัวแปลงสัญญาณกับคอนเทนเนอร์จริง ไม่ใช่ดูเฉพาะนามสกุลไฟล์

ค้นหาไฟล์ที่เล็กที่สุดโดยยังมีคุณภาพที่ยอมรับได้อย่างไร

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

บันทึกลายนิ้วมือ SHA-256 ของไฟล์ต้นทาง แล้วตรวจสอบสตรีมและโครงสร้างคอนเทนเนอร์
พิจารณาว่าอนุญาตให้เข้ารหัสแบบสูญเสียข้อมูลหรือไม่ โดยค่าเริ่มต้นให้คงไฟล์ที่สูญเสียข้อมูลอยู่แล้วและไฟล์ที่มีเมทาดาทาที่ไม่รองรับไว้ตามเดิม
เข้ารหัส Opus ด้วยค่าที่ค่อนข้างระมัดระวังเป็นไฟล์ทดสอบแรก แล้วทดลองอัตราบิตที่ต่ำลงบางค่าซึ่งเลือกไว้ แทนการลองทุกค่าที่เป็นไปได้อย่างไร้ทิศทาง
ถอดรหัสไฟล์ทดสอบแต่ละไฟล์ ตรวจว่ามีเสียงจริง ช่องสัญญาณที่ต้องการยังอยู่ ข้อมูลเวลาเป็นไปได้ และกระบวนการถอดรหัสจบโดยไม่มีข้อผิดพลาด
เปรียบเทียบเสียงอ้างอิงกับไฟล์ทดสอบโดยใช้ช่วงเสียงที่จัดแนวตรงกันและตัวชี้วัดคุณภาพตามการรับรู้ พร้อมตรวจสอบความสมบูรณ์ของสเตอริโอ เสียงขาดหาย การตัดยอดสัญญาณ และปัญหาอื่นที่ตัวชี้วัดอาจมองข้ามอย่างเป็นอิสระ
เลือกไฟล์ทดสอบที่เล็กที่สุดซึ่งผ่านนโยบายและช่วยประหยัดพื้นที่ได้อย่างมีนัยสำคัญ มิฉะนั้นให้เก็บต้นฉบับเหมือนเดิมทุกไบต์
ตรวจสอบว่าไฟล์ต้นทางไม่เปลี่ยนระหว่างประมวลผล และเผยแพร่ผลลัพธ์ต่อเมื่อข้อมูลทั้งหมดในพื้นที่พักผ่านการตรวจสอบแล้ว

เครื่องมือที่ใช้งานได้จริงควรบันทึก COMPRESSED, PRESERVED และ FAILED เป็นผลลัพธ์สามแบบที่แตกต่างกัน การคงไฟล์เดิมอาจเป็นการตัดสินใจปรับแต่งที่ถูกต้อง ไม่ใช่ข้อผิดพลาด การกำหนดเกณฑ์ประหยัดพื้นที่ขั้นต่ำที่ปรับได้ช่วยหลีกเลี่ยงการเสียคุณภาพเสียงและทรัพยากร CPU เพื่อแลกกับไฟล์ที่เล็กลงเพียงเล็กน้อย

ViSQOL วัดอะไรได้ และวัดอะไรไม่ได้

ViSQOL เป็นเครื่องมือประมาณคุณภาพเสียงตามการรับรู้แบบอาศัยสัญญาณอ้างอิงเต็มรูปแบบ โดยเปรียบเทียบรูปคลื่นอ้างอิงกับรูปคลื่นที่คุณภาพลดลงและคืนค่าประมาณ MOS-LQO จึงมีประโยชน์ในการจัดลำดับไฟล์เข้ารหัสทดสอบ แต่ผลลัพธ์เป็นการทำนายจากแบบจำลอง ไม่ใช่การทดสอบฟังโดยมนุษย์หรือหลักฐานยืนยันว่าคุณภาพเสียงไม่ต่างจากต้นฉบับ

โหมดการทำงานและการเตรียมข้อมูลมีความสำคัญ โหมดเสียงของ ViSQOL ต้องการข้อมูลเข้า 48 kHz และจะผสมเสียงหลายช่องเป็นโมโนเพื่อเปรียบเทียบ ส่วนโหมดเสียงพูดใช้แบบจำลองอีกชุดและต้องการข้อมูลเข้า 16 kHz คะแนนทำนายสูงสุดของแบบจำลองเสียงอยู่ที่ประมาณ 4.75 ไม่ใช่คะแนนเต็มสมบูรณ์แบบ 5 ที่ใช้ได้ทั่วไป ดังนั้นการกำหนดคะแนนหนึ่งค่า เช่น 4.45 เป็นเกณฑ์ที่มีหลักฐานทางวิทยาศาสตร์รองรับสำหรับการบันทึกเสียงทุกชนิดจึงไม่สมเหตุสมผล เกณฑ์ต้องปรับเทียบตามเนื้อหาและข้อกำหนดการฟัง

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

แม้จะตรวจทั้งไฟล์ก็ยังแก้ปัญหาไม่ได้ทุกอย่าง คะแนนที่คำนวณจากโมโนไม่สามารถยืนยันว่าความกว้างของภาพเสียงสเตอริโอหรือความสัมพันธ์ของเฟสยังเหมือนเดิม การจัดแนวที่คลาดเคลื่อนอาจทำให้การเปรียบเทียบมีอคติ และความผิดเพี้ยนบางประเภทอาจไม่ถูกสะท้อนโดยแบบจำลองที่เลือก ควรมีการตรวจสัญญาณแยกต่างหาก และทดสอบการฟังแบบควบคุมหรือ ABX กับเนื้อหาที่เป็นตัวแทนก่อนนำเกณฑ์ไปใช้รับรองผลในระบบจริง ในงานพัฒนาที่มีอยู่ การทดสอบบูรณาการอัตโนมัติเรียกใช้อินเทอร์เฟซ ViSQOL ผ่านตัวจำลองสำหรับการทดสอบ ไม่ได้ยืนยันความแม่นยำของ ViSQOL จริงหรือการที่ผู้ฟังแยกความต่างไม่ออกบนระบบ macOS เป้าหมาย

เหตุใดข้อมูลเสียงที่ถูกต้องจึงไม่ได้หมายความว่าไฟล์ผลลัพธ์ถูกต้อง

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

WAV และ AIFF มีข้อมูลมากกว่าตัวอย่างเสียง

ไฟล์ RIFF/WAV อาจมีจุดคิว เมทาดาทาการวนซ้ำ เมทาดาทาการออกอากาศ ฟิลด์ฟอร์แมตเพิ่มเติม และส่วนข้อมูลที่ไม่รู้จัก ส่วน AIFF มีโครงสร้างเครื่องหมายและข้อมูลที่เกี่ยวข้องกับเครื่องดนตรีของตัวเอง ไฟล์หนึ่งอาจถอดรหัสเสียงได้สมบูรณ์ แต่ยังมีไบต์ที่ไม่ใช่เสียงซึ่งไม่รอดจากการเข้ารหัส Opus ตามปกติ การจัดการแบบระมัดระวังต้องตรวจสอบโครงสร้างที่ทราบว่าปลอดภัย และเก็บต้นฉบับทั้งไฟล์ไว้เมื่อไม่อาจจัดประเภทส่วนข้อมูลใดได้อย่างมั่นใจ แม้แต่ส่วนที่มักใช้เป็นข้อมูลเติมช่องว่างก็อาจมีไบต์ที่ไม่เป็นศูนย์ การสันนิษฐานว่าทิ้งได้ทั้งหมดจึงไม่ปลอดภัยหากข้อตกลงกำหนดให้เก็บไบต์เดิมไว้

FLAC เก็บข้อมูลแบบมีโครงสร้างที่การแปลงเป็น Opus อาจรักษาไว้ไม่ได้

FLAC รองรับบล็อกเมทาดาทาสำหรับรูปภาพ แผ่นรายการจุดคิว ข้อมูลแอปพลิเคชัน ตารางตำแหน่งสำหรับค้นหา และความคิดเห็นแบบ Vorbis โดยคีย์ในความคิดเห็นสามารถซ้ำกันได้ การทดสอบแบบควบคุมที่มีรายการ ARTIST=Alice และ ARTIST=Bob แยกกันแสดงให้เห็นว่า แม้การแปลงจะดูเหมือนสำเร็จ แต่หากผลลัพธ์เหลือเพียง ARTIST=Alice;Bob ความหมายทางโครงสร้างอาจผิดไป เพราะการแทนข้อมูลทั้งสองแบบไม่จำเป็นต้องเทียบเท่ากัน ตัวแปลงที่ระมัดระวังควรตรวจจับคีย์ซ้ำและการเข้ารหัสความคิดเห็นที่ไม่รองรับ แล้วเก็บต้นฉบับไว้ แทนที่จะยุบโครงสร้างโดยไม่แจ้งให้ทราบ ภาพรวมฟอร์แมต FLAC อธิบายรูปแบบบล็อกเมทาดาทานี้

MP4/M4A ต้องตรวจโครงสร้าง ไม่ใช่แค่ชื่อแท็ก

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

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

ออกแบบเครื่องมือปรับไฟล์เป็นชุดให้เป็นธุรกรรม ไม่ใช่วงวนเขียนทับไฟล์

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

ตรวจสอบก่อนเริ่ม: ยืนยันว่ามี FFmpeg, FFprobe, ตัวเข้ารหัสที่จำเป็น และเครื่องมือตรวจคุณภาพเพิ่มเติมถ้าจะใช้ ต้องแก้ไขพาธขาเข้าและขาออกให้ชัดเจนก่อนสร้างสิ่งใด และปฏิเสธความสัมพันธ์ของพาธที่เกิดจากการลิงก์เชิงสัญลักษณ์
สำรวจรายการ: แจกแจงไฟล์และโฟลเดอร์ ปฏิเสธออบเจ็กต์ในระบบไฟล์ที่ไม่รองรับ และตรวจการชนกันของชื่อภายใต้กฎที่ไม่แยกตัวพิมพ์เล็กใหญ่หรือมีการปรับรูปแบบ Unicode อย่าลืมว่าขีดจำกัดความยาวชื่อไฟล์มักวัดเป็นไบต์ ไม่ใช่จำนวนอักขระ
พักผลลัพธ์: สร้างไฟล์ทดสอบในพื้นที่ทำงานชั่วคราวโดยเฉพาะ ซึ่งอยู่บนระบบไฟล์เดียวกับปลายทางสุดท้าย และอย่าแก้ไขไฟล์ต้นฉบับ
ตรวจสอบ: สร้างลายนิ้วมือของต้นทางและผลลัพธ์ ตรวจสอบทั้งโฟลเดอร์ และเปรียบเทียบข้อมูลที่ต้องการกับรายการไฟล์ในพื้นที่พัก อย่าข้ามการตรวจสอบเส้นทางที่เลือกเก็บต้นฉบับเพียงเพราะไม่มีการเข้ารหัสเกิดขึ้น
ยืนยันการเผยแพร่: ใช้ล็อก บันทึกธุรกรรม การเปลี่ยนชื่อไฟล์แบบควบคุม และสำเนาสำรองที่ตรวจสอบแล้วเพื่อเผยแพร่โฟลเดอร์ทั้งชุด การเปลี่ยนชื่อหลายครั้งไม่ได้กลายเป็นธุรกรรมแบบอะตอมครั้งเดียว ระบบกู้คืนจึงต้องเข้าใจสถานะระหว่างขั้นตอน
กู้คืน: กู้เฉพาะผลลัพธ์ที่ตรวจสอบความเป็นเจ้าของและค่าแฮชได้ ส่วนข้อมูลตกค้างที่ไม่รู้จักหรือน่าสงสัยให้แยกเก็บกักกัน แทนการลบทิ้งโดยอัตโนมัติ

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

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

ทดสอบเส้นทางความล้มเหลวให้เข้มงวดพอ ๆ กับการทดสอบตัวแปลงสัญญาณ

การทดสอบตัวแปลงสัญญาณควรรวม WAV และ FLAC ทั่วไป เสียงโมโนและสเตอริโอ และเนื้อหาที่มีเสียงฉับพลันชัดเจน การทดสอบโครงสร้างควรรวมความคิดเห็น FLAC ที่มีคีย์ซ้ำ เมทาดาทา MP4 แบบซ้อนชั้น ส่วนข้อมูลเสริมของ WAV/AIFF ไฟล์ที่ไม่มีสตรีมเสียง ชื่อไฟล์ยาว การชนกันของชื่อไฟล์ผลลัพธ์ และไฟล์ที่เปลี่ยนระหว่างประมวลผล ส่วนการทดสอบกู้คืนควรแทรกการหยุดทำงานระหว่างการเปลี่ยนชื่อไฟล์ต่อเนื่องกัน แล้วตรวจว่าผลลัพธ์ที่ถูกต้องก่อนหน้านั้นยังคงอยู่หรือสามารถกู้คืนได้

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

หลักตัดสินใจที่ใช้งานได้จริงสำหรับเสียงในระบบจริง

สำหรับสำเนาใหม่เพื่อเผยแพร่ที่สร้างจากมาสเตอร์แบบไม่สูญเสียข้อมูลซึ่งเชื่อถือได้ และสามารถสร้างใหม่หรือทิ้งได้ ให้เริ่มจาก Opus แบบ VBR คุณภาพสูง แล้วตรวจสอบผลลัพธ์ภายใต้สภาพการฟังที่สมจริง เสนอ AAC เพิ่มเมื่อสภาพแวดล้อมการเผยแพร่ต้องการ และคง MP3 ไว้เมื่อมีเหตุผลด้านความเข้ากันได้ สำหรับไฟล์ต้นฉบับ ทรัพยากรสำหรับตัดต่อ และไฟล์ที่มีโครงสร้างอื่นนอกเหนือจากเสียงซึ่งไม่อาจทดแทนได้ ควรเก็บไฟล์เดิม และใช้ FLAC เฉพาะเมื่อยืนยันการแปลงแบบไม่สูญเสียข้อมูลตามข้อกำหนดการเก็บรักษาได้ โดยค่าเริ่มต้นควรหลีกเลี่ยงการแปลงซ้ำจากฟอร์แมตสูญเสียข้อมูลหนึ่งไปยังอีกฟอร์แมตหนึ่ง

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