Tìm phụ đề kết thúc trước khi bắt đầu
Hoặc dán văn bản phụ đề
Tùy chọn
Các mốc thời gian được tính theo frame rate nào. Trên các trang định dạng, đây là thông số MicroDVD cần, vì định dạng này lưu thời gian dưới dạng số khung hình. Trên các trang frame rate, đây là tốc độ mà tệp được tính theo — phiên bản mà phụ đề được làm cho — và ô thứ hai của trang nhận tốc độ của video mà bạn sẽ dùng phụ đề cùng. 23.976, 24, 25, 29.97, 30, 50, 59.94 và 60 là những giá trị thường gặp. Điền sai sẽ làm lệch toàn bộ dòng thời gian, và trên các trang frame rate, nó làm lệch theo một tỉ lệ chứ không phải một lượng cố định.
Một cue kết thúc trước khi nó bắt đầu là một timecode không thể đúng: 00:00:03,000 --> 00:00:03,000, hoặc tệ hơn, thời điểm kết thúc nằm trước thời điểm bắt đầu. Trang này báo cáo những tệp từng chứa cue như vậy, đếm từ các sửa chữa mà trình đọc buộc phải làm, vì một timecode có hình dạng đó không thể được giữ trong bộ nhớ và được thay bằng một timecode thật trước khi bất cứ việc gì khác diễn ra. Thứ quay về là báo cáo, không bao giờ là tệp đã bị sửa.
Đó là lý do báo cáo mở đầu bằng những gì bị mất khi đọc rồi mới tới phát hiện. Cue có thời điểm kết thúc không sau thời điểm bắt đầu được cấp một mili giây để phần còn lại của tệp có thể được đọc, xem trước và xuất; số lần sửa như vậy nằm ở phần đầu báo cáo, còn phát hiện bên dưới ghi một lỗi mà không có số cue, vì các lần sửa được đếm trong lúc đọc chứ không được giữ thành danh sách. Hai dòng mô tả cùng một timecode hỏng từ hai phía, và đó là lý do chúng thuộc về cùng một báo cáo thay vì hai báo cáo.
Cái bẫy mà trang này phải viết vòng qua là một cue một mili giây hợp lệ trông giống hệt một cue đã được sửa. Vì vậy phép kiểm tra không nhìn vào thời lượng chút nào — nó nhìn vào bản ghi sửa chữa — và một cue thực sự kéo dài một mili giây được để yên. Thời lượng âm và thời lượng bằng 0 là cùng một lỗi và được đếm chung. Hai định dạng hoàn toàn không được nhận, và lần này lý do ở cả hai phía là như nhau: LRC suy ra thời điểm kết thúc từ mốc thời gian kế tiếp nên một cặp ở đó không bao giờ có thể chạy ngược, còn văn bản thuần không có thời gian cue nào cả. Kiểm tra một trong hai sẽ tạo ra báo cáo sạch về một trường mà định dạng đó không có, và đó là kiểu câu trả lời tệ hơn cả việc không trả lời.
Ví dụ
Một cue không có thời lượng
Phụ đề
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
Báo cáo tìm thấy gì
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Thời điểm kết thúc bằng thời điểm bắt đầu. Trình đọc cấp cho cue một mili giây để tệp có thể được giữ, ghi lại việc sửa, và báo cáo in cả hai nửa: dòng mất mát ở phần đầu và một lỗi bên dưới. Việc sửa là bằng chứng; một mili giây chỉ là hình dạng mà bằng chứng mang.
Một cue thật sự kéo dài một mili giây
Phụ đề
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
Báo cáo tìm thấy gì
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Được viết tay như một cue một mili giây và không bị báo. Quyết định đó định hình toàn bộ phép kiểm tra: một cue dài 0 đã được sửa cũng cho ra một mili giây, nên một quy tắc gắn cờ thời lượng ngắn ở đây sẽ gọi mọi tệp có timecode hỏng là tệp đầy cue ngắn đến mức không thể.
Thời điểm kết thúc nằm trước thời điểm bắt đầu
Phụ đề
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
Báo cáo tìm thấy gì
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Từ năm giây đến hai giây: cùng một lỗi như trường hợp dài 0, được đếm bằng cùng một quy tắc và được báo giống hệt. Không gì trong tệp bị viết lại — các mốc thời gian đã sửa chỉ tồn tại trong bản sao của trình đọc để phần còn lại của tệp có thể được xử lý, và chúng không phải là một bản sửa mà trang này đang cung cấp.
Câu hỏi thường gặp
Trang này coi thế nào là cue kết thúc trước khi bắt đầu?
Là thời điểm kết thúc không muộn hơn thời điểm bắt đầu: hoặc bằng nó, như 00:00:03,000 đến 00:00:03,000, hoặc sớm hơn, như 00:00:05,000 đến 00:00:02,000. Cả hai là cùng một lỗi và được đếm chung, và cả hai được đếm từ lần sửa mà trình đọc thực hiện chứ không từ cue, vì một timecode có hình dạng đó không thể được giữ trong bộ nhớ.
Vì sao báo cáo không nêu số thứ tự các cue liên quan?
Vì những lần sửa này được đếm trong lúc đọc tệp chứ không được gom thành danh sách. Báo cáo đưa ra con số — một lỗi, một mục ở dòng mất mát phần đầu — và hai nửa đó là cùng một sự kiện nhìn từ phần đầu và từ phần phát hiện. Nếu cần đúng cue nào, hãy tìm trong tệp theo số lượng timecode của nó chứ không theo số thứ tự cue.
Cue kéo dài đúng một mili giây có phải vấn đề không?
Không phải ở đây, và đó là cố ý. Một cue một mili giây viết tay là hợp lệ và không bị báo; thứ bị báo là timecode đã phải sửa, mà sau khi sửa tình cờ được lưu thành một mili giây. Kiểm tra thời lượng thay vì kiểm tra bản ghi sửa sẽ gắn cờ mọi tệp chứa cue dài 0 là tệp đầy cue ngắn đến mức không thể, tức là sai hai lần.
Trang kiểm tra timecode có sửa các timecode tìm thấy không?
Không. Các mốc thời gian đã sửa chỉ tồn tại bên trong trình duyệt để phần còn lại của tệp có thể được đọc và báo cáo. Tệp bạn tải xuống hay kéo vào không thay đổi, và không có cách nào lưu phiên bản đã sửa từ trang này — thay một timecode hỏng là một thao tác có tệp phụ đề làm đầu ra, không phải một phép kiểm tra.
Những định dạng phụ đề nào kiểm tra được cue kết thúc trước khi bắt đầu?
Mười trong mười hai định dạng: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON và CSV. Hai định dạng vắng mặt và không cái nào là sơ suất. LRC lưu một mốc thời gian mỗi dòng và trình đọc suy ra thời điểm kết thúc từ mốc kế tiếp, nên một cặp ở đó không bao giờ có thể chạy ngược — phép kiểm tra sẽ đánh giá một trường mà định dạng không có. Văn bản thuần không có thời gian cue nào. Nếu tệp của bạn thuộc một trong hai định dạng đó, hãy chuyển đổi trước.
Những timecode hỏng này thường đến từ đâu?
Hầu như luôn được sinh ra chứ không phải được gõ tay. Một lần chuyển frame rate làm tròn sai hướng, một phép dịch thời gian áp hai lần lên cùng một cue, một lần xuất bảng tính mà cột kết thúc bị bỏ trống và được đọc thành 0, và một phụ đề được trích từ tệp văn bản có mốc thời gian vốn không có thời lượng ngay từ đầu.
Có thể kiểm tra nhiều tệp trong cùng một lần chạy không?
Được. Thả vào bao nhiêu tệp cũng được và chúng được đọc lần lượt, mỗi tệp tạo báo cáo riêng, và các báo cáo được tải xuống cùng nhau dưới dạng tệp zip. Hàng đợi hiển thị tiến độ theo từng tệp, có thể hủy giữa chừng, và không tệp nào bị tải lên ở bất kỳ thời điểm nào.