แปลงไทม์โค้ด drop-frame เป็น non-drop
หรือวางข้อความคำบรรยาย
ตัวเลือก
30 fps non-drop และ 29.97 drop-frame เขียนนาฬิกาเดียวกันต่างกัน และช่องนี้เลือกว่าจะอ่านไฟล์ทางใดและเขียนกลับทางใด คิวที่หนึ่งชั่วโมงอ่านเป็น 01:00:00,000 ภายใต้แบบหนึ่งและ 01:00:03,600 ภายใต้อีกแบบ — สองแบบห่างกัน 3.6 วินาทีต่อชั่วโมง ไม่ใช่ความคลาดจากการปัด ชื่อหน้าบอกทิศทางหนึ่ง และช่องนี้เสนอเฉพาะทิศทางนั้น ไฟล์ที่คุณได้จึงเป็นไฟล์ที่หน้าว่าด้วย ไม่มีอะไรในข้อความเปลี่ยน: ไม่มีคิวถูกปรับเวลากับวิดีโอ ไม่มีเฟรมเรตถูกแปลง และคิวภายในนาทีแรกของชั่วโมงกลับมาเหมือนเดิมเพราะไม่มีป้ายเฟรมใดถูกทิ้งตรงนั้น
เฟรมเรตที่ใช้คำนวณเวลา ในหน้าเกี่ยวกับรูปแบบ ช่องนี้คือสิ่งที่ MicroDVD ต้องการ เพราะมันเก็บเวลาเป็นหมายเลขเฟรม ในหน้าแปลงเฟรมเรต ช่องนี้คือเฟรมเรตที่ไฟล์ถูกตั้งเวลาไว้ — เวอร์ชันที่คำบรรยายถูกทำขึ้นมา — และช่องที่สองของหน้ารับเฟรมเรตของวิดีโอที่คุณจะใช้กับคำบรรยายนี้ ค่าที่พบทั่วไปคือ 23.976, 24, 25, 29.97, 30, 50, 59.94 และ 60 หากใส่ผิดจะเลื่อนไทม์ไลน์ทั้งหมด และในหน้าแปลงเฟรมเรตจะเลื่อนด้วยอัตราส่วน ไม่ใช่ด้วยจำนวนคงที่
หน้านี้เขียนไทม์โค้ดทุกตัวในไฟล์คำบรรยายใหม่จาก 29.97 เฟรมต่อวินาที drop-frame กลับเป็น 30 เฟรมต่อวินาที non-drop-frame นาฬิกาแต่ละเรือนจึงถอยหลังด้วยจำนวนคงที่ที่โตตามความยาวรายการ ไม่มีอะไรในนาทีแรกของชั่วโมง 3.6 วินาทีต่อชั่วโมง 36 วินาทีที่สิบชั่วโมง ข้อความ หมายเลขคิว ลำดับคิว และการขึ้นบรรทัดใหม่เป็นของไฟล์เดิมและออกมาไม่ถูกแตะ ไฟล์ที่หน้านี้มีไว้สำหรับถูกประทับเทียบกับจอหรือเครื่องเล่นที่นับแบบ drop-frame ซึ่งเป็นเรื่องปกติกับวัสดุ 29.97 เพราะ drop-frame คือธรรมเนียมที่ตามนาฬิกาผนังทัน และทุกอย่างปลายน้ำอ่านนาฬิกาเป็น non-drop เมื่ออ่านแบบนั้น ไทม์โค้ดทุกตัวในไฟล์จึงใหญ่เกินไปด้วยจำนวนที่โตขึ้นเรื่อย ๆ คำบรรยายจึงมาถึงก่อนและก่อนมากขึ้นเมื่อรายการดำเนินไป ผ่านไปครึ่งชั่วโมงความคลาดคือ 1.8 วินาทีและไม่หยุดโตที่ใดในไฟล์ นั่นคือเหตุผลที่การแก้ไม่ใช่การเขยิบ แต่เป็นการเขียนป้ายใหม่ที่ทุกเวลา ด้วยขนาดการแก้ที่กำหนดจากตำแหน่งของคิว การอ่านนาฬิกาเป็นไทม์โค้ดหมายถึงการดูดไปเส้นเฟรม 30 ที่ใกล้ที่สุด และใน drop-frame มีสองเส้นที่ไม่มีอยู่ drop-frame ข้ามป้าย ;00 และ ;01 ที่ต้นทุกนาทียกเว้นทุกนาทีที่สิบ มันนับ 00:00:59;28, 00:00:59;29 แล้วกระโดดไป 00:01:00;02 ดังนั้น 00:01:00,000 ที่เข้ามาจึงชื่อห้วงเวลาที่ธรรมเนียมนี้เขียนไม่ได้ มันถูกดึงกลับไปป้ายสุดท้ายที่เขียนได้คือ 00:00:59,933 ซึ่งเร็วกว่า 67 มิลลิวินาที นั่นคือขอบเขตจริงของการคำนวณไม่ใช่ค่าความคลาด และถูกบอกบนหน้านี้แทนที่จะกลบไว้ สองชั่วโมงมี 216 ค่า
คิวที่หลังการดูดแล้วสั้นกว่าหนึ่งเฟรมเขียนออกมาไม่ได้เลย เพราะสองขอบตกบนเส้นเดียวกันและคิวที่จุดจบเท่ากับจุดเริ่มไม่ใช่คิว คิวนั้นถูกทิ้งและนับในรายงานการสูญเสียด้านบนแทนที่จะถูกยืดเป็นหนึ่งเฟรมอย่างเงียบ ๆ ในทางปฏิบัติสิ่งนี้แตะเฉพาะวัสดุที่ตัดทีละเฟรม แต่หน้านี้ไม่ได้อาศัยความหายากนั้น มันรายงานจำนวน และไฟล์ที่ไม่มีคิวเช่นนั้นรายงานว่าไม่มี ไม่มีอะไรถูกอัปโหลด ไฟล์ถูกอ่านและเขียนใหม่ในแท็บเบราว์เซอร์และไม่เคยออกจากเครื่อง สิ่งนี้สำคัญด้วยเหตุผลเดียวกับทุกหน้าบนเว็บไซต์นี้ วัสดุที่อยู่ภายใต้ข้อผูกมัดการรักษาความลับส่งให้บริการแปลงไฟล์ไม่ได้ และหน้านี้ไม่ขอ
ตัวอย่าง
ไฟล์ที่ห้านาที
ข้อมูลนำเข้า
1
00:05:00,000 --> 00:05:02,000
The room is dark.
2
00:10:00,000 --> 00:10:03,000
A cold night.
ผลลัพธ์
1
00:04:59,667 --> 00:05:01,667
The room is dark.
2
00:09:59,400 --> 00:10:02,400
A cold night.
การแก้ไม่ใช่ตัวเลขเดียวที่ใช้กับทั้งไฟล์ ที่ห้านาทีนาฬิกาถอยไป 333 ms และที่สิบนาทีถอยไป 600 ms เพราะ drop-frame ทิ้งไปสิบป้ายเมื่อถึงคิวแรกและสิบแปดป้ายเมื่อถึงคิวที่สอง แต่ละคิวคงความยาวถึงมิลลิวินาทีเพราะสองขอบเลื่อนด้วยจำนวนเดียวกัน นี่คือการเขียนป้ายใหม่ไม่ใช่การเลื่อน
การแก้เดียวกันที่หนึ่งชั่วโมง
ข้อมูลนำเข้า
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
ผลลัพธ์
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
ที่หนึ่งชั่วโมง 01:00:03,600 ใน drop-frame คือ 01:00:00,000 ใน non-drop ต่างกัน 108 ป้ายที่ถูกข้ามหรือ 3600 ms นี่คือตัวเลขที่ใช้ตรวจหน้านี้ บรรทัดแรกของเอาต์พุตต้องเร็วกว่าบรรทัดแรกของอินพุต 3600 ms พอดี และไฟล์ที่ออกจากเครื่อง drop-frame ควรลงที่ชั่วโมงกลม
คิวภายในนาทีแรก
ข้อมูลนำเข้า
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:05:00,000 --> 00:05:02,000
This one does move.
ผลลัพธ์
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:04:59,667 --> 00:05:01,667
This one does move.
ระหว่างนาทีแรกของชั่วโมงไม่มีป้ายใดถูกข้าม สองธรรมเนียมจึงเขียนหกสิบวินาทีนั้นเหมือนกันและคิวแรกถูกปล่อยไว้ คิวที่สองที่ห้านาทีเลื่อน หนึ่งคิวไม่เปลี่ยนข้างหนึ่งคิวเลื่อนคือเอาต์พุตที่ถูกต้องของไฟล์นี้ ไม่ใช่การรันที่ค้าง การแก้เป็นศูนย์ที่ต้นชั่วโมงและโตจากขอบนาทีแรกเป็นต้นไป
คำถามที่พบบ่อย
ทำไมคำบรรยายจึงออกมาเร็วกว่าแทนที่จะช้ากว่า?
เพราะนาฬิกาของไฟล์ใหญ่กว่าห้วงเวลาที่มันระบุ non-drop-frame นับ 30 ป้ายต่อวินาทีราวกับว่า 29.97 เฟรมต่อวินาทีส่ง 30 เฟรมจริง มันจึงค่อย ๆ วิ่งนำเวลาจริง drop-frame ข้ามสองป้ายต่อนาทีเพื่อตามให้ทัน นาฬิกาที่อ่านจากเครื่อง drop-frame แล้วตีความเป็น non-drop จึงชี้เลยจุดที่ควรเป็น การแก้คือลบส่วนเกินนั้น 333 ms ที่ห้านาที 3600 ms ที่หนึ่งชั่วโมง 36000 ms ที่สิบชั่วโมง จำนวนเป็นศูนย์สำหรับทุกนาฬิกาภายในนาทีแรกของชั่วโมง การแก้ที่เล็กที่สุดที่หน้านี้ใช้จึงอยู่ที่ขอบนาทีแรก และไม่มีนาฬิกาใดถูกดันต่ำกว่า 00:00:00
ไทม์โค้ด drop-frame ที่เขียนไม่ได้จะเกิดอะไร?
มันถูกดึงกลับไปป้ายสุดท้ายที่เขียนได้ ทุกนาทีที่ข้ามใน drop-frame ไม่มีป้าย ;00 และ ;01 ดังนั้น 00:01:00,000 และ 00:01:00,010 ไม่ใช่นาฬิกาที่ธรรมเนียมนี้แสดงได้ ทั้งคู่ตกบน 00:00:59,933 ซึ่งเร็วกว่า 67 ms นี่คือที่เดียวบนหน้านี้ที่เอาต์พุตไม่ใช่การเขียนป้ายใหม่แบบแม่นยำ และมันมีขอบเขต สองป้ายต่อนาทีที่ข้าม 216 ค่าภายในสองชั่วโมง หน้านี้จึงบอกไว้ตรงนี้แทนที่จะให้คุณไปพบใน diff
คิวสามารถหายไปจากไฟล์ได้ไหม?
เฉพาะคิวที่สั้นกว่าหนึ่งเฟรมคือ 33.37 ms สองสิ่งดันคิวให้เหลือเฟรมเดียวได้ การดูดที่กล่าวถึงข้างบน ซึ่งคิวสิบคิวอย่าง 00:01:00,000 ถึง 00:01:00,010 มีสองขอบถูกดึงไปที่ 00:00:59,933 และคิวที่สั้นกว่าหนึ่งเฟรมอยู่แล้วตอนมา คิวที่จุดเริ่มและจุดจบเป็นห้วงเดียวกันเขียนออกไม่ได้ จึงถูกทิ้งและจำนวนปรากฏในรายงานการสูญเสียด้านบนพื้นที่ทำงาน ไฟล์ที่ไม่มีคิวเช่นนั้นรายงานว่าไม่มี ซึ่งเป็นกรณีปกติ
นอกจากค่าบนนาฬิกาแล้วมีอะไรในไฟล์เปลี่ยนไหม?
ไม่ หมายเลขคิว ลำดับ ข้อความทุกบรรทัด การขึ้นบรรทัดใหม่ภายในคิว และจำนวนคิวทั้งหมดเป็นของไฟล์เดิมและคงอยู่ หน้านี้เขียนสองตัวเลขต่อคิวใหม่ในรูปที่เขียนป้ายต่างออกไป และไม่ได้บันทึกที่ใดว่าตอนนี้นาฬิกาเป็น non-drop เพราะไม่มีรูปแบบใดที่อ่านที่นี่มีช่องเก็บได้ SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON และ CSV ล้วนไม่มี และไฟล์ที่คุณวางลงมาก็ไม่ได้บอก
ควรใส่เฟรมเรตเท่าไรในช่อง?
อัตราใดก็ได้ที่ฟุตเทจจริงมี มันไม่กระทบการแปลงนี้ 30 และ 29.97 ในชื่อหน้าเป็นธรรมเนียมการนับที่เขียนบนสายไทม์โค้ด ไม่ใช่เฟรมเรตของวิดีโอ จึงไม่มีอะไรถูกสเกลด้วยตัวเลขที่คุณใส่ ช่องนี้จำเป็นเพียงเพราะ MicroDVD เก็บเวลาเป็นหมายเลขเฟรมแทนนาฬิกา และการอ่านไฟล์ MicroDVD เป็นไปไม่ได้ถ้าไม่รู้เฟรมเรต
ถ้ารันหน้าตรงข้ามกับเอาต์พุตนี้จะได้ไฟล์เดิมคืนไหม?
ได้ทุกไบต์ ตราบใดที่ไม่มีไทม์โค้ดใดตกในชั้นที่ drop-frame เขียนไม่ได้ สองหน้าเป็นการคำนวณเดียวกันที่อ่านสองทิศ หน้านี้ลบจำนวนที่โตขึ้น อีกหน้าบวกกลับ และจำนวนถูกกำหนดจากตำแหน่งของแต่ละคิวไม่ใช่ค่าออฟเซตคงที่ ข้อยกเว้นคือกรณีดูด 00:01:00,000 ที่ออกมาเป็น 00:00:59,933 จะกลับมาเป็น 00:00:59,933 และเป็นชั้นเดียวของเวลาที่คู่นี้ไม่ใช่การไปกลับ