Chọn định dạng mã hóa âm thanh tốt nhất không phải là cuộc thi tìm ra tệp nhỏ nhất. Một quyết định hợp lý phải cân bằng chất lượng cảm nhận khi nghe, khả năng tương thích khi phát, thời gian mã hóa, độ trễ, chi phí lưu trữ và những thông tin bắt buộc phải được giữ lại sau khi chuyển đổi. Một codec có thể giữ được tín hiệu âm thanh nghe tương đối tốt nhưng âm thầm làm mất ảnh bìa, nhiều mục tên nghệ sĩ, dấu mốc lặp, điểm đánh dấu hoặc siêu dữ liệu riêng của ứng dụng. Chuyển mã thành công về mặt kỹ thuật chưa chắc đã là chuyển đổi tệp chính xác.
Với nhu cầu phân phối âm thanh thông dụng và hiệu quả, lựa chọn khởi đầu hợp lý là Opus với tốc độ bit biến thiên. AAC vẫn là phương án có khả năng tương thích tốt, MP3 vẫn hữu ích trên các môi trường phát đời cũ, còn FLAC an toàn hơn khi việc bảo toàn nguyên vẹn các mẫu âm thanh quan trọng hơn dung lượng. Đây chỉ là những điểm xuất phát chứ không phải lựa chọn tối ưu trong mọi trường hợp. Bài toán kỹ thuật khó hơn là làm sao để bộ nén tự động biết khi nào không nên mã hóa bất cứ thứ gì.
Nên chọn codec âm thanh nào?
| Định dạng | Kiểu nén | Trường hợp sử dụng phù hợp nhất | Hạn chế quan trọng |
|---|---|---|---|
| Opus | Có mất dữ liệu | Nén hiệu quả giọng nói, nhạc, âm thanh truyền trực tuyến và âm thanh độ trễ thấp | Phải kiểm tra khả năng hỗ trợ của định dạng chứa và thiết bị đích; mã hóa lại có thể làm mất siêu dữ liệu |
| AAC-LC | Có mất dữ liệu | Tương thích rộng với các thiết bị và MP4 | Hiệu quả phụ thuộc vào bộ mã hóa và tốc độ bit; các biến thể có tốc độ bit thấp cần được đánh giá riêng |
| MP3 | Có mất dữ liệu | Máy phát đời cũ, tải tệp đơn giản và các trường hợp cần khả năng tương thích đã phổ biến từ lâu | Thường kém hiệu quả hơn codec hiện đại ở mức chất lượng cảm nhận tương đương |
| FLAC | Không mất dữ liệu | Lưu trữ lâu dài, bàn giao cho công đoạn xử lý âm thanh hoàn thiện và bảo toàn mẫu PCM | Tệp vẫn lớn hơn đáng kể so với bản mã hóa theo cảm nhận thính giác; siêu dữ liệu vẫn cần được xử lý cẩn thận |
| ALAC | Không mất dữ liệu | Âm thanh không mất dữ liệu trong quy trình làm việc xoay quanh hệ sinh thái Apple | Định dạng chứa MP4 có thể mang những cấu trúc không thể ánh xạ nguyên vẹn sang định dạng khác |
| WAV / PCM | Thường là PCM không nén | Biên tập, trao đổi dữ liệu, tín hiệu thử nghiệm và truy cập trực tiếp các mẫu âm thanh | Tệp lớn; WAV có thể chứa các khối RIFF không phải âm thanh nhưng vẫn quan trọng |
Đối với ứng dụng web hiện đại có thể cung cấp nhiều nguồn phát, Opus là lựa chọn mã hóa chính hợp lý, còn AAC là phương án thay thế khi cần tương thích rộng hơn. Với kho lưu trữ có yêu cầu cốt lõi là khôi phục chính xác từng mẫu âm thanh, hãy giữ bản gốc và cân nhắc FLAC như một bản biểu diễn không mất dữ liệu bổ sung. Nếu đầu vào đã là MP3, AAC hoặc Opus, giữ nguyên tệp thường tốt hơn là chuyển đổi có mất dữ liệu thêm một lần nữa. Mỗi lần mã hóa lossy đều có thể tạo ra méo tiếng mới; thay codec không thể lấy lại thông tin đã bị loại bỏ trước đó.
Cần phân biệt rõ codec, bộ mã hóa và định dạng chứa. Opus là codec; libopus là một bộ mã hóa được sử dụng rộng rãi; còn Ogg, WebM và những cấu hình MP4 được hỗ trợ có thể đóng vai trò định dạng chứa. AAC thường được lưu trong MP4/M4A. Phần mở rộng .m4a không cho biết âm thanh bên trong là AAC hay ALAC không mất dữ liệu. Hãy kiểm tra các luồng dữ liệu thực tế thay vì suy đoán chất lượng hoặc cách mã hóa từ tên tệp. Hướng dẫn codec âm thanh của MDN trình bày sự khác biệt giữa định dạng và định dạng chứa, còn RFC 6716 định nghĩa Opus.
Vì sao chỉ nhìn tốc độ bit không thể xác định chất lượng âm thanh
Tốc độ bit cho biết lượng dữ liệu đã mã hóa được dùng trong một giây, chứ không cho biết bao nhiêu thông tin nghe được còn tồn tại. Hai bộ mã hóa chạy cùng tốc độ bit có thể tạo ra những lỗi âm thanh khác nhau. Bản ghi giọng nói nhỏ nhẹ và bản nhạc dày đặc với nhiều âm chuyển tiếp đột ngột cũng đặt ra những khó khăn nén khác nhau. So sánh dung lượng đầu ra mà không xác định nội dung, codec, cấu hình kênh và thiết lập bộ mã hóa có thể dẫn đến kết luận sai.
- Tốc độ bit biến thiên (VBR) cho phép bộ mã hóa dành nhiều bit hơn cho đoạn phức tạp và ít bit hơn cho đoạn đơn giản. Cách này thường tốt hơn việc cố định tốc độ bit một cách cứng nhắc nếu yêu cầu lưu lượng mạng ổn định, dễ dự đoán không phải là ràng buộc chính.
- Tần số lấy mẫu xác định tần suất lấy mẫu của dạng sóng sau giải mã. Tăng tần số lấy mẫu của nguồn có tần số thấp không tái tạo được thông tin tần số cao đã mất. Việc lấy mẫu lại cũng có thể làm phức tạp phép so sánh chất lượng nếu tín hiệu tham chiếu và tín hiệu ứng viên được xử lý khác nhau.
- Độ sâu bit thể hiện độ chính xác lượng tử hóa PCM, không phải độ trung thực của codec có mất dữ liệu. Giải mã một nguồn vốn đã suy giảm chất lượng sang độ sâu bit cao không thể phục hồi chi tiết bị mất.
- Bố trí kênh là một phần của tín hiệu. Trộn xuống mono có thể giảm dung lượng nhưng không phải là cách tối ưu tự động chấp nhận được đối với nội dung cần giữ nguyên không gian stereo.
- Độ trễ, độ trễ của bộ mã hóa và phần đệm ảnh hưởng đến phát âm thanh tương tác, chuyển đoạn liền mạch và các đoạn âm thanh lặp cần độ chính xác cao. Chỉ nhìn thời lượng không thể phát hiện mọi vấn đề căn chỉnh.
Có thể bắt đầu thử nghiệm ở khoảng 128–192 kbit/s với nhạc stereo mã hóa Opus và mức thấp hơn nhiều với giọng nói mono, sau đó điều chỉnh theo nội dung và yêu cầu phát thực tế. Những con số này là tham số để tìm kiếm, không phải ngưỡng bảo đảm rằng người nghe không nhận ra khác biệt. Đối với phát trực tuyến ở tốc độ bit thấp, nên đánh giá các công nghệ như xHE-AAC tại những môi trường triển khai có hỗ trợ. Các codec âm thanh dùng mạng nơ-ron đang xuất hiện có thể hấp dẫn cho hệ thống giọng nói chuyên biệt hoặc nghiên cứu, nhưng một bài báo hay bản trình diễn không đủ chứng minh codec đó có thể thay thế trực tiếp một định dạng phân phối đã được hỗ trợ rộng rãi.
Dùng FFprobe để nhận diện nguồn và FFmpeg để mã hóa các phương án
Hãy bắt đầu bằng cách xác định luồng âm thanh thực tế, tần số lấy mẫu, các kênh và thời lượng. Nhờ đó, bạn không mặc nhiên cho rằng mọi định dạng chứa giống MP4 đều có âm thanh hoặc mọi phần mở rộng quen thuộc đều giải mã được.
ffprobe -v error -select_streams a -show_entries stream=codec_name,sample_rate,channels,channel_layout:format=duration -of json input.m4aVới nguồn WAV đơn giản mà bạn được phép xử lý và đã biết các khối dữ liệu bổ sung có thể bỏ đi, đây là ví dụ mã hóa Opus chất lượng cao:
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Để phân phối với khả năng tương thích MP4 rộng, có thể tạo phương án AAC-LC bằng bộ mã hóa AAC tích hợp trong FFmpeg:
ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a aac -b:a 192k output.m4aĐể tạo bản biểu diễn âm thanh không mất dữ liệu:
ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a flac -compression_level 8 output.flacĐây là những ví dụ cho từng tệp riêng lẻ, không phải quy trình chuyển đổi hàng loạt an toàn. Chúng không chứng minh được mọi trường siêu dữ liệu, luồng phụ, điểm đánh dấu hoặc khối của định dạng chứa đều được giữ lại. Với lệnh nén không mất dữ liệu, phải xác minh rằng các mẫu PCM sau giải mã tương đương nhau trên cùng một cách biểu diễn mẫu trước khi khẳng định quá trình chuyển đổi âm thanh có thể đảo ngược hoàn toàn. Việc mã hóa bằng libopus, bao gồm các tùy chọn VBR và độ phức tạp, được trình bày trong tài liệu về codec của FFmpeg. Khả năng phát trên trình duyệt cần được kiểm tra với đúng cặp codec và định dạng chứa, không chỉ dựa vào phần mở rộng.
Cách tìm tệp nhỏ nhất nhưng vẫn đạt yêu cầu
Bộ tối ưu hóa dựa trên cảm nhận thính giác giống một bài toán tìm kiếm có ràng buộc: giảm dung lượng đầu ra đến mức thấp nhất nhưng vẫn đáp ứng các kiểm tra kỹ thuật, tiêu chí chất lượng tối thiểu và yêu cầu bảo toàn đã xác định rõ. Không gian phương án bao gồm thiết lập codec, tốc độ bit, cách xử lý kênh và độ phức tạp của bộ mã hóa. Nhỏ hơn không mặc nhiên tốt hơn, và không bao giờ được chấp nhận một phương án có tốc độ bit thấp chỉ vì bộ mã hóa kết thúc thành công.
- Ghi lại dấu vân tay SHA-256 của nguồn và khảo sát các luồng dữ liệu cùng cấu trúc định dạng chứa.
- Xác định có được phép mã hóa mất dữ liệu hay không. Theo mặc định, giữ nguyên các nguồn đã nén mất dữ liệu và các tệp có siêu dữ liệu chưa được hỗ trợ.
- Mã hóa một phương án Opus với thiết lập thận trọng, sau đó thử một số mức tốc độ bit thấp hơn được chọn có chủ đích, thay vì dò mù quáng mọi thiết lập có thể.
- Giải mã từng phương án và xác nhận có âm thanh, các kênh cần thiết vẫn hiện diện, thông tin thời gian hợp lý và quá trình giải mã hoàn tất không lỗi.
- So sánh tín hiệu tham chiếu với phương án bằng những đoạn trích được căn chỉnh phù hợp và thước đo chất lượng cảm nhận, đồng thời kiểm tra độc lập tính toàn vẹn stereo, các đoạn âm thanh bị mất, hiện tượng clipping và những lỗi khác mà thước đo có thể bỏ sót.
- Chọn phương án nhỏ nhất đáp ứng chính sách và đem lại mức tiết kiệm đáng kể. Nếu không có, giữ nguyên tệp gốc đến từng byte.
- Kiểm tra nguồn không thay đổi trong quá trình xử lý; chỉ công bố kết quả sau khi xác thực toàn bộ dữ liệu ở khu vực chuẩn bị.
Một bộ tối ưu hóa hữu ích ghi nhận COMPRESSED, PRESERVED và FAILED là ba kết quả riêng biệt. Giữ nguyên tệp có thể là quyết định tối ưu đúng đắn chứ không phải lỗi. Ngưỡng tiết kiệm tối thiểu có thể cấu hình giúp tránh đánh đổi chất lượng và tài nguyên CPU chỉ để giảm được một lượng dung lượng không đáng kể.
ViSQOL đo được gì và không đo được gì?
ViSQOL là công cụ ước lượng chất lượng cảm nhận có sử dụng đầy đủ tín hiệu tham chiếu. Nó so sánh dạng sóng tham chiếu với dạng sóng đã suy giảm và đưa ra ước lượng MOS-LQO. Vì vậy, công cụ này hữu ích để xếp hạng các phương án mã hóa, nhưng kết quả chỉ là dự đoán của mô hình, không phải bài kiểm tra nghe của con người hay bằng chứng rằng sự khác biệt hoàn toàn không thể nghe thấy.
Chế độ hoạt động và bước tiền xử lý đều quan trọng. Chế độ âm thanh của ViSQOL yêu cầu đầu vào 48 kHz và chuyển âm thanh đa kênh thành mono để so sánh. Chế độ giọng nói dùng mô hình khác và yêu cầu đầu vào 16 kHz. Mức dự đoán cao nhất của mô hình âm thanh vào khoảng 4.75, chứ không phải điểm hoàn hảo 5 áp dụng cho mọi trường hợp. Do đó, không có cơ sở để coi một điểm duy nhất—chẳng hạn 4.45—là ngưỡng đã được khoa học xác lập cho mọi bản ghi. Các ngưỡng cần được hiệu chỉnh theo nội dung và yêu cầu nghe thực tế.
Giá trị trung bình có thể che khuất hư hại cục bộ. Một phương án có thể nghe ổn ở phần lớn bản nhạc nhưng lại làm méo một tiếng chũm chọe, một phụ âm sắc hoặc một âm chuyển tiếp rất ngắn. Chính sách cẩn thận hơn sẽ lấy mẫu những đoạn khó và, nếu cần, chạy các cửa sổ chồng lấn trên toàn bộ tệp, giữ lại kết quả phù hợp tệ nhất thay vì chỉ dựa vào trung bình. Quét toàn bộ đòi hỏi giải mã và tính toán thước đo nhiều hơn. Nên lưu đệm các cửa sổ tham chiếu với giới hạn dung lượng đĩa để những bản ghi dài không làm cạn bộ nhớ tạm.
Ngay cả quét toàn bộ cũng không giải quyết được mọi chuyện: điểm số dựa trên mono không chứng minh được độ rộng không gian stereo hay quan hệ pha được bảo toàn, sai lệch căn chỉnh có thể làm thiên lệch phép so sánh, và một số loại lỗi âm thanh không được mô hình cụ thể phản ánh tốt. Hãy duy trì các phép kiểm tra tín hiệu độc lập và thực hiện kiểm tra nghe có kiểm soát hoặc thử nghiệm ABX trên nội dung đại diện trước khi dùng một ngưỡng làm tiêu chí chấp nhận trong môi trường sản xuất. Trong phần triển khai đã có, các kiểm tra tích hợp tự động chỉ thử giao diện ViSQOL bằng thành phần thay thế phục vụ kiểm thử; chúng chưa xác lập độ chính xác thực tế của ViSQOL hay xác nhận rằng người nghe không phân biệt được âm thanh trên hệ thống macOS đích.
Vì sao dữ liệu âm thanh đúng chưa chắc tạo ra tệp đầu ra đúng
Dạng lỗi quan trọng nhất được phát hiện trong quá trình phát triển là mất dữ liệu trong định dạng chứa nhưng lại trông như nén thành công. Bộ giải mã âm thanh thường đưa ra luồng có thể phát được và bỏ qua những cấu trúc khác. Chuyển mã luồng đó có thể tạo ra đầu ra hợp lệ nhưng âm thầm vứt bỏ thông tin mà chủ sở hữu bản gốc muốn giữ lại.
WAV và AIFF chứa nhiều thứ hơn các mẫu âm thanh
Tệp RIFF/WAV có thể chứa các điểm đánh dấu, siêu dữ liệu về vòng lặp, siêu dữ liệu phát sóng, trường định dạng bổ sung và những khối không xác định. AIFF có cấu trúc riêng cho dấu mốc và thông tin liên quan đến nhạc cụ. Một tệp có thể giải mã hoàn hảo nhưng vẫn mang những byte không phải âm thanh sẽ biến mất khi mã hóa Opus theo cách thông thường. Cách xử lý thận trọng phải kiểm tra những cấu trúc đã biết là an toàn và giữ nguyên toàn bộ tệp gốc khi không thể phân loại an toàn một khối. Ngay cả khối thường dùng để đệm cũng có thể chứa byte khác không; coi mọi khối như vậy đều có thể loại bỏ là không an toàn nếu yêu cầu bao gồm bảo toàn nguyên vẹn từng byte.
FLAC có thể bảo toàn thông tin có cấu trúc mà việc chuyển sang Opus không giữ được
FLAC hỗ trợ các khối siêu dữ liệu cho hình ảnh, bảng chỉ dẫn (cuesheet), dữ liệu ứng dụng, bảng tra vị trí và chú thích Vorbis. Những chú thích này có thể chứa khóa lặp. Một phép thử có kiểm soát với hai mục riêng biệt ARTIST=Alice và ARTIST=Bob cho thấy vì sao quá trình chuyển đổi tưởng như thành công lại có thể sai về ngữ nghĩa nếu đầu ra chỉ còn ARTIST=Alice;Bob. Hai cách biểu diễn đó không nhất thiết tương đương. Bộ chuyển đổi thận trọng phải phát hiện các khóa lặp và kiểu mã hóa chú thích không được hỗ trợ, rồi giữ tệp gốc thay vì âm thầm gộp phẳng cấu trúc. Tài liệu tổng quan định dạng FLAC giải thích mô hình các khối siêu dữ liệu.
MP4/M4A cần kiểm tra cấu trúc thay vì chỉ kiểm tra tên thẻ
Tệp M4A có thể chứa thẻ nghệ sĩ, tên bài thông thường bên cạnh các atom riêng tư hoặc lạ. Atom không xác định có thể xuất hiện ở nhiều cấp, kể cả bên trong những hộp siêu dữ liệu tưởng như quen thuộc. Chỉ kiểm tra tên atom ngoài cùng là chưa đủ: thành phần con không nhận diện được hoặc cách biểu diễn dữ liệu bất ngờ có thể bị mất ngay cả khi luồng ALAC hoặc AAC giải mã bình thường. Chính sách an toàn hơn là chủ động chỉ công nhận một tập nhỏ những cấu trúc atom đã biết chắc là an toàn và giữ nguyên mọi đầu vào không rõ ràng, không chuyển mã.
Tương tự, một tệp có phần mở rộng quen thuộc có thể chỉ chứa phụ đề hoặc video, hoặc có nhiều luồng dữ liệu. Không nên ép tệp đó qua bộ mã hóa âm thanh hay loại bỏ nó như một tác vụ âm thanh thất bại. Hãy giữ nó như tệp phụ trợ, với điều kiện định dạng chứa hợp lệ và phép kiểm tra tính toàn vẹn nguồn đều đạt. Đừng suy ra sự tồn tại của luồng âm thanh chỉ từ phần mở rộng.
Xây dựng bộ tối ưu hóa hàng loạt như một giao dịch, không phải vòng lặp ghi đè tệp
Bài học kỹ thuật lớn còn lại liên quan đến việc công bố kết quả. Bộ tối ưu hóa không bao giờ được phá hỏng một kết quả tốt có từ trước chỉ vì tệp xử lý sau đó gặp lỗi, tiến trình bị gián đoạn hoặc một phương án trông nhỏ hơn. Mô hình an toàn là coi thư mục cuối cùng như một sản phẩm được quản lý, có thông tin nguồn gốc và quy trình hoàn tất giao dịch có thể phục hồi.
- Kiểm tra trước: xác nhận có FFmpeg, FFprobe, những bộ mã hóa bắt buộc và công cụ đo chất lượng tùy chọn. Xác định đường dẫn đầu vào và đầu ra trước khi tạo bất cứ thứ gì; từ chối trường hợp thư mục chứa lẫn nhau thông qua liên kết tượng trưng.
- Kiểm kê: liệt kê tệp và thư mục, từ chối đối tượng hệ thống tệp không được hỗ trợ, đồng thời phát hiện xung đột tên theo quy tắc không phân biệt chữ hoa chữ thường hoặc chuẩn hóa Unicode. Hãy nhớ giới hạn độ dài tên tệp thường được đo bằng byte, không phải số ký tự.
- Chuẩn bị: tạo các phương án trong không gian làm việc tạm chuyên dụng trên cùng hệ thống tệp với đích cuối cùng. Giữ nguyên các tệp nguồn.
- Xác minh: tính dấu vân tay nguồn và đầu ra, kiểm tra toàn bộ thư mục và đối chiếu nội dung dự kiến với tệp kê khai ở khu vực chuẩn bị. Đừng bỏ qua nhánh giữ nguyên chỉ vì không có bước mã hóa nào diễn ra.
- Hoàn tất: dùng khóa, nhật ký giao dịch, thao tác đổi tên được kiểm soát và bản sao lưu đã xác minh để công bố cả thư mục. Nhiều thao tác đổi tên không tạo thành một giao dịch nguyên tử duy nhất; logic phục hồi phải hiểu được các trạng thái trung gian.
- Phục hồi: chỉ khôi phục những đầu ra có thể xác minh được quyền sở hữu và giá trị băm. Giữ các phần còn sót lại không rõ nguồn gốc hoặc đáng ngờ trong khu vực cách ly, thay vì tự động xóa.
Tệp kê khai cũng thuộc bề mặt có thể bị tấn công và gây lỗi. Phải giới hạn kích thước, phân tích cú pháp theo hướng phòng thủ và mở chúng như tệp thông thường, không đi theo liên kết tượng trưng hay bị chặn vô thời hạn khi gặp ống dẫn có tên. Các khóa ánh xạ và đường dẫn được khôi phục cũng cần được xác thực: một giá trị JSON trông vô hại không bao giờ được khiến thao tác phục hồi vượt ra ngoài thư mục gốc đầu ra đã chọn. Không nên lưu những tên thuộc tính JavaScript đặc biệt vào các đối tượng dạng từ điển có prototype mà không có biện pháp bảo vệ.
Cuối cùng, tệp nguồn có thể thay đổi trong lúc quá trình mã hóa kéo dài. Chỉ tính giá trị băm ở bước phát hiện ban đầu là không đủ. Hãy kiểm tra lại đúng dấu vân tay ban đầu khi sao chép nguồn được giữ nguyên, khi bác bỏ một phương án theo chất lượng cảm nhận và ngay trước khi công bố kết quả. Một phép thử có kiểm soát bằng cách chủ động tạo lỗi đã cho thấy lý do: thay đầu vào sau khi đã kiểm tra có thể khiến phiên bản triển khai trước đó báo rằng tệp đã được giữ nguyên thành công, trong khi các byte được công bố lại đến từ một trạng thái nguồn khác. Quy tắc đã sửa sẽ từ chối lần chạy đó thay vì công bố kết quả gây hiểu nhầm.
Cần kiểm thử các tình huống lỗi nghiêm ngặt không kém kiểm thử codec
Kiểm thử codec phải bao gồm WAV và FLAC thông thường, âm thanh mono và stereo, cùng nội dung có các âm chuyển tiếp rõ rệt. Kiểm thử cấu trúc phải bao gồm chú thích FLAC có khóa lặp, siêu dữ liệu MP4 lồng nhau, khối phụ trợ WAV/AIFF, tệp không có luồng âm thanh, tên tệp dài, tên đầu ra trùng nhau và các tệp thay đổi trong lúc xử lý. Kiểm thử phục hồi cần chủ động gây gián đoạn giữa những thao tác đổi tên liên tiếp và xác nhận kết quả hợp lệ trước đó vẫn được giữ lại hoặc được khôi phục.
Đừng nhầm một loạt phép kiểm thử đạt với kết quả đánh giá chất lượng nghe. Công việc kỹ thuật được đề cập ở đây có các phép kiểm tra mã hóa và giải mã bằng FFmpeg thực sự, các bộ dữ liệu thử nghiệm cố ý bị lỗi hoặc bất thường, cùng các phép kiểm thử tích hợp dùng thành phần mô phỏng cho thước đo chất lượng cảm nhận. Những kiểm tra ấy cung cấp bằng chứng cho các đặc tính an toàn cụ thể, chứ không phải phép so sánh codec có tính đại diện thống kê, khả năng bao phủ mọi định dạng chứa hay kết quả xác thực trên tất cả hệ điều hành. Các báo cáo của bất kỳ bộ tối ưu hóa âm thanh nào cũng cần thể hiện sự khác biệt đó: một tệp giải mã được, một tệp đã đo chất lượng cảm nhận và một tệp đã được con người nghe kiểm tra tương ứng với ba mức độ tin cậy khác nhau.
Quy tắc thực tế để lựa chọn âm thanh trong môi trường sản xuất
Với những bản sao mới để phân phối, có thể tạo lại hoặc loại bỏ và được tạo từ nguồn master không mất dữ liệu đáng tin cậy, hãy bắt đầu bằng Opus VBR chất lượng cao rồi xác minh kết quả trong điều kiện nghe thực tế. Cung cấp AAC nếu môi trường phân phối cần. Giữ MP3 nếu yêu cầu tương thích khiến điều đó hợp lý. Với bản gốc, tài nguyên dùng để biên tập và những tệp chứa cấu trúc không phải âm thanh không thể thay thế, hãy giữ tệp hiện có và chỉ dùng FLAC khi có thể xác minh chuyển đổi không mất dữ liệu đáp ứng yêu cầu bảo toàn. Theo mặc định, tránh chuyển mã từ một định dạng lossy sang một định dạng lossy khác.
Vì vậy, bộ tối ưu hóa đáng tin cậy nhất không phải là bộ nén mọi tệp. Đó là bộ có thể giải thích, với từng đầu vào, vì sao chọn codec ấy, vì sao đầu ra vượt qua các kiểm tra chất lượng và tính toàn vẹn tương ứng, và vì sao đôi khi quyết định không nén lại mới là kết quả đúng duy nhất.