Video và phụ đề · Bộ công cụ phụ đề
Tại sao lỗi thời gian phụ đề nhỏ lại khiến người xem dễ nhận thấy
· Tại sao nó quan trọng
phụ đề mã thời gian khả năng tiếp cận
Người xem nhanh chóng phát hiện ra phụ đề không đồng bộ, ngay cả khi lỗi chỉ là một phần nhỏ của giây. Bài đăng này giải thích một cách định tính lý do tại sao mắt và tai lại nhạy cảm với nó đến vậy, lỗi đồng bộ hóa phát sinh như thế nào trong quy trình làm việc cũng như cách đo lường và khắc phục chúng.
Các bình luận cho biết phụ đề có vẻ sai nhưng không ai có thể nói tại sao - vấn đề về cảm nhận với lỗi đồng bộ hóa
Các báo cáo luôn mơ hồ. Người xem cho biết phụ đề khiến họ cảm thấy khó chịu, mất tập trung hoặc họ đã ngừng sử dụng chúng và hiếm khi nói mức độ hoặc theo hướng nào. Sự mơ hồ đó là đặc tính của lỗi chứ không phải của khán giả: sự không phù hợp được nhận thấy từ rất lâu trước khi nó có thể đo lường được đối với một người không tìm kiếm nó.
Điều đó cũng có nghĩa là khiếu nại được gửi đến mà không có thông tin cần thiết để giải quyết. Bước đầu tiên hữu ích không phải là điều chỉnh bất cứ điều gì mà là biến ấn tượng thành hai con số, hướng và độ lớn.
Tại sao chúng ta để ý — đọc một dòng trước hoặc sau khi nghe nó sẽ phá vỡ mối liên kết giữa lời nói và văn bản
Chú thích được đọc trong khi nghe những từ giống nhau, do đó, hai luồng được khớp liên tục thay vì thỉnh thoảng được kiểm tra. Khi văn bản đến trước bài phát biểu, nó sẽ được đọc trước, điều này sẽ loại bỏ thời điểm mà nó nhằm hỗ trợ; khi nó đến sau, nó xác nhận điều gì đó đã được hiểu. Dù thế nào đi nữa, người đọc đã làm việc khiến việc tính thời gian trở nên vô nghĩa.
Đây là lý do tại sao dung sai lại không đối xứng trong thực tế. Chú thích hơi muộn có xu hướng bị đọc là trễ, trong khi chú thích hơi sớm có thể làm hỏng một dòng trước khi nó được chuyển tải, điều này có hại cho phim hài và chính kịch hơn là độ trễ tương đương.
Trường hợp lỗi đồng bộ hóa xâm nhập vào quy trình làm việc — cắt bớt phần giới thiệu sau khi tạo phụ đề, mã hóa lại ở tốc độ khung hình khác hoặc xuất với thời gian bắt đầu khác
Hầu hết các lỗi đồng bộ hóa đều xuất hiện sau chú thích chứ không phải trong lúc chú thích. Việc cắt bớt phần giới thiệu, phương tiện chặn hoặc đếm ngược sẽ di chuyển mọi khung hình tiếp theo trong khi vẫn giữ nguyên dấu thời gian của phụ đề. Mã hóa lại ở tốc độ khung hình khác sẽ điều chỉnh lại vật liệu theo dấu thời gian tuyệt đối. Việc xuất với mã thời gian bắt đầu khác 0 sẽ bù đắp cho chương trình so với tệp bắt đầu bằng 0.
Trong mỗi trường hợp, tệp phụ đề không thay đổi và vẫn nhất quán bên trong, đó là lý do tại sao việc xác thực vượt qua và tệp trông có vẻ chính xác một cách riêng biệt. Lỗi nằm ở mối quan hệ giữa hai đồ tạo tác chứ không phải ở bên trong một đồ vật nào.
Bù đắp và trôi dạt - phân biệt hai điều này sau vài phút xem
Việc phân biệt độ lệch với độ lệch mất vài phút và quyết định áp dụng hiệu chỉnh nào. Xem một dòng gần đầu và một dòng gần cuối. Nếu cả hai đều sai ở mức độ như nhau thì lỗi sẽ được bù không đổi và một ca duy nhất sẽ khắc phục được. Nếu phần kết tệ hơn phần mở đầu thì lỗi ngày càng lớn, tức là trôi dạt và việc dịch chuyển sẽ làm cho phần kết tệ hơn trong khi dường như đã sửa được phần mở đầu.
Công cụ ghi lại chính xác đây là một lỗi phổ biến vì đây là một hành động sai về mặt trực quan: việc sắp xếp dòng đầu tiên của một tệp trôi dạt là thỏa mãn và có hại, đồng thời cả hai thao tác phải được hoàn tác trước khi mở rộng quy mô.
Đo lường lỗi - sử dụng đồng hồ của người chơi và dòng đầu tiên rõ ràng thay vì đoán
Đo theo đồng hồ của người chơi thay vì theo số lần hiển thị. Chọn một dòng bắt đầu sắc nét, từ đầu tiên sau khoảng lặng thay vì một cụm từ trong bài phát biểu liên tục và lưu ý thời gian chú thích xuất hiện và thời gian từ đó được nghe. Lặp lại gần cuối chương trình. Hai phép đo trên những sự khởi đầu rõ ràng có giá trị hơn hàng tá những đánh giá về những sự khởi đầu mơ hồ.
Ghi lại hướng đi một cách rõ ràng vì lỗi ký hiệu là phổ biến. Các chú thích xuất hiện trước đoạn hội thoại cần có sự bù đắp tích cực để trì hoãn chúng; một phần bù âm sẽ di chuyển chúng sớm hơn và nhân đôi lỗi.
Ví dụ đã hoạt động: phần giới thiệu được cắt bớt đã dịch chuyển mọi thứ trong 1.2 giây — chẩn đoán và sửa lỗi đó
Lấy một chương trình trong đó phần giới thiệu dài một giây thứ năm được cắt bớt sau khi có chú thích. Giờ đây, mọi chú thích sẽ xuất hiện sau dòng của nó một giây rưỡi. Phép đo lúc bắt đầu cho biết trễ 1200 mili giây; phép đo gần cuối cũng nói như vậy. Các lỗi bằng nhau có nghĩa là phần bù, vì vậy một ca sẽ sửa tệp.
Nhập nó dưới dạng 1200 chứ không phải 1.2. Trường này mất một phần nghìn giây mà không cần nhập giây hoặc mã thời gian và việc nhập 1 sẽ dịch chuyển tệp theo một mili giây: thao tác thành công, tệp thực sự thay đổi và quá trình đồng bộ hóa trông vẫn sai như trước. Nếu sự thay đổi là âm và bất kỳ tín hiệu nào sẽ vượt qua số 0 thì cảnh báo kẹp sẽ quan trọng vì những tín hiệu đó được ghim vĩnh viễn khi bắt đầu và việc dịch chuyển về phía trước sau đó sẽ không khôi phục chúng.
Điều này không bao gồm những gì - chú thích sai về nội dung hoặc phân chia không hợp lý giữa các dòng
Điều này bao gồm thời điểm chú thích xuất hiện, chứ không phải nội dung chú thích hoặc cách chúng được chia thành các dòng. Một chú thích được đồng bộ hóa hoàn hảo và bị phân đoạn kém vẫn khó đọc và một từ bị phiên âm sai dù ở bất kỳ khía cạnh nào cũng có thể bị sai.
Nó cũng không bao gồm các chú thích bị trôi do bản thân video có tốc độ thay đổi hoặc được tập hợp từ các nguồn ở tốc độ khác nhau. Đó là một bước nhảy chứ không phải là một đoạn đường dốc trơn tru và không một ca hay một thang âm nào có thể sửa được nó.
Bài học rút ra: đo, sau đó dịch chuyển — cách tính năng thời gian lại của Bộ công cụ phụ đề sửa lỗi chênh lệch không đổi trong một lần chuyển
Đo, sau đó dịch chuyển một lần. Trình tự lãng phí thời gian là điều chỉnh bằng cảm nhận, xem lại, điều chỉnh lại, bởi vì mỗi lần vượt qua sẽ thay đổi vật được đo và các tín hiệu bị kẹp sẽ tích lũy ở mức 0 trong suốt quá trình.
Hai quan sát theo thời gian cho biết hướng và độ lớn, và độ lớn được nhập tính bằng mili giây là một thao tác. Xác nhận trên hai dòng tương tự sau đó thay vì chỉ ở phần mở đầu, vì phần mở đầu là nơi việc sửa sai có vẻ thuyết phục nhất.