De Broncode

[Michael1954]

From: Rogier

Ok, maar dan zou het wel degelijk een compressie zijn. En ik geloof niet dat je met wat voor knappe formules dan ook een film kunt reconstrueren op basis van een paar kilobyte data. En zeker niet dat zoiets door een analoge technicus wordt bedacht, want zo'n proces zou op z'n zachtst gezegd zeer complexe informatiebewerkingen en datastructuren omvatten.

[Michael1954]

From: Anonymous

Misschien denk jij er te complex over Rogier. Sloot was bang het te verliezen omdat het zo simpel was/is!

[Michael1954]

From: Anonymous

Jan Sloot's principle looks like that of Klaus Holtz with the different that Sloot made a fixed static reference memory with all the unique data already in, while Holtz made it dynamic as a self learning system, also was Sloot final output key only 1Kb in size. As written in the book "De broncode" Sloot used 5 algorithms where he needed 12Mb for each algorithm what included storage for temporary calculation. He was working on a new application what needed 74Mb for each algorithm to store the temporary calculations for longer movie/TV programs, probably to store the bigger amount of frame keys after the 1Kb input key was decoded. The advantage of Sloot system was that it was possible; to add in every electronic device the processors with the algorithm included the reference memory and memory for the temporary calculations storage. After that only a one 1Kb key code for every movie or TV program was needed to generate the frames for displaying it at a display device.

Let's say one movie/program frame is 1024x640=655,360pixels
According to Jan Sloot second patent:
One block is 16x16=256 pixels
And 64 blocks are one row
Then there are 655,360/256=2,560 blocks in a frame
And 655,360/(256*64)=40 rows in a frame

If there are 25 frames a second and a movie is 90 minutes then:
There are 655,360x25x60x90=88,473,600,000 pixels in a movie/program
88,473,600,000/256=345,600,000 blocks in a movie/program
88,473,600,000/64=5,400,000 rows in a movie/program
88,473,600,000/38.125=135,000 frames in a movie/program


Figure 3 explanation:
30 reference memory contains all possible pixel values (colour values 256 or 2560 or 102400)
31 1st (de)coding part(*) compares every decoded pixel value with the reference memory (30)
32 pixel memory store pixel codes, 256 pixel values stored
33 2nd (de)coding part generate a block code from 256 pixels
34 block memory store block codes, 64 block values stored
35 3rd (de)coding part generate a row code from 64 blocks
36 row memory store row codes, 40(**) row values stored
37 4th (de)coding part generate a frame code from 40(**) rows
38 frame memory store frame codes, 135.000(***) frame values stored
39 5th (de)coding part generate a movie/program code from 135.000(***) frames
40 movie/program memory store movie/program codes, 1Kb each

* Also digital video signal input.
** Frame pixel size depended.
*** Frames a second and movie/program length depended.

41 key processor decoding part check if all blocks, rows and frames are only stored once and that in case of double ones only coordinates are stored
42 storage (chip card) keep a copy of the movie/program memory (40) and calculations from the key processor (41)
43 input-output equipment (chip card reader)
44 key processor coding part(*) stores the movie/program code in the movie/program memory (40)

* Also digital video signal output.

In the above example pixels are used but it's also possible with audio or text.
Details about the reference memory storage and the key code algorithms are not explained in this patent description.
If for example a video input pixel is 1byte then for example every coding part (5 in total) must generate an output key 40 times smaller then the input data to end with a 1Kb key.
88,473,600,000bytes/(40x40x40x40x40)=864bytes (without audio).

[Michael1954]

From: Rogier

(Anonymous)
Misschien denk jij er te complex over Rogier. Sloot was bang het te verliezen omdat het zo simpel was/is!

Misschien, maar dan moet het over een nieuwe manier van dataopslag zijn gegaan. Dat er een zeer simpel idee achter een techniek zou zitten die films in 1 KB opslaat geloof ik niet. Sterker nog, dat dat uberhaupt mogelijk zou zijn geloof ik al niet.

Dat een analoge technicus een eenvoudige doch briljante manier vindt om dataopslag veel compacter te maken, dat kan ik best geloven. Maar dat verhaal over "één kilobyte" en een algemene formule om daaruit de originele film terug reconstrueren: no way.

(Anonymous)
(...)
If for example a video input pixel is 1byte then for example every coding part (5 in total) must generate an output key 40 times smaller then the input data to end with a 1Kb key.
88,473,600,000bytes/(40x40x40x40x40)=864bytes (without audio).

Dit hele verhaal wordt gebracht alsof het een generieke manier beschrijft om die data zo klein te krijgen. En dat is sowieso onmogelijk, want het is bewijsbaar dat er geen compressie-algoritme bestaat dat data van een bepaalde grootte per definitie kleiner maakt.

Ga maar na: als het écht mogelijk was om iedere film -desnoods beperken we het even tot alleen films van 1024x640 25fps 90min- tot 1024 bytes te reduceren, dan zou dat betekenen dat er uit 28193 verschillende films (en dat is nog een compleet te verwaarlozen kleine fractie van het totale aantal mogelijke films) al minstens de helft wordt gecomprimeerd tot dezelfde sleutel als een andere film. En één van die twee kan dus niet meer worden gedecomprimeerd tot zijn origineel.

[Michael1954]

From: Kokkie_d

(Rogier)
Misschien, maar dan moet het over een nieuwe manier van dataopslag zijn gegaan. Dat er een zeer simpel idee achter een techniek zou zitten die films in 1 KB opslaat geloof ik niet. Sterker nog, dat dat uberhaupt mogelijk zou zijn geloof ik al niet.

De hersenen zijn nog altijd het beste opslag medium dat er bestaat. He kleinste en volledig solid state!

(Rogier)
Dit hele verhaal wordt gebracht alsof het een generieke manier beschrijft om die data zo klein te krijgen. En dat is sowieso onmogelijk, want het is bewijsbaar dat er geen compressie-algoritme bestaat dat data van een bepaalde grootte per definitie kleiner maakt.

Generiek = Hersenen !?

En we proberen het over coderen te hebben en niet compressie.

[Michael1954]

From: Joep

Beste mensen,

Ik heb nu even alles doorgenomen en heb het volgende beeld gekregen
dat misschien weer wat suggesties kan uitlokken of mensen kan mee
laten denken...

STEL:
Je slaat in een 'database' op:
een signaal op van 1 frame pixels combinatie
(of het nu met geluid is of nie)
bestaande uit:
-een signaal op voor 1 pixel combinatie
-een signaal op voor 1 rij pixels combinatie

Simpel: 1 of 0 naar 2, de rij word dan uit alle mogelijkheden van deze 1en en 0en een 3, uit alle mogelijkheden van deze rijden word dan een frame bv een 4.

Zo heb je dus een woordenboek in een peramidevorm die een formule
opzet van een pixel signaal naar een rij-signaal naar een frame signaal.

Zo hoef je niet alles te gaan bekijken naar of het nou een 1 of een 0 is maar welke combinatie het zal zijn met betrekking tot deze getallen.

[Michael1954]

From: Rogier

Ik begrijp niet helemaal wat je precies doet... maar als het een manier is om iedere willekeurige film kleiner te kunnen opslaan, dan werkt het niet

[Michael1954]

From: Rogier

(Kokkie_d)
De hersenen zijn nog altijd het beste opslag medium dat er bestaat. He kleinste en volledig solid state!

Maar de hersenen zijn dan ook een stuk groter dan 1KB

(Rogier)
Dit hele verhaal wordt gebracht alsof het een generieke manier beschrijft om

Generiek = Hersenen !?

Nee met generiek bedoel ik algemeen toepasbaar.

En we proberen het over coderen te hebben en niet compressie.

Als we het niet over compressie hebben, dan is heel die kreet "een film in 1KB" die Pieper heeft laten vallen, volkomen onzin.

Maar coderen, wat schiet je daar mee op? Bedoel je coderen als in opslag van de data, of als in uniek identificeren van iedere film (dus feitelijk geen opslag van de film zelf).

[Michael1954]

From: Rudie

Zou het niet zo kunnen zijn dat hij zo te werk ging:

Een bestand bestaand uit 1en en 0en gecombineerd in een reeks.

Als hij nu de bestanden eerst analyseerd in welke reeksen de de 1en en 0en zijn opgebouwd van het betreffende bestand kan je een blauwdruk overhouden. Niet bestaande uit al deze 0en maar uit een blauwdruk die de opzet en verbindingen weergeeft.

Zo kan je de basis, de stuctuur van alle mogelijke combinaties van deze 1en en 0en in een zogenaamde database opslaan. Deze output dan alleen de blauwdruk in combinatie met deze database, zodat je ook de overeenkomende gegevens kan dupliceren zonder ze alweer eens te laten genereren.

Eenvoorbeeld zou ook kunnen zijn:

Je hebt een bestand bestaande uit:
111100101
100001011
101101000

Zo kan je ervan maken in een combinatieopzet van 111(1), 110(2), 101(3), 011(4), 000(5), 001(6), 010(7), 100(8) = dus 8 mogelijkheden. Deze pleur je zeg maar in een database. (voor de makkelijkheid maar 8 mogelijkheden gegeven, kan ook een reeks pakken met bv 1000 1en en 0en combinaties)

Zo word de vorige combinatie:
183
864
335


Of zo pak je alles samen en kijk je naar de herhaling van de 1en en 0en:
zo word de eerst aangegeven reeks:
42112
4113
12113

En hoe groter je bestand hoe klein je de reeks dan kan vereenvoudigen...

Ik hoop dat wat mensen een hiernaar kijken en hun mening hierover geven, dus kijken OF de 3 theorien wezenlijk zijn enz.

[Michael1954]

From: Rogier

(Rudie)
Zou het niet zo kunnen zijn dat hij zo te werk ging:

een bestand bestaand uit 1en en 0en gecombineerd in een reeks.

Als hij nu de bestanden eerst analyseerd in welke reeksen de de 1en en 0en zijn opgebouwd van het betreffende bestand kan je een blauwdruk overhouden. Niet bestaande uit al deze 0en maar uit een blauwdruk die de opzet en verbindingen weergeeft.

Dat is gemiddeld even groot als de data zelf.

Er bestaat geen algemene manier om data kleiner te krijgen, da's echt onmogelijk.

Een voorbeeld zou ook kunnen zijn:
(...)
Zo word de vorige combinatie:
183
864
335

Hoeveel ruimte denk je dat het kost om één zo'n getal (dat 1 t/m 8 kan zijn) op te slaan?

Of zo pak je alles samen en kijk je naar de herhaling van de 1en en 0en:
Zo word de eerst aangegeven reeks:
42112
4113
12113

Dat heet "run length encoding" - werkt redelijk op content waar veel reeksen van dezelfde bits in voorkomen, maar in ieder geval niet goed voor films en zeker niet voor algemene random data.

Er zullen vast slimmere compressiemethoden mogelijk zijn dan wat we nu gebruiken om films te comprimeren... maar 250 duizend keer zo klein, dat kan niet. En zeker niet als het bedacht is door een analoge technicus die zelf zei dat erg simpel was. Dit vereist echt wel inzicht op het gebied van databewerking, het gaat om droge wiskunde en informatica.