De Broncode

[Michael1954]

From: Rogier

(JanMeut)
Het aantal mogelijke combinaties is nog altijd groot, maar het gaat nog om haast menselijke getallen.

Vind je? Dat aantal is 272000 = ruim 1021674
Ter vergelijking: het aantal deeltjes in het universum wordt geschat op 1080

Reken vervolgens uit hoeveel combinaties van 72000 nullen en enen er zijn.

Je hebt twee enorm grote getallen, maar het einde van het verhaal is volgens mij dat er meer films mogelijk zijn dan getallen in 72000 bits passen.

Ja, allicht zijn er veel meer films dan dat, zelfs één zwart/wit (d.w.z. 1 bit per pixel) beeldje van 720x576 pixels (standaard pal TV resolutie) is al veel groter.
Maar dat gaat alleen voor lossless compressie op, het idee is natuurlijk dat je best wat informatie mag weggooien zodat het nog steeds voldoende op de film lijkt (net zoals Jpeg voor plaatjes zeg maar).
Met lossless compressie is het sowieso onmogelijk om gegarandeerd alles kleiner te maken.

(WiZ)
Maar wat nou als hij het wiel opnieuw heeft uitgevonden en bijv de processor rechtstreeks kan aanspreken zonder dat er eerst een O/S opgeladen moet worden die vervolgens een media speler oplaadt wat vervolgens het mpeg filmpje stukje bij beetje terug codeerd. In principe weet je computer wel welke code er voor de kleur blauw staat

Nee zo werkt het niet, de hoeveelheid informatie die je op de gebruikelijke manier (dus met een normaal bestand wat door een media player wordt uitgepakt en alles) nodig hebt om bijvoorbeeld de kleur blauw aan te geven, is al heel erg minimaal. Rechtstreeks communiceren met de processor of videokaart zou de methode véél inefficiënter en groter maken.

Ik heb daar ook mijn hoofd over gebroken. Met de techniek van Jan Sloot leg je oneindige dingen vast binnen een eindig getal. Dat is theoretisch alleen mogelijk als alles is opgebouwd uit fractals.

Hoe bedoel je?


En wat suyver zegt inderdaad, in hoeverre ligt informatie besloten in de data zelf, of meer in de manier waarop het wordt uitgelezen. Een www.imdb.com titelnummer of een ed2k (edonkey) hash van 128 bits is voldoende om een film uniek te identificeren. Ik kan natuurlijk ook wel een "programma" van 900 gigabyte maken waarin alle tot nu toe bekende films zitten. Een film hoeft dan nog maar een paar byte te kosten, namelijk een index zodat het programma weet welke film hij moet tonen / uitpakken. Ik denk niet dat we dat nog compressie kunnen noemen.

Wat ik als compressie beschouw: een programma waarmee je ook nog niet bestaande films (of bestanden in het algemeen) kunt comprimeren en decomprimeren.

[Michael1954]

From: WiZ

In het boek wordt gezegd dat hij de enen en nullen achter zich heeft gelaten. Hij had het meer op kleuren gebaseerd. Hij zegt dat hij het zag dat de processor van nu 2-dimensionaal werkt en dat hij hem 3-dimensionaal had gemaakt. Ik weet het niet precies heb het zelf namelijk niet gelezen, een vriend van me heeft het boek en vertelde mij dat. Ik zal hem vanavond vragen om hier te komen met het boek en dan citeer ik wel een stuk.

Of denken jullie dat het echt onmogelijk is en dat die Sloot de boel belazerd heeft?

[Michael1954]

From: Rogier

(WiZ)
In het boek wordt gezegd dat hij de enen en nullen achter zich heeft gelaten. Hij had het meer op kleuren gebaseerd. Hij zegt dat hij het zag dat de processor van nu 2-dimensionaal werkt en dat hij hem 3-dimensionaal had gemaakt. Ik weet het niet precies heb het zelf namelijk niet gelezen, een vriend van me heeft het boek en vertelde mij dat. Ik zal hem vanavond vragen om hier te komen met het boek en dan citeer ik wel een stuk.

Ben benieuwd. Klinkt interessant, maar ik heb ook al héél veel suffe bla-bla-verhalen gehoord met dit soort kreten. Gaat het bijvoorbeeld om 3D vs 2D in logische of fysieke zin? Dus bestaat zijn processor uit een soort ruimtelijke variant van een printplaat? Of wordt er alleen in logische zin met 3d-datastructuren gewerkt.

Of denken jullie dat het echt onmogelijk is en dat die Sloot de boel belazerd heeft?

Ja en nee. 16 films comperimeren tot een grootte van 64 KB, of een andere datavorm die niet per se op bits gebaseerd is maar overeen komt met een datahoeveelheid van 64 KB, dat geloof ik niet.
Maar technisch gezien moet het opslaan van 16 films in een apparaatje of medium wat dezelfde fysieke grootte heeft als hedendaagse flash-kaartjes van 64 KB, theoretisch geen probleem zijn. Het praktijkvoorbeeld dragen we zelf bij ons: de informatiedichtheid van DNA of onze hersenen is veel groter dan die van harddisks of andere opslagmedia.

Zolang Philips met dat nieuwe medium niet duidelijk specificeert of hun datadichtheid nou zo goed is (dus hoeveel bits zitten er in dat kaartje) of dat om een revolutionaire audio/videocompressie gaat (dus tot hoeveel bits comprimeren ze een gemiddelde film) geloof ik het allemaal niet. Philips is toch een serieus bedrijf? Waarom dan vage verhaaltjes ophangen.

[Michael1954]

From: Rand

Kortom er zijn nog weinig feiten op tafel , ook in dit forum weinig feiten dus.

1) Romke Jan Bernard Sloot was TV-reparateur, analoog WAS zijn ervaring. hij heeft zich later verdiept (zelfstandig) in digitale technieken.
2) alle berekeningen die ik hier en op andere forums zie zijn gebaseerd op de "oude" technieken.
3) Zijn uitvinding had wel degelijk meer nodig dan alleen de keycard van 64kb, in zijn "kastje" zat geheugen ingebouwd
4) Zijn eigen claim was een verbetering van 8x tov de "oude" technieken"

We moeten leren feiten en speculaties te scheiden en alleen met feiten verder te gaan. ALs we dat massaal zouden doen dan reproduceren we snel "zijn" uitvinding, er is genoeg technisch vernuft onder ons.

Kijk nog eens naar een feit: http://www.Davoc.com, is recentelijk ge-update.

Rand(t)

[Michael1954]

From: Elmo

De hamvraag blijft of Sloot een geniaal uitvinder was of een meesteroplichter. [...] Vast staat dat wetenschappers ervan overtuigd zijn dat wat Sloot liet zien, onmogelijk is. De Broncode is daarmee vooral een mooi verhaal, meer eigenlijk niet.

Bron

Sloot stelt in de tekst die Smit afdrukt dat zijn uitvinding geen compressiemethode is. De ene kilobyte die in zijn systeem een film kan definiëren, ontsluit een geheugen met 'voor data een x aantal karaktercodes, voor geluid een x aantal tooncodes en voor beeld een x aantal pixelcodes.' Dit geheugen heeft volgens Sloot een omvang van 370 MB.

De beschrijving doet denken aan de manier waarop muziek wordt weergegeven in de Midi-standaard. De geluidskaart van een pc heeft een databank met enkele MB aan klanken van standaardinstrumenten: gitaar, piano, viool en dergelijke. Een Midi-bestand hoeft dan alleen maar noten te specificeren: een E op de gitaar, een A op de piano, enzovoorts. Dit is geen compressie maar codering, een onderscheid dat Sloot ook maakt. Een paar minuten muziek in Midi-vorm kosten vaak maar enkele kB terwijl een mp3-bestand van dezelfde duur duizend keer zo groot is. Wel klinkt muziek in Midi-vorm vaak kunstmatig.

Een dergelijke methode bestaat ook voor beelden maar er is geen schijn van kans dat Sloot alle mogelijke speelfilms zou kunnen weergeven met 370 MB aan basiseffecten, en ook niet dat 1 kB aan codes zou volstaan voor één film. Ook is het niet aannemelijk dat een processor van 500 MHz (in 1999 was dat geavanceerd) een aldus gecodeerde film ter plekke zou kunnen reconstrueren, en al helemaal niet dat een en ander verliesloos zou zijn, zoals Sloot beweerde. Codering kán niet verliesloos zijn, omdat een synthetische versie van een origineel wordt gemaakt.

Bron

[Michael1954]

From: Rand

Zonder veel woorden, maar met wat meer mensen kennis:
Jan Sloot was geen meesteroplichter, misschien wel paranoide en angstig, maar nou niet echt het voorbeeld van een oplichter.

Ik kom overal die 1 kB tegen, die heeft Jan nooit geclaimd zover ik weet, die hebben we weer uitgerekent naar vermoedelijke feiten die nu niet meer staafbaar zijn. Wie heeft het over een processor?
Jan niet, ooggetuig verslag varieert van:
- hij sloot zijn kastje aan op een 22 inch monitor
- hij sloot zijn kastje aan op een 24 inch monito
- hij sloot zijn kastje aan op een laptop

Maakt nogal uit, en op welke ingang sloot Jan aan. is meer de interessante vraag hier.

RanDt

[Michael1954]

From: Boaz

Zijn broncode moet namelijk de precieze karacteristieken (formules dus) van al die verschillende fractals bevatten

Zo langzamerzeker varieren de verhalen behoorlijk. Wat ik me herinner van 5 jaar geleden is dat hij 3Gb aan code had, maar met die drie Gb kon hij wel alles definieren. Maar goed, ik probeer ook alleen maar een verklaring te vinden voor iets wat onverklaarbaar lijkt...

[Michael1954]

From: Rogier

(RanDt)
Ik kom overal die 1 kB tegen, die heeft Jan nooit geclaimd zover ik weet, die hebben we weer uitgerekent naar vermoedelijke feiten die nu niet meer staafbaar zijn.

In de documentaire, en ook in eerdere verhalen die ik me over dit onderwerp kan herinneren, was sprake van "16 films op een geheugen kaartje van 64 kilobyte. En het kan nog beter, er zouden zelfs 64 films op kunnen."

[Michael1954]

From: Boaz

Ik heb daar ook mijn hoofd over gebroken. Met de techniek van Jan Sloot leg je oneindige dingen vast binnen een eindig getal. Dat is theoretisch alleen mogelijk als alles is opgebouwd uit fractals.

Hoe bedoel je?

Neem weer die 64 kB. Dan heb je nu eenmaal een beperkt aantal mogelijkheden. Neem in plaats van films nu eens miljoenen (of liever oneindig veel verschillende) bestandjes. Ik kan ze allemaal (misschien niet tegelijk) op diezelfde 64 kB kwijt. Maar ik heb maar een beperkt aantal mogelijkheden. Dus leg je eigenlijk een oneidig aantal vast binnen een eindig aantal. Aangezien dat (volgens mij) onmogelijk is, zul je het moeten doen met een soort 'loop'. Neem voor mijn part een getal, dat getal wordt d.m.v. algoritmes een aantal keer vermeerderd. Uiteindelijk komt daar een mega'getal' uit, of liever een hele reeks kleinere, die je vervolgens weer kan omzetten naar digitale codes. Het getal 64 is letter A is 40 Hex. Het getal 121064123001078 kun je dan lezen als 121-064-123-001-78, dat is weer 79-40-7B-1-4E in hex code.

Het probleem zit hem in het creeeren van je basisgetal. Als je een file omzet naar een lange logische reeks getallen dan komt daar uiteindelijk een mega groot getal uit. Dit getal zal je moeten zien te verkleinen door een algoritme te verzinnen dat omkeerbaar is. De uitkomst van het algaritme moet teruggerekend weer het orginele getal opleveren. Als je een algoritme kunt verzinnen waarbij de uitkomst ALTIJD kleiner is dan het orgineel, en de uitkomst terug te rekenen is naar het orginele getal dan geldt er daarna nog maar een voorwaarde. Het aantal keer dat je het algoritme erop los mag laten mag niet groter zijn dan het orginele getal. Nog sterker, het aantal digits moet minimaal 1 kleiner zijn.

Wat ik hierboven beschrijf is eigenlijk het zoeken naar de basis fractal die door hem maar vaak genoeg aan elkaar te leggen je uiteindelijk je orginele getal teruggeeft.

[Michael1954]

From: Tool

Ik ga me zelf toch maar eens verdiepen in het inkorten van data op alle mogelijke manieren, gewoon uit nieuwsgierigheid over hoe klein je bepaalde data in theorie op zou kunnen slaan en van welke informatie het daadwerkelijk nodig is om het over te sturen met de huidige grote van harde schijven.