Skus http://abx.digitalfeed.net/
z vysledku som bol velmi smutny.
Tak jsem to právě zkusil. Momentálně na komplet dobastlené a nehotové aparatuře a výsledky dopadly tak, jak jsem čekal. (M-Audio fast track pro, ARS840, zes momentálně bastl s TPA3116 (ale leží mi v šuplíku MIR50 je dodělat...))
Daft punk jsem uhádl na 100%, Eagles na 80. Pak takový ty country hoky jsem tinul ještě tak, že jsem tomu i věřil, ale zbytek spíš statistický šum.
Díky za odkaz na test. Já mám z toho závěr takový, že záleží na stylu hudby.
Vím, jak funguje fourierův rozklad i fourierova transformace a vím, že obdélníky (ty oblíbené sudé harmonické) klesají na amplitudě s 1/n, kdežto ty nemilé liché trojúhelníky a 1/n^2. A je mi jasné, ža ta informace někde chybět musí. A ověřil jsem si, že ne vždy vadí, když chybí.
(a je mi jasné, že s tím, čemu lidi říkají repráky k počítači, to musí znít všechno komplet stejně)
Tak toho Fouriera bys mel jeste dopilovat, placas nekolikanasobny kraviny.
K rozkladu, ne, ze by to melo nejak zvlast silnou souvislost s psychoakustikou vnimani nelinearniho zkresleni: 1/n umerenost plati shodne u pily (neplest s trojuhelnikem) i u obdelniku, nekdo muze rict 1/n^2, to zalezi, bavime-li se o vykonu, nebo amplitude -- podstatny je, ze obalka umernosti je shodna pila/obdelnik. Pila ma sudy i lichy. Obdelnik a trojuhelnik (neplest s pilou) maji jenom lichy. Co jsi myslel chybejici informaci u techhle signalu, to nam sem ani nepis. A pred tim kdyztak mrkni na AAC, at se neztrapnis jeste vic.
Pokud jde o jakost prednesu soustavou (cili ne kompresnim kodekem), pak se skutecne subjektivni dojmy z pridelanejch lichejch/sudejch harmonik lisej. Zalezi to "kupodivu" ne na osazeni lampy/tranzistory, ale predevsim na topologii: jednocinna vs. dvojcinna. Kazdopadne oba druhy zkresleni (symetricky => lichy harmoniky, nesymetricky => lichy i sudy harmoniky) zpusobuji pri jakemkoli slozitejsim nez jednotonovem zvuku intermodulacni zkresleni a to vadi nejvic.
Pokud jde o kompresni kodeky, samozrejme, ze vygumovany harmoniky pocitove vadej, procez je nahrazuje AAC. Vadi tam ale predevsim uplne jiny veci, ktery s nejakou trivialitou jako je obsah harmonickejch skutecne nesouvisej -- proste kompresni artefakty.
Výsledek je silně závislý na MP3 encoderu, 320kbit/s nepozná už skoro nikdo ale vizuálně je to vidět, když se stopy prolnou (marginální rozdíly i po zazoomování).
Důležité tedy je, který encoder produkoval zdroj, což platí hodně i u videa, kde mohou být naprosto fatální rozdíly při téměř totožném bitrate.
Výsledek je hlavně závislý na tom, CO komprimujete! Jde-li o hudbu, které již v originálu chybějí vysoké frekvence, rozdíl nemusíte vůbec poznat, protože obojí stojí za hovno. To není tak vyjímečný případ! Zkomprimujete-li např. sólový zpěv, může být stejně dobrý jako originál, protože frekvencí k uložení moc není, takže bitový tok postačí. Nejlepší na ověření komprimace a nejnáročnější na datový tok jsou zvukově přecpané skladby (symfonický orchestr, některá elektronická hudba) a skladby s výškami (které se při komprimaci obvykle zahazují první; bicí).
Takže říci „tady máš jakousi skladbu ve 2 provedeních a rozeznej mp3“ je kravina, je třeba mít vhodný vzorek. To by se taky dala vzít rovnou sinusoida.
2SB: ono pokud nekomprimujes primo ten signal z mikrofonu, tak uz stejne dostates totalne zmrsenou vec, takze i tech 64kbit muze ve finale vlastne znit lip, nez "original". Mam doma i par podobnych "demo" placek na kterych sem to svyho casu par "hifistum" ukazoval. (tvrdili ze vypalena placka nemuze hrat tak dobre jako orig ... ;D ).
Mp3 nejsnaz poznas u vazny muziky, ale kolik promile populace to posloucha ... u vseho ostatniho je to prast jako uhod, navic drtiva vetsina lidi posloucha v aute/socce/... takze poslechovy parametry jejich okoli ... i 32kbit je fajn.
A pak zkus nekomu zatelefonovat, a budes blejt. V dobe 8k telefonujeme pri 5-10kbitech ... a to jeste s parametrama vstupu a vystupu za ktery by se stydel i Bell.
"Guetzli is designed to work on high quality images (e.g. that haven't been already compressed with other JPEG encoders)"
Tedy že ten kodek má přínos, jen když obrázek už není zašpiněn artefakty z předchozí komprese. Ale kde takové obrázky vezmou? To pak využije jen někdo, kdo fotí do RAWu, a bude ochoten se zabývat nějakou externí kompresní utilitou, i když má kodek v photoshopu - který je také lepší než standardní kodek.
Obrázky bych měl kde brát, nemusí to být jen RAW, ale třeba i vlastní tvorba grafiky pro web, ale doteď třeba Gimp neumí vyrobit webp, takže buď to nepodporují prohlížeče, nebo to není jak vyrobit nebo obojí. Tohle prohlížeče budou umět, ale nebude to čím uložit. Exportovat do něčeho neztrátového a pak přeukládat nějakou utilitkou je samosřejmě nesmyslná představa, to dělat nikdo nebude.
Jestli to vylepsujou stejne jako videa na youtube, tak jen premejslim, jestli se z toho vetsina lidi pobleje uz po 10 nebo az po 11 fotce. Nkrat sem totiz resil s ruznema llidma proc na tom ytubu to video se kterym se tak srali aby vypadalo dobre ... je tak hnusny.
Oni neresej jak docilit kvalitniho obrazu, oni resej jak docilit co mozna nejmensiho obrazu, coz se proste projevi a to tak ze v jejich pripade zcela vzdy.
ujč použití nedoporučuje, ale ani nevylučuje.
http://www.ujc.cas.cz/jazykova-poradna/dotazy/0185.html
Máš právdu, že to je nešvar posledních let, v češtině logicky nedává smysl více dvojitých záporů.
Je to až bizarní, ale s progressive JPEG mají problém i některé nejnovější televize, které jinak podporují 4K HDR v H265... Paměti i výkonu musejí mít spoustu, tak mi z toho vychází, že na to mají zadrátovaného předpotopního švába, jinak to nedává smysl. Je to ostuda, ty požadavku jsou dnes minimální i pro levné krabičky.
Jenze ta telka ma extraswaba pro to 4k ... a pak dalsiho swaba pro ten zbytek, takze zadnej extra vykon ani ram ve skutecnosti nema. A mimo jiny treba prave proto, ti u ty TV 100Mbit pripojka na prehravani fimu stacit nebude, presto ze bitrate toho filmu ani zdaleka 100Mbit neni. Jednoduse proto, ze na PC se ti vpohode naladuje do RAM i nekolik minut, kdezto na ty TV ani sekundy ne ...
Běží tam WebOS 3.0 a je to Ultra HD, takže je velká šance, že tam je něco jako Cortex A9 1.2 GHz Dual Core + 3 GB RAM (minimálně tam bude 1 GB). To není žádná hitparáda, ale na dekompresi dvacet let starého formátu by to stačit mohlo :-) Jsou pro to nějaké programy (a další se dají dopsat), jde tam surfovat po webu, úplné ořezávátko to není.
To není zrovna přesný odkaz… Myslíte ty dvě trojice, které jsou v příspěvku na blogu https://opensource.googleblog.com/2017/03/guetzli-new-open-source-jpeg-encoder.html ? Zmenšil jste si ej na původní velikost a porovnával jste je? Ty jsou přece určené pro ilustraci rozdílů.
Co bych si zmensoval? Temihle obrazky argmentuji sami tvurci. Jsou urcene pro ilustraci absence rozdilu, tj. jejich algoritmus ma stejne/lepsi vysledky pri mensi filesize. Ve clanku resili vicemene jen artefakty, ztratu barvy tezko.
"And while Guetzli produces smaller image file sizes without sacrificing quality..."
U toho oka to proste neni pravda.
Co bych si zmensoval?
Ty obrázky, které jsou vložené v článku. Jsou totiž záměrně výrazně zvětšené, aby byly dobře vidět rozdíly, které mají ilustrovat.
Jsou urcene pro ilustraci absence rozdilu
Ne, nejsou. Jsou určené k ilustraci toho, co je napsáno v jejich popisku. První je určen k ilustraci toho, že Guetzli má méně artefaktů u čáry protínající oblohu. Druhý ilustruje zmenšení počtu artefaktů kolem kočičího oka.
Ve clanku resili vicemene jen artefakty, ztratu barvy tezko.
Také tam k žádné ztrátě barvy nedochází.
U toho oka to proste neni pravda.
To můžete těžko posoudit, když jste si ty obrázky nezmenšil na původní velikost.
Jsou určené k ilustraci toho, co je napsáno v jejich popisku.
Aha, a co je tam napsano?
"...shows less ringing artefacts than libjpeg (middle) and has a smaller file size."
"...shows less ringing artefacts than libjpeg (middle) without requiring a larger file size."
Tzn. oproti libjpeg jsou blizsi originalu (mene artefaktu = to jsem myslel tou absenci rozdilu), plus venuji se jen "ringing artifacts".
Také tam k žádné ztrátě barvy nedochází.
Tobe ta zelena v oku vazne neprijde vyblita?
mám kalibrovaný IPS na fotky a mohu říct, že kvalita není nejhorší, jen se ztratila ostrost, je to takové rozpatlané, ale na mobilu skoro nevidím žádný rozdíl, obyč notebook také všechno rozdíly schová, u macu s retinou rozdíl vidím, ne ale tak patrný jak na desktopu.
(porovnával jsem fotky z RAWu - přes tiff - s exportovaným jpgem)
Takže něco jako znovuvynalezený https://github.com/mozilla/mozjpeg ?
Udelal jsem si par testu. Pri stejne velikosti vystupniho souboru mi prijde MozJpeg kvalitnejsi. A zel i pri treba 2/3 velikosti Mozjpeg vs toto mi prijde ze je kvalita srovnatelna. Co se tyce casove narocnosti kodovani, to je kapitola sama pro sebe. Nicmene z --verbose je videt, ze defacto zkousi ukladat s ruznymi parametry stale dokola a vylepsuje pomer chybovosti. Bohuzel vtipne je i to, ze JPEG ulozeny primo z FreePascalu je mnohdy mensi.
Rady bych udelal testu vic - porovnal kvalitu primo pro stejne velke soubory, ale to je diky dobe kodovani nerealne.
K rychlost jeste poznamka - uloha, ktera bezi 6minut u mozjpegu (par tisic obrazku) bezi hodinu Je odhadem v 5% ! Pamet je volne spousta (tudiz zadny swaping), iotop vicemene prazdnej. Testuji na ubuntu 17.04 pre na Ryzen 1800X, 32Gb ram 2400Mhz, NVme ssd.