Konversi akhir baris subtitle
Atau tempel teks subtitle
Opsi
Setiap baris dalam file berakhir dengan satu karakter tak terlihat (LF) atau dua karakter (CRLF). Pemutar, editor, dan alat subtitle semuanya membaca keduanya, jadi ini hampir tidak pernah menjadi penyebab file subtitle berperilaku aneh — dua penyebabnya adalah pipeline build atau parser ketat yang menolak yang lain, dan alat diff yang menampilkan setiap baris sebagai berubah karena akhir barisnya berbeda. LF menjadi pilihan bawaan di sini karena itulah yang dipakai Unix, macOS, dan web, dan karena file yang sudah memakainya dibiarkan. Memilih CRLF mengonversi kedua jenis akhir baris yang ada, sehingga file dengan campuran keluar konsisten.
Frame rate yang dipakai untuk menghitung waktu. Di halaman format, inilah yang dibutuhkan MicroDVD, karena format itu menyimpan waktu sebagai nomor frame. Di halaman frame rate, ini adalah laju yang dipakai saat file diberi waktu — versi tempat subtitle dibuat — dan kotak kedua di halaman tersebut menerima laju video yang akan Anda gunakan bersama subtitle ini. 23,976, 24, 25, 29,97, 30, 50, 59,94, dan 60 adalah nilai yang umum. Nilai yang salah akan menggeser seluruh timeline, dan di halaman frame rate pergeserannya berupa rasio, bukan jumlah tetap.
Akhir baris adalah karakter atau pasangan karakter yang mengakhiri sebuah baris, dan ada dua yang dipakai sehari-hari. Sistem Unix mengakhiri baris dengan satu karakter, LF; Windows mengakhirinya dengan dua, CR lalu LF. Keduanya tampak sama di layar dan dibaca sama oleh pemutar subtitle, sehingga perbedaan ini termasuk yang tetap tak terlihat sampai ada sesuatu di hilir yang mempermasalahkannya.
Yang mempermasalahkannya: kontrol versi, tempat setiap baris file bisa tampak berubah karena akhir barisnya berubah; skrip build dan pipeline yang memotong karakter terakhir suatu baris lalu menyisakan carriage return liar padahal mengharapkan newline; alat yang memecah file pada LF dan berakhir dengan carriage return menempel pada field terakhir; serta spesifikasi pengiriman yang menyebut salah satu dari keduanya. File subtitle yang harus dibandingkan dengan file lain, atau digabung dengan file lain, adalah file yang akhir barisnya menjadi bagian dari antarmukanya.
Halaman ini sengaja seragam dalam keluarannya. File dengan akhir campuran — sebagian baris CRLF karena disunting di Windows, sebagian LF karena disunting di tempat lain — keluar seluruhnya dalam gaya yang Anda pilih, karena halaman menormalkan akhir baris ke LF lebih dulu lalu menerapkan pilihan Anda. Itu bukan hal yang sama dengan mengonversi akhir baris yang sudah benar dan membiarkan sisanya: artinya jawaban atas “gaya apa file ini” berhenti bergantung pada baris mana yang Anda lihat, dan hanya versi jawaban itu yang berguna bagi skrip.
Carriage return tunggal, akhir baris Mac sebelum OS X, ditangani bersama yang lain. Tidak ada yang memilihnya lagi, tetapi file masih muncul membawanya, dan file yang barisnya berakhir begitu merupakan satu baris panjang bagi setiap alat yang hanya mencari LF. Menormalkan lebih dulu membuat file itu keluar dengan benar alih-alih keluar sebagai satu cue raksasa.
Kedua panel di halaman ini adalah satu-satunya tempat di keluarga ini yang perbedaannya terlihat langsung: akhir baris adalah karakter nyata, dan file dengan baris yang tampak berjarak ganda di penampil yang tidak menyembunyikannya adalah file CRLF. Kedua belas format diterima, karena akhir baris adalah sifat teks, bukan sifat format subtitle — transkrip teks biasa pun punya baris. Tidak ada yang diunggah, dan file dibaca, diubah, serta ditulis di peramban Anda.
Contoh
Mengonversi file Unix ke akhir baris Windows
Masukan
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Keluaran
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Setiap akhir baris menjadi dua karakter, termasuk baris kosong di antara cue — baris kosong itu juga akhir baris, dan konversi yang melewatinya akan meninggalkan file yang pemisah cue-nya masih LF tunggal. Teks yang diharapkan menuliskan akhir baris sebagai pasangan CR LF agar jumlahnya bisa dibaca langsung, dan tidak ada bagian lain file yang bergeser.
Mengonversi file Windows kembali ke akhir baris Unix
Masukan
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Keluaran
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Arah yang akibatnya terlihat. File yang menyisakan carriage return tampil di sebagian editor sebagai punya baris kosong setelah setiap baris, dan di pipeline shell sebagai carriage return yang menempel di akhir field terakhir. Video, timecode, dan teks identik pada kedua file; perbedaannya adalah satu karakter di akhir setiap baris, dan inilah arah yang menghapusnya.
File yang disunting di dua mesin, diseragamkan
Masukan
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Keluaran
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
File yang sama disentuh di dua mesin: sebagian baris berakhir CRLF, sebagian LF, dan satu pemisah cue ditulis dengan masing-masing cara. Keluarannya seragam, dan itulah intinya — file tidak lagi bermakna berbeda tergantung baris yang Anda baca. Pencarian-dan-ganti naif salah pada kasus ini di kedua arah: ia membiarkan baris LF saat menuju CRLF, dan menghasilkan carriage return ganda saat arah sebaliknya.
Pertanyaan yang sering diajukan
Bagaimana saya bisa melihat akhir baris yang dipakai file subtitle?
Di sebagian besar editor, gaya akhir baris ditampilkan di bilah status sebagai LF, CRLF, atau campuran. Dari shell, file yang barisnya berakhir CRLF menunjukkan carriage return di akhir setiap baris saat dilihat dengan alat yang menampilkan karakter kontrol. Uji langsungnya adalah melihat byte di akhir baris: 0A tunggal adalah LF dan pasangan 0D 0A adalah CRLF.
Apa yang dilakukan halaman ini pada file subtitle dengan akhir baris campuran?
Halaman membuat semuanya sama. File dinormalkan ke LF lebih dulu lalu dikonversi ke gaya yang Anda pilih, sehingga file yang sebagian barisnya berakhir satu cara dan sebagian lain keluar sepenuhnya seragam, bukan setengah terkonversi. File menjadi begitu karena disunting di lebih dari satu mesin, dan campuran itulah yang membuat perbandingan dengan salinan lain tidak terbaca.
Apakah akhir baris mengubah timing subtitle atau teks cue?
Tidak. Cue, nomornya, waktu mulai dan selesainya, serta kata di dalamnya semuanya identik sebelum dan sesudah; yang berubah adalah satu atau dua karakter di akhir setiap baris. Pemutar membaca kedua file dengan cara yang sama, dan itulah sebabnya konversi ini bisa dilakukan demi syarat pengiriman tanpa mengkhawatirkan subtitle-nya sendiri.
Sebaiknya akhir baris subtitle saya ubah ke LF atau CRLF?
LF kecuali ada sesuatu di depan Anda yang menyebut CRLF. Itu yang diharapkan alat Unix, sebagian besar pipeline build, dan spesifikasi WebVTT, serta membuat file lebih pendek satu byte per baris. Pilih CRLF bila spesifikasi pengiriman atau alat khusus Windows memintanya, dan perhatikan bahwa pilihannya per file, bukan global: file subtitle yang dikirim sendiri bisa berbeda dari bagian lain proyek.
Mengapa konversi ke CRLF juga mengubah baris kosong di antara subtitle?
Karena baris kosong itu adalah baris, dan akhirnya juga akhir baris seperti yang lain. SRT memisahkan cue dengan baris kosong, jadi file yang dikonversi ke CRLF tetapi pemisah cue-nya tetap LF tunggal akan memiliki satu akhir baris berbeda jenis di tengah file yang seragam — persis campuran yang ingin dihapus halaman ini. Hal yang sama berlaku untuk baris terakhir file.
Apakah carriage return Mac lama ikut dikonversi?
Ya. File yang barisnya berakhir dengan carriage return tunggal, gaya Mac OS sebelum OS X, dinormalkan bersama yang lain, sehingga keluar dalam gaya yang Anda pilih alih-alih tetap sebagai satu cue panjang. Tidak ada pilihan CR di panel karena tidak ada yang menulis file begitu lagi, tetapi file yang sudah begitu dibaca dan ditulis ulang dengan benar.