Video & subtitle · Perangkat Subtitle
Mengapa tag nyasar dalam file subtitle dapat merusak unggahan teks platform
· Mengapa itu penting
subtitle pemrosesan teks webvtt
Platform mengurai unggahan teks secara ketat dan sering kali secara diam-diam. Posting ini menjelaskan alasan umum file subtitle ditolak atau ditampilkan secara aneh, mengapa format tag dan kode adalah penyebab umum dan bagaimana file standar yang bersih menghindari masalah.
Unggahan tersebut diterima dan keterangannya menunjukkan tag literal — kegagalan diam-diam dari file yang tidak bersih
Hasil terburuk bukanlah penolakan. Unggahan yang ditolak memberi tahu Anda ada sesuatu yang salah saat Anda masih melihat formulir. Hasil yang umum adalah penerimaan diikuti dengan teks yang menampilkan markupnya sendiri kepada pemirsa, karena pemeriksaan unggahan dan jalur rendering adalah perangkat lunak berbeda yang menanyakan pertanyaan berbeda.
Pemeriksaan unggahan biasanya menanyakan apakah file diurai menjadi isyarat atau tidak. Render menanyakan apa yang harus dilakukan dengan konten setiap isyarat, dan parser yang mengabaikan tag asing akan menggambarnya sebagai teks. Kedua langkah tersebut melakukan apa yang dirancang untuk mereka lakukan.
Platform apa yang sebenarnya diterima — SRT biasa dan WebVTT dengan struktur yang dapat diprediksi, dan sedikit toleransi terhadap tambahan
Apa yang diterima oleh platform lebih sempit daripada apa yang dikeluarkan oleh alat. Dalam praktiknya, itu berarti SRT atau WebVTT biasa dengan bentuk yang dapat diprediksi: blok dipisahkan oleh garis kosong, baris kode waktu, baris teks, dan lainnya. Toleransi terhadap tambahan sangatlah rendah dan, yang lebih penting, tidak terdokumentasikan, sehingga asumsi yang aman adalah bahwa apa pun di luar bentuk tersebut merupakan risiko, bukan fitur.
Ini bukan konservatisme semata. Sebuah platform yang menerima markup sewenang-wenang harus memutuskan bagaimana merendernya secara konsisten di seluruh klien web, seluler, dan televisi, yang merupakan komitmen yang jauh lebih besar daripada menerima file teks.
Penyebab umum — tag mirip HTML, kode gaya ASS, BOM, akhiran baris campuran, dan isyarat kosong
Pelakunya yang berulang hanya sedikit. Tag kurung sudut untuk huruf miring, suara pembicara, dan kelas isyarat tetap bertahan dalam konversi dari format yang mendukungnya. Kode override yang dibatasi kurung kurawal berasal dari format SubStation dan tidak berarti apa-apa di luar format tersebut. Tanda urutan byte di awal file melekat pada nomor indeks pertama. Akhiran baris campuran dari pemisahan blok jeda pengeditan lintas platform. Isyarat yang teksnya menjadi kosong setelah markup dihapus tetap kosong dengan stempel waktu.
Tak satu pun dari ini yang eksotik. Mereka adalah keluaran normal dari rantai konversi di mana setiap langkah masuk akal secara individual, itulah sebabnya mereka muncul dalam file yang terlihat bagus di editor.
Mengapa satu platform menoleransi penolakan platform lain — parser yang berbeda di balik formulir unggahan serupa
Platform yang berbeda mentolerir subset yang berbeda, dan itulah yang membuat kesalahan tersebut membingungkan untuk didiagnosis. File yang sama dapat diunggah dengan bersih dan dirender dengan benar pada satu layanan, diunggah dan dirender markup pada layanan kedua, dan ditolak oleh layanan ketiga, tanpa pesan kesalahan yang menyebutkan penyebab sebenarnya. File tidak berubah di antara upaya; tiga parser tidak setuju.
Oleh karena itu, memperlakukan satu platform sebagai referensi adalah naluri yang salah. File yang berfungsi pada layanan paling permisif tidak memberi tahu Anda apa pun tentang layanan lain, dan parser yang paling ketat adalah yang menentukan apakah suatu file portabel.
Contoh praktis: satu file, tiga unggahan — bagaimana kekacauan yang sama muncul secara berbeda dan hilang setelah dibersihkan
Ambil satu ekspor yang membawa kode override bagian atas bingkai pada enam puluh isyarat, tag penekanan pada empat puluh, dan tanda urutan byte. Diunggah ke tiga layanan mungkin diterima di mana-mana. Pada tag pertama dihormati dan kode override diambil secara harfiah. Yang kedua keduanya muncul sebagai teks. Pada tanda ketiga, tandanya memerlukan isyarat pertama, yang tidak pernah muncul, dan tidak ada yang memperhatikan karena baris pembuka biasanya berupa judul.
Pembersihan sekali akan menghapus ketiga kelas di sumbernya. Tag kurung sudut dan kode kurung kurawal diganti, spasi yang tertinggal diciutkan, isyarat yang dikosongkan oleh penghapusan dihilangkan alih-alih dikeluarkan sebagai blanko yang diberi stempel waktu, dan file ditulis ulang dengan isyarat yang dinomori ulang secara berdekatan dari satu. Output yang sama kemudian disalurkan ke ketiga layanan.
Apa yang tidak tercakup di sini — panduan gaya khusus platform, batas karakter per baris, dan teks bawaan
Hal ini mencakup portabilitas struktural, bukan kesesuaian editorial. Panduan gaya platform mengenai panjang garis, karakter maksimum, posisi label speaker, dan penanganan efek suara merupakan persyaratan terpisah yang tidak dapat dipenuhi oleh file bersih secara otomatis. File teks yang secara struktural sempurna masih dapat melanggar panduan gaya.
Teks yang dibakar adalah mekanisme yang sepenuhnya berbeda. Teks yang dirender ke dalam bingkai video bukanlah file teks, tidak dapat diubah, dan tidak terpengaruh oleh apa pun yang dijelaskan di sini.
Kesimpulan: bersihkan sekali, unggah di mana saja — bagaimana fitur pembersihan dan konversi pada Perangkat Subtitle menghasilkan file yang ramah platform
Bersihkan sekali dan unggah file yang sama di mana saja. Alternatifnya, mempertahankan ekspor terpisah per platform, melipatgandakan jumlah file yang mungkin tidak sinkron dengan master dan tidak menghilangkan kekacauan yang mendasarinya.
Jalankan pembersihan dan konversi bersama-sama, lalu baca masalah yang dilaporkan sebelum mengunggah, bukan setelahnya. Nama masalah ini diberi isyarat berdasarkan nomor, yang merupakan perbedaan antara mengetahui suatu file mempunyai masalah dan mengetahui baris mana yang harus dilihat.