Cách chuyển SRT sang SCC (CEA-608) chuẩn broadcast và kiểm tra giải mã

💡 Để tạo file SCC (CEA-608) chuẩn broadcast từ SRT: chạy seconv in.srt ScenaristClosedCaptionsDropFrame --fps:29.97 --output-folder:out --overwrite, sau đó kiểm tra giải mã bằng caption-inspector. CEA-608 giới hạn 32 ký tự mỗi hàng, 15 hàng địa chỉ tối đa, cần drop-frame timecode cho 29.97 fps và chỉ hỗ trợ ký tự Latin - tiếng Anh đi vào SCC, ngôn ngữ khác đi kèm dưới dạng track phụ đề riêng.

File SCC khác SRT như thế nào trong môi trường broadcast?

File SRT là văn bản thuần với timestamp millisecond - không liên quan gì đến khung hình truyền hình. File SCC (Scenarist Closed Captions) khác hoàn toàn: nó lưu dữ liệu closed-caption CEA-608 dưới dạng cặp byte hex trên SMPTE timecode 29.97 fps drop-frame. Broadcaster Mỹ và các nền tảng streaming tuân thủ quy định FCC không chấp nhận SRT cho track caption - họ cần SCC, hoặc định dạng SMPTE-TT/ST 2052-1 cho workflow HD.

File SCC không chỉ chứa text. Nó mang cả CEA-608 control codes: hàng nào hiển thị, chế độ pop-on hay roll-up, tín hiệu xóa caption khỏi màn hình. Converter xử lý sai các control code này sẽ tạo ra file hợp lệ về cú pháp nhưng hiển thị sai text hoặc sai timing trên decoder thực tế - đó là lý do tôi luôn chạy decode check sau khi chuyển đổi.

Một ràng buộc cần nói thẳng: CEA-608 là chuẩn broadcast của Mỹ và Bắc Mỹ, chủ yếu cho tiếng Anh. Bảng ký tự EIA-608 hỗ trợ Latin và một số ký tự Tây Âu cơ bản. Ký tự CJK, Arabic, và các bảng chữ không phải Latin không thể mã hóa trong track 608. Các ngôn ngữ đó đi dưới dạng track phụ đề riêng (SRT hoặc IMSC), không phải dữ liệu 608 - đây là giới hạn của tiêu chuẩn CEA-608 chứ không phải của công cụ.

Ràng buộc CEA-608 mà file SRT cần đáp ứng

Trước khi chuyển đổi, tôi kiểm tra SRT theo các giới hạn lưới 608. Dòng quá 32 ký tự sẽ bị cắt hoặc xuống dòng không kiểm soát. Hơn 4 dòng xếp chồng trong một sự kiện có thể gây chồng lấp khi hiển thị trên một số decoder.

Đặc tính CEA-608	Giá trị / giới hạn
Số ký tự tối đa mỗi hàng	32
Số hàng có địa chỉ trên màn hình	15 (hàng 1-15)
Số hàng tối đa trong một sự kiện pop-on	4
Chế độ roll-up	RU2 (2 hàng), RU3 (3 hàng), RU4 (4 hàng)
Bảng mã ký tự	Bảng Latin EIA-608 (không có CJK, không có Arabic)
Định dạng timecode tại 29.97 fps	Drop-frame: HH:MM:SS;FF
Định dạng timecode tại 30 fps NDF	Non-drop: HH:MM:SS:FF
Kênh caption chính (tiếng Anh)	CC1 (Field 1, channel 1)

Tôi kiểm tra số ký tự trong Subtitle Edit qua View > Show character count per line. Dòng nào hơn 32 ký tự thì tách thủ công trước khi chạy seconv. Với file nguồn nhất quán, quy tắc "Fix common errors" cho dòng dài trong Subtitle Edit có thể tự động hóa bước này.

Cách chạy lệnh chuyển đổi SRT sang SCC với SeConv?

Tôi dùng SeConv - giao diện command-line của Subtitle Edit - cho việc chuyển đổi này. Nó xử lý đúng việc mã hóa byte CEA-608 và ánh xạ timestamp millisecond sang SMPTE timecode.

# Chuyển một file SRT sang SCC drop-frame tại 29.97 fps
seconv.exe in.srt ScenaristClosedCaptionsDropFrame --fps:29.97 --output-folder:out --overwrite

# Chuyển hàng loạt cả thư mục
seconv.exe *.srt ScenaristClosedCaptionsDropFrame --fps:29.97 --output-folder:out --overwrite

Ý nghĩa từng tham số:

• in.srt - file nguồn, hoặc glob pattern như *.srt để batch convert
• ScenaristClosedCaptionsDropFrame - tên format SeConv cho SCC drop-frame 29.97 fps. Với master 30 fps non-drop-frame, dùng ScenaristClosedCaptions.
• --fps:29.97 - tốc độ khung hình đích; quyết định cách timestamp millisecond ánh xạ sang số khung trong SCC. Broadcast NTSC hầu như luôn là 29.97.
• --output-folder:out - thư mục đích cho file .scc
• --overwrite - ghi đè file output đã có cùng tên

Mở file .scc trong trình soạn thảo để kiểm tra nhanh: file phải bắt đầu bằng Scenarist_SCC V1.0, và mỗi timecode phải dùng dấu chấm phẩy (00:00:01;00). Dấu hai chấm trong output 29.97 nghĩa là đã dùng nhầm format non-drop-frame.

Cách xác minh file SCC giải mã đúng như thế nào?

File SCC hợp lệ về cú pháp không đồng nghĩa với file SCC chính xác về nội dung. Conversion tạo ra cặp byte hợp lệ vẫn có thể có control codes theo thứ tự sai, khiến decoder hiển thị sai text hoặc bỏ qua caption. Quy trình kiểm tra của tôi dùng caption-inspector - công cụ mã nguồn mở miễn phí từ Comcast, chạy qua Docker:

# Giải mã và QC file SCC bằng caption-inspector
docker run --rm -v /path/to/captions:/data   nebulabroadcast/caption-inspector   -o /data /data/in.scc

Lệnh này tạo ra ba file trong cùng thư mục:

• in-C1.608 - giải mã văn bản CEA-608 stream đúng như decoder thực tế nhìn thấy. Đây là file tôi đọc để xác nhận text đầy đủ và chính xác.
• in-S1.708 - lớp service CEA-708 (file SCC-only sẽ có dữ liệu 708 tối thiểu)
• in.ccd - chi tiết byte ở cấp ký tự, hữu ích khi debug lỗi mã hóa

Trong file -C1.608, tôi tìm: từ bị cắt, sự kiện caption bị thiếu, ký tự bị nhiễu, và control codes đến sai thứ tự. Nếu text đọc rõ ràng và timing hợp lý, file SCC sẵn sàng giao.

Cần kiểm tra gì trong file SRT trước khi chuyển đổi?

Một số vấn đề xuất hiện thường xuyên khi tôi chuyển SRT chưa được viết cho delivery 608:

• Dòng hơn 32 ký tự - tách ra. Encoder sẽ cắt hoặc xuống dòng tự động mà không có cảnh báo.
• Văn bản không phải Latin - CEA-608 xóa hoặc làm nhiễu ký tự ngoài bảng Latin của nó, không có thông báo lỗi. Xóa hoặc thay thế trước khi chuyển đổi.
• Hơn 4 dòng trong một sự kiện - tách thành hai sự kiện với khoảng trống nhỏ giữa chúng.
• Timecode chồng lấp hoặc sự kiện thời lượng không - dùng "Fix common errors" của Subtitle Edit. Hệ thống QC của broadcaster sẽ từ chối các lỗi này.
• Thẻ HTML - <b>, <i>, <u> chuyển thành CEA-608 formatting codes. Kiểm tra mỗi thẻ được đóng đúng trong từng sự kiện.

Khi nào chuyển đổi format là đủ, khi nào cần làm caption từ đầu?

Lệnh seconv từ SRT được viết đúng sẽ tạo ra file SCC hợp lệ kỹ thuật. Nhưng tiêu chuẩn chất lượng closed-captioning của FCC đòi hỏi nhiều hơn định dạng file. Các tiêu chí FCC - độ chính xác, đồng bộ, đầy đủ, và vị trí - yêu cầu caption phản ánh đúng những gì được nói và nghe, bao gồm hiệu ứng âm thanh, cue nhạc, và nhận dạng người nói.

Ranh giới tôi đặt ra: nếu SRT gốc được viết như file closed-caption (có cue âm thanh kiểu [TIẾNG CHUÔNG CỬA], nhận dạng người nói, ký hiệu nhạc), thì seconv sang SCC là broadcast-safe. Nếu SRT là track phụ đề ngoại ngữ - chỉ đối thoại, không có cue âm thanh - thì kết quả chuyển đổi vượt qua kiểm tra format nhưng thất bại kiểm tra khả năng tiếp cận thính giác.

Với closed-caption tiếng Anh giao cho broadcaster Mỹ hoặc nền tảng cần tuân thủ FCC, tôi xử lý toàn bộ quy trình closed-caption - từ viết caption đến xuất SCC và QC bằng caption-inspector. Nếu dự án cũng cần dịch phụ đề sang ngôn ngữ khác cùng với caption tiếng Anh, dịch thuật phụ đề là bước tiếp theo.

Câu hỏi thường gặp

Drop-frame timecode là gì và tại sao SCC cần nó?

Video NTSC chạy ở đúng 29.97 fps, không phải 30 fps tròn. Drop-frame timecode bù đắp bằng cách bỏ qua số khung 0 và 1 ở đầu mỗi phút (trừ mỗi phút thứ 10), giữ đồng hồ timecode căn chỉnh với thời gian thực. Trong file SCC, drop-frame dùng dấu chấm phẩy: 00:00:59;29 tiếp theo là 00:01:00;02 (bỏ qua ;00 và ;01). Non-drop-frame dùng dấu hai chấm. Với chương trình broadcast 30 phút, non-drop-frame lệch gần 2 giây - đủ để caption lạc sync rõ ràng. Chỉ định ScenaristClosedCaptionsDropFrame và --fps:29.97 trong SeConv xử lý điều này tự động.

SCC và MCC khác nhau như thế nào?

SCC (Scenarist Closed Captions) chỉ mang dữ liệu CEA-608. MCC (MacCaption) mang cả CEA-608 lẫn CEA-708 trong một file duy nhất, bọc trong định dạng VANC độc quyền. Broadcaster yêu cầu 708 có thể yêu cầu MCC. Tuy nhiên, xuất MCC bằng công cụ mã nguồn mở - kể cả output MacCaption của Subtitle Edit - có thể tạo ra lớp service CEA-708 không đáng tin cậy. Trong quy trình của tôi, tôi giao content service 708 dưới dạng SMPTE-TT (ST 2052-1) XML thay vì MCC tự xây, và dùng SCC cho deliverable 608-only. Trang caption QC có thêm chi tiết.

Điều gì xảy ra nếu dòng SRT dài hơn 32 ký tự?

Hành vi phụ thuộc vào encoder. SeConv có thể cắt im lặng ở ký tự thứ 32, hoặc thử xuống hàng phần còn lại. Dù theo cách nào, những gì người xem thấy sẽ khác với SRT gốc. Quy trình an toàn: bật hiển thị số ký tự trong Subtitle Edit (View > Show character count per line) và tách thủ công dòng nào hơn 32 ký tự trước khi chạy seconv. Quy tắc "Split long lines" trong "Fix common errors" của Subtitle Edit có thể tự động hóa bước này với source nhất quán.

Có cần chạy caption-inspector cho mỗi file SCC không?

Với deliverable broadcast giao cho broadcaster Mỹ hoặc nền tảng chạy QC tự động, có. Hệ thống ingest của broadcaster sẽ giải mã SCC và gắn cờ lỗi control code - bị từ chối ở bước đó tốn thời gian và phí giao lại. Caption-inspector chạy trong vài giây và phát hiện lỗi mã hóa mà tôi sẽ bỏ qua khi chỉ xem thủ công. Với sử dụng không phải broadcast, kiểm tra "Info" nhanh trong Subtitle Edit thường đủ.

Kiểm tra file video đã có caption nhúng sẵn bằng cách nào?

Dùng ffprobe để xem danh sách stream trước khi làm bất cứ điều gì:

ffprobe -v error -show_entries stream=codec_type,codec_name,tags -of default input.mp4

Tìm stream có codec_name=eia_608 hoặc codec_name=mov_text. Nếu đã có caption nhúng sẵn, extract bằng CCExtractor và so sánh với SRT của bạn trước khi ghi đè nội dung caption hiện có.

Nguồn

• FCC - Closed Captioning on Television - Tiêu chuẩn chất lượng và yêu cầu tuân thủ FCC cho closed captions. Verified tháng 9 năm 2026.
• Subtitle Edit / SeConv (nikse.dk) - Tên format SeConv, tham số command-line và tùy chọn chuyển đổi. Verified tháng 9 năm 2026.
• Comcast caption-inspector (GitHub) - Docker usage, mô tả file output (-C1.608, -S1.708, .ccd). Verified tháng 9 năm 2026.
• Tài liệu CCExtractor - Extract stream caption CEA-608/708 từ container video. Verified tháng 9 năm 2026.