Video & subtitle · Perangkat Subtitle
Kecepatan bingkai dan subtitle: mengapa 23.976, 25, dan 29.97 fps menyebabkan penyimpangan
· Latar belakang
subtitle kecepatan bingkai kode waktu
Frame rate adalah warisan televisi analog, dan masih menghantui waktu teks. Postingan ini menjelaskan dari mana angka ganjil itu berasal, bagaimana ketidakcocokan kecepatan bingkai menghasilkan penyimpangan, dan bagaimana mempertimbangkannya sebelum memperbaiki apa pun.
Teks yang disinkronkan ke satu master menyimpang ke master lainnya — hasil praktis dari standar televisi selama satu abad
File keterangan dapat disejajarkan secara sempurna dengan satu master dan menyelesaikan beberapa menit atau detik dari dialog di master lainnya meskipun tidak ada isyarat yang diedit. Pola tersebut menyimpang: waktu subtitle yang telah berlalu dan waktu program yang telah berlalu meningkat dengan kecepatan yang berbeda. Pembukaan tersebut memberikan sedikit bukti karena mengalikan waktu yang kecil menghasilkan kesalahan yang kecil; penutupannya membuat ketidakcocokan menjadi jelas.
Alur kerja televisi dan film mewarisi beberapa tingkat yang berjarak dekat, sehingga file yang diberi label hanya dengan judul dan bahasa mungkin kehilangan konteks yang diperlukan untuk menafsirkan waktunya. Perbaikan praktis dimulai dengan mengidentifikasi hubungan tingkat suku bunga dibandingkan menerapkan offset yang menyelaraskan satu situasi dan membiarkan pertumbuhan tidak tersentuh.
Dari mana 24, 25 dan 30 berasal — proyeksi film dan frekuensi utama televisi Eropa dan Amerika
Tarif bilangan bulat seperti 24, 25 dan 30 mencerminkan garis produksi dan televisi yang berbeda. Film umumnya diasosiasikan dengan 24 frame per detik, sedangkan sistem televisi dibangun berdasarkan kendala listrik dan penyiaran regional yang menyebabkan tarif nominal berbeda. Asal usul yang luas tersebut adalah latar belakang yang stabil; artikel ini tidak menetapkan tanggal penemuan atau mengklaim satu jalur universal dari frekuensi listrik ke setiap format modern.
Fakta restorasi yang penting adalah bahwa angka ini mewakili durasi yang berbeda untuk jumlah frame yang sama. Seratus ribu frame yang diputar pada 25 fps selesai lebih cepat dibandingkan frame yang sama yang diputar pada 24 fps, sehingga subtitle yang dibuat dalam satu durasi tidak dapat tetap selaras dengan durasi lainnya tanpa pengaturan waktu ulang yang proporsional.
Mengapa 29.97 dan 23.976 ada — kompromi televisi berwarna dan dampaknya terhadap transfer film
Tarif pecahan mendekati 30 dan 24 adalah bagian dari warisan televisi berwarna dan transfer film. Riwayat rekayasa tepatnya berada di luar sumber repositori, jadi artikel ini tidak mengulangi rumus subcarrier secara mendetail. Yang penting untuk pembuatan subtitle adalah 29.97 bukan 30 dan 23.976 bukan 24; memperlakukan salah satu pasangan sebagai identik menimbulkan persentase kesalahan kecil yang terakumulasi seiring berjalannya waktu.
Singkatan desimal juga dibulatkan. Alur kerja harus menggunakan metadata laju persis yang tersedia dari master, bukan mengambil faktor dari label tiga desimal ketika presisi penting. Alat ini menerima faktor skala numerik; itu tidak memeriksa metadata video atau mengidentifikasi tingkat mana yang membuat teks.
PAL percepatan — mengapa film berjalan sedikit lebih cepat pada transfer 25 fps dan apa pengaruhnya terhadap pengaturan waktu
Pengiriman materi asal film dengan kecepatan 25 fps yang umum menjalankan frame lebih cepat daripada master yang kira-kira 24 fps. Hal ini sering disebut percepatan PAL. Setiap peristiwa terjadi lebih cepat, sehingga teks yang diatur waktunya ke master yang lebih lambat semakin lambat saat digunakan tanpa perubahan dengan transfer yang lebih cepat. Urutan kata dan isyarat tetap benar; hanya hubungan jamnya yang salah.
Hal ini tidak diperbaiki dengan menggerakkan setiap isyarat pada jarak yang sama. Pergeseran adalah penambahan, sedangkan kesalahan ini mengubah jarak dari nol ke setiap isyarat. Operasi yang diperlukan adalah perkalian, dan arahnya penting: ketika tujuan berjalan lebih cepat, stempel waktu dari sumber yang lebih lambat memerlukan faktor di bawah satu agar menjadi lebih awal.
Dari kecepatan bingkai hingga penyimpangan teks — bagaimana perbedaan persentase kecepatan yang tetap menjadi kesalahan kode waktu yang semakin besar
Perbedaan persentase kecepatan yang konstan menghasilkan kesalahan yang sebanding dengan waktu yang berlalu. Sepuluh menit dalam suatu program, kesalahan absolutnya kecil; sembilan puluh menit di dalamnya adalah sembilan kali kesalahan sepuluh menit. Pertumbuhan garis lurus itulah yang menjadi alasan mengapa dua pos pemeriksaan membedakan ketidakcocokan laju dari trim intro yang konstan: kesalahan yang sama menunjukkan adanya pergeseran, sedangkan kesalahan akhir yang lebih besar menunjukkan penskalaan atau bentuk penyimpangan lainnya.
ToolAcre menyimpan stempel waktu sebagai bilangan bulat milidetik dan scaleCues mengalikan kedua batas dengan faktor yang dipilih, membulatkan masing-masing ke milidetik terdekat dan menjepit pada nol. Oleh karena itu, penskalaan kurang dapat dibalik dibandingkan dengan pergeseran. Bekerja dari file isyarat asli dan terapkan satu faktor terhitung alih-alih menyempurnakan beberapa ekspor yang dibulatkan.
Contoh praktis: film berdurasi 90 menit dipindahkan dari master 23.976 ke master 25 fps — memperkirakan penyimpangan di bagian akhir
Untuk file subtitle berdurasi sembilan puluh menit yang dibuat berdasarkan materi 23.976 fps dan digunakan dengan transfer 25 fps pada frame yang sama, kalikan stempel waktu sumber dengan 23.976 dibagi 25, kira-kira 0.95904. Sumber yang berakhir pada 5,400 detik menjadi sekitar 5,178.8 detik, sehingga master yang lebih cepat menyelesaikan sekitar 221.2 detik lebih awal. Estimasi tersebut mengasumsikan urutan frame yang sama dan perubahan laju yang seragam.
Perjalanan sebaliknya menggunakan 25 dibagi 23.976, kira-kira 1.0427, yang merupakan contoh yang didokumentasikan di samping bidang skala. Verifikasi hasil yang dihitung terhadap dialog nyata di kedua ujungnya. Jika perbedaan konstan sisa tetap ada setelah koreksi proporsional, maka terapkan offset terukur.
Apa yang tidak tercakup dalam hal ini — perekaman kecepatan bingkai variabel dan penghapusan pull-down
Perekaman kecepatan bingkai variabel tidak memberikan satu faktor untuk keseluruhan program, dan materi yang dikumpulkan dari beberapa konversi kecepatan dapat mengubah perilaku pada titik pengeditan. Penghapusan pulldown menambahkan lapisan lain karena irama bingkai dan kecepatan bingkai yang ditampilkan tidak ditangkap oleh daftar stempel waktu subtitle sederhana. Sebuah skala global tidak dapat memperbaiki kasus-kasus tersebut dengan jujur.
Alat shift juga tidak dapat mengatur ulang rentang waktu yang dipilih. Jika teksnya benar hingga dipotong dan kemudian melonjak dengan jumlah yang tetap, itu merupakan ketidakcocokan edit, bukan penyimpangan laju yang mulus. Pertahankan sumbernya dan pindah ke editor yang peka terhadap garis waktu yang dapat mengoreksi segmen secara mandiri.
Kesimpulan: penyimpangan memiliki penyebab yang dapat Anda sebutkan — cara mendiagnosisnya sebelum menggunakan fitur retime pada Perangkat Subtitle
Beri nama kesalahan sebelum mengubahnya. Bandingkan isyarat yang jelas di dekat awal dengan isyarat di dekat akhir, catat arah dan besarnya kedua kesalahan, dan cari perilaku konstan versus proporsional. Penyimpangan kecepatan bingkai memerlukan penskalaan dari nol; bemper yang dilepas memerlukan satu offset; pengeditan di tengah program memerlukan pekerjaan regional yang tidak disediakan oleh alat ini.
Gunakan Shift subtitle timing hanya setelah diagnosis tersebut. Masukkan faktor skala positif, periksa keluaran yang dibulatkan pada kedua titik pengukuran dan unduh file baru daripada menimpa master. Implementasinya melakukan aritmatika yang Anda tentukan; itu tidak menyimpulkan sejarah video untuk Anda.