Konvertera SUP (PGS) till SRT
Första körningen laddar ner textläsaren – ungefär 4 MB plus språkmodellen, serverad av den här webbplatsen och cachad av webbläsaren efteråt. Inget laddas upp, och resultatet är maskinläst: korrekturläs det innan du förlitar dig på det.
Inställningar
En bitmappsundertext är en bild av text, så orden måste läsas tillbaka ur den. Berätta för läsaren vilket språk undertexterna är skrivna på – listan täcker alla språk som den här webbplatsen ges ut på. Ryska undertexter lästa med den engelska modellen kommer ut som brus, inte som ryska. Bara modellen du väljer laddas ner (de andra aldrig), så att byta kostar en nedladdning per språk, cachad efteråt.
En .sup-fil är en PGS-ström, det bildundertextformat Blu-ray-skivor använder. Det finns inte ett enda tecken i den: varje undertext lagras som en bitmapp tillsammans med en palett och ögonblicket då den ska synas, och en spelare lägger den ovanpå videon. Att få ut text ur en sådan fil betyder därför att läsa bokstäverna i varje bild. Den här sidan gör det i fliken med en OCR-motor som sajten själv serverar, och skriver resultatet som en .srt-fil.
Formatet är en följd av segment, var och ett med ett tretton byte långt huvud som bär en presentationstidsstämpel i 90 kHz-enheter, en typ och en längd. Fyra typer spelar roll: palettdefinitionen (PDS), som mappar indexvärden till full RGB via YCbCr; objektdefinitionen (ODS), som håller en längdkodad bitmapp; presentationskompositionen (PCS), som säger vilka objekt som sitter var på bildrutan; och visningsuppsättningen som staplar dem. Ett textblocks start är tidsstämpeln för den visningsuppsättning som visar det. En PGS-ström bär ingen sluttid alls – en undertext står kvar tills nästa visningsuppsättning ersätter den – så slutet på varje textblock här är starten på nästa, vilket är exakt vad en spelare gör.
Eftersom varje textblock läses av en maskin är texten en avläsning och inte en transkription: ett typsnitt med seriffer i liten storlek, ett ovanligt typsnitt eller en kraftig kontur kan göra ett tecken till ett annat. Korrekturläs filen innan du förlitar dig på den. Den varningen är inte en tom fras – det här är den enda platsen på sajten där utdata inte härleds från vad filen sade, och sidan säger det i stället för att presentera resultatet som exakt.
Välj det språk undertexten faktiskt är skriven på. Listan täcker alla språk som den här webbplatsen ges ut på, och varje modell läser sitt eget skriftsystem. Att köra en engelsk modell över japansk undertext ger brus i stället för en dålig översättning, eftersom igenkännaren letar efter former som inte finns där. Bara modellen du väljer laddas ner, och den cachas efteråt.
Textblock vars bilder inte ger någon text alls – en övergångsbild, en logotyp, ett svart block – lämnas utanför och räknas i förlustlistan i stället för att skrivas som tomma rader. Allt som var en bild förblir en bild till sin natur: typsnitt, färg, kontur och placering på skärmen finns inte i en .srt, och förlustlistan säger det en gång för hela filen.
Inget laddas upp. Igenkännaren körs i fliken, och dess worker, WebAssembly-kärna och språkmodell serveras alla från den här sajten och cachas av webbläsaren. De enda förfrågningar sidan gör är efter de filerna, alltså nedladdningar – aldrig en uppladdning av din .sup.
Vanliga frågor
Vad finns inuti en .sup-fil som gör PGS till SRT till ett igenkänningsjobb?
Segment, inte tecken. Varje undertext i en PGS-ström är ett objekt: en längdkodad bitmapp av palettindex plus en palettdefinition som gör de indexen till RGB. De enda textliknande värdena i filen är presentationstidsstämplarna, som är heltal i 90 kHz snarare än något en människa läser. Att konvertera det till SRT betyder att lägga varje bitmapp på en canvas och känna igen bokstäverna, vilket är varför resultatet behöver korrekturläsas och varför sidan frågar vilket språk undertexten är på.
Varför slutar den sista undertexten i .sup-till-SRT-utdata ett par sekunder senare än den borde?
Eftersom PGS aldrig säger när en undertext slutar. En spelare visar en komposition tills nästa anländer eller tills strömmen rensas, så den enda sluttid som finns i filen är ”starten på nästa”. För det sista textblocket finns inget nästa; sidan ger det två sekunder och registrerar valet i förlustlistan. Om skivan verkligen lät sin sista rad stå kvar i tio sekunder är den ärliga åtgärden en förskjutning eller en längdändring, inte en gissning gömd i konverteraren.
Vilken språkmodell ska jag välja för .sup-undertext med både japanska och engelska rader?
Den som merparten av dialogen är på. En PGS-bild kan blanda skriftsystem i en enda rad – en japansk mening med ett engelskt lånord skrivet med latinska bokstäver är vanlig – men igenkännaren får en modell per körning, och en modell tränad på ett skriftsystem läser det andra som skräp. Om filen verkligen växlar mellan två skriftsystem kör du den två gånger, en per språk, och behåller de rader varje körning fick rätt: utdata är en vanlig .srt, så att slå ihop de två är en diff, inte en ny export.
Följer undertextens färger med över till SRT-filen från .sup?
Nej, och de kan inte göra det. En .sup kodar färg tre gånger om: i paletten (som är YCbCr med en alfakanal, per textblock), i kompositionen (var bitmappen sitter på en 1920×1080-ruta) och i konturen och skuggan som är ritade inuti bitmappen. SRT har ingen av de platserna. Sidan läser luminansen i varje pixel för att avgöra vad som är text och vad som är bakgrund, vilket är allt OCR behöver, och förlustlistan rapporterar formatering en gång för filen i stället för att låtsas att färgerna överlevde.
Några textblock blev tomma eller saknas i .sup-till-SRT-resultatet. Vad hände med dem?
En bild som inte gav någon text togs bort i stället för att skrivas som en tom undertext. Det händer med in- och uttoningsbilder, med block som bara är en logotyp eller en symbol och med mycket liten text under den storlek igenkännaren klarar. Varje sådant räknas i förlustlistan, så filen du får är inte tystare kortare än filen du gav. Är antalet högt är den vanliga orsaken fel språkmodell eller en ström vars bitmappar är ovanligt små.
Laddas .sup-filen eller dess bilder upp någonstans?
Nej. Igenkännaren körs i fliken, och dess worker, WebAssembly-kärna och språkmodell serveras alla från den här sajten och cachas av webbläsaren. De enda förfrågningar sidan gör gäller de filerna, och de går ner, inte upp. Det spelar större roll här än på en textsida: en PGS-ström som extraherats från en skiva är ofta det enda material en studio eller en jurist minst vill lämna till en tredje part, och hela poängen med sidan är att de inte behöver.