Vagy tényleg nagyon trivit írtam, vagy nagyon újat, LOL :D
Azt akartam kiemelni, h "...jó módszer lehet...". A tömörítési algoritmus kiválasztása külön tudomány, nem lehet egy jó módszert ráhúzni egy másik adatkupacra. Az EXE fájlok tömörítésére biztosan más algoritmust kell használni mint egy GIF-re, ezért nincs is értelme olyat mondani, hogy "legjobb tömörítõ program"
Az uccsó link óriási, bár még csak a vitaindító üzenetet olvastam el...
Mellesleg (visszaolvasás nélkül) valszeg a következõkre gondolt Frayer barátunk:
1.) h ha van egy ABC, aminek a leírásához kevesebb bit is elég, mint ahány biten tárolják, akkor ott lehet "sorfolytonosan" tárolni az adatok bitjeit, majd azokat felszabdalni a tárolásnak megfelelõ hosszra. Ezzel lehet eleve "tömöríteni", persze ezzel "olvashatatlan" lesz az eredeti. Ráadásul ezt még tömöríteni is lehet már ismert módszerekkel.
2.) Lehet az eredeti üzenet jeleibõl összefogni 2 vagy több jelet egy csoportba és ezeket a kapott csoportokat elnevezni ABC-nek és ezzel leírni az üzenetet. Ez is jó módszer lehet és ezt is tovább lehet tömöríteni, miután "sorfolytonos" bitsorozatot csináltál belõle.
Amit itt leírtam, minden informatikai ismeret nélkül kb. 5 perc alatt magam ki tudtam találni, akkor most elvisznek engem is vagy nem?
Amúgy kedvenc topikjaim egyike, szóval, UP!!!!!!!!!!
"Ha valaki tud valamit Frayer-õl, azt írja le ide. 2009 óta nem írt semmit," Ha Google segítségével visszaolvasod a hozzászólásait, láthatod, hogy 2010-ben még aktív volt. Ha pedig elolvasod a büntetõpont-naplót, illetve a róla szóló topikot, deriválható, hogy a fórummal inkompatibilis magatartása miatt nem maradt meg.
"végülis bevált-e az ötlete, vagy nem, de ha igen, akkor itt valami szerintem bûzlik : Valakik elhallgattatták." Mivel - tudomásom szerint - nem igazán közölt egyetlen egy matematikai levezetést, kész programot, forráskódot, nem hinném hogy ez lenne az oka. Pláne, mint az az elõzõekbõl kiderült, nem igazán volt kompatibilis a fórum közösségével sem.
"Az, hogy a vizsgaidõszaktól jobban izgult, mint attól, hogy mi lesz a saját maga számára bizonyítottan mûködõ ötlettel, az nem lelkiismeretes tanulás, hanem baromság és igénytelenség." Baromság és igénytelenség elvégezni egy fõiskolát/egyetemet és többet keresni mint akik nem végezték el? Hm, érdekes felvetés. Mellesleg hol bizonyította Frayer az állításának helyességét? Programot, forráskdot, algoritmust, matematikai levezetést nem közölt - tudomásom szerint.
Mellesleg tömörítés: mutatok egy hasonlóan magasröptû topikot: Itt van
Halló! Tudom, hogy 2010 tele óta kihalt ez a topic, de lenne egy nagy, és nagyon-nagyon fontos kérésem: Ha valaki tud valamit Frayer-õl, azt írja le ide. 2009 óta nem írt semmit, 2010 óta pedig nem látogatja a SG-t. Nem tudom, hogy végülis bevált-e az ötlete, vagy nem, de ha igen, akkor itt valami szerintem bûzlik : Valakik elhallgattatták. Mondhatni eléggé naív volt, s SAJÁT MAGÁVAL szemben lenézõ és igénytelen. Az, hogy a vizsgaidõszaktól jobban izgult, mint attól, hogy mi lesz a saját maga számára bizonyítottan mûködõ ötlettel, az nem lelkiismeretes tanulás, hanem baromság és igénytelenség. Az pedig, hogy ahhoz képest, hogy mirõl volt itt szó, eléggé szabatosan írt, s még egy nyomorék IP-cím cserélõt sem használt internetezéskor, ÖNGYILKOSSÁG!
Én személy szerint õszintén sajnálom õt, ha a lelépésében valóban az internetmaffia keze volt benne, de amit magával szemben tett, az felháborító. Védeni kellett volna az ötletét! Lehet, hogy csak egy jelentéktelen felhasználó, aki zöldségeket írt össze, s nincs valóságalapja, vagy mûködõ kivitelezése az ötletének, Istenre, még ez lenne itt a jobbik. Na de ha valóban képes volt, vagy lett volna egy óriási jelentõséggel bíró algoritmus és szoftver megírásában, akkor itt tényleg óriási GÁZ lehet, ha valóban eltûnt, vagyis eltûntették !
Mindenesetre, aki tud felõle valamit, tényleg szépen, nagyon szépen kérem, hogy szóljon.
Elõre is köszönöm!
Sziasztok
Ajánlanék a figyelmetekbe 2 tömörítõprogramot.
Az egyik a FreeArc, a másik pedig a NanoZip
NanoZip 0.08 alpha Innen lehet letölteni: http://www.nanozip.net/download.html fórum itt: http://encode.ru/threads/111-NanoZip-a-new-archiver-using-bwt-lz-cm-etc...
FreeArc 0.666 http://www.freearc.org/Download.aspx vagy ha a legfrissebb verzió kell, akkor itt: http://forum.ru-board.com/topic.cgi?forum=5&topic=31386&start=0&limit=1&m=1#1 fórum itt: http://encode.ru/threads/43-FreeArc
És a jövöbeli tervek :) (egy kicsit késnek már vele): http://freearc.org/FuturePlans.aspx
Az encode.ru fórumán is olvashattok mind a kettõ tömörítõröl.
A FreeArc közel 80 nyelvet támogat, közte a magyart is. Ingyenes, nyílt forráskódú. Konzolos és grafikus felület. Akár 2-5* gyorsabban is tömöríthet mint a többi tömörítõ. 11 féle tömörítési eljárást ismer. Külsõ tömörítõprogramot is képes a tömörítés során meghívni. Tömör blokkok gyors újratömörítése. SFX archívumok létrehozása. AES/Blowfish/Twofish/Serpent titkosítás. És még egyéb tulajdonságok (nézd meg a honlapon).
A Nanozip csak angolul tud. Konzolos és grafikus felület. SFX archívum létrehozása (csak konzolos verziójú SFX modul). 7 féle tömörítési eljárás a 0.07-es verzióig, a 0.08-asnál kibõvítve (összesen 11-re plussz a raktározva tömörítés az összes verziónál) az "nz_lzhd" és az "nz_lzhds" tömörítési metódusok 'parallel' és 'parallel_extra' tömörítési eljárásokkal bõvítve. Több-magos prociknál 20-40%-kal gyorsabb tömörítés az "nz_lzpf" és "nz_lzpf_large" tömörítési metódusnál. Tervezik a titkosítást, többkötetes tömörítést és shell-integrációt a Windows-ba. (mint pl. a 7-Zip/FreeArc/WinRAR/WinZIP/WinUHA tömörítõknél).
Szerintem ezek a legjobb ingyen hozzáférhetõ tömörítõk (A WinUHA is).
A WinRK esetleg még jobban is tömöríthet, de hétköznapi használatra nem igen jó a maximális tömörítés fok, (Ha a 'PWCM' tömörítést választod a betömörítésnél) lassú ez is, és lassú a fájlanalizáló mechanizmusa is. A PAQ és ennek társai is/meg nagyon lassúak (Az UDA/WinUDA tömörítõ meg az/nagyon is). A KGB Archiver meg szerintem s***, tök lassú ez is a maximális tömörítés felé (PAQ5-PAQ6-tõl fölfelé), az ilyen floopy-s/néhány tíz/száz kB-os archívumok is csak kamu, van benne 1-2 valódi adatot tartalmazó fájl a tömörített archívumban, pl.: 1-2 exe/dll fájl(ok), a többi meg csak üres adathalmazú fájl (pl: azonos karakterek vannak csak benne). Vagyis ez is használhatatlan. A NetOpSystems Recomposer, NetOpSystems FEAD/FEAD II Optimizer/Dynamizer és az újabbak, NOSSO, iNOSSO/iNOSSO PLUS, ezek az igazán jó tömörítõ(k), a tömörített fájlokat is összetömöríti (lásd: Adobe Reader 6.x/7.x verziók telepítõi, a 8.x-tõl fölfelé már csak raktározva vannak a fájlok a Data1.cab fájlban) csak azt sem lehet róluk tudni, hogy hol, mennyiért lehet(ne) beszerezni legálisan (biztos méregdrága). Egy-két PDF doksi kering a neten csak róla (a FEAD-rõl).
Tisztelt Faustus!
Köszönöm megtisztelõ válaszod. Közben a wim -ek hibásságára rájöttem - nem tudtam mountolni (winmount)azokat. Megvizsgáltam a többi állományt viruskergetõvel, szerencsére negatív. Arra a megállapításra jutottam (amúgy ezek torrenttal leszedett állonányok), hogy közönséges reklámkonténernek használta a kiötlõje (url -ek - letöltési lista ..)
szivélyes üdvözlettel ahojan
1. A tömörített állományban van két tömörített állomány 50 és 30 MByte-osak. Így a 80 MByte érthetõ. 2. A két tömörített állományban két nagy állomány található - amik egészen kicsire tömöríthetõek (a tömörítést RAR 3.80 beta 3 segítségével végeztem, alapbeállításokkal, Debian Linux 5.0.3 alatt): - install.wim: 2,3 GByte -> install.rar: 1,2 MByte - boot.wim: 117 MByte -> boot.rar: 59 kByte
Hogy miért? Mert a .wim állományok kvázi üresek - a tartalmuk szimplán csak 0-ás bájtokból áll. 3. Van még egy 74 MByte-os .exe és az összes többi kicsi állomány (többnyire jól tömöríthetõ szövegfájlok vagy 4 MByte méret alatti .exe állományok) - összesen 80 MByte méretben. 4. Ha a két rar állományban levõ összes állományt kicsomagolom, majd a kapott állományokat RAR-ral (a tömörítést RAR 3.80 beta 3 segítségével végeztem, alapbeállításokkal, Debian Linux 5.0.3 alatt) összetömörítem kapok egy 80 MByte-os .rar állományt. ;)
Mellesleg ez valami becsapás - egy rendes DVD-képbõl nem kapnál 80 MByte-os állományt - ahogy azt egy hasonló dologról a piratebayen is állítják: "The resultant ISO created with this torrent will not boot, missing files. Not trolling, but as of now, it is absolutely impossible to compress Vista's 2.5 GB to 80 MB. Not even using PAQ8O."
"This is a bullshit download. It's not a real ISO, it will not boot. It's not Vista. It seems more like a lo-tech virus than something legit. My VS program promptly went nuts when this file was finished. Stay away, stay very far away. No compression IN THE WORLD is going to take multiple gigs down to 80 megs. Period. You're a fool if you run this and I hope your computer dies a horrible painful death."
"WOW! so i downloaded this with utorrent..i burned it with the software included in the download..set my bios settings to where it would only boot with my cd/dvd drive. and it fucked up pretty bad..it had a problem starting windows and erased a bunch of my programs..i did every thing your instructions said and it didnt work at all. if it sounds to good to be true..it is... "
Ezt a produkciót miképpen lehetne utánozni? A 80MB -os fájl ~2.6 GB adatot tartalmaz. A tömörítvény kibontásához a jelszó: Only80MB
Miképpen lehetne hasonló tömörítést elérni? Próbálkoztam a kgb -vel de az nagyon gép- és idõpazarló megoldás.
Üdvözlettel ahojan
Amin most dolgozok az a veszteség mentes eljárás, nem sok köze van a veszteségeshez. Csak annyiban hogy a keletkezett adat kisebb lesz mint a kiinduló érték. A veszteségmentes lassú, de nem veszik el adat. A veszteséges gyors, de romlik a minõség, és megváltozik az adatstruktúra.
A veszteségesnél képzelek el olyat hogy, létrehozunk egy véges méretû adatbázist, amiben tipikus mintákat tárolunk, olyan mintákból álna az adatbázis ami leginkább jellemzi a természetes képeket. Sok olyan mintázat van amik gyakran megtalálhatóak, bármely képen, legyen rajta egy hegy, fa, vagy egy autó. Kis pixel csoportokra gondolok, egymás közelségében, szomszédságában. De mégtöbb olyan mintacsoport van amik szinte sose fordulnak elõ a természetes képeken. Pl, az analóg TV-kben mikor adásszünet van, az a képzaj, na az ilyen jeleket nem tároljuk le, mert szinte sosem fordul elõ a természetes képeken. A gyakori minták viszont meglesznek. A minták jelváltozásokat írna le a képben. És úgy épülne fel a kép vagy hang, hogy csak a minták sorszámával hívatkozunk a tömörített adatban, és ahól szükséges megadhatunk olyan transzformációkat amiket kis helyen el tudunk tárolni, de amik nagy pontossággal fel építenek egy természetes képet.
Egy példa. Emberi haj. Ez egy gyakori minta a képeken, sok hajszál fut egymás mellett, sok kis közel párhuzamos vonal fut egymás mellett. Mivel ez egy gyakori minta , nagy valószínûséggel megtalálható lesz a minta adatbázisban, a több tíz vagy száz ezer minta között. A tömörítés során a program logaritmus kereséssel megkeresi melyik minta hasonlít rá a legjobban a képen szereplõ struktúrához, majd veszi azt a mintát és ha kell kicsit elforgat rajta, nagyít vagy kicsinyít, kicsit megdönti ha kell. Majd eltárolja a minta sorszámát, és azokat a biteket amik leírják hogy milyen transzformácit kell még rajta végezni.
Most gondolj bele, 8 bit meghatároz 256 elemet. 16 - 65536 ot. 24 bit meg 16 milliót. Tehát hatalmas is lehet a minta adatbázis, akkor is csak pár bit kell az adatbázisban lévõ minták beazonosításához, mivel elegendõ csupán a sorszámokkal hivatkozni rájuk. Pár bittel sok esetben 60-100 pixel közelítõ értékeit is meg lehetne adni. Ahól meg homogén a felület ott meg pár bit meghatározhat akár töb száz, vagy ezer pixelnyi területet is.
Hm... Frayer, milyen érdekes projekten dolgozol. Anno a szakdogámat a veszteségmentes tömörítési eljárásokból írtam, ahol kielemeztem elég sokféle adattömörítési eljárást. RLE, LZ(W), Huffman, delta meg ilyenek... Most sajna nem találom a szakdogámat, h az összeset felsoroljam. Igen jó nyomnak érzem a nem az LZ szerû redundancia megszüntetés alapú, hanem összehasonlítási módszeres gondolatodat. Ha jól értettem ez lenne az alapötleted. Tehát olyasmirõl lenne szó, mint az RLE, csak nem azt nézed, hogy egymás után hogyan vannak a minták, hanem kinézel egyet, és megnézed, h az hányszor fordul elõ az adathalmazban. Jól értem?
Sziasztok. Újból írok ebbe a topikba. A tömörítõ algoritmus optimalizálásának a közepén járok még mindig. Sajnos nem megy olyan gyorsan mint amilyenre számítottam.
De most volt egy áttörés, és most úgy néz ki a helyzet hogy sikerült elérnem azt hogy egy iteráció alatt az adatot eredeti méretének 82-70 %-ára csomagoljam be, olyan feltételek mellett,hogy az eredeti adatokat maradéktalanul vissza lehessen állítani, bitrõl bitre teljesen egyezzen az eredetivel. A másik kritérium, hogy az adatok csomagolt állapotban is tovább tömöríthetõek legyenek. Örülök, mert sikerült elérnem,hogy percek helyett másodpercek alatt lehessen becsomagolni pár tíz megás állományt. De még így is nagyon lassú, mivel alapvetõen a bájtokban lévõ biteket egy olyan vektorban kezelem amikben bájt méretû alapegységek vannak. Tehát egy bit egy bájtot foglal le, így 8X lassabban dolgozik a cpu vele, ha a sávszélességgel számolunk. A program nem számolás igényes, nem használ lebegõpontos egységet, csak integert, elvétve. DE, viszont tele van az elgoritmus, elágazásokkal, nagyon sok, méghozzá olyanokkal amiknél semmit nem ér a modern processzor elágazás becslés áramköre. Teljesen kiszáíthatalan ugrások tarkítják a munkamentet. Ha készen lesz a végsõ elgoritmus, minden féle képpen célhardwert kell hozzá építeni ha gyorsan kell hogy mûködjön. Egy normális áramkör erre az elgoritmusra optimalizálva szerintem azonos órajelen 50-80 X is gyorsabb lehet az x86 os architektúránál.
jaja :) Már rá is kapcsolódtam. Megvettem a Bjarne féle c++ programozási nylev c. köynvét. bazi nagy 1300 oldal a két kötet, egymás tetejére rakva van vagy 15 centi szélesek.
Na mindegy, az a lényeg,hogy most rajta vagyok a témán, és pár hét múlva tudok majd adni grafikonokat is. Most olyan programot írok amivel bizonyos szempontok szerint tudom vizsgálni az adatstruktúrákat. Különbözõ filterekkel. Szóval majd tudok mutatni képeket is a grafikonokról, meg a programoról is. De ez még nem a tömörítõ lesz, ez csak megmutatja nekem hogyan lesz érdemes megírni a tömörítõ algoritmust, hogy bizonyos szintig optimális legyen, azaz mûködjön minden adathalmaznál.
Phase I. Elkészítése egy általam kigondolt és számomra szükséges adatsruktúra elemzõ program különbözõ filterkekkel. kb 1 hónap, vagy 3 hét még. ON THE WAY
Phase II. Adatok elemzése, kiseb változtatások az elemzõ programban, optimális algoritmus megírása pszeudó nyelven papíron. egy hónap lesz ez is kb.
Phase III. overcome - productum Maga az algoritmus megírása win32 platformra. windowsos grafikus interfészt használva kommunikál a felhasználóval és csak egy filet tud majd tömöríteni, remélem sikerrel, akárhányszor. Ez is 2 héttõl -egy hónapig fog tartani. Ha ezzel készen vagyok és jól fog sikerülni, elkezdek azon gondolkozni hogy hól tudnám hasznosítani a dolgot.
Nah, van már mûködõ változat?
Másik topikban azt írtad, hogy ha vége a vizsgaidõszaknak, nekiállsz és akkor az egész digitális világot megváltod...
Útközben lemondtam errõl a blokk mintákról, Elég sokat nézegettem a wavelet képeket hogy rájöjjek, ez lesz az alapja. Tetszik nekem a képek színhûsége és lágysága, egy HD képet be lehet nyomni 40-50 kb ba jelentõs minõségvesztés nélkül. Ezt még valahogy ötvözni kellene egy minta adatbázissal, tehát az eredeti ötlettel. Nem is lenne nehéz, a hatásfok is kiváló lenne, nézegettem a wavelet coefficiens jeleit amibõl a képet rakja össze, és eléggé tipikus jelek vannak benne, amit erre tipikus mintákkal közelítõleg meg lehetne adni, ezzel akár még tovább le lehetne nyomni egy framet, mondjuk 5-10 kb ra.
mit gondoltál, majd én fogom õket berajzolni??? :DD Persze hogy írok rá programot, veszek több száz lossless képet, vagy bmp-t és szépen egy program leveszi a mintákat, teli írja az összes helyet, 1-65536- ig és aztán folytatja tovább, a következõ mintát kiszedi a képbõl és megnézi,hogy melyikhez hasonlít a legjobban az adatbázisban, majd a kettõt átlagolja és már az kettõ átlagát írja vissza az adatbázisba. Minden mintához tartozik majd egy számláló, ezért könnyen súlyozni lehet majd hogy melyik minta szerepel többször általában a képeken. Ezeket a nagy értékû mintákat, megtartom és amik csak elvétve fordulnak elõ, mondjuk pár millió minta közül csak egyszer jön elõ azokat elvetem, hogy legyen hely a többi olyan mintának amik fontosabbak, mert kb minden 2 ezredik blokkban elõfordul.
Nem rossz 5let, de csak a kettes szám többszörösével érdemes szorozni, mivel így férne bele a kettes számrendszerbe maradék nélkül.
De nem kell izgulnod, mivel három szín komponens van ezért egy 8x8 as blokkra igazából 3 db 8x8 as blokk jut, minden színre egy. Foggalmam sincs milyen lesz a végeredmény, de az biztos hogy artifakt mentes, nem lesz benne tömörítési zaj, max csak nem pontosan ugyan olyanok lesznek a szín intenzitások néhól egy egy pixelen, de az is lehet hogy még nagyítva sem látunk majd különbséget a tömörítés után. Nem tudom, de az biztos,hogy egyedül ez nagyon sokáig fog tartani leprogramozni. Fõleg a mozgóképek esetében. A egy jó delta kódolás nem egyszerû játék az biztos. Egyedül biztos nem fog menni ez a része, ezért inkább elõbb a veszteséges eljárást fejezem be, aztán neki állok ennek is.
"gondosan legyártott mintákat tartalmaznak" Ebbe bele is lehet õrülni... mi lenne, ha írnál hozzá olyan programot, ami készítene mintákat?
Bár én nem vagyok programozó, de a mintás ötlet már nekem is eszembe jutott. :) Mi lenne, ha 65536-ot még megszoroznád legalább 3-al?
jah, bocsi a helyes írási hibákért,de most vettem nemrégen egy apple billentyûzetet, és még nem alakult ki az érzés, párszor nem ütöm le elég erõsen a billt. Na jó, olyan embert keresek aki leginkább a gyors kódok írásában jártas, ismeri a procik újabb kiterjesztett utasítás készleteit, mint mmx, sse 1-4. Örülnék ha találkozhatnék olyannal aki jártas a mozgókép kodolásban, tudja hogy mûködik a hatékony mpeg layer4 "divx" mozgás lekódolása, Delta kódolása hogy valósul meg. Ezekre nem nagyon találtam leírást, még. Jah, és nem open projectet akarok, ahoz túl jó lesz a végeredmény szerintem , és sok meló lenne benne. Nem ismeri valaki a magyar mplayer fejlesztõ csapatból valakit?
Amit én csinálok, annak meglehetõsen rossz a hatásfoka, egy menetben kb, 10%-os lesz a hatásfok. De a lényeges az az, hogy akárhányszor is át tudok menni az adatokon, rekurzióval és mindig jelentkezik ez a 10% os csökkenés. De igazából ,nem ehez az algoritmushoz kellene segítség, hanem erre szeretnék építeni egy veszteséges mozgóképtömörítési alkalmazást. Ami egyrészt rettenetesen hatékony lenne és nem tartalmaz képzajt, "artifaktokat".
A koncepció már megvan csak kicsit még hiányos. Szeretném megtudni ,hogy mûködik a Divixnél vagy a többi mpg4 módszer "delta" kódolása, mert abból ki tudnék indulni.
A koncepció az,hogy a képeket felbontom 8x8 pixeles blokkokra mint a jpeg nél, csak aztán nem történik furier transzformáció, hanem ezt a blokkot összehasonlítom egy hatalmas bázisminta állomny több ezer blokjával. Amik persze elõre elkészített, gondosan legyártott mintákat tartalmaznak, minden minta a lehetõ legjobban különbözik egymástól. Minden minta más és 65536 van belõllük. Na szóval amelyik mintára a legjobban hasonlít a a mi blokkunk annak a számával hivatkozok rá a tömörített állományban. Azaz egy blokk 64 bájtját, 2 bájton tárolok el. De ez csak egy kis része az egésznek, mert nagyon sok trükköm van még, már egy idelye dolgozok rajta, csak a processzorra optimális fejlesztés nem megy. Nem nagyon tudom,hog írjak optimaliált gyors kódokat. Meg még kedõ is vagyok.
Soha nem adom el. Csak a használati jogokat , bizonyos idõre, és úgy képzelem ,hogy a belõlle származó haszon egy kis részét elkérem.
Részben C++ ban szeretném, a megját meg ASM-ben. Baromi gyors lesz. Van ez a shanon limit, amit még egy tömörítõ program sem tudott átlépni. Ennél a programnak pont az a lényege,hogy ha megnõ a minta entrópiája akkor megy jól a tömörítés. Abból a feltevésbõl indultam ki, hogy akármilyen féle mintákra fel lehet álítani olyan szabályokat ami alapján jó lesz a tömörítés. A sorhossz kódolás akkor hatékony ha sok azonos érték van egymás mellett, a huffman ha adott értékbõl fajtákból jelentõsen több van az állományban. Az lzw akkor jó ha bizonyos adott mintákból jelentõs van az állományban. Az enyém úgy mûködne, hogy akkor hatékony ha minél nagyobb az entrópiája, minél véletlenszerûbbek az adatok... azaz, ugyanazon "szimbólumok" aránylag közel helyezkednek el a kódban. De a legnagyobb különbség az, hogy az eddigi alkalmazásokkal elvégett átkodolás után megnõ az adatok entrópiája, közel a shanon limithez és már nem érhetõ további méretcsökkenés, esetleg nagyon pici.. mivel ezek az algoritmusok az ismétlõdéseket "redundanciát" veszik ki a kódból. Amit én készítek annál a kódolás után ugyan olyan nagy lesz a kimenõ entrópia mint a bemenõ adatoknál, azaz akárhányszor megyünk át rajta , mindig kisebb és kisebb lesz, és ahogy mélyebre megyünk egyre jobban a rekurzióba, annál hatékonyabb lesz a tömörítés is. Érdekes. Én sem számítottam rá. Egy menetben átlagosan 10-20% al lesz kisebb az adat, és kicsomagolással egyértelmûen vissza is lehet álítani minden bitet a kezdeti állapotra. Ami lehetõvé teszi a mûködést, az az,hogy a "véletlen" egymás után következõ száoknak , szimbólumoknak , mintázatuk van. És akármilyen véletlennek tûnõ sorozatot nézel, azokban is benne vannak a minták. Úgy néz ki a mi világunkban mindenhól felbukkannak ezek a minták. Gyanítom ,hogy ez egy mester fraktál lehet.
gondolom el tudod magyarázni, ha már úgyis embereket keresel, h mi is a lényege
ha van itt egy infos, aki jó volt a Shannon-féle tanokból, biztosan be tudja bizonyítani, mekkora infomennyiség mennyi redundanciát tartalmaz és van-e módszer arra, h azt el is lehessen a lényegtõl választani infoveszteség nélkül.
Ekkora komprimálást sztem nem lehet csinálni, de persze matematikai bizonyítás nélkül ezt nem állítom.
Éns is foglalkoztam nagyon rövid szövegek tömörítésével, de épphogy másfélszeresre össze tudtam nyomni - a fölé kell mindenféle hókuszpókusz, amit nem programoztam le... :P de vannak ötleteim....
Én most dolgozok egy olyan programon ami elég jól tömörít majd, nem az adatok redundanciáját fogja kihasználni henem az nagy entrópiában kialakuló mintákat fogja kihasználni. Nagyon gyors lesz mivel stream szerûen megy végig az adatotok, és úgy néz ki,hogy semmi akadálya annak,hogy egy 1 gigás fájlból pár kilobájtosat tudjon csinálni, mert akárgányszor átmegy az adatokon az algoritmus, mindannyiszor kisebb lesz kb. úgy 10-20 % al. Úgy néz ki, ha rekurzívan visszavezetem az adatokat mondjuk 40-szer, akkor 10 szor kisebb állományt kapok, ha meg 50 szer akkor meg ezerszer kisebb lesz. Ahhoz, hogy ezerszer kisebb állományt kapjak a végén, kb egy 10 megás fájlnél, a processzor kb, 100 mega adaton kell mûveletet végeznie, egséz számokkal, sok elágazásos utasítással. mivel nem lzw szerûen mûködik hanem sorosan, baromi gyors lehet. Akit érdekel az szoljon, egyedül nehéz leprogramozni.
Windowsos UHARC Az egyik legjobb,és nem kel a parancssorokkal baszakodni,mint a dosos verziónál.
nem hiszem,h ez lenne az a .z -s tömöritõ,de köszi, megnéztem a linked, és kb cerka mégis az kell h legyen... csak ne .txt-vel példáloznának az oldalon :)
én találkoztam egy ratDVD progival, ami egy DVD-t, szal 4.7 GB-ot tömörített 1.7 GB-ba oszt vissza... érdekes volt aszittem vmi átverés, hogy 1.7 GB os .ratdvd fájlt hipphopp a progivel egy 4.7 GBos lemezzé alakítok, namost nemtom mennyire volt veszteséges, én nem láttam semmi problémát a filmen minden szép volt.. errõl mit tudtok errõl a ratDVD-rõl?
Én teszteltem több féle állományon néhány tömörítõt, hogy melyik is tömörít a legkisebb méretre. Minden tesztben a Winuha gyõzött. Bár ez tömörít a leglassabban, de torony magasan ennek a legjobb a tömörítési aránya.
Létezik olyan program amivel gyorsan meglehet nyitni kódolt tömörített fájlokat ha nem vágom a jelszót???:D
melyik az a tömöritõ,ami hivatalosan linuxos eredetü,de pl. megtalálhato a pcsx2 0.9.2 1ik dvd pluginjában is,és a .iso, .mdf, .nrg, etc etc (szal imagefájlokbol) csinál nem ritkán 20 megás .z kiterjesztésû fájlt? az eddigi rekordom: 1.6 GB-s mittom én melyik DBZ .iso -jábol csinált 27 MB-s .z fájlt. az más kérdés,h mivel nemtom,mi ez a tömöritõ, igy csak a pluginnal ttam kicsomizni,de továbbra is vitte a pcsx2 hibamentesen a játékot, szal nem hiszem,h komoly adatvesztés lett vna,és ttommal a .iso azért olyan kicsi,mer az eleve vmilyen szinten "sürü" :)
és nem a gzip-re gondolok,bááááár... amennyi "zip" van manapság,nem lepõdnék meg...
szal mi csinál .z kiterjesztésû tömöritményt? (nem .gz, nem .zip, nem .gzip, etc etc,hanem szimlán .z) image fájlok csomizásánál nálam ez tuti favorit :)
Jah, és telepítõ exe-ket se próbálgassatok tömörítgetni, mert azok eleve tömörítettek :)
Sejthetõ, ugyanis a szöveges dokumentumokat veszteségmentesen akár a tizedére is össze lehet tömöríteni, ha nem kissebbre, de te ezt nyílván nem tudhatod, kicsi ákombákom :)
Szerintem azt mondja hogy nincs ertelme tomotireni manapsag mert azt a keves helyet felesleges megsporolni. Megis egyre jobb lossless(vesztesegmentes) tomoritesi algoritmusokat/eljarasokat fejlesztenek ki, hang es video tomoritesi celzattal. :P
Õszintén szólva a tömörítés ma már nem annyira lényeges mint régebben, mivel óriásit fejlõdött az adathordozók kapacitása... persze itt most a veszteségmentes (RAR, ZIP) tömörítõkre gondolok.
Több száz megás cuccot mi értelme van betömöríteni? Szerintem nem ér meg annyi szenvedést egy kis helyspórolás
CABinet packer, unpacker :) ennél jobb ugyse létezik,nem véletlenül használják mindenféle winfos, játék, etc etc tömöritéséhez, ráadásul már létezik "visual formában" is
ez után jön nálam a winrar :)
ja én azt hittem ez valami jókis új zene formátum nem ilyen telefonos faszság.
MP3 to ringtone... neked nem tomorito kell, hanem segitseg...
szerintem is az uharc, csak nem tudom használni. Valahogy külön kell vele az egyes állományokat megbuherálni. pl a Scarface 200 megara van letömörítve vele.
Sorry váratlnanul el kellett utaznom akyyy.
Köszönöm a sok üzenetet.végre megtalátam a nekem valót:WINRAR! Egyébként,ha vki mp3-at akar tömöríteni ajánlom figyelmébe az MP3 to ringtone gold-ot ezzel a progival veszteségmentesen lehet és 3.6mb-os számból(MP3 csak) 900Kb-os MP3-at készít. ha vkinek kell elküldüm(keyemmel): MSN: [email protected]
ez tömöríti legjobban a programokat :)
winrar
és ki tud jól emészthetõ algoritmus leírásokat tömörítõkhöz. konkrétan szövegfájlok becsomagolásáról lenne szó és én akarom megírni.
A winrar jelszovedelme a legjobb a vilagon! Az istennek nem lehet feltorni. :)
az is igaz topiknyitó megnyitja a topikját, ráadásul olyat, ahol saját magán akar segíteni, és többet vissza se néz:D
Winzip a kep tartalmakat tomoriti legjobban, Winrar a hangfajlokat, es szovegfajlokat, dokumentumokat, WinAce a programokat (es futtathato fajlokat).
Ha nagyon osszetett az anyag, amit tomoriteni akarsz, erdemes mindegyikkel kiprobalni, de nagy kulonbsegek nem igazan vannak, szerintem a Winrar mindenre jo valasztas.
Ha pedig igazan nagy tomoritest szeretnel, minosegromlast kell eszkozolni, lehetoleg ugy, hogy a szemed, fuled ne vegye eszre a kiszedett képpontokat, hangsávokat.
mégis hol írja szerencsétlen hogy zenét vagy filmet akar tömöríteni?
mivan ha monjduk dokumentumait, jegyzeteit, akarja..
A tömörítés mértéke függ a tömörítendõ fájl típusától. Pl egy 500 megás AVI videót nem fogsz tudni 10 megára lecsökkenteni. Amúgy jelenlegi tudásom szerint a 7-Zip- tud a legjobban tömöríteni, elvileg ennek van a legjobb tömörítési rátája. Ráadásul ingyenes is.
Informatika és tudomány
