Introductie

Als je net zoals steller dezes werkzaam bent in de IT, dan komt ééns in de zoveel tijd het verhaal van ‘de broncode‘ voorbij zoemen. En tot enige tijd geleden nam ik het verhaal telkens ter kennisgeving aan. Tot ik het in digitale vorm tegenkwam en op m’n e-reader zette. Toen ik vervolgens de audioversie toegespeeld kreeg via Maurice Duijndam kon ik er niet meer onder vandaan: ook ik zou mijzelf onderdompelen in het fantastische verhaal van de uitvinding van de eeuw!

Na een week luisteren (al forenzend tussen Den Haag en Amsterdam), hink ik op twee gedachten. Enerzijds wil ik geloven dat de Groninger Jan Sloot inderdaad de uitvinding van de eeuw heeft gedaan (al was het maar omdat ik een zwak heb voor sociaal gemankeerde maar tevens briljante mensen), maar de in jaren verzamelde technische bagage zegt me dat er wat hiaten in het verhaal zitten. Aan de andere kant: het feit dat ik nu op mijn TV draadloos HD-films (bv. via DLNA) kan bekijken zou in 1999 net zo onmogelijk hebben geleken.

Ik wil graag geloven dat de uitvinding van Jan Sloot, het Sloot Digital Coding System (SDCS), daadwerkelijk werkt. Het zou een ommekeer in de almaar uitdijende behoefte voor opslagruimte hebben betekend. Een gemiddeld radiostation (mijn huidige terrein) zou aan een simpel PC’tje met een harde schijf van een gigabyte meer dan voldoende hebben gehad voor de opslag van zo’n beetje alle audio die er bestaat. Om over Video-On-Demand en soortgelijke initiatieven nog maar te zwijgen.

Twijfels

Jan SlootMaar ergens in mijn achterhoofd blijft er een klein stemmetje vervelend aanwezig. Dat stemmetje roept dat Jan Sloot ook wel eens heel goed een hele gewiekste oplichter had kunnen zijn. Een nu dode oplichter, dat wel, maar niettemin een oplichter. Enige naspeuring op het Internet leert dat ik niet de enige ben die er eventueel zo over zou kunnen denken. Een simpel rekensommetje dat op de Wikipedia-pagina van de uitvinder staat, lijkt te bewijzen dat zijn beweringen op z’n zachtst gezegd niet kloppen:

In veel verhalen over de vinding van Jan Sloot wordt vermeld dat hij films kon terugbrengen tot een vaste grootte van 1 kilobyte. Het is eenvoudig te bewijzen dat dit onmogelijk is. Er zijn namelijk meer films dan sleutels mogelijk. Films bestaan uit beeldjes die achter elkaar uitgezonden worden. Stel we nemen alleen de films in beschouwing die uit puur zwarte en puur witte beeldjes bestaan. Om dit soort films op te slaan heb je precies één bit per beeldje nodig.

Stel we nemen alleen de puur zwart of witte “films” in beschouwing van precies 8193 beeldjes lengte. Hoeveel mogelijke “films” zijn er dan? Dat zijn er 28192.

Met 1 kilobyte beschik je over 8*1024 = 8192 bits. Het aantal mogelijke sleutels dat we hiermee kunnen maken is 28192. Bijgevolg bestaan er meer films dan er sleutels zijn. Hiermee is bewezen dat Jan Sloot films niet in één enkele sleutel kon samenvatten.

-Wikipedia

Wat ik niet begrijp is dat techneuten als Carel Jan Van Driel (inmiddels Vice President Technology and Standards bij Philips) en de mannen van Sun Microsystems bovenstaande berekening niet konden maken en dat ook de technische man van Roep Pieper, Marius Abel, deze toch flinke hiaat niet heeft gezien. Tenzij Jan Sloot een manier gevonden heeft om volledig en letterlijk out-of-the-box een nieuwe manier van opslag te bedenken. Er zijn na de dood van Jan Sloot meer vragen bijgekomen dan dat er daadwerkelijk beantwoord zijn.

Terugkomend op de kern van dit gedachtenspinsel: is de uitvinding van Jan Sloot mogelijk? Ik heb geen twijfels over het feit dat de uitvinder inderdaad een nieuwe manier van coderen heeft bedacht. Ik heb ook geen twijfel of deze nieuwe manier van coderen (ooit) technisch mogelijk zal zijn. Waar ik aan twijfel is of Jan Sloot inderdaad zijn uitvinding in de praktijk werkend heeft gekregen.

Hardware

PC

Iets waar ik bijvoorbeeld niet direct mee uit de voeten kan is het feit dat Sloot zijn eerste demonstraties gaf vanaf een een notebook, volgens het boek een Pentium 1 met Windows 95 (er wordt geen uitspraak gedaan over de hoeveelheid geheugen of de snelheid van de processor. We nemen voor beiden even het maximale aan: 256MiB en 300Mhz). Een X86-CPU kan uitsluitend overweg met het binaire stelsel. Als Jan Sloot dus, zoals hij zelf aangeeft, een andere manier van opslag heeft gevonden, zijn er een aantal opties:

  • Er draait op de notebook een driver die de data vanuit de kaartlezer omzet in een datastroom die Windows 95 kan begrijpen en verwerken. Dus: de driver decodeert de film tot zijn oorspronkelijke formaat.
  • De kaartlezer is een door Sloot zelf aangepast model met in de lezer zelf een decoder voor de opslag van Jan Sloot. Data die uit de kaartlezer komt is al omgezet naar het binaire stelsel.
  • Bij het starten van de applicatie van Jan Sloot wordt Windows 95 in z’n geheel uit het geheugen gehaald en draait enkel nog de applicatie van Jan Sloot. Bij het afsluiten wordt Windows 95 weer gestart vanuit een aan ‘hibernate’-gelijkende situatie.

De laatste optie lijkt mij het minst waarschijnlijk. Maar er is nog wat: volgens Dick Vesters, een door Roel Pieper geraadpleegde IT-deskundige, ‘brand het LED-lampje slechts heel even’, volgens hem een teken dat er niks van de harde schijf wordt gelezen. Nou zijn er 1000-en-1 manieren om dit lampje al dan niet tijdelijk uit te schakelen, dus een echte controle is het niet, maar als we er vanuit gaan dat het LED-je niet gemanipuleerd is, worden ook de andere twee opties twijfelachtig. In beide gevallen wordt de film in ergens gedecodeerd tot zijn oorspronkelijke formaat en een fullscreen film (in die tijd waarschijnlijk 1024×768 pixels) past domweg niet in 256MiB intern geheugen. Dus moet er geswapt worden met de harde schijf. Ook als de film niet in z’n geheel wordt gedecodeerd is het twijfelachtig dat er geen gebruik wordt gemaakt van de harde schijf. Ook een minuut film in die resolutie (en daarbij bedenkende dat ook Windows 95 nog in het geheugen zit, waardoor de aansturing van de videokaart via Windows dient te geschieden) kan niet zonder swappen worden gedecodeerd in het interne geheugen.

Kaartlezer

Dan is er de gebruikte kaartlezer waar ik wat vraagtekens bij heb. Er wordt nergens in het boek vermeld hoe de kaartlezer is aangesloten op de notebook, maar ik ga er vanuit dat dit of via een seriele/COM-poort (RS-232) of via USB gebeurde. De eerste lijkt me vrijwel onmogelijk, daar de maximale doorvoersnelheid van het RS232-protocol op 115 kilobits per seconde ligt. Dit komt neer op 14,38KiB per seconde. Eén frame film (zonder geluid) in een resolutie van 1024×768 met 16bits-kleuren neemt in het binaire stelsel 1536 kilobytes[(((1024px*768px)*16bits)/8)/1024] aan geheugen in beslag. Wil een film schokvrij op je beeld verschijnen, dan heb je minstens 25 frames per seconde nodig. Dit komt dus neer op 37,5MiB[((1536KiB*25)=38400KiB)/1024] per seconde. Bij gebruik van een seriële poort is dit onmogelijk.

Aangezien de seriële poort hierboven is uitgesloten, blijven er twee kandidaten over: USB en FireWire. Die laatste kunnen bevoegelijk vergeten, aangezien FireWire in 1998 en 1999 uitsluitend geleverd werd op Apple-hardware. Blijft USB over. In 1999 was de gebruikte standaard USB 1.1 met een maximale doorvoersnelheid van 12Mits/sec, wat neerkomt op 1,5MiB per seconden. Ook bij lange na niet voldoende voor de 37,5MiB/sec uit de bovenstaande berekening.

Er is nóg een mogelijkheid, zij het een hele onwaarschijnlijke. Het kan zijn dat de kaartlezer is omgebouwd om gebruik te maken van de netwerkaansluiting op de notebook (UTP/RJ45). In dat geval is de maximale doorvoersnelheid 100Mbits/sec, wat neerkomt op 12,5MiB/sec. Niet genoeg voor doorvoer zonder bufferen, maar absoluut meer geschikt dan serieel of USB. Maar welke methode er ook wordt gebruikt, als de data op de kaartlezer wordt gedecodeerd is de doorvoersnelheid in alle gevallen onvoldoende om zonder bufferen en fullscreen te tonen. Als we uitgaan van de hoeveelheid geheugen uit de aantekeningen van Jan Sloot (270MiB), dan komen we aan een totale buffer van 7,2 seconden[270/37,5]. Het vullen van de buffer duurt initieel 21,6 seconden[270/12,5]. Als je dus verder voor- of achteruitspoelt dan 7,2 seconden heb je daarna op z’n minst 21,6 seconden nodig om de buffer te vullen. Dit maakt snel voor- of achteruitspoelen vrijwel onmogelijk. Wisselen van film zoals omschreven in het boek is zelfs onmogelijk omdat er eerst de buffer volledig opnieuw gevuld zal moeten worden met nieuwe data. Dit kost, zoals gezegd, 21,6 seconden.

Voor bovenstaande berekeningen ben ik er vanuit gegaan dat de decodering van de film (dus het terugbrengen naar de oorspronkelijke vorm) gebeurde in de kaartlezer, zodat er aan de notebook ‘kant en klare’ binaire data werd aangeboden. Het kan ook zijn dat alleen de oorspronkelijke sleutel (volgens Jan Sloot zelf maximaal 1 KiB) werd aangeboden aan de notebook en dat deze door een driver (geschreven door Jan Sloot) wordt omgezet naar de oorspronkelijke film. De sleutel van de film overzetten naar de notebook is een kwestie van seconden. Hierna zou de kaartlezer niet meer nodig zijn geweest. Uit het boek blijkt echter dat als de kaart uit de kaartlezer wordt verwijderd, de film stopt met afspelen. Hiervoor geldt dezelfde theorie als het eerder genoemde groene LED-je, er zijn 1000-en-1 manier om dit voor elkaar te krijgen, maar ik ga er voor nu vanuit er inderdaad continue data van de kaartlezer ontvangen wordt.

Software

Er wordt in de bijlagen van het boek gesproken over de notities van Jan Sloot omtrent SDCS. In een van deze notities schrijft de uitvinder dat zijn uitvinding werkt met vijf algoritmes die bij elkaar ongeveer 270MiB nodig hebben voor het decoderen van de data. Dat is al meer dan het complete interne geheugen van de gebruikte notebook. Het zou zo kunnen zijn dat dit geheugen in de kaartlezer zit waardoor het niet in de notebook hoeft te zitten. Alleen strookt dat niet met het flitsend terug- en doorspoelen van de film en het razendsnel wisselen tussen twee films. Data die nog niet gedecodeerd is (omdat de film bij normaal afspelen nog niet op dat punt was aangekomen of omdat er een compleet andere film werd afgespeeld) moet dan worden gedecodeerd (waardoor er automatisch andere data gewist moet worden uit het geheugen) en de gedecodeerde data moet ook nog worden omgezet naar het binaire stelsel omdat de computer er anders niks mee kan. De naar binair omgezette data moet dan worden opgeslagen in het geheugen. Dit alles zonder gebruik van de harde schijf is al bijna onmogelijk op hedendaagse hardware, maar dat het werkt op de hardware uit 1999 is uiterst onwaarschijnlijk.

Dan blijft derde, meest onwaarschijnlijke mogelijkheid over. Jan Sloot heeft een geheel eigen OS geschreven dat, bij het opstarten van een applicatie Windows 95 verwijderd uit het geheugen en direct communiceert met de kaartlezer, de videokaart en de geluidskaart. Het zelf schrijven van een compleet operating system, hoe basaal ook, is een monsterklus. Hoewel ik er niet aan twijfel dat Jan Sloot een geniaal mens was, lijkt me dit niet waarschijnlijk. Ik kan het echter ook niet helemaal uitsluiten…

In bovenstaande voorbeelden ben ik enkel uitgegaan van beeldinformatie (video) en ik heb de audio buiten beschouwing gelaten. Dit omdat de hoeveelheid dat de die audio toevoegt aan de datastroom te verwaarlozen is. Tenzij er gebruikt gemaakt wordt van surround (AC3 / Dolby Digital) hebben we het over maximaal 320kbits/seconde, wat neerkomt op 40KiB[320/8=40] per seconde. Op een reeds bestaande datastream van 37,5MiB/seconde is dat te verwaarlozen. De kans dat er gebruik gemaakt werd van AC3 is zo klein dat ik die optie buiten beschouwing laat voor dit artikel.

Conclusie

Kan ik na drie pagina’s concluderen dat Jan Sloot de boel heeft bedonderd? Nee, dat kan ik niet. Ondanks alle hiervoor aangehaalde voorbeelden ben ik (misschien wel tegen beter weten in) nog steeds niet overtuigd van het feit dat de uitvinding van Jan Sloot thuishoort in het domein van de fantasie/loze beloften. Misschien is het wel de onverbeterlijke dromer in mij die hardnekkig wil blijven geloven dat een sociaal gemankeerde TV-monteur uit Nieuwegein verantwoordelijk had kunnen zijn voor dé revolutie in opslagtechnieken sinds de uitvinding van de chaostheorie om data op te slaan op harde schijven. Misschien ben ik wel niet goed genoeg in het denken ‘outside-the-box’. Misschien heeft Jan Sloot inderdaad een revolutionaire manier van opslag bedacht. We zullen het waarschijnlijk nooit weten. Tenzij de na de dood van Sloot verdwenen documenten ‘ineens’ weer boven water komen of als het originele doosje (de versie die door Roel Pieper meegenomen werd naar de Verenigde Staten en dat verborgen schijnt te liggen in een villa in het Gooi) spontaan opduikt. Tot die tijd kunnen we niks anders doen dan nadenken en ons verwonderen…

Delen is lief! Kies je platform

6 Comments

  1. Geurts 5 oktober 2011 at 17:51 - Reply

    De werkelijke waarheid zullen we nooit meer achterhalen omdat andere belangen een zwaarder gewicht hebben.

    Op http://jansloot.telcomsoft.nl/Sources-3/Dna/NL_Dna.htm staat een demo die veel gelijkenis vertoond.

    Chris

  2. Dick Vesters 15 juni 2012 at 11:09 - Reply

    Jan Sloot’s uitvinding blijft mensen fascineren. Ik heb de demo gezien en Jan vragen gesteld. Neem offline contact op.

  3. Jament 19 februari 2013 at 22:10 - Reply

    de rekenfout welke je maakt is dat voor jouw Kilobytes bestaan uit 1 en 0.
    Dat is welke de huidige chips met miljarden per m/s kunnen verwerken.

    De uitvinding van Sloot was juist dat ipv 1 en 0 gebruik maken van het complete ASCII. Simpel gezegd zou een 11000110101000110010100010010010010101101010010000111…x2 command dus al vertaald kunnen worden naar een A. of een A*. Met een juist algorithme op een chip (naar verluidt 1Kb) zou dit mogelijk moeten zijn.

    Daarnaast wordt er gesproken over 64Kb voor 5 films op SD resolutie destijds. De claim is wellicht overtrokken maar zelfs bij een x1000 factor van overdrijving is het nog steeds industry changing.

    • Jacob Fresco 26 september 2013 at 12:35 - Reply

      Volgens het boek vormden de algoritmes bij elkaar ongeveer 270MiB en niet 1KiB. Met je laatste alinea ben ik het overigens volledig eens.

  4. h.j van oyen 11 juli 2013 at 16:37 - Reply

    het is een heel ander systeem dat gebruik maakt van iets dat buiten het bitsysteem valt maar wel kan samen werken met het bitsysteem

Leave A Comment