Je moet het zien als een sofinummer: op basis van jouw sofinummer kan "men" (de belasting, whatever) je volledige naam, adres, geboortedatum, etc. achterhalen. Maar al die gegevens zitten natuurlijk niet echt in dat sofinummer, die gegevens zitten in een grote database, en die halen ze eruit op basis van dat sofinr.
Jan praatte wel over een database: een die bepaalde afspraken beschreef en die hoeft niet zo groot te zijn, misschien zelfs te verwerken in zeg een formule? aangezien hij waarschijnlijk een variant van 256 gebruikt (aantal mogelijkheden voor 1/4 deel van een kleur)
Dat het echt met compressie kan, geloof ik niet. Temeer daar je voor zo'n klus een behoorlijk diepgaande informatica achtergrond moet hebben, en Jan Sloot was een analoge technicus.
Overigens praat je nog steeds over compressie. Jan had het over coderen!
Mijn idee is dat Jan inderdaad een "analoge" oplossing had gevonden.
Computer games do not affect us. I mean: Otherwise we would all be running around in darkened rooms munching pills and listening to repetitive music.
Okee, als we het idee "compressie" even loslaten, dan is het ook onzin om te spreken over "een film in 4 kilobyte".
Coderen dan, prima, maar ik zie niet hoe een nieuwe manier van coderen een revolutie teweeg zou brengen in dataverkeer en -opslag. En dat is in ieder geval wel wat Netwerk en destijds Pieper c.s. suggereerden.
Een database met alle films waar je de gewenste film op basis van een identificatienummer eruit kunt halen, dat is theoretisch mogelijk. Hetzelfde idee als met die sofinr's dus. Nu zou met de huidige compressie en datastorage technieken zo'n database wel behoorlijk groot zijn (zowel fysiek als qua hoeveelheid data), maar het grootste bezwaar is: wat heb je eraan? Wil je die database in alle tv's en dvd-spelers stoppen? Er komen dagelijks nieuwe films uit, die kun je dan op die manier niet afspelen.
En een anologe oplossing, een oplossing waarvoor?
In theory, there's no difference between theory and practice. In practice, there is.
We kunnen nog steeds over "een film in 4 kilobyte" spreken, want uiteindelijk moeten we de Key-code opslaan en daar is het digitale medium heel goed voor. Denk maar na: hoeveel creditcards kun jij in je portemonee houden, zonder dat ie echt te dik word?
Wat ik denk: er bestaat inderdaad een mogelijkheid om via formule te coderen en dat heel klein te bescrhijven. In theorie betekend dit dat je kan uitgaan van een vast getal (welke nog niet eens zo groot hoeft te zijn) -misschien een aantal vaste getallen- die verwerkt zijn in formules die je gebruikt om samen met de key-code de films te beschrijven.
Dat getal (of getallen) kun je makkelijk in een paar formules stoppen en die in hardware gieten (en daar is je database!).
Computer games do not affect us. I mean: Otherwise we would all be running around in darkened rooms munching pills and listening to repetitive music.
We kunnen nog steeds over "een film in 4 kilobyte" spreken, want uiteindelijk moeten we de Key-code opslaan en daar is het digitale medium heel goed voor.
Maar dan sla je de film niet op in 4 kilobyte. Als je een bestand van 200 megabyte op je harddisk hebt staan, en de bestandsnaam is 10 karakters lang. Spreken we dan over een bestand in 10 bytes of 200 meg?
Wat ik denk: er bestaat inderdaad een mogelijkheid om via formule te coderen en dat heel klein te bescrhijven. In theorie betekend dit dat je kan uitgaan van een vast getal (welke nog niet eens zo groot hoeft te zijn) -misschien een aantal vaste getallen- die verwerkt zijn in formules die je gebruikt om samen met de key-code de films te beschrijven.
Dat getal (of getallen) kun je makkelijk in een paar formules stoppen en die in hardware gieten (en daar is je database!).
Ok, dus dan zou je 1 algemene formule hebben (die niet hoeft te worden aangepast telkens als er nieuwe films uitkomen) waarmee je alle films kunt genereren als je er de juiste input in stopt. En die input kan dan klein zijn, in de orde van een paar kilobyte.
De formule zelf (of formules als het uit meer delen bestaat) en de eventuele vaste data die daarin verwerkt zit mag best groot zijn, bijv. een paar honderd megabyte. Is dat wat je bedoelt?
(in dat geval is er inderdaad wel sprake van een film in 4kb)
In theory, there's no difference between theory and practice. In practice, there is.
een aantal formules/algoritmen, waarbij elke formule een stap omhoog beschrijft. Zie het maar als een piramide: je begint heel klein, maar aan de voet is het enorm groot en die uitbreiding kun je als een formule beschrijven.
Nu start je met een bepaalde waarde die unique is: de keycode (dvd titel), welke je in die formules gooit en je krijgt je film eruit.
En die keycode hoeft zoals jezelf al aangeeft niet zo groot te zijn
je kunt met 1kB aan gegevens iedere film (*) uniek identificeren
De formule zelf hoeft alleen maar in verschilllende chips te passen, maar zal niet enkele honderd Megabyte bevatten.
Je spreekt nog steeds over 4kB per film, want de keycode zal niet groter zijn. Dat de formule misschien meer byte in beslag neemt doet niets af aan het gegeven dat de totale film gereconstrueerd kan worden uit 4kB.
Computer games do not affect us. I mean: Otherwise we would all be running around in darkened rooms munching pills and listening to repetitive music.
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.
In theory, there's no difference between theory and practice. In practice, there is.
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.
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 schreef:(...)
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.
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.
In theory, there's no difference between theory and practice. In practice, there 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.
De hersenen zijn nog altijd het beste opslag medium dat er bestaat. He kleinste en volledig solid state!
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.
Computer games do not affect us. I mean: Otherwise we would all be running around in darkened rooms munching pills and listening to repetitive music.
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.
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
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).
In theory, there's no difference between theory and practice. In practice, there is.
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.
Rudie schreef: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.
Eenvoorbeeld 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.
In theory, there's no difference between theory and practice. In practice, there is.
