💡 Theo 47 CFR § 79.1(j)(2), FCC yêu cầu bốn tiêu chuẩn chất lượng phụ đề: chính xác (chuyển ngôn trung thực kèm nhận diện người nói và âm thanh quan trọng), đồng bộ (phụ đề xuất hiện khi lời thoại bắt đầu), đầy đủ (từ đầu đến cuối), và vị trí (không che mặt người hay đồ họa). Chạy Fix Common Errors trong Subtitle Edit và Caption Inspector để kiểm tra cả bốn trước khi giao file broadcast.
Ý chính
- Bốn tiêu chuẩn FCC theo 47 CFR § 79.1(j)(2): chính xác, đồng bộ, đầy đủ, vị trí. Mỗi tiêu chí tương ứng trực tiếp với một bước kiểm tra bằng công cụ miễn phí.
- Trong Subtitle Edit: bật cột CPS (View > Column Chooser) và chạy Tools > Fix Common Errors để phát hiện lỗi chính xác và đồng bộ trong một lần. Đánh dấu sự kiện vượt khoảng 17 CPS cho nội dung người lớn.
- Với file SCC và MCC: output
-C1.608của Caption Inspector hiển thị lỗi PAC row, sự không khớp drop-frame/non-drop timecode, và lỗi mã hóa cấp byte mà bản xem trước Subtitle Edit che giấu. - Tiêu chí đầy đủ dễ bị bỏ sót: kiểm tra timecode sự kiện caption cuối phải tại hoặc sau dòng thoại cuối cùng, không bị cắt bởi chuyển sang quảng cáo.
- FCC áp dụng quyền phán xét de minimis cho lỗi lẻ tẻ; vi phạm có hệ thống hoặc liên tục trên bất kỳ tiêu chí nào đều có thể dẫn đến xem xét tuân thủ.
Bốn tiêu chuẩn chất lượng caption FCC là gì?
Đạo luật CVAA năm 2010 (21st Century Communications and Video Accessibility Act) chỉ thị FCC thiết lập tiêu chuẩn chất lượng cho phụ đề đóng, nay được quy định tại 47 CFR § 79.1(j)(2). Các tiêu chuẩn này áp dụng cho mọi nhà phân phối chương trình video bắt buộc phải có phụ đề theo Part 79, và bao gồm bốn lĩnh vực chất lượng riêng biệt.
Chính xác yêu cầu phụ đề phản ánh lời nói trung thực: chính tả, dấu câu, viết hoa và thì động từ đúng. Nội dung âm thanh phi lời nói cũng thuộc tiêu chí này: nhận diện người nói, hiệu ứng âm thanh, chú thích nhạc và phản ứng khán giả khi cần thiết cho sự hiểu biết. Diễn giải lại được phép chỉ khi hạn chế thời gian khiến caption nguyên văn bất khả thi.
Đồng bộ yêu cầu phụ đề xuất hiện khi lời thoại hoặc âm thanh tương ứng bắt đầu và kết thúc khi audio kết thúc. Tốc độ hiển thị phải cho người xem đủ thời gian đọc. Với nội dung trực tiếp, FCC thừa nhận độ trễ không thể tránh khỏi nhưng cần giữ ở mức tối thiểu.
Đầy đủ yêu cầu phụ đề chạy từ đầu đến cuối chương trình, "trong phạm vi tốt nhất có thể". Điều này bao gồm caption âm thanh trong giờ quảng cáo nếu âm thanh chương trình tiếp tục, và không cắt phụ đề khi chuyển sang quảng cáo hay chương trình tiếp theo.
Vị trí yêu cầu phụ đề không che "khuôn mặt, văn bản nổi bật trên màn hình (như thông tin thời tiết), đồ họa, hay thông tin hình ảnh khác quan trọng cho việc hiểu chương trình". Phụ đề phải được định kích thước và vị trí phù hợp để hiển thị đầy đủ trên màn hình.
FCC thừa nhận rằng lỗi caption lẻ tẻ là không thể tránh khỏi, đặc biệt trong phát sóng trực tiếp. Quyền phán xét trong thi hành cân nhắc loại lỗi, tần suất, tính liên tục hay lẻ tẻ của lỗi và các biện pháp khắc phục đã thực hiện.
Danh sách kiểm tra QC: từ tiêu chuẩn đến bước kiểm tra cụ thể
Tôi dùng bảng này như danh sách kiểm tra trước mỗi lần giao file broadcast hoặc streaming. Công cụ thay đổi theo định dạng: Subtitle Edit dùng cho SRT, WebVTT và TTML; Caption Inspector dùng cho SCC và MCC.
| Tiêu chuẩn FCC | Yêu cầu cốt lõi (47 CFR § 79.1) | Kiểm tra trong Subtitle Edit | Kiểm tra Caption Inspector (SCC/MCC) |
|---|---|---|---|
| Chính xác | Chuyển ngôn trung thực: chính tả, dấu câu, nhận diện người nói, chú thích âm thanh | F7 Spell Check; Fix Common Errors: sửa khoảng trắng kép, thiếu dấu chấm, khoảng trắng thừa | Đọc -C1.608 so với kịch bản; ký tự bị rối = lỗi mã hóa Latin |
| Đồng bộ | Phụ đề xuất hiện khi lời thoại bắt đầu; tốc độ hiển thị đọc được | Bật cột CPS (View > Column Chooser); Fix Common Errors: Fix short display times; đánh dấu sự kiện vượt ~17 CPS | Kiểm tra timestamp trong -C1.608 so với TC chuẩn; dấu chấm phẩy = drop-frame (đúng cho 29,97 NTSC) |
| Đầy đủ | Phụ đề từ đầu đến cuối chương trình, tốt nhất có thể | Kiểm tra TC sự kiện đầu = IN chương trình; TC sự kiện cuối tại hoặc sau dòng thoại cuối | Đếm sự kiện trong -C1.608; tìm khoảng cách bất thường dài hơn bình thường |
| Vị trí | Không che mặt, đồ họa thời tiết hay văn bản nổi bật | Trong export SCC 608: kiểm tra thiết lập hàng (Row 15 = dưới cùng) | Đọc PAC row trong -C1.608: Row 15 = dưới (đúng cho hầu hết nội dung Mỹ), Row 1 = trên; toàn Row 1 = lỗi chuyển đổi |
Làm thế nào để kiểm tra chính xác và đồng bộ trong Subtitle Edit?
Với file SRT, WebVTT và TTML, tôi luôn bắt đầu bằng hai bước: bật cột CPS rồi chạy Fix Common Errors.
Để hiện cột CPS: View > Column Chooser > đánh dấu "Characters per second". Con số CPS sẽ xuất hiện trực tiếp trên mỗi hàng sự kiện. Tôi quét tìm sự kiện vượt khoảng 17 CPS cho kịch người lớn và 13 CPS cho chương trình trẻ em. Đây không phải quy định FCC mà là thực hành ngành phổ biến cho tốc độ hiển thị đọc được, chính là điều tiêu chuẩn đồng bộ yêu cầu về mặt thực tế. Đặt giới hạn tại Tools > Settings > General > "Show characters per second for active subtitle".
Sau đó chạy Tools > Fix Common Errors. Các kiểm tra tôi bật mỗi lần:
- Fix missing periods at end of sentences: bắt lỗi chính xác khi thiếu dấu chấm cuối dòng thoại.
- Fix extra spaces in text: khoảng trắng kép bên trong sự kiện caption tạo khoảng cách nhìn thấy được trên màn hình.
- Fix short display times: sự kiện ngắn hơn khoảng 0,8 giây có thể trôi qua trước khi người xem kịp đọc, vi phạm tiêu chuẩn đồng bộ.
- Fix long display times: sự kiện kéo dài quá mức sẽ chồng lên dòng thoại tiếp theo.
- Remove empty lines: sự kiện trống ở đầu hoặc cuối file sẽ không qua kiểm tra đầy đủ.
Sau lần Fix Common Errors, tôi cuộn danh sách sự kiện với cột CPS hiển thị và tìm các hàng màu đỏ. Giá trị CPS màu đỏ nghĩa là sự kiện vượt giới hạn đã cấu hình và cần xem lại cách ngắt dòng hoặc điều chỉnh thời gian trước khi giao.
Làm thế nào để xác minh vị trí và tính đầy đủ trong file SCC broadcast?
Với file SCC (CEA-608), bản xem trước của Subtitle Edit không đủ để kiểm tra vị trí. Các PAC row nằm trong mã hóa byte nhị phân, và Subtitle Edit hiển thị tất cả caption ở vị trí xem trước cố định bất kể dữ liệu hàng thực tế. Tôi dùng Caption Inspector để giải mã vị trí PAC thô.
docker run --rm -v $(pwd):/data nebulabroadcast/caption-inspector \
-o /data /data/my-captions.scc -f 2997-v $(pwd):/data: mount thư mục hiện tại để các file kết quả xuất hiện cùng với SCC đầu vào.-f 2997: đặt frame rate 29,97 fps cho nội dung SCC broadcast Mỹ. Bắt buộc để timecode trong output chính xác.
Mở file -C1.608 trong bất kỳ trình soạn thảo văn bản nào. Mỗi sự kiện caption hiển thị một dòng như:
{Preamble Address Code: Row 15, Column 0, White, Normal}
"Welcome to the evening news."Row 15 là hàng dưới cùng của lưới 15 hàng CEA-608: đúng cho hầu hết nội dung broadcast Mỹ. Nếu mọi sự kiện đều ở Row 1 (đầu màn hình), một bước chuyển đổi đã bỏ dữ liệu định vị và dùng giá trị mặc định thay thế. Đây là lỗi vị trí tôi gặp thường xuyên nhất sau khi chuyển đổi SRT sang SCC mà không thiết lập rõ ràng output row trong cài đặt export 608 của Subtitle Edit.
Để kiểm tra tính đầy đủ trong file SCC, tôi mở output -C1.608 và kiểm tra timestamp đầu tiên gần với điểm bắt đầu chương trình và timestamp cuối cùng tại hoặc sau dòng thoại cuối. File kết thúc mười giây trước khi audio chương trình kết thúc sẽ không đạt tiêu chuẩn đầy đủ.
Tự làm được gì và khi nào cần chuyên gia?
Tất cả các bước trên đều tự phục vụ được với Subtitle Edit (miễn phí) và Caption Inspector qua Docker (miễn phí). Tôi chạy quy trình QC này trên mọi file trước khi giao, và nó phát hiện lỗi vị trí, lỗi mã hóa và khoảng cách đầy đủ trước khi hệ thống tiếp nhận của đài phát sóng gắn cờ.
Nơi kinh nghiệm tạo ra sự khác biệt thực sự: nếu output Caption Inspector hiển thị ký hiệu X trong file .ccd (cặp byte không hợp lệ mà decoder broadcast bỏ qua), hoặc mọi sự kiện nằm sai hàng mà không có bước chuyển đổi rõ ràng để giải thích, truy vết các lỗi đó đòi hỏi phải biết công cụ tác giả nào tạo ra các byte gốc và lỗi được đưa vào ở bước nào trong chuỗi.
Với mọi file giao cho đài phát sóng thuộc thẩm quyền FCC, bốn tiêu chuẩn không chỉ là mong đợi mà là một phần của khung pháp lý cho nhà phân phối chương trình video. Lỗi chính xác hay đồng bộ có hệ thống có thể dẫn đến khiếu nại và xem xét. Dịch vụ kiểm tra caption QC của tôi bao gồm decode check đầy đủ, kiểm tra đầy đủ và vị trí, và đánh giá theo bốn tiêu chuẩn FCC cho bản giao hàng broadcast và streaming Mỹ.
Câu hỏi thường gặp
FCC có quy định tỷ lệ chính xác cụ thể, như 99%, không?
Không. Tiêu chuẩn chất lượng tại 47 CFR § 79.1(j)(2) yêu cầu phụ đề "khớp với lời nói" trung thực nhưng không đặt ra ngưỡng tỷ lệ chính xác số học cụ thể. FCC cân nhắc tính hệ thống và tần suất của lỗi cũng như các biện pháp khắc phục. Con số "99% chính xác" đôi khi được trích dẫn đến từ hướng dẫn ngành và tiêu chuẩn nội bộ của một số đài phát sóng, không phải từ văn bản CFR.
Tiêu chuẩn chất lượng FCC có áp dụng cho nền tảng streaming như Netflix hay YouTube không?
Quy tắc chất lượng caption của FCC theo Part 79 áp dụng cho các nhà phân phối chương trình video thuộc thẩm quyền FCC: đài phát sóng qua sóng, nhà khai thác cáp và truyền hình vệ tinh. Chúng cũng áp dụng cho các clip streaming là phiên bản phát lại của nội dung đã phát sóng trước đó theo quy tắc nội dung phát qua IP của CVAA. Netflix và YouTube hoạt động theo hướng dẫn riêng thường vượt quá tiêu chuẩn tối thiểu FCC nhưng tách biệt với cơ chế thi hành của FCC.
Nên dùng ngưỡng CPS nào để kiểm tra đồng bộ?
FCC không quy định con số CPS tối đa trong 47 CFR § 79.1. Trong thực tế, hầu hết người caption broadcast Mỹ dùng khoảng 17 CPS cho chương trình người lớn và 13 CPS cho nội dung trẻ em, các giá trị lấy từ Netflix Timed Text Style Guide và thực hành ngành phổ biến. Subtitle Edit có thể đánh dấu đỏ sự kiện vượt giới hạn CPS bạn cấu hình qua Tools > Settings > General. Luôn xác minh tiêu chuẩn nào client hoặc đài phát sóng của bạn yêu cầu.
Tính đầy đủ có nghĩa là phải caption mọi âm thanh nền không?
Không. Tiêu chuẩn chính xác FCC yêu cầu "thông tin phi lời nói truyền tải qua âm thanh, bao gồm hiệu ứng âm thanh có ý nghĩa". Tính đầy đủ có nghĩa là phụ đề chạy từ đầu đến cuối, không phải mọi tiếng ồn nền đều được caption. Trong thực tế, tôi caption các tín hiệu nhạc nhận dạng được, lời thoại, nhận diện người nói và hiệu ứng âm thanh ảnh hưởng đến sự hiểu biết. Âm thanh nền liên tục không mang thông tin liên quan thường không được caption riêng, mặc dù nhãn như [tiếng đám đông] khi bắt đầu cảnh là phổ biến trong track SDH.
Tiêu chuẩn de minimis của FCC trong thi hành là gì?
FCC thừa nhận lỗi caption thỉnh thoảng là không thể tránh khỏi, đặc biệt trong phát sóng trực tiếp. FCC cân nhắc: tính chất và tần suất lỗi, liệu lỗi có hệ thống hay lẻ tẻ, liệu xảy ra trong nội dung trực tiếp hay pre-recorded, và các biện pháp khắc phục sau khi được thông báo. Lỗi chính tả lẻ tẻ hay độ trễ đồng bộ ngắn trong tin tức trực tiếp được xử lý khác với lỗi vị trí có hệ thống hay các phần lớn bị thiếu caption trong chương trình pre-recorded. Đây là tiêu chuẩn định tính, không phải trần số lỗi cụ thể.
Nguồn
- 47 CFR Part 79 - eCFR (Electronic Code of Federal Regulations) - văn bản gốc quy tắc phụ đề FCC bao gồm § 79.1(j)(2) tiêu chuẩn chất lượng. Kiểm tra tháng 11/2026.
- WCAG 2.1: Understanding 1.2.2 Captions (Prerecorded) - W3C - tiêu chí WCAG về chính xác, đồng bộ và đầy đủ của caption. Kiểm tra tháng 11/2026.
- Comcast/caption-inspector - GitHub - cú pháp lệnh và định dạng output Caption Inspector. Kiểm tra tháng 11/2026.
- Subtitle Edit - nikse.dk - cột CPS và tính năng Fix Common Errors. Kiểm tra tháng 11/2026.
Bài viết bởi Đào Huy (Lucas), biên dịch viên và chuyên viên bản địa hóa tiếng Việt (Anh, Trung, Pháp sang Việt). See translation services →