Het Jan Sloot Digital Coding mysterie, deel 5

juist zo'n 30% van topic (1 tot 5) gelezen wat toch al behoorlijk veel is vind'k

daarom alleen al deze post, kwestie van dan toch ook mijn 2 cent kwijt te zijn.

alleszinds ben ik niet van plan om me voor of tegen te positioneren, ik heb de mens nooit gekend, weet niet tot wat hij in staat was en heb zelf te beperkte kennis (maar afdoende logisch inzicht) in IT.

Nu alleszinds lijkt het mij iets "te" sterk en zitten er iets "te" veel gaten in heel het verhaal... wat natuurlijk ook weer niets uitsluit.

Zou het niet gewoon kunnen dat de man (vortgaand op het payTV idee) een systeem had uitgedokterd om een gescrambled beeld van x aantal films tegelijk op 1 kanaal uit te zenden en dat de matrices ervoor waren om die ene film terug te reconstrueren en de sleutel dan juist toegang gaf voor die ene film. stel dan dat die x-aantal films 1 week uitgezonden worden dan moet er elke week een update van de matrices gebeuren. (dit lijkt me commerciëel alleszinds al een haalbaar product zelfs nu, laat staan 15 jaar geleden).
Ervan uitgaand dus dat er ongelooflijk veel poeha rond dit verhaal ontstaan is ( mede door de man z'n plotse en overwachte dood?) nu ja is eerder een id dat bij mij onstaan is, ik baseer me dus uitsluitend op lucht en voorgaande veronderstellingen en uitspraken...

Alleszinds als de man ooit gemaakt heeft wat er beweerd wordt, dan hoop ik ergens vanachter in de tuin een verroesterd doosje te vinden met daarin een sleuteltje en een code van een kluis hier in't station waar de man al z'n plannen, broncodes en al het andere nodige net voor z'n dood veilig had opgeborgen... of zal ik toch maar m'n lotto formulier invullen deze week?

Sloppel


Me

quote:

Op woensdag 8 december 2004 01:00 schreef livEliveD het volgende:
Ik denk dat functiecompressie geen kloot met redundatie te maken heeft.

Nee klopt Jij probeert data gewoon op een andere manier te noteren in de hoop dat er magischerwijs enkele duizenden decimalen verdwijnen...

quote:

Daarnaast zijn er legio functie combinaties en er is sowieso voor elke data een functie te vinden. Of deze het ook kleiner maakt is de vraag. Tuuwk is de kans niet groot maar echt super klein wil ik hem niet noemen (meerdere assen, meerdere variabelen, meerdere aannames, meerdere functies etc. -> oneindig of schijnbaar oneindig combinaties denkbaar. Tja rekentijd is een ander verhaal).

Echt, die kans is superklein. Het grappige is trouwens dat elk van de factoren die jij daarna noemt er stuk voor stuk ervoor zorgen dat er meer data wordt opgeslagen ipv minder.

quote:

Tuuwk denk ik dat het sowieso een oplichting was. Het is alleen simpelweg niet bewijsbaar maar alleen hoogst onwaarschijnlijk te maken. Dat was ook me hele punt. Verder niet

Mooi zo.

quote:

Op woensdag 8 december 2004 09:48 schreef HenryHill het volgende:
Nee klopt Jij probeert data gewoon op een andere manier te noteren in de hoop dat er magischerwijs enkele duizenden decimalen verdwijnen...

Hoezo magie? Tis gewoon gebruik maken van de oneindigheid van functies waarbij je dus puur de formules in handen hebt.

quote:

Echt, die kans is superklein. Het grappige is trouwens dat elk van de factoren die jij daarna noemt er stuk voor stuk ervoor zorgen dat er meer data wordt opgeslagen ipv minder.

Supercompressie kans is extreem klein idd. Maar de kans dat je het kleiner kan maken met functies is denk ik niet zo klein . Daarnaast kun je natuurlijk altijd een rest opslaan en het is dus puur zaak om in de buurt te komen van de data (het snijpunt) zeg maar.
Begin je met 2 lijnen in de goede richting. (formule 1,2). Dan een boostgetal waarbij bv 5 eigenlijk 5^5^5^5 voorstelt ofzo. Dan weer 2 lijnen om het bij te sturen. Misschien nog een hoek opslaan. Etc. En uiteindelijk een rest (of ik skip wat frames (aftiteling ofzo) waarbij de film dichter in de buurt van het punt komt. Ik meen dat Sloot ook iets zij dat het niet helemaal loss-less was en als ik geen goede formules vind dan kan ik ook de data in tweeen splitsen en opnieuw proberen voor elk afzonderlijk blok.

Tja hoe meer formules hoe meer ruimte. Balen. Tweede nadeel is dat het aantal formule combinaties zo groot is (oneindig?) dat er gewoon nooit genoeg processing power in het universum zal bestaan om het te behappen en de optimale compressie te vinden. Toch eens bouwen als ik iets meer tijd heb dan kan ik kijken hoe goed je het kan krijgen als je uitgaat van een paar standaard formulecombinaties. Ik zal voor de grap als testdata een film pakken. _{Die ik netjes gedownloadkocht heb}

quote:

Mooi zo.

Ik denk dat er weinig IT'ers zijn die er anders over denken hoor . Het verhaal spreekt wel tot de verbeelding maar helaas pindakaas.

quote:

Op woensdag 8 december 2004 11:09 schreef livEliveD het volgende:


Begin je met 2 lijnen in de goede richting. (formule 1,2).

Tak, daar heb je het al, er is geen keuze van de 'goede richting'... als je een bestaande film wilt comprimeren heb je te werken met videodata die voorgelegd is, en nee, dat zijn nooit mooi egale 'lijnen in de juiste richting' maar enorme aantallen binaire data, die gegevens opslaat over de RGB-kleurlagen alswel audio-sporen ..
juist in de grond bestaan er weinig voorspelbare of 'mooie' patronen ...

ga je daar JPEG of MPEG compressie op afsturen heb je in feite idd datgene wat jij beschrijft, de beelden worden opgedeelt in matrixes waarbij de YUV-kleurenruimte dusdanig aangepast dat er een percentage compressie bereikt wordt, juist door het kiezen van compressie gebaseerd op de kleurruimte, alwel de matices te laten verschuiven is het effect redelijk miniem, zeker bij fotografische data met weinig sterke contrast en randen, maar het blijft lossy, en bovenal het heeft gewoon ook een grens... iedereen kent wel het moment waarop een divx/mpeg gewoon niet meer mooi wordt en waarop je eigenlijk liever kiest voor minder compressie, maar meer kwaliteit ...

Binnen moderne codecs (H.264/AVC: Context-Adaptive Binary Arithmetic Coding) zitten intelligente zaken die de sampling-rates kan wisselen specifiek op frames/audiosporen gericht, hiermee valt uiteindelijk nog net iets meer mee te winnen, maar ook dit blijft ver van super-compressie ...

Uiteindelijk is jouw voorbeeld iets als een compressie-algorithme dat een film tot op 64Kb kan verkleinen, mits de film enkel zwarte beelden bevat en een stabiele zachte bromtoon als achtergrondgeluid kent, zodra hiervan afgeweken wordt is de compressie niet mogelijk ...
leuk 'bewijs' voor super-compressie heb je daarmee in handen.

Verder is het natuurlijk positief als je het gewoon uit gaat proberen, en uiteindelijk zal ontdekken dat theoretisch het leuke ideeen zijn, maar ze in feite niet toepasbaar zijn, omdat ze doorslaan in het uitbuiten van een theoretische perfecte situatie, die echter in de werkelijkheid niet voorkomt ...

Overigen fractal-based compressie is natuurlijk een andere mogelijkheid, echter deze kent een ander probleem en dat is dat de uitkomst van fractals lastig stuurbaar is en in die zin een fractal even slecht toepasbaar als gewooin egale 'mooie' algorithme's, simpelweg omdat het 'matchen' evenveel moeite moet doen ...

Hooguit kan het zijn dat Sloot een 'matching-systeem' had: gebaseerd op een enorme database met zulke fractal-patronen, die hij uitzonderlijk snel kon matchen en plaatsen ...
dat zou kunnen overeenkomen met de investeringsmemo waarin de uitvinding enigszins vaag wordt geduid, en er wordt verwezen naar een eerdere database-product dat diende om fouten binnen videosystemen te tracen; welk door Sloot was ontwikkeld ...

[ Bericht 21% gewijzigd door RM-rf op 08-12-2004 12:19:52 ]

Ik heb geen kloot met frames te maken (of audio sporen).
Ik zie die stroom bits gewoon als een gigantisch nummer. Dit nummer splits ik op in meerdere nummers en plot deze als het ware op een mega grafiek en ik probeer dan combo's van formules te vinden die die punten aanwijzen (als snijpunt). Hoe ik dat mega nummer opsplits is flexibel net als het aantal opsplitsingen. Hopelijk is de data zo op te delen dat ik bv 100 punten over hou die ik met 200 ingewikkelde formules kan terughalen. Dan moeten de komma getallen in die formules wel klein worden en das het lastige eraan. Verder heb je niet oneindige rekentijd om alle mogelijk formule combo's te proberen.

quote:

Op woensdag 8 december 2004 12:21 schreef livEliveD het volgende:
Ik heb geen kloot met frames te maken (of audio sporen).

tja, een stuk video is niet gewoon 'één lang nummer', zelfs een statisch kleurbeeld is dat niet, het kent een bepaalde bestandsstructuur...

iedere compressietechniek maakt gebruik van de bestaande structuur binnen een bestand, immers enkel binaire data zelf (dus ofwel een 1 ofwel een 0) is zelf niet verder te comprimeren, zodra je bepaalde 'vastheden' kunt localiseren kun je deze gebruiken ..

Om bijvoorbeeld transformatie encoding toe te passen, het 'afvlakken van gegevens die je opslaat in een beperktere vorm, zoals in wavelet compresie, moet je ook weten welke vormen van afvlakking het minst storende 'lossy' bestandsbeschadiging opleveren ...
hierop is bv de bestaande methode om Fourier transformatie (DCT) binnen JPEG over de YUV-kleurruimte toe te passen, gebaseerd.

de lossy effecten hebben weinig direkte negatieve invloed op specifiek het doel waarvoor JPEG gemaakt is, namelijk het afbeelden van foto's, zonder strakke egale vlakken of scherpe lijnen..
een puur grafisch beeld met heldere teksten en egale kleurvlakken gaat er in JPEG al snel 'viesjes' uitzien, maar voor normale toepassingen om foto's op te slaan voldoet JPEG wel ...

zulke winst verlies je juist als je enkel kijkt naar één Groot Generiek Compressie Algorithme voor het Grote Digitale Alles ...

Mja das balen idd. Maar het heeft als voordeel dat het supercompressie mogelijk maakt. (als je Guus Geluk bent maar toch). Een stuk video is ergens ook gewoon een lang nummer, plaatje, geluidsfragment, video, grafiek -> Ligt puur aan de representatie die je kiest. Ik kan het echter niet in het Sloot verhaal plaatsen omdat de kansen van slagen veel te klein zijn. Daarnaast (zoals ik eerder aangaf) blijft het op deze manier toch oplichting (omdat Sloot had moeten weten dat het niet met elke film gaat werken) en geen gevaar voor de filmindustrie ofzo.

quote:

Op woensdag 8 december 2004 11:09 schreef livEliveD het volgende:

[..]

Hoezo magie? Tis gewoon gebruik maken van de oneindigheid van functies waarbij je dus puur de formules in handen hebt.
[..]

Supercompressie kans is extreem klein idd. Maar de kans dat je het kleiner kan maken met functies is denk ik niet zo klein . Daarnaast kun je natuurlijk altijd een rest opslaan en het is dus puur zaak om in de buurt te komen van de data (het snijpunt) zeg maar.
Begin je met 2 lijnen in de goede richting. (formule 1,2). Dan een boostgetal waarbij bv 5 eigenlijk 5^5^5^5 voorstelt ofzo. Dan weer 2 lijnen om het bij te sturen. Misschien nog een hoek opslaan. Etc. En uiteindelijk een rest (of ik skip wat frames (aftiteling ofzo) waarbij de film dichter in de buurt van het punt komt. Ik meen dat Sloot ook iets zij dat het niet helemaal loss-less was en als ik geen goede formules vind dan kan ik ook de data in tweeen splitsen en opnieuw proberen voor elk afzonderlijk blok.

't Is leuk wat nu allemaal vertelt, maar dit gaat gewoon niet werken, en wel om 1 simpele reden: het pigeonhole-principe. Om het maar meteen te vertalen naar deze toepassing: als je n mogelijke waarden hebt, kun je die niet naar een andere representatie van m (waar m < n) mogelijke waarden mappen zonder informatie weg te gooien (die dus niet meer terug te halen is).
(edit: zie ook hier: http://mathworld.wolfram.com/DirichletsBoxPrinciple.html)

Met andere woorden: als jij met je formules een blok data wilt coderen ter grootte van x bytes, moeten je formules ook tenminste x²⁵⁶ mogelijke uitkomsten kennen. En om de parameters van die formules op te slaan heb je dus ook minimaal x bytes nodig (want anders, volgens het pigeonhole principe, mapt 1 uitkomst van je formule naar meerdere combinaties van x bytes). En waarschijnlijk heb je meer dan x bytes nodig, want gegarandeerd dat meerdere combinaties van formule-parameters wel naar dezelfde combinatie van ongecomprimeerde bytes mappen.

De reden waarom lossy compressie goed werkt is omdat de representatie van de beelden zo wordt gekozen dat er feitelijk meer redundantie ontstaat. Rm-rf noemt al een aantal voorbeelden zoals het juist kiezen van de kleurenruimte en alleen het verschil met de vorige frame opslaan ipv elk frame apart zodat het makkelijk wordt om nagenoeg irrelevante informatie weg te gooien (zoals een groep pixels met bijna dezelfde kleur beschouwen als een groep van dezelfde kleur). Let wel: hier gooi je dus wel informatie weg, maar allen die informatie die voor het menselijk oog toch bijna niet waarneembaar is.

En als je gecontrolleerd informatie weggooit, krijg je dus compressie. Het verschil met MPEG compressie en jouw formules is dus dat de eerste wel gecontroleerd informatie kan schrappen, terwijl als je bij jouw formules besluit een parameter weg te laten o.i.d. dan is er met geen mogelijkheid te voorspellen welke gevolgen het heeft op je videostream. _{Behalve dan dat het er beroerd uitkomt}

[ Bericht 1% gewijzigd door HenryHill op 08-12-2004 13:33:35 ]

quote:

Op woensdag 8 december 2004 13:19 schreef HenryHill het volgende:
't Is leuk wat nu allemaal vertelt, maar dit gaat gewoon niet werken, en wel om 1 simpele reden: het pigeonhole-principe.

Tuuwk kan het nooit werken als je alle combo's van mogelijke data bekijkt. Das inherent aan loss-lees compressie en ja dat zie je ook als je het pigeonhole-principe bekijkt. Toch is het in dit geval absoluut geen ramp omdat ik slechts 16 combos (16 films) heb. Er is een mogelijkheid dat het voor deze 16 films erg goed gaat werken en dat ik daarmee een structuur heb die voor andere films niet gebruikt kan worden is niet erg.
Althans het is erg omdat ik er geen kloot mee kan maar het is niet erg omdat ik een demo kan maken die 50 miljoen kan lospeuteren. Tuuwk zijn er andere methodes om dit te faken en ook geld los te krijgen maar het enige, en ook het het enige, punt dat ik wil maken is dat 16 -van te voren bekende- films in 64K misschien mogelijk is. Als je zoekt naar een goede compressie die op alle films werkt dan is gecontroleerd data weggooien uiteraard een betere optie.

Ergo: Ja het moet een vorm van oplichting zijn geweest.
Stonden er 16 films op dat 64K kaartje: De kans is klein maar niet uit te sluiten

tvp

quote:

Sloot kon met het indrukken van een toets de film vliegensvlug voor- en achteruitspoelen. Zonder hoorbaar gezoem, zonder enige vertraging in kleine fracties van seconden. De snelheid waarmee dat ging, was verbazingwekkend en heb ik daarna nooit meer ergens waargenomen. Zelfs met moderne DVD-spelers is er sprake van enige vertraging bij het voor- en achteruitspoelen. De data-stream kon dus op een of andere wijze razendsnel naar voren of naar achteren worden gestuurd. Bovendien flipte hij tussen twee films been en weer. Dat maakte dat alles wat ik al had gezien nog eens met de factor twee werd vermenigvuldigd.

(Dick Vesters over zijn observaties van de demo van januari 1999 in een interview met Eric Smit en Hans Ueldhuyzen van Zanten)

Hoe is dit dan te verklaren met de toen bestaande technieken??

Hele goede vraag. Bestaande mainstream computers konden dat volgens mij niet dus we kunnen aannemen dat er chips in dat ding zaten die geoptimaliseerd waren voor specifieke taken en dus ook heel snel waren. Dat is ook al eerder door Sloot naar buiten gebracht.

De vraag is wat de resolutie van die film was. Als we van 640x480 pixels uitgaan en 3 bytes voor de kleuren. Verder 30 frames per seconde voor vloeiend beeld dan is dat 640*480*3*30/(1024*1024) =+- 26,37 MB/sec. -> 1.5 uur film = (90*60*26,37)/1024 = 139 Gigabyte.

Het lijkt me duidelijk dat er compressie/codering moet zijn geweest. Ik vraag me af of hierbij kwaliteitsverlies optrad of niet.

Ik weet niet wat voor compressie er toen al bestond maar als je de standaard mediaplayer van windows als chip laat bakken en in je computer zet dan zal een film ook supersnel gaan. DVD heeft volgens mij vertraging omdat het zoeken op dat schijfje relatief traag is . Sloot kan er tig repen geheugen in gestopt hebben waardoor ie de gecomprimeerde film letterlijk uit het geheugen las. Mja blijft speculeren.

Oh wat had ik graag bij die demo willen zijn

quote:

Op woensdag 8 december 2004 21:40 schreef schatje het volgende:

[..]

(Dick Vesters over zijn observaties van de demo van januari 1999 in een interview met Eric Smit en Hans Ueldhuyzen van Zanten)

Hoe is dit dan te verklaren met de toen bestaande technieken??

Vraag is al eerder langsgekomen. Kwestie van een goeie hypermedia presentatie in elkaar zetten.
Je kan mensen dan overtuigen dat ze naar 16 verschillende films zitten te kijken die spoelen of spelen, in werkelijk kijk je slechts naar een opname daarvan.

Ik meen dat er ook een interactieve demo is geweest en dat er 15 minuten werd gefilmd waarna het gecodeerd en gekeken is op dat ding van Sloot

En?
Ik heb wel eens een gochelaar een tijger in een vrouw zien veranderen, en een Value Added Services Centre demo gezien die alleen in QuickTime bestond.

Ja illusies kunnen maar dat geeft niet aan hoe hij het heb gedaan en voegt dus niks toe.

Ff kijken hoever we komen:
15 minuten filmen: check
2 uur coderen: check
Vervolgens dat filmpje afdraaien op zijn dedicated hardware waardoor het vloeiend gaat.

Dit zou idd kunnen. Maar dan blijf ik me afvragen waarom Sloot 20 jaar eraan heeft lopen werken. Of is dat misschien gelul? Maar dat zou betekenen dat ie andere dingen op zijn kamer deed 20 jaar lang of zijn zoon lult ook. Of kwam Sloot er pas in een heel laat stadium achter dat het niet ging werken?

quote:

Op donderdag 9 december 2004 08:46 schreef Redux het volgende:

[..]

En nog zeggen je hilarisch leuke vergelijkingen niks over de uitvinding van van sloot.

Nee, inhoudelijke argumenten geven laat ik aan jouw over, helaas doe je dat alleen niet.

quote:

Op woensdag 8 december 2004 22:55 schreef livEliveD het volgende:
Ja illusies kunnen maar dat geeft niet aan hoe hij het heb gedaan en voegt dus niks toe.

Ff kijken hoever we komen:
15 minuten filmen: check
2 uur coderen: check
Vervolgens dat filmpje afdraaien op zijn dedicated hardware waardoor het vloeiend gaat.

Dit zou idd kunnen. Maar dan blijf ik me afvragen waarom Sloot 20 jaar eraan heeft lopen werken. Of is dat misschien gelul? Maar dat zou betekenen dat ie andere dingen op zijn kamer deed 20 jaar lang of zijn zoon lult ook. Of kwam Sloot er pas in een heel laat stadium achter dat het niet ging werken?

Geloof best dat ie een filmpje kon opnemen en afspelen maar dat is niet het punt. Weet echter dat niet dat het op een 64 K chipkaartje past.

quote:

Op donderdag 9 december 2004 10:31 schreef Redux het volgende:

[..]

Ik heb al eerder op je verzoek inhoudelijk te reageren gereageerd dat ik dat niet kan.

En dat is het hele punt, niet, er is hier veel inhoudelijk gepost waarom het Sloot systeem niet kan. Jouw kritiek hierop is met je voetjes stampen en zeggen, welles...
Als ik mensen redeneerfouten probeer duidelijke te maken aan de hand van een abstract humoristisch voorbeeld ben je er als de kippen bij om te zeggen dat dit niets over Sloot zegt, maar dat was het punt dan ook niet.

quote:

Op donderdag 9 december 2004 11:22 schreef Redux het volgende:
Correct. Net als jij je ergert aan mensen zoals ik die roepen dat je niet kan aantonen dat de uitvinding van van sloot niet mogelijk is, erger ik me op mijn beurt aan mensen zoals jij die roepen dat aan de hand van bestaande technieken de uitvinding van van sloot niet mogelijk is.

Je ergert je er aan als ik zeg dat er geen technieken bestaan om dit mogelijk te maken. Correct, die bestaan niet, en Sloot heeft ze ook niet gemaakt.
Ik heb een voorbeeld gegeven van hoeveel rekenkracht je er voor nodig zou moeten hebben, om in theorie een kans te hebben dit te bereiken.
Kortom je ergert je eraan dat er mensen zijn die techniek begrijpen en weten waar ze het over hebben, en je droom aan diggelen werpen.
Nogmaals, het is geen hardware of software onmogelijkheid, het is een WISKUNDIGE onmogelijkheid.
Nu kan je weer een post gaan maken dat er een demo was waar JS bla bla bla

quote:

Op woensdag 8 december 2004 22:09 schreef Pietverdriet het volgende:

[..]

Vraag is al eerder langsgekomen. Kwestie van een goeie hypermedia presentatie in elkaar zetten.
Je kan mensen dan overtuigen dat ze naar 16 verschillende films zitten te kijken die spoelen of spelen, in werkelijk kijk je slechts naar een opname daarvan.

Met het verschil dat het voor- en achteruitspoelen pas gebeurde na het indrukken van de toets.