แปลง ปรับเวลา และล้างไฟล์คำบรรยาย SRT และ VTT ภายในเบราว์เซอร์
SubRip (.srt) มาจากโปรแกรม DVD-ripping ในช่วงต้นทศวรรษ 2000 และกลายเป็นรูปแบบคำบรรยายเริ่มต้นที่เกือบจะบังเอิญ WebVTT (.vtt) ได้รับการออกแบบในภายหลัง สำหรับวิดีโอ HTML5 โดยเฉพาะ และเป็นสิ่งที่เบราว์เซอร์คาดหวังเมื่อคุณแนบองค์ประกอบแทร็กเข้ากับวิดีโอ
มีลักษณะคล้ายกันมากจนผู้คนถือว่าการเปลี่ยนชื่อไฟล์ก็เพียงพอแล้ว มันไม่ใช่ และความล้มเหลวก็เงียบไป: เบราว์เซอร์ส่งไฟล์ SRT ที่เปลี่ยนชื่อเป็น .vtt โดยปกติจะไม่แสดงอะไรเลย โดยไม่มีข้อผิดพลาดในการอธิบายสาเหตุ
ขั้นแรกให้ส่วนหัว ไฟล์ WebVTT ต้องขึ้นต้นด้วยคำตามตัวอักษร WEBVTT ในบรรทัดแรก ไฟล์ SRT ไม่มีส่วนหัวและเริ่มต้นโดยตรงกับคิวแรก บรรทัดที่ขาดหายไปเพียงบรรทัดเดียวนี้เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ไฟล์ที่แปลงแล้วล้มเหลวในเบราว์เซอร์
ประการที่สอง ตัวคั่นมิลลิวินาที SRT เขียน 00:00:01,500 ด้วยเครื่องหมายจุลภาค WebVTT เขียน 00:00:01.500 ด้วยจุด ผู้เล่นคาดหวังอย่างใดอย่างหนึ่งและอีกสิ่งหนึ่งมักจะปฏิเสธคิว
ประการที่สาม การนับเลขคิว SRT กำหนดหมายเลขตามอัตภาพด้วยบรรทัดที่มีเพียงจำนวนเต็มก่อนการประทับเวลาแต่ละครั้ง ใน WebVTT ตัวระบุนั้นเป็นทางเลือก และ (หากมี) อาจเป็นสตริงใดๆ แทนที่จะเป็นตัวเลข
มีความแตกต่างเล็กๆ น้อยๆ เช่นกัน: WebVTT อนุญาตให้ละเว้นองค์ประกอบชั่วโมงได้ ดังนั้น 01:30.000 จึงหมายถึงเก้าสิบวินาที และรองรับการตั้งค่าตำแหน่งหลังจากการประทับเวลา เช่น บรรทัด:90% align:center เครื่องมือนี้จะอ่านสิ่งเหล่านี้ทั้งหมดและรักษาการตั้งค่าคิวไว้เมื่อแปลงเป็น VTT
โหลดไฟล์ของคุณ — รูปแบบจะถูกตรวจพบโดยอัตโนมัติจากส่วนหัว WEBVTT — จากนั้นดาวน์โหลดในรูปแบบใดก็ตามที่คุณต้องการ การกำหนดเวลาจะถูกเก็บไว้ภายในเป็นจำนวนเต็มมิลลิวินาที ดังนั้นการแปลงจึงเป็นค่าที่แน่นอน และการแปลงกลับไปกลับมาจะไม่สะสมค่าความคลาดเคลื่อน
หมายเลขคิวจะถูกกำหนดหมายเลขใหม่ติดกันจาก 1 ในการส่งออก หากไฟล์ต้นฉบับของคุณมีช่องว่างหรือซ้ำกันในการกำหนดหมายเลข ซึ่งเป็นเรื่องปกติในไฟล์ที่ได้รับการแก้ไขด้วยมือ ผลลัพธ์ที่ได้จะสะอาด
ทุกไฟล์จะถูกตรวจสอบเมื่อโหลด และผลลัพธ์จะปรากฏเหนือการแสดงตัวอย่าง แต่ละข้อความจะตั้งชื่อหมายเลขคิวเฉพาะ เนื่องจาก "ไฟล์นี้ไม่ถูกต้อง" จะไม่มีประโยชน์เมื่อไฟล์มีเก้าร้อยคิว
ข้อผิดพลาดคือการแตกหักอย่างแท้จริง: คิวที่สิ้นสุดก่อนที่จะเริ่ม คิวที่เริ่มต้นก่อนคิวก่อนหน้า หรือการประทับเวลาที่ไม่สามารถอ่านได้เลย คำเตือนคือสิ่งที่ถูกต้องในทางเทคนิคแต่มักไม่ได้ตั้งใจ: สัญญาณระยะเวลาเป็นศูนย์ที่จะไม่มีวันปรากฏบนหน้าจอ หรือสัญญาณสองรายการซ้อนทับกันเพื่อให้ทั้งสองรายการแสดงพร้อมกัน
คิวที่มีรูปแบบไม่ถูกต้องไม่ได้ยกเลิกไฟล์ทั้งหมด มีการรายงานบล็อกที่เสียหายและสัญญาณที่เหลือยังคงโหลด ดังนั้นคุณจึงสามารถดูขนาดของปัญหาได้ในครั้งเดียว แทนที่จะแก้ไขข้อผิดพลาดที่ขัดข้องทีละครั้ง
ไฟล์คำบรรยายมักจะมีมาร์กอัป: แท็กที่เหมือน HTML เช่น <i> และ <b>, คลาส WebVTT และแท็กเสียง เช่น <c.loud> และ <v Speaker> และ SubStation จะแทนที่บล็อก เช่น {\an8} ที่ควบคุมตำแหน่ง
ปุ่ม "ลบแท็กการจัดรูปแบบ" จะตัดสิ่งเหล่านี้ทั้งหมดโดยยังคงรักษาการขึ้นบรรทัดใหม่ในแต่ละคิว ซึ่งมีความสำคัญต่อการอ่าน เอนทิตีอักขระ เช่น & ถูกปล่อยให้อยู่ตามลำพังโดยเจตนา เนื่องจากเป็นเนื้อหามากกว่าการจัดรูปแบบ
คำบรรยายที่ไม่ตรงกันมีสองรูปแบบที่แตกต่างกัน และการใช้การแก้ไขที่ไม่ถูกต้องจะทำให้สิ่งต่างๆ แย่ลง ใช้เวลาสามสิบวินาทีในการวินิจฉัยก่อนที่คุณจะสัมผัสสิ่งใดๆ
CONSTANT OFFSET หมายความว่าคำบรรยายไม่ถูกต้องด้วยจำนวนเท่ากันทุกที่ ตรวจสอบเส้นใกล้จุดเริ่มต้นและเส้นใกล้จุดสิ้นสุด หากทั้งสองสายมาช้าประมาณสองวินาที คุณต้องมีกะงาน
DRIFT หมายถึงข้อผิดพลาดเพิ่มขึ้นในขณะที่เล่นวิดีโอ หากบรรทัดแรกเกือบจะถูกต้องแต่บรรทัดสุดท้ายอยู่ห่างออกไป 40 วินาที การเปลี่ยนแปลงจะไม่ช่วยอะไร คุณต้องปรับขนาด การเคลื่อนไปมักจะมาจากอัตราเฟรมที่ไม่ตรงกัน กล่าวคือ คำบรรยายมีกำหนดเวลาเทียบกับการเผยแพร่ 23.976 fps และวิดีโอของคุณทำงานที่ 25 fps หรือในทางกลับกัน
ป้อนค่าชดเชยเป็นมิลลิวินาที จำนวนบวกจะทำให้คำบรรยายล่าช้า ซึ่งเป็นสิ่งที่คุณต้องการเมื่อปรากฏเร็วเกินไป ตัวเลขติดลบจะเลื่อนไปเร็วกว่านั้น สำหรับคำบรรยายที่ล้าหลังบทสนทนา
วัดข้อผิดพลาดแทนที่จะคาดเดา สังเกตการประทับเวลาที่มีการพูดประโยคจริงและการประทับเวลาที่ปรากฏอยู่ในปัจจุบัน จากนั้นใช้ความแตกต่าง สองวินาทีคือ 2000 ms
การประทับเวลาจะถูกบีบไว้ที่ศูนย์ ทั้ง SRT และ WebVTT ไม่สามารถแสดงถึงเวลาที่ติดลบได้ และผู้เล่นที่ส่งไปมักจะปฏิเสธคิวหรือพฤติกรรมที่คาดเดาไม่ได้ ดังนั้น หากคุณเลื่อนไฟล์ไปข้างหลังมากกว่าเวลาเริ่มต้นของคิวแรก สัญญาณที่ได้รับผลกระทบจะถูกปักหมุดไว้ที่ 00:00:00 แทนที่จะไปเป็นค่าลบ และเครื่องมือจะบอกคุณอย่างชัดเจนถึงจำนวนสัญญาณที่เกิดขึ้น หากคุณเห็นคำเตือนนั้น แสดงว่าออฟเซ็ตของคุณอาจใหญ่เกินไป
การปรับขนาดจะคูณทุกการประทับเวลาด้วยปัจจัยคงที่ ซึ่งเป็นการแก้ไขที่ถูกต้องสำหรับการดริฟท์
ปัจจัยคืออัตราส่วนของอัตราเฟรม การแปลงคำบรรยายที่กำหนดเวลา 23.976 fps เป็นวิดีโอ 25 fps หมายถึงการคูณด้วย 25 __ 23.976 ประมาณ 1.0427 ไปทางอื่น ใช้ 23.976 __ 25 ประมาณ 0.959
หากคุณไม่ทราบอัตราเฟรม คุณสามารถหาปัจจัยจากการดริฟท์ได้: หารเวลาที่ถูกต้องของบรรทัดสุดท้ายตามเวลาปัจจุบัน ใช้แล้วตรวจสอบปลายทั้งสองอีกครั้ง
การรวมมีไว้สำหรับเนื้อหาที่มีคำบรรยายเป็นบางส่วน เช่น สองซีกของภาพยนตร์ที่ออกเป็นไฟล์แยกกัน เป็นต้น
โหลดไฟล์หลักของคุณก่อน จากนั้นเลือกไฟล์ที่สองในแผงผสานและชดเชยให้ ออฟเซ็ตคือจุดที่ส่วนที่สองเริ่มต้นในไทม์ไลน์รวม: หากส่วนที่หนึ่งทำงานเป็นเวลา 58 นาทีและ 20 วินาที ออฟเซ็ตจะเป็น 3,500,000 ms
สัญญาณจากทั้งสองไฟล์จะถูกรวมและจัดเรียงใหม่ตามเวลาเริ่มต้น ดังนั้นผลลัพธ์จึงอยู่ในลำดับที่ถูกต้องเสมอ แม้ว่าออฟเซ็ตจะทับซ้อนทั้งสองเซ็ตเล็กน้อยก็ตาม ทุกอย่างมีการกำหนดหมายเลขใหม่จาก 1
การแยกจะย้อนกลับ โดยแบ่งไฟล์เดียวตามการประทับเวลาที่คุณเลือก
ตามค่าเริ่มต้น ส่วนที่สองจะถูกรีเบสใหม่ ดังนั้นจึงเริ่มจากศูนย์ ซึ่งเป็นสิ่งที่คุณต้องการเมื่อจะเล่นกับไฟล์วิดีโอแยกต่างหากที่เริ่มที่ศูนย์เช่นกัน ตัวชี้นำถูกกำหนดให้กับส่วนที่มีเวลาเริ่มต้น ดังนั้นคิวที่คร่อมจุดแยกจะไปพร้อมกับส่วนที่เริ่มด้วยแทนที่จะถูกตัดครึ่ง
ดาวน์โหลดทั้งสองส่วนพร้อมกัน ชื่อ -part1 และ -part2 หากจุดแยกที่คุณเลือกทำให้ส่วนหนึ่งว่างเปล่า เครื่องมือจะบอกคุณแทนที่จะสร้างไฟล์ว่างโดยไม่แจ้ง