Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
spelček, mé srdce zaplesalo nad tímto krásným slovem 😆
/dev/
adresář (!) a do něj připojovat .iso? Je to někde popsané? To nejde tomu programu dát cestu k .iso nebo k adresáři někde v /mnt/
nebo jinde?
Jinak díky za návod.
Podadresáře pod /dev
se vytvářejí celkem běžně už odedávna (jen to teď spíš dělá udev) a některé se i používají jako mounting pointy (/dev/pts
, /dev/shm
, …), ale dělat si tam mounting point pro (releativně) normální filesystém je opravdu dost nezvyklé.
V tomto případě je to o to podivnější, že mnohé distribuce vytvářejí /dev/dvd
jako symlink na zařízení s DVD mechanikou (je-li přítomna) a některé programy (např. mpv) tuto cestu používají jako default:
mike@lion:~> ls -l /dev/dvd lrwxrwxrwx 1 root root 3 srp 15 13:43 /dev/dvd -> sr0
mencoder
ripovat to z VIDEO_TS struktury.
U většiny DVD celkem dobře funguje trik
mpv -stream-dump=dvd-${i}.dump dvd://$i
a následná konverze toho dumpu pomocí ffmpeg
.
Některá DVD (nejčastěji se s tím setkávám u večerníčků) jsou ale zprasená tak, že se takhle člověk k některým částem nedostane, takže nezbývá než vybrat potřebné *.VOB
soubory z namountovaného DVD, zkonvertovat je přímo a pak z toho vyřezat potřebné části.
Je tu ale problém, že jak dump získaný výše uvedeným postupem, tak přímo zkopírované *.VOB, postrádají timestamps, takže se v nich nedá seekovat. Většinou to řeším tak, že spojím všechny *.VOB dohromady (nebo jen ty, které mne zajímají), udělám rychlou konverzi celého souboru s "-c:v libx264 -preset ultrafast
", odměřím si začátky a konce jednotlivých částí (docela dobře to jde třeba v kdenlive) a hodnoty pak použiju pro ostrou konverzi s "-c:v libx265 -preset slow". Moc pohodlné to ale není.
Bez reencodingu ale nepůjde dělící body zvolit moc přesně, ne?
Právě tohle je hlavní důvod, proč to dělám tak krkolomně: nechci překódovávat dvakrát a s původním zdrojem si klasické editory většinou neporadí, protože nemá timestampy.
BTW: už několikrát jsem si skládal .mkv z víc zdrojů pomocí MKVToolNix, protože v jednom bylo mizerné rozlišení, ale dobrá zvuková stopa, a v jiném byl zase dobrý obraz, ale zvuk buď nekvalitní nebo v jiném jazyce, než chci.
Naštěstí to většinou sedělo resp. stačilo posunout začátek, případně vynásobit koeficientem, pokud se lišil počet snímků za vteřinu. Ale trefit ten správný posun je někdy docela opruz – člověk musí hledat místo, kde třeba bouchnou dveře nebo se rozsvítí lampa, aby na sebe seděl obraz a zvuk.
Nemáte někdo tip jak tohle zautomatizovat? Program by mohl rozpoznat např. hudbu na pozadí a další zvuky (v podstatě všechno kromě dialogů) a podle toho správně upravit posun i rychlost. Ale to bych asi chtěl moc :-). Taky by se mohlo stát, že by v jednom ze zdrojů byla vystřižená nějaká scéna, ale na to jsem zatím nenarazil.
Zdroje, které jsem našel (např. tady), vesměs tvrdí, že u libx265 hodnoty CRF nižší než 24 (18 u libx264) nemají moc smysl, protože už jen zvětšují soubor, aniž by zvyšovaly kvalitu obrazu. Moje experimenty se to zatím zdají potvrzovat (ale to byla 1080p videa, u DVD to asi bude ještě víc jedno).
U testovaného vzorku o délce 102 minut dělá -crf 20 nějakých 725 MB, -crf 16 pak 1,1 GB (včetně opus 5.1 zvuku).
To je docela dost, vezmu-li v úvahu, že hodinové 1080p video (např. aktuální sérii Game of Thrones nebo Twin Peaks) s libx265 při CRF 24 (jen s AAC pro zvuk) dostanu typicky někam kolem 800 MB.
ffmpegu
rozkouskovanou mezi popis x265 a x264. Mám tendenci to obracet a používat jako strop hodnoty z x264.
Zároveň ale co mám lepší a větší monitor jsem nějak citlivější na špatně zvládlé tmavé scény, takže nechci tolik tlačit na pilu (aneb "visually lossless or nearly so").
Já to do nedávna vůbec neřešil, protože jsem ani s defaultními hodnotami subjektivně nepociťoval žádný problém. Ale u těch zmíněných epizod GoT a Twin Peaks, které jsem si konvertoval z docela kvalitního zdroje (1080p.AMZN.WEBRip.DD5.1, x264 + EAC3, hodinová epizoda 4-6 GB), jsem najednou viděl rozdíl. V pohybu se to ztratí, ale třeba u scén, kde je statický pohled do tváře někomu, kdo nemá zrovna hladkou pleť nebo má fousy (Tyrion, Davos, "Bad Cooper", Gordon Cole), to je docela znát. Proto jsem pro tyhle účely začal používat "-crf 24". Velikost výsledných souborů sice vzrostla z 500-600 MB na 700-800 MB, ale kresba obrazu je viditelně lepší.
Všechny zdroje, které jsem k tomu našel (bohužel jich moc není a očividně nejsou zdaleka nezávislé), tvrdí, že libx264 má default 23 a rozsah, který má praktický smysl, by měl být 18-28 (teoretický je 0-51); u libx265 má být default 28 a nejnižší rozumná hodnota 24. V každém případě jsem u konvertovaného videa z DVD ani s defaultní hodnotoru nikdy neměl pocit, že bych o něco přicházel, takže 20 mi připadá dost overkill.
The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn't technically lossless.Jinak to není lossless (to je -crf 0) ale spíš se to blíží k transparenci. Ta je samozřejmě ztracena pokud se video po kompresi škáluje.
Ta je samozřejmě ztracena pokud se video po kompresi škáluje.Mám to chápat tak, že pokud bych film přehrál 1:1, tak mi -crf 18 (x264) zajistí že to bude "visually lossless", ale pokud ho zvětším tak ne, a tudíž by se mohly hodit detaily zachované při -crf < 18, které v 1:1 nemám moc šanci vidět?
Osobně mám problém spíš s tím, že na obrazovkách s vyšším rozlišením (monitor 2560x1440, televize 4K) nevypadají moc hezky ...S týmto má problém aj OCR ktorý prevádza tie obrázky na text. Pri BlueRay to nebude tak zlé ako pri DVD ktoré aktuálne teraz ja riešim.
Když už je řeč o titulcích: nechce se někomu udělat dobré (!) české titulky k filmu Heathers? Klidně bych to i trochu zasponzoroval.
A tím se vlastně dostáváme k výhodě textových titulků: lze je snadno opravovat a vylepšovat.
Proč bych tě tím měl srát? Znáš ten film?
Jen pro pořádek: já jsem tu mluvil o přídavných textových titulcích, které si samozřejmě můžeš vypnout. Titulky vložené do videa jsou prasárna, na tom se asi shodneme všichni.
Nejlepší je mít MKV s více zvukovými a titulkovými stopami – je to jeden soubor a zároveň můžeš snadno cokoli vyhodit nebo přidat.
Kdyby to bylo v obchodech, tak si to koupím sám ;-) Ale sehnal jsem jen anglickou verzi z USA. Přitom podle ČSFD to údajně existuje i s českým dabingem – to by bylo ještě lepší (pokud není nějaký zkriplený).
Co se týče ceny tak nevím, spíš navrhni cenu (nemám ani moc představu, kolik času tvorba titulků zabere) a já pak můžu říct, jestli bych to byl ochotný zaplatit sám, nebo jestli by bylo potřeba najít další lidi, abychom se na to složili. A měl by to dělat někdo, kdo má s překladem zkušenost, aby dobře přeložil ty fráze… mizerný překlad totiž už existuje.
P.S. a už je to nějakou dobu, co jsem ty titulky hledal, tak kouknu, jestli je mezitím někdo neudělal, ale spíš tipuji, že ne.
Fakt by nestačilo, aby si někdo, kdo umí rozumně anglicky a má trochu cit pro jazyk, sedl na anglické titulky s dobrým časováním a přeložil je?Pokud k tomu přistupuje takhle, tak ne. Sám jsem pár českých titulků vytvořil a vím, že pokud má člověk dobrý základ s dobrým časováním (ať už anglické titulky z originálního nosiče nebo zprasený český překlad, který je potřeba předělat), tak pokud to má udělat skutečně pořádně, tak to vlastní přeložení zabere jenom malý zlomek celkového času. Nejmíň 90 (ale spíš mnohem víc) procent pak zabere doladění a vypilování. Ale takhle to je obecně se vším. Sice hodně pomůže, když třeba anglický originál už tam má ty titulky načasované, ale je potřeba to brát jenom jako základ, od kterého se dá odrazit. Český překlad neodpovídá anglickému 1:1, ty titulky mají v různých jazycích různou délku, někdy i různý počet (někdy se nějaké titulky oproti anglickému originálu musí přidat, jindy odebrat, ten jazyk je prostě jiný), je potřeba to vyladit tak, aby to bylo dobře česky (a vůbec hlavně česky, ne czenglicky), aby se to dobře četlo, aby se to stihlo číst, ale zároveň nic zbytečně nechybělo nebo nesvítilo zbytečně dlouho tam, kde to jenom odvádí pozornost od dění v obrazu (to je velmi častý problém těch amatérských titulků), aby ty pointy byly dobře načasované, a hlavně překládat ten film, který člověk soustavně při tom sleduje. Ne překlady naslepo, kdy jenom přepíše ten anglický text do češtiny, aniž by věděl, co se tam v každé té pasáží odehrává (typická bolest amatéských titulků, kdy leckdy ani překladatel neví, jestli píše o ženské, nebo chlapovi, tak píše v chybném rodě, protože prostě ten film ani neviděl, jenom přepsal anglické titulky a nazdar). A to už vůbec nemluvím o speciálních případech jako jsou třeba muzikály s veršovanými písněmi, filmy se spoustou různých reálií, které je potřeba znát, v různých okrajových dialektech a podobně, to je ještě jiný level obtížnosti… Bohužel amatérský překlad titulků je typickou ukázkou platnosti Dunningova-Krugerova efektu, který je tedy všeobecně platný v současném světě. Lidé s velmi nízkými schopnostmi mají tendenci svoje schopnosti velmi silně přeceňovat. Mnoho překladatelů na titulky.com je toho učebnicovými příklady. Jednoduše řečeno, blbec si neuvědomuje, že je blbec.
Fakt by nestačilo, aby si někdo, kdo umí rozumně anglicky a má trochu cit pro jazyk, sedl na anglické titulky s dobrým časováním a přeložil je?
Minimálně by měl ten film vidět, aby věděl, jaké má být celkové vyznění a atmosféra. A taky by mj. měl správně rozlišit mužské a ženské postavy.
Dobré amatérské titulky jsou použitelné a dá se na to koukat a nemusí to stát tolik jako profesionální překlady. Ale fakt to nejde udělat během chvilky jen přeložením anglických titulků.
Úzkým hrdlem je hlavně to, kdo na to bude koukat :-)
Pokud má to médium třeba devadesát minut, tak je celkem jedno, jestli strávíš minutu vyndaváním z krabičky nebo mačkáním nějakých tlačítek či spouštěním příkazu.
Tiskni
Sdílej: