Rus wint opnieuw prijs met 'supercompressie'

De Russische software-ontwikkelaar Alexander Ratushnyak is er in geslaagd om 100MB aan Wikipedia-tekst te comprimeren tot een zelfuitpakkend bestand van 16.481.655 bytes.

Daarmee wint hij voor de tweede maal de Compression of Human Knowledge-prijs, ook bekend als de Hutter Prize. De Rus behaalt met zijn lossless-programmeerkunsten een compressieratio van 6,07, zodat hij voor elke Wiki-byte slechts 1,32 bit nodig had. Daarmee verbeterde hij zijn oude record met 3,5 procent en verdiende hij 1732 euro aan prijzengeld. Het wedstrijdregelement stelt dat het gecomprimeerde bestand zichzelf moet kunnen uitpakken op zowel een Linux- als een Windows-machine. De klus moet op een 2GHz Pentium 4 met 1GB werkgeheugen binnen een tijdspanne van tien uur zijn geklaard. De compressiemethode van Ratushnyak, waarin verschillende taalanalyses op de data worden losgelaten, doet er negen uur over om de Wiki-data uit te pakken tot het originele bestand. De oud informatica-student biedt zijn verbeterde algoritme, paq8hp12 geheten, met een gpl-opensourcelicentie aan.

Volgens Marcus Hutter, initiatiefnemer van de prijs, nadert Ratushnyak met zijn compressieratio de grenzen van wat menselijk gezien mogelijk is bij het voorspellen van patronen in tekstdata. Alleen met kunstmatige intelligentie zouden dergelijke bestanden in de toekomst mogelijk nog beter gecomprimeerd kunnen worden, maar AI wordt door Hutter juist gezien als een even lastig probleem om aan te pakken als het ontwikkelen van complexe compressie-algoritmes. De grenzen van wat theoretisch haalbaar is, werden al door een van de grondleggers van de informatica, de Amerikaan Claude Shannon, voorspeld en later door twee wetenschappers bevestigd. Toch weten programmeurs als Ratushnyak hun algoritmes elk jaar weer met enkele procenten te verbeteren.

Reacties (103)

[Munters]

Het lijkt me dat er een flinke fout staat in de samenvatting boven. Het lijkt een beetje op wat ongelukkig in de tekst snijden. (Eerst vermelden dat het een zelf-uitpakkend bestand moet worden, en vervolgens melden dat "de klus" maximaal 10 uur mag duren).

Bij het inpakken komt taal-analyse om de hoek kijken, en kan het erg lang duren. In de praktijk dus 9 uur voor deze data-set.
Bij uitpakken is de methode bekend, en kan er recht-toe-recht-aan uitgepakt worden. Dat kan nooit zo lang duren. Dat blijkt ook wel uit de rare tekst: "de wiki-data uitpakken tot het originele bestand". Het bestand wordt uiteraard uitgepakt tot de originele wiki-data.

[Jan-E]

Als je het originele artikel leest blijkt dat de validatie binnen die 10 uur gedaan moet worden. Dat is dus inpakken, uitpakken en vergelijken. En ze schrijven zelf al dat het uitpakken vele malen makkelijker is dan het inpakken.

[Verwijderd]

Allemaal heel mooi maar wat ben je met een compressie die 9 uur nodig heeft om zich uit te pakken ?

[BugBoy]

Op mijn oude vertrouwde Commodore 64 had ik de hele nacht nodig om een demo te comprimeren. Jaren later comprimeerde ik op een PC het al gecomprimeerde bestand in een fractie van een seconde en er zat nog zeker 10% lucht in. Compressie algorithmes worden steeds verfijnder en sneller en ook de CPU power gaat hier vrolijk in mee.

[ATS]

Het zou mij verbazen als je met dat nieuwere algoritme het originele bestand niet nog kleiner zou kunnen krijgen. In het originele bestand zullen meer patronen te zien zijn dan in het al gecomprimeerde bestand, waardoor ook een moderner compressiealgoritme beter zal kunnen presteren.

[elmuerte]

Niet alleen veel CPU tijd is nodig, ook heel veel geheugen.
Zie: http://en.wikipedia.org/wiki/PAQ#Large_Text_Benchmark

Het gaat bij dit soort dingen niet om direct nuttige toepassingen.

[Reactie gewijzigd door elmuerte op 22 juli 2024 23:09]

[Sebast1aan]

Je moet het zien als een soort Formule-1, maar dan voor nerds.

Je hebt er niet direct wat aan, het is entertaining, maar de verschillende technologien of gedeeltes daarvan hebben wel praktisch nut en zullen hun weg naar de real-world maken.

[Verwijderd]

Nu is het idd nog spielerei, maar wie zegt dat zulks in de (verre) toekomst in bepaalde situaties niet nuttig kan zijn? Er moeten toch situaties zijn waar juist het verzenden van informatie heel duur is?

Dan denk ik bijvoorbeeld aan meetapparatuur op afgelegen of moeilijk bereikbare plaatsen, zoals geavanceerde seismografische stations in een vulkaankrater die hun informatie per satelliet moeten verzenden. Of misschien in de ruimtevaart wie weet? De marsautootjes die heden rondcruisen op de Rode Planeet hebben telkens maar elf minuten radiocontact. Met een steviger compressie zou men dus meer data kunnen verpompen...

Maar voor de particulier is een dergelijk algoritme idd niet handig. Misschien verandert dat door de immers sneller wordende hardware - wie ooit al eens een rar-file van een paar mb heeft uitgepakt op een 386 weet wel waarom.

En wie weet komt er wel hardwarematige ondersteuning? Krijgen tapestreamers en consoorten een dedicated chipje aan boord voor dit soort zaken?

[Verwijderd]

Allemaal heel mooi maar wat ben je met een compressie die 9 uur nodig heeft om zich uit te pakken?

Het nut van een dergelijk algoritme is uiteraard puur wetenschappenlijk. Kijken hoe we de theorische wiskundige grenzen kunnen benaderen met een traag algoritme kan straks de basis leggen voor een nieuw, beter, en sneller algemeen bruikbaar algoritme.

Praktisch gezien is dit vrijwel nutteloos. Niet alleen omdat het bijna 10 uur duurt, maar ook omdat het met taal-analyse werkt, en dus geen binaire data kan verwerken. Bovendien is schijfruimte is veel goedkoper dan CPU-time.

[Blokker_1999]

backups

[Verwijderd]

Ik weet het niet hoor... Als er hier iets in de knoop zit, kost iedere minuut gewoon opdrachten, en dus geld. We hebben 150GB aan actieve data, en die moet gewoon binnen 2 uur teruggezet kunnen worden.

Als 100MB 9 uur duurt, dan duurt 150GB 573.9 dagen.

[CARman]

Het gaat er bij deze wedstrijd om data zo ver mogelijk in te pakken, niet om het ook snel te laten zijn, alleen maar binnen de gestelde limiet voor de wedstrijd. Zijn factor is nu met 3,5% verbeterd terwijl de tijd die nodig is om het bestand nu nog verder te comprimeren met bijna 80% gestegen is.

De data waar jij het over hebt die je snel weer wilt gebruiken en hoogst waarschijnlijk op tapes staat met een compressiefactor die gemiddeld nog geen factor 2 haalt ( ten opzichte van 6,07 die hier gehaald is ), dan kun je snel backups terug zetten en proberen om zo ver mogelijk te comprimeren niet met elkaar vergelijken.

[dcm360]

Is dat dan ook 150GB aan tekst? het gaat in het artikel namelijk om de compressie van zeer veel tekst van Wikipedia, niet diverse (binaire) bestanden.

[Ravek]

Tekst is juist makkelijker te comprimeren dan willekeurige binaire informatie. Elk tekstbestand is tenslotte ook een binair bestand, maar niet elk binair bestand is een geldig tekstbestand. De binaire bestanden die geen geldige tekst vormen kunnen daarom gebruikt worden om een stuk tekst te representeren.

Een tekenreeks als "zrxyz" zal bijvoorbeeld nooit in normaal Engels voorkomen, dus kan diezelfde tekenreeks gebruikt worden bijvoorbeeld "the apple" te representeren. Gezien dat "zrxyz" minder tekens heeft dan "the apple" kost het minder ruimte om het eerste op te slaan, dus wordt het totale bestand kleiner.

Natuurlijk is dit verhaal enorm versimpeld en laat het veel andere en verdere mogelijkheden voor compressie weg, maar het basisidee komt hierop neer.

[Reactie gewijzigd door Ravek op 22 juli 2024 23:09]

[catfish]

backup tape streamers hebben (de betere toch) hardware compressie, wat (indien goed geimplementeerd) VELE malen sneller gaat dan die 9u, je merkt er dus niks van als het goed is

[Jejking]

...

Op een Intel P4 2.0GHz met 1 gig mem. Houd je daar ook even rekening mee?

[Jace / TBL]

Juist niet, want opslagruimte kost geen drol meer.

[i-chat]

euh even denken ik heb een (fictief) bedrijft dat 1 terabyte aan data per maand genereerd, en als bedrijf ik ik dat 7 jaar bewaren (iets met een wettelijke termijn),

ook heb ik besloten dat al m'n backup cassettes dubbel en op 2 verschillende locaties bewaard worden...

hoeveel geld zouden 2 van deze van climate-controll vorziene kluizen me laarlijks kosten?

Data opslag-ruimte is niet alleen maar, die ene 1TB hdd die jij in je pc hangt....
maar ook de talloze data tapes die in geschikte omstandigheden bewaard moete worden - zowel binne (voor directe toegang) als buiten (voor extra veiligheid tegen bijv brand) je bedrijfspand.

[Verwijderd]

Onzin. Geld is geld. En de hoeveelheden data waar een beetje bedrijf mee te maken krijgt neemt elk jaar met 100-200% toe.

[Verwijderd]

Toekomstige pc's zullen ook wel iets sneller worden...

[-=bas=-]

En later zou je natuurlijk alles in hardware kunnen uitvoeren.
Zeker fabrikanten van backup producten zoudne dit soort chips kunnen toepassen.

Maar ik moet wel zeggen dat wikipedia-pagina's niet zomaar willekeurige databestanden zijn.

[i-chat]

idd dat is eigenlijk alleen maar text, grofweg net als de hele documentatie van een bedrijft, beschrijvingen van hun pattenten hun mail etc etc...

wil je dit in een bedrijfs-toepassing doen zul je je documenten dus min of meer eerst moeten spitsen - en de plaatjes en overige bestanden uit je txt moete filteren - je zou die dan in een ander compressie formaat wellicht naast je text kunne opslaat met een active verweizing hoe 't document terug moet worden opgbouwt, (eigenlijk niet eens zoveel afweikend zoals nu een OpenDocumentText-bestand, (open die maar 's in je zip programma).

[eth0]

Over 10 jaar misschien nog maar 9 minuten, en over 20 jaar 9 sec met deze methode. Want computers worden steeds krachtiger

[TD-er]

Waarom zou het alleen maar sneller worden doordat de computers krachtiger worden?
Zoals ik het nu begrijp gebruikt hij zeer uitgebreide woordenboeken, die helemaal toegespitst zijn op de in te pakken tekst. (dan kun je verwijzen naar woorden, of stukken tekst, ipv die helemaal op te slaan)
Het lijkt me dat het zoeken naar het meest optimale woordenboek hier het meeste tijd kost en dat lijkt me nou typisch iets wat je van te voren ook al kunt optimaliseren.
Bijvoorbeeld Wikipedia-teksten zijn vrij makkelijk te herkennen aan de gebruikte wiki-markup-syntax. Als je in je compressor alvast een aantal goed presterende woordenboeken als voorkeur aanbied voor bepaalde soorten data, dan kun je de compressie enorm versnellen.
Zo zou je de boel ook nog eens multithreaded kunnen maken door elke thread een stuk data met een bepaald woordenboek kunnen laten comprimeren en na afloop alleen het resultaat gebruiken wat de grootste compressie oplevert.

Het voordeel is duidelijk, namelijk snelheid.
Het nadeel is dat je compressor aanzienlijk groter zal worden en je waarschijnlijk meer geheugen zult gebruiken tijdens de compressie.

[rp87]

maar over 10 jaar heb je ook geen bestanden meer van 100 mb.

[engelbertus]

uhm "nee natuurlijk niet. dan heb je voor hetzelfde op te slaan wel 1 gb nodig zonder compressie. "

dat is natuurlijk een beetje rare redenatie van je. het komt er op neer dat we steeds meer willen opslaan. en het gaat dan niet om een bestandsgrootte. 100 MB blijft 100 MB

[Verwijderd]

over 10 jaar heb je ook geen PCs meer met slechts 4 processoren

[TeXiCiTy]

En nu reist natuurlijk de vraag of deze alog. multitreaded te doen is Lijkt me meer prestige dan iets met een veelgebruikte commercieel haalbare toepassing.

[RedLizard]

Dat gaat prima. Hak je data op in blokjes van 100 MB, en laat iedere thread een blokje doen. Of het ook *beter* kan is inderdaad een goede vraag.

Waarschijnlijk kan je de blokjes steeds kleiner maken, en zal vanaf een gegeven moment de compressieratio afnemen (een byte laat zich slecht comprimeren als je niet naar de context kijkt). Er zal dus een grens zijn aan hoeveel threads je kunt gebruiken zonder een significant effectiviteitsverlies. Maar multithreaded kan het zeker.

[jvdmeer]

Tenzij je natuurlijk natuurlijk te maken hebt een progressieve compressie (weet de juiste term niet). Ik bedoel hierbij dat je de laatste byte pas kan uitpakken als je de informatie over alle voorgaande bytes beschikbaar hebt.

Dan valt er helemaal niets te multithreaden.

[Pietervs]

Nee, dat wil je niet, maar door de "ontwikkeling" van Microsoft bestaat die kans wel degelijk. Open nu maar eens een Word document, en sla die op zonder 1 tekentje tekst erin: is al een bestand van 10-15 Kb (tenminste met Word XP). Dat zie ik in de toekomst alleen maar groter worden...

[d-snp]

Okey tijd voor wetenschappelijke onderbouwing. Men neme 1 leeg document in Word2007. Men slaat op als word97-2003 bestand (.doc) vervolgens slaat men op als .docx, resultaat:

.docx 9.840 bytes (12.288 on disk)
.doc 26.112 bytes (28.672 on disk)

Vooruitgang bestaat wel degelijk, ook bij microsoft. (Overigens is Word 2007 de beste word processor die ik ooit heb gebruikt, OpenOffice en andere Word versies ver achter zich latend, en corel printoffice ook )

[Verwijderd]

Men slaat op als word97-2003 bestand (.doc) vervolgens slaat men op als .docx

docx is dan ook een PKZIP-archief. Het is dus al gecomprimeerd (en zal daardoor met entropie-compressie niet veel kleiner te krijgen zijn).
OpenOffice gebruikt ook een zip-variant, meen ik.
Voor zover ik weet, gebruikten eerdere versies van Word geen datacompressie.
Ik denk dat de ongecomprimeerde inhoud van een docx-bestand wel groter is. Er zit een hele directory-structuur in verstopt, en XML-bestanden zijn ook minder compact dan binaire varianten.
Na compressie zal dit echter weinig uitmaken (dezelfde tags komen steeds terug, dus kunnen met weinig bits geencodeerd worden).

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:09]

[Top-Rob]

OpenOffice achter zich latend? OpenOffice is opensource en dus gratis... volgens jouw logica kan ik ook wel OpenOffice met Microsofts Kladblok vergelijken en concluderen dat OpenOffice veel beter is .

[Zarc.oh]

Vooruitgang bestaat wel degelijk, ook bij microsoft. (Overigens is Word 2007 de beste word processor die ik ooit heb gebruikt, OpenOffice en andere Word versies ver achter zich latend, en corel printoffice ook )

En de wetenschappelijke onderbouwing voor deze uitspraak is waar te vinden?

[Amdk6II]

Er was ook een Microsoft Office versie waarbij het doc bestandje steeds groter werd als je hem opsloeg terwijl die leeg was.
Moet ik wel zeggen dat ik mijn vroegere office programma's vrijwel nooit update.

[RwD]

@Amdk6II:
Volgens mij houd/hield office bij wie er hoe lang aan een bestand werkte. Die informatie wordt dan weer in het bestand opgeslagen. Lijkt me op zich een redelijke verklaring waarom een leeg bestand groter wordt, maar ik weet niet of dit ook de werkelijke reden is. Je mag er wel van uit gaan dat ook Word geprogrammeerd is en vaste patronen af loopt en er dus iets gebeurd wat minimaal loigsich is om te doen (al dan niet wenselijk of handig).

[Reactie gewijzigd door RwD op 22 juli 2024 23:09]

[Verwijderd]

De vraag is sowieso hoe nuttig dit is. Als gebruik gemaakt wordt van taalanalyse om tekstpatronen te voorspellen zal deze compressie-methode waarschijnlijk taal-afhankelijk zijn. Alles dat geen platte tekst is zal door deze methode hoe dan ook veel minder goed gecomprimeerd worden en zelfs als de tekst in de beoogde taal is maar bijvoorbeeld in Open XML is gevat zal de compressie eronder lijden.

Het is een leuk wetenschappelijk experiment, maar verder?

[turbomckwek]

Binnen 10 uur is natuurlijk leuk voor de wedstrijd, maar voor thuis gebruik is het natuurlijk vreselijk onhandig om een computer 10 uren te laten worstelen om een bestand uit te pakken. Maar wel knap dat hij het weer heeft gedaan en nog eens 3,5% verbeterd. HULDE

[Gepetto]

En er zat natuurlijk nog de beperking op dat het een het bestand zichzelf moet kunnen uitpakken op zowel een Linux- als een Windows-machine. Als je er een gecomprimeerd bestand van maakt waarbij je een losse uitpakker mag gebruiken en dit alleen maar onder Windows hoeft te werken, kunnen waarschijnlijk nog veel betere resultaten behaald worden.

[.Johnny]

In zo'n wedstrijd kan dat natuurlijk niet. Je kunt dan de losse uitpakker gewoon volgooien met patronen en vervolgens een ultra klein ingepakt bestandje maken. Dan is alleen je uitpakker megagroot, dus slaat je compressie alsnog nergens op!
En het zijn relatieve resultaten in zo'n wedstrijd, dus iedereen heeft hetzelfde nadeel met de self-extractor.

[Reactie gewijzigd door .Johnny op 22 juli 2024 23:09]

[killercow]

wat een onzin dat een losse uitpakker nog veel beter zou kunnen, hoeveel van de 16 meg denk je dat er gebruikt wordt voorhet uitpak algo?

En waarom zou een windows uitpakker schelen boven een linux uitpakker?

[Str1ngS]

Vervang dan 'Windows' door 'één OS'.

Ik denk dat Gepetto zelf alleen op windows werkt, en dat het niet zijn bedoeling was om linux onderuit te halen..

[Gepetto]

wat een onzin dat een losse uitpakker nog veel beter zou kunnen, hoeveel van de 16 meg denk je dat er gebruikt wordt voorhet uitpak algo?

Neem maar eens een bestand en maak hier een losse zip-file van en doe vervolgens het zelfde met een self-extracting zip-file, dan zie je ongeveer hoe de verhouding ligt. En dan werkt zip nog met een relatief eenvoudig algoritme, dus zonder taalanalyses.

En waarom zou een windows uitpakker schelen boven een linux uitpakker?

Dat zeg ik niet, maar dit zijn wel dingen die nu met het bestand zelf worden "meeverpakt".

Mee eens dat ze het voor die wedstrijd zo hebben gedaan, maar wanneer je het op een praktische manier wilt gebruiken hoef je natuurlijk de uitpakker niet met elk bestand mee te sturen, die wordt zoals gezegd met een gpl-opensourcelicentie aangeboden.

[Reactie gewijzigd door Gepetto op 22 juli 2024 23:09]

[Nijn]

Sterker nog, als iemand zo slim is om een (goedkope) insteekkaart te fabriceren met dit algorithme... Met een CPU die hiervoor gemaakt is zou het wellicht on-the-fly moeten kunnen.

[Fulcrum2000]

Het algoritme is trouwens een aangepast variant van PAQ8 (ontwikkeld door Matt Mahoney), speciaal geoptimaliseerd voor text data. Wat PAQ8 normaal al kan kun je hier zien: http://www.maximumcompression.com/

[bulle bas]

Ach, als het aantal cores per processor jaarlijks toeneemt, kan dit in de nabije toekomst wellicht een goede comprimeermethode blijken.

[Bamsebjorn]

Maar... thuis gebruiken we inmiddels Core 2 Duo 2,4 Ghz met 4GB werkgeheugen... dat zal allicht een stuk sneller gaan.

[i-chat]

vergeet hier niet dat het om een intel pentium 4 met 1gb geheugen ging, het is dus een SINGLE core op slechts 2ghz, - 9uur op zo'n ding, zoal missching nog maar 5 en een half uur zijn op een core2 quad 2ghz 4gb ram.

[MatthiasDS]

Om echt dagelijks bruikbaar te zijn heb je echt wel beter nodig dan een factor 2 sneller. Zeg maar gerust minstens 500 keer sneller.

[Reactie gewijzigd door MatthiasDS op 22 juli 2024 23:09]

[DarkSide]

Als ik dit soort dingen lees moet ik toch altijd aan de Nederlander denken die het ultime zip algortime bedacht had, maar dit heeft meegenomen in zijn graf.

Neemt niet weg dat dit best knap is natuurlijk. Maar om nu bijna 10u te wachten totdat een bestandje uitgepakt is?

[Atomsk]

Als ik dit soort news items lees, vrees ik altijd dat er weer iemand over die van der Sloot begint. En ja hoor..

Het valt echter nog mee dat niemand hem nu nog fanatiek verdedigt met pseudo-argumenten als "ja maar vroeger dacht men ook dat vliegmachines onmogelijk waren, dus dan moet onmogelijke compressie ook kunnen".

Het appelleert gewoon aan een verlangen naar mysteries en spannende complotten, die als ze waar zouden zijn, een revolutie teweeg zouden brengen. Hij had bij wijze van spreken ook "het geheim v/d eeuwige jeugd" mee in zijn graf kunnen nemen. Dan had hij net zo'n schare fanatieke gelovigen gehad.

Nu heb je weer bijv. Steorn met z'n claim van 'energie uit niets opwekken'.

[Bulls]

het ging niet om compressie techniek maar om een algoritme voor films. een bepaalde chip heeft alle waarden voor geluid en beeld opgeslagen, en een sleutel bestand van 1Kb kan dat unlocken waardoor je gewoon eigenlijk vanaf de chip afspeeld wat door de sleutel op de goede volgorde word gezet.

als deze techniek er zou zijn en het ook op alle data kon worden toegepast, dan had je bijvoorbeeld met een torrent bestand gelijk het hele spel te pakken in plaats van dat je daarmee nog 4 GB moest downloaden om maar een voorbeeld te noemen.


maarja die knakker was te voorzichtig en daarom is het er niet gekomen.
als het echt was geweest had hij gewoon het aan zn zoon moeten uitleggen en door hem laten doen inplaats van een hartaanval te krijgen door de stress

[martijnvanegdom]

Jij bedoeld Sloot? Ten eerste weten we niet of dat inderdaad een werkelijke compressietechniek was.. iig niet loseless (wat zip is) want Sloot zat zwaar onder die theoretische grens en of zijn uitvinding uberhaupt waar was aangezien hij niemand de techniek heeft laten zien en alleen maar half werkende demo's.

Edit : Even voor de duidelijkheid.. Ik geloof absoluut niet in de claims van Sloot.

[Reactie gewijzigd door martijnvanegdom op 22 juli 2024 23:09]

[DarkSide]

Idd van der sloot.
denk ook niet dat zijn uitvinding mogelijk was, maar het blijft een boeiend verhaal.

[Rixard]

Jan Sloot

[Verwijderd]

Van der Sloot was die jongen ervan verdacht werd een een compleet meisje op Aruba te comprimeren. Was alleen geen lossless compressie...

[Verwijderd]

Het bekende verhaal van Jan Sloot bedoel je:
http://home.hccnet.nl/h.b...p%20een%20chipkaartje.htm

[Jazzle]

Jan sloot was dat, ik heb dat boek "de broncode" gelezen, maar het komt gewoon niet geloofwaardig over. Ten eerste is het gewoon ongeloofwaardig klein, 16 speelfilms op 64kilobyte. En ten 2e, waarom is er dan nooit iets als een broncode gevonden, en waarom was hij zo bang om ook maar íets vrij te geven over z'n uitvinding...

[lennartkocken]

Ik heb het boek ook gelezen, en inderdaad, de groottes waren ongeloofwaardig, maar dat maakt het juist logisch dat-ie niets van z'n uitvinding wilde vrijgeven, hij was als de dood dat iemand anders met zijn uitvinding aan de haal ging...

[ThE_ED]

Zip is toch al een vast algoritme

[Reinstein]

Er zijn er zelfs twee:

pkzip aka winzip
wordt voornamelijk op windows machines gebruikt

gzip
wordt voornamelijk op *nix machines gebruikt

[Verwijderd]

Vergeet ook bzip niet, en ik meen dat ook 7zip z'n eigen variant heeft... En wie weet wat er verder nog aan zip te krijgen is

[Gepetto]

rar

[Reactie gewijzigd door Gepetto op 22 juli 2024 23:09]

[Verwijderd]

Rar is geen zip
Ja, rar ondersteunt wel zip-bestanden, maar ik bedoel dat niet alles met 'zip' in de naam hetzelfde algoritme heeft. Er zijn een paar verschillende (niet-compatibele) varianten die allemaal 'zip' in de naam hebben.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:09]

[poepkop]

Ja ja geduld hebben he ;-) denk dat het op een 3ghz core 2 duo wel wat sneller gaat... Voor een backup van wiki is het leuk.

[Rixard]

Je bedoeld de compressie van Jan Sloot http://nl.wikipedia.org/wiki/Jan_Sloot. Het is nog steeds niet duidelijk of dit wel echt bestaan heeft.

[.oisyn]

Je bedoelt de hoax van Jan Sloot? En dat was geen "zip" algoritme, maar een lossy compressie algoritme.

[HaterFrame]

Dat was toch een HOAX?
Edit: In het vervolg wat sneller op het tobo rammen.

[Reactie gewijzigd door HaterFrame op 22 juli 2024 23:09]

[Rinzwind]

Jep, denk het ook, maar wel eentje waar een aantal mensen wel wat mee verdiend hebben.

[Reactie gewijzigd door Rinzwind op 22 juli 2024 23:09]

[CrimsonRider]

Van der Sloot bedoel je? Dat was gewoon onzin.

[AlexanderB]

ik heb nog iemand gekend die eenzelfde idee zei te hebben, ook nooit meer wat van hem gehoord hopelijk leeft hij nog.. (ik heb em wel het verhaal verteld van de nederlandser.. etc..)

[rodie83]

De vraag is een beetje, wat doet WinRar met 100MB tekst? En hoe snel pakt die het weer uit?

[SH4D3H]

Op 'n Celeron M 1.6 GHz (Yonah):

Inpakken:
WinRAR 3.7, best compression, no SFX: 100.000.000 naar 24.753.284 in 1m50s
Idem, SFX: 100.000.000 naar 24.948.356 in 1m49s

Uitpakken:
.rar 1m15s
.exe 1m15s

Disclaimer: Ik heb in WinRAR de standaard settings (op compression na dan) gebruikt voor compressie en SFX.
Ik weet niet of met advanced opties de boel nog wat te tweaken is.

[Reactie gewijzigd door SH4D3H op 22 juli 2024 23:09]

[humbug]

Scheelt dus toch zo'n 33%.

[Verwijderd]

Het is misschien miereneuken maar 100MB is nog altijd 104 857 600 bytes

overigens kan je de andere resultaten hier bekijken: http://www.maximumcompression.com/data/summary_mf.php

@Durona:

A megabyte is a unit of information or computer storage equal to either 106 (1,000,000) bytes or 220 (1,048,576) bytes, depending on context.

Eijndeloze discussie dus

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:09]

[Verwijderd]

Het is misschien miereneuken maar 100MB is nog altijd 104 857 600 bytes

Als je dan toch wil "miereneuken" doe het dan goed:
100MB (MegaByte) is 100x10⁶ Bytes
100MiB (MebiByte, bi staat voor binary) is 100x2²⁰ Bytes

[SH4D3H]

Dan moet je zeuren bij de redactie
Download maar eens het testbestand van de bronsite, die is 100.000.000 bytes.
Dat is dan ook, logisch!, het bestand dat ik voor deze test heb gebruikt.

[C-dude]

Doet me denken aan een zip bestandje dat ik hier heb staan
Terabyte.zip ~ 1 Mb groot.
Maar het uitpakken vraagt wel 1 terrabyte aan space.

[lembregtse]

witruimte kan je zoveel in een zip steken als je maar wilt
of je er na het uitpakken nu ook iets mee bent ...

[Leronjo]

Das waarschijnlijk een gezip bitmapje met maar 1 kleur erin?

[C-dude]

Neen.
16 teksbestanden van ~66Mb groot.
http://users.telenet.be/c-dude/terabyte.zip

[Fulcrum2000]

Gewoon een mega textfile met een enkel karakter als input.
Dit rar-filetje van 550 bytes, is uitgepakt ook bijna 5 megabyte!.

http://www.maximumcompression.com/test.rar

[Verwijderd]

Deze 66MB*16 zijn in totaal 1056 MB, overeenkomende met ongeveer 1 GB, waar is je terabyte? Bovendien zijn het 16 bestandjes met alleen maar spaties...

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:09]

[C-dude]

Oeps idd.
Zie het ook net.

Excuses Dacht dat het bestanden waren met 1 enkel karakter en het totaal een terabyte opbracht.

[Oxiounking]

Ik heb ook nog ergens een 7z bestand met een film van 600MB erin, totale grootte? precies, 17kb.

Waarom,
1. die film zijn uncompressed, aka bitmapjes achter elkaar geplakt
2. Het is in 1024x768 in windows
3. het grootste gedeelte is allemaal hetzelfde, het laat zien hoe je een bestandje tussen mapjes verhuist

EDIT: wacht, dit kan ook:
r[1000000000000]

Da's uitgepak 1 terabyte groot en ingepakt maar 16byte.

Ik bedoel hier mee te zeggen, wat jullie proberen duidelijk te maken is behoorlijk nutteloos

[Reactie gewijzigd door Oxiounking op 22 juli 2024 23:09]

[SVDT]

Er wordt een taalanalyse op het te comprimeren bestand losgelaten. Haalt deze compressietechniek dan niet een stuk slechtere resultaten als het om compressie van een gewoon binair bestand gaat?

[dcm360]

Dat ligt er dan aan hoeveel binaire woorden je in je taal hebt

Het gaat gewoon zuiver om een programma dat is geoptimaliseerd om tekst te kunnen comprimeren, en daardoor waarschijnlijk niet met binaire inhoud om kan gaan, of er gewoon niets nuttigs uit krijgt.

[NaliXL]

Ben ik de enige die een virus-waarschuwing krijgt op PAQ8HP12.EXE uit het bestand paq8hp12.zip? Ik gebruik Norman antivirus, en de virusnaam die aangegeven wordt is W32/Suspicious_U.gen .....

[mae-t.net]

suspicious en generic... Klinkt alsof Norman op basis van heuristieken een onbekend inpak/compressieprogramma detecteert. Laat dat nou net zijn wat het is

[Krizzie]

Pentium 4 2Ghz he.

Een Core Duo/Quad kan daar al een flinke schep van af halen denk ik zo.

[flippy]

heeft iemand die gozer als verteld dat floppys niet meer gebruikt worden als opslagmedium?