Konversi JSON ke LRC
Atau tempel teks subtitle
Apa yang berubah dalam konversi ini
5 hal dihapus atau memerlukan keputusan
- Waktu
waktu akhir cue (format keluaran hanya mencatat kapan cue mulai)
- Pemformatan
seluruh pemformatan (tebal, miring, warna, garis tepi, bayangan)
- Posisi
posisi di layar (setiap cue kembali ke posisi bawaan)
- Karaoke
timing karaoke (penyorotan per suku kata)
- Presisi
presisi waktu — jam keluaran lebih kasar, sehingga setiap stempel waktu dibulatkan ke 10 ms terdekat
Daftar ini berasal dari matriks kemampuan untuk kedua format ini, bukan dari file tertentu yang Anda muat. File tertentu bisa kehilangan lebih banyak jika memakai fitur yang diizinkan format tetapi tidak dimodelkan matriks.
Di sini Anda dapat mengonversi JSON ke LRC: seret satu file atau tempel teks, lalu unduh hasil LRC. Pemrosesan sepenuhnya lokal di peramban — tidak ada file yang diunggah dan tidak perlu akun.
Perbedaan kedua format ini bukan soal tampilan: timing, gaya, posisi, dan karaoke tidak punya tempat di LRC; nilai yang lebih halus dari 10 ms dibulatkan, karena LRC menyimpan waktu dalam langkah 10 ms. Dokumen JSON di sini adalah model field: setiap cue punya `id`, `start`, dan `end` dalam milidetik, `lines` membawa `tags`, dan objek `styles` menyimpan tabel gaya. Karena daftar di atas berasal dari model kemampuan format, daftar itu sudah final bahkan sebelum Anda menyeret file.
Batch juga didukung: antrean memproses setiap file secara berurutan, lalu seluruh hasil dikemas sebagai satu ZIP.
Contoh
File JSON umum, dikonversi ke LRC
Masukan
{
"version": 1,
"title": "Fixture: typical",
"fps": 25,
"styles": {
"Default": {
"name": "Default",
"fontFamily": "Arial",
"fontSize": 20,
"primaryColor": "#FFFFFF",
"bold": false,
"italic": false
}
},
"generator": "subtitlematrix fixtures",
"cues": [
{
"id": "1",
"start": 0,
"end": 2000,
"lines": [
"Hello world.",
"Second line."
],
"style": "Default",
"position": {
"x": 100,
"y": 200,
"align": "center"
}
},
{
"id": "2",
"start": 2500,
"end": 4000,
"lines": [
"Plain line.",
{
"text": "Styled line.",
"tags": [
{
"kind": "italic",
"start": 0,
"end": 6
}
]
}
]
},
{
"id": "3",
"start": 4500,
"end": 6000,
"lines": [
"Roger: I am here."
],
"speaker": "Roger"
}
]
}
Keluaran
[ti:Fixture: typical]
[00:00.00]Hello world.
[00:00.00]Second line.
[00:02.50]Plain line.
[00:02.50]Styled line.
[00:04.50]Roger: I am here.
Yang hilang pada keluaran ini: timing, gaya, posisi, karaoke, dan presisi. Sisanya cocok baris demi baris.
Konversi yang sama pada input berantakan
Masukan
[
{ "start": 0, "end": 1000, "lines": ["First."] },
{ "start": 1000, "end": 2000, "text": "Second." },
"not an object",
{ "start": 2000, "end": 3000, "lines": ["Third."], "class": "top" }
]
Keluaran
[00:00.00]First.
[00:01.00]Second.
[00:02.00]Third.
Inilah jenis kerusakan yang ada pada file nyata — byte-order mark, koma yang hilang, nilai null, atau waktu yang tidak terbaca. Bandingkan dengan contoh rapi di atas untuk melihat apa yang dimaafkan parser.
Pertanyaan yang sering diajukan
Apa yang terjadi pada waktu selesai setiap cue JSON?
LRC mencatat kapan sebuah baris dimulai dan tidak mencatat hal lain — pemutar lirik membiarkan baris tetap tampil sampai baris berikutnya mulai, jadi waktu selesai akan berlebihan. Setiap akhir dibuang dan setiap awal JSON tidak disentuh.
Apa yang terjadi pada tebal, miring, dan warna dari JSON ke LRC?
LRC tidak menyimpan gaya apa pun, jadi ketika JSON menjadi LRC semuanya hilang: `tags` yang dibawa baris sebuah cue, atau entri dari objek `styles` dokumen itu sendiri — tidak ada yang punya tempat, dan setiap baris ditulis sebagai teks biasa. Kata-katanya sendiri tidak disentuh.
Apa yang terjadi pada posisi di layar dari JSON ke LRC?
LRC tidak dapat menyatakan di mana subtitle digambar, jadi rujukan posisi yang dibawa setiap cue dibuang saat keluar dari JSON, dan setiap cue kembali ke posisi bawaan yang dipilih pemutar — umumnya bagian bawah bingkai dan di tengah.
Apa yang terjadi pada timing karaoke dari JSON ke LRC?
Timingnya hilang; kata-katanya tetap. Karaoke hidup di span karaoke yang dibawa cue JSON, yang menandai kapan setiap suku kata menyala, dan LRC tidak punya cara mencatat momen di dalam satu baris — jadi tandanya dilepas dan suku katanya tiba sebagai teks LRC biasa.
Mengapa stempel waktu bergeser dari JSON ke LRC?
LRC menyimpan waktu sebagai `[00:04.12]` sedangkan JSON menyimpannya sebagai `4126` — seperseratus detik versus seperseribu — jadi setiap timecode dibulatkan ke 10 ms terdekat: 00:00:04,126 menjadi 4,13 detik. Tidak ada yang diregangkan atau diurutkan ulang dan tidak ada cue yang bergeser lebih dari 5 ms, tetapi jika Anda menyelaraskan subtitle ini dengan file lain, di situlah konversi ini berhenti eksak.
Seperti apa keluarannya ketika JSON menjadi LRC?
Keluaran LRC disusun seperti LRC — tanpa nomor cue: setiap baris membawa stempel waktu dalam tanda kurung siku. Cue yang di JSON ditulis `4126` menjadi cue yang di LRC ditulis `[00:04.12]`, dalam urutan yang sama, dan tidak ada teks yang berubah.
Bagaimana cue JSON dua baris keluar di LRC?
Dua baris JSON menjadi dua baris bertimestamp dengan waktu yang sama, cara LRC menyatakan bahwa keduanya satu kesatuan. Pasangannya bertahan — keduanya tetap menjadi satu subtitle di keluaran LRC, dan pemutar menampilkannya bersama.
Apakah cue JSON mempertahankan urutannya di keluaran LRC?
Ya. Selama konversi, cue disusun menurut waktu mulai dari yang paling awal, karena itulah urutan yang diharapkan semua format di sini dan yang dibaca pemutar. Bila file JSON mendaftar cue tidak berurutan, keluaran LRC merapikannya; struktur file berubah, isinya tidak, dan itu memang disengaja.
Bisakah LRC dikonversi balik ke JSON?
Ya, dan arah itu punya daftarnya sendiri: mengonversi LRC ke JSON menghilangkan timing. Daftar itu berbeda dari daftar di atas karena kedua format menyimpan hal yang berbeda.
Apakah keluaran LRC mempertahankan encoding file JSON?
Tidak — keluarannya UTF-8, dengan akhir baris Unix dan tanpa byte-order mark, apa pun yang dipakai file JSON. File yang datang dalam UTF-16 atau encoding satu-byte Windows didekode saat masuk (panel hasil memberi tahu bila itu terjadi); yang keluar selalu LRC UTF-8 yang sama.