Het compressiegeheim van Jan Sloot ontrafeld

[Michael1954]

From: Lampje74

Tja.. compressie technieken zijn niet bepaald moeilijk te verzinnen.
Ik heb ok al 10 jaar terug een methode bedacht voor lossless compressie. Hiermee is een extreme compressie mogenlijk. Hoe groter het bestand hoe beter de compressie verhouding was te maken. En het compressen gaat erg snel. Echter is het decompressen van mijn methode het hekelpunt. Ik heb het inmiddels al jaren niet meer geprobeert om aan de decompressor te sleutelen. M'n 486 waar ik het in der tijd in TP6 had geschreven struikelde op geheugen problemen en de zelf aanroepende procedure (JA met goed werkende until exit!) Op klein formaat werkte het redelijk. maar ging je het systeem opschalen liep het vast omdat de procedure enkele 100den layers diep ging Is niet omheen te komen op het moment.
Mischien weer eens uit het stof halen in in delphi aan de gang gaan. iedergeval de compressor afwerken en tests doen met diverse bestanden.. kijken of de compressie resultatien ook werkelijk uniek blijven. Het is nl rekenkundig gecomressed waarbij de output evt weer opnieuw door het zelfde comressie systeem kan. of te wel de resultaten bieden een gelijke data als dat gebruikt kan worden als input (bytes). Dit integen stelling tot zip/rar/jpg/mp3/mpg enz...

[Michael1954]

From: Anonymous Coward

Is dit een grap, of bedoel je het serieus?

[Michael1954]

From: Grr

Volgens mij sluit in dit geval het een het ander niet uit.

[Michael1954]

From: Anonymous Coward

[Michael1954]

From: Lampje74

Ja serieus.
Inpakken is het probleem niet.
En afgezien van magische vierkanten (waar ook weer omwegen voor zijn) verwacht ik geen problemen.
Maar wat ik zeg.. het uitpakken vergt nog al wat, via het door mij daar voor verzonnen princiepe. Op papier kan je dat goed simuleren, maar ik mis nog wat (wiskunde/programeer) kennis om dit netjes uit te werken.
Wat ik dus al schreef.. nog weer eens in duiken.
Iedergeval kan ik de compressor schrijven. wat ik nog nodig heb is een tool/code om crc's te calculeren en om files mee te vergelijken op afwijkingen. (2 verschillende bestanden die een gelijke grote packed file opleveren met elkaar vergelijken om te controleren dat de packed files toch verschillend zijn)

[Michael1954]

From: Anonymous Coward

Ja serieus.

Volgens mij beweer je iets wat niet mogelijk is. Maar tegelijkertijd omschrijf je het een beetje onduidelijk, dus misschien begrijp ik je wel verkeerd. Kun je nog eens duidelijk omschrijven wat je claim is?

Inpakken is het probleem niet.

Inpakken gaat makkelijker dan uitpakken?

wat ik nog nodig heb is een tool/code om crc's te calculeren en om files mee te vergelijken op afwijkingen.

Waarom zou je dat nodig hebben? Je kunt twee bestanden (van gelijke afmetingen) gewoon bit per bit vergelijken. Dat is ten eerste veel makkelijker. Maar ten tweede ook veel betrouwbaarder, je zult namelijk bestanden tegen komen die dezelfde crc hebben, maar die toch niet hetzelfde zijn.

Maar wat veel belangrijker is, kun je een roundtrip maken? Als je een bestand inpakt en daarna weer uitpakt, krijg je dan het origineel weer terug?

[Michael1954]

From: Lampje74

ik wil het vaag houden zodat een ander er niet mee aan de haal gaat...

Inpakken gaat idd erg makkelijk. meer wil ik niet kwijt ivm 'diefstal'.

Uitpakken is lastig omdat ik (huidig) opzoek ga naar de inhoud om dat te vergelijken met het inpak resultaat. beetje als brute force een password zoeken.

Ik wil een crc en bit/byte wise file compare hebben om een matchende filesize&crc te scannen. filesize is de snelle 1e check. dan de crc als 2e check. en als 3e check de filecompare. dit duurt vaak wat langer lijkt me.
Het idee is dan dus om de packer te schrijven en m'n HD in te pakken (file voor file) en de resultaten in een map dumpen en kijken of er gelijke resultaten uit voort komen. om zo hopelijk te bewijzen dat het unieke packed files opleverdt.

Overigens heb ik met de magische vierkanten al heel wat prijs gegeven van de methode.

[Michael1954]

From: Anonymous Coward

Ik wil een crc en bit/byte wise file compare hebben om een matchende filesize&crc te scannen. filesize is de snelle 1e check. dan de crc als 2e check. en als 3e check de filecompare. dit duurt vaak wat langer lijkt me.

Nee hoor, een directe file compare is sneller dan van beide files een crc uitrekenen.

om zo hopelijk te bewijzen dat het unieke packed files opleverdt.

En wat schiet je daar mee op? Als het geen unieke packed files geeft dan heb je bewezen dat het niet werkt. Maar als alle packed files wel uniek zijn heb je nog lang niet bewezen dat het wel werkt.

ik wil het vaag houden zodat een ander er niet mee aan de haal gaat...

Ah. Je weet niet hoe een crc moet uitrekenen maar je claimt wel dat je een revolutionaire nieuwe methode hebt gevonden waar je 'extreme compressie' mee kunt bereiken?

[Michael1954]

From: Lampje74

Waarom nadenken over hoe je een CRC uitrekend als het al diverse malen is gedaan. Dus de vraag om dat deel code/tool...
Staat los van het feit dat het juist een dood eenvoudige methode van compressie is. Maar als je een beetje kap kan proggen in Delphi (kan ik het tenminste volgen..) wil ik wel met je om tafel om e.e.a. uit te leggen en samen te werken
ff in excel de compressie factor calculator op gezet. 65536byte wordt terug gebracht tot 2560byte (plus header data) dus zeg dat je op 3KB uit komt. Is een factor 25.
Ga ik naar een groter reken veld (2x zo groot) kan er 262144byte aan data naar 5120byte worden terug gebracht, ex header. Dat is een factor 50. grotere bestandne worden opgedeeld inmerdere velden. Of als de terugreken methode sterk is te verbeteren tov brute-force kan je nog grotere velden aan. met nog hoger ecompressie factoren tot gevolg. En zoals gezecht kan je het compressie resultaat weer opnieuw compressen en zo nog hogere ratio's behalen.

[Michael1954]

From: Anonymous Coward

Waarom nadenken over hoe je een CRC uitrekend als het al diverse malen is gedaan.

Dat zeg ik niet. Het valt mij op dat dat iets relatief simpel is in vergelijking met het ontwikkelen van een compressie algoritme.

Staat los van het feit dat het juist een dood eenvoudige methode van compressie is. Maar als je een beetje kap kan proggen in Delphi (kan ik het tenminste volgen..) wil ik wel met je om tafel om e.e.a. uit te leggen en samen te werken

Waarom niet gewoon hier?

ff in excel de compressie factor calculator op gezet. 65536byte wordt terug gebracht tot 2560byte (plus header data) dus zeg dat je op 3KB uit komt. Is een factor 25.

Dus een bestand van 65536 bytes gaat terug naar 2560? Hoezo is het originele bestand precies 65536 bytes groot? Wat heb je allemaal in de header staan? Wat voor data zit er in het originele bestand?

En zoals gezecht kan je het compressie resultaat weer opnieuw compressen en zo nog hogere ratio's behalen.

Zegt het begrip entropie je iets?