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.
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).
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 ..)
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... "
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.
I love to walk in the rain, because no one knows im crying
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.
I love to walk in the rain, because no one knows im crying
Ú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.
I love to walk in the rain, because no one knows im crying
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.
I love to walk in the rain, because no one knows im crying
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?
I love to walk in the rain, because no one knows im crying
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.
I love to walk in the rain, because no one knows im crying
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.
I love to walk in the rain, because no one knows im crying
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 :)
8800GT,A64 X2 3800+,A8N-E,2GB DDR,SB A2
Razer Db Magma patkány + Logitech Cordless Rumblepad2:)
azért van leirva,h mindenki tja,mi a konfigom,ha bajom van...
é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?
"Az nem villámlás, csak készítik a képeket a GoogleEarth-höz!"
É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.
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 :)
8800GT,A64 X2 3800+,A8N-E,2GB DDR,SB A2
Razer Db Magma patkány + Logitech Cordless Rumblepad2:)
azért van leirva,h mindenki tja,mi a konfigom,ha bajom van...
Jah, és telepítő exe-ket se próbálgassatok tömörítgetni, mert azok eleve tömörítettek :)
- De ezzel saját magad lejáratását folytatod, ezt nem érted meg? Magadat égeted tovább. Ami a legszomorúbb hogy magyar színekben. Tapló.
- nem is szines a nevem
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 :)
- De ezzel saját magad lejáratását folytatod, ezt nem érted meg? Magadat égeted tovább. Ami a legszomorúbb hogy magyar színekben. Tapló.
- nem is szines a nevem
- De ezzel saját magad lejáratását folytatod, ezt nem érted meg? Magadat égeted tovább. Ami a legszomorúbb hogy magyar színekben. Tapló.
- nem is szines a nevem
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
"meg fog azoknak a száma növekedni, akik bár minden rátermettség nélkül úgy érzik, hogy a nemzet vezéri szolgálatába kell állítaniuk "halhatatlan" erejüket"
Mein Kampf, Adolf Hitler
www.sulyokg.hu
Ki nem szarja le, hogy milyen géped van?
Az én irodámban mindenki örömöt okoz. Egyesek azzal, hogy bejönnek, mások azzal, hogy kimennek.
www.sulyokg.hu
Ki nem szarja le, hogy milyen géped van?
Az én irodámban mindenki örömöt okoz. Egyesek azzal, hogy bejönnek, mások azzal, hogy kimennek.
Ő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 :)
8800GT,A64 X2 3800+,A8N-E,2GB DDR,SB A2
Razer Db Magma patkány + Logitech Cordless Rumblepad2:)
azért van leirva,h mindenki tja,mi a konfigom,ha bajom van...
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.
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: marcokeceli@hotmail.com
Az élet semmi, csak egy árnykép, a gyengék menedéke, ami persze nem védheti meg őket.
"Az ember nem hal meg olyas valamiért,amiben ő maga nem hisz" - A.H.
Heil Sogron! ๏̯͡๏)
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.
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.
A fórumban portálunk látogatói kapnak lehetőséget véleményük kifejezésére. Az itt megjelenő vélemények regisztrált látogatóink magánvéleménye, és nem tükrözik az SG.hu Hírmagazin szerkesztőségének álláspontját.
