Mogelijke werking broncode van Jan Sloot

quote:

Op vrijdag 27 november 2009 11:48 schreef RM-rf het volgende:
ik zie nergens een 'verbetring' van de MPEG1 standaard..
bovenal een opslag van een analoge datastroom, zelfs gecrompimeerd voor en VHS film van meer dan een uur, past domeg niet in 370 Mb, wat Sloot claimde

Dit is een beetje een bud opmerking.
Waarom? Nou in 1995 was iedereen er van overtuigd dat 56K6 het maximale was wat we uit een koperen telefoondraad konden persen. Nu persen we er 20Mbit doorheen.

Ik ga dit wel even volgen.

quote:

Op vrijdag 27 november 2009 11:50 schreef xibieanor het volgende:

[..]

Hij rekende met de sleutel het analoge signaal uit. Zolang het systeem sneller rekent dan hij voor- of achteruitspoelt heb je beeld en geen database nodig. De chipkaart was dus de sleutel.
Ook in die tijd kon je met een plotter een oscilloscoopsignaal printen. Hij gebruikte waarschijnlijk die printercode of iets wat daarvan was afgeleid. Sloeg die printercode op in een database, die hij thuis had staan. Optimaliseerde de code in de database door dubbele waardes te vervangen. Dan had hij in principe een enorm lang getal, dat getal werd teruggerekend tot een sleutel. Die sleutel ging op de chipkaart. Het kastje kon de sleutel terugrekenen tot het getal dat de waardes van het analoge signaal vertegenwoordigde.

Je kan wel een sleutel maken op basis van een film, maar je kan geen film maken op basis van een sleutel.

quote:

Op vrijdag 27 november 2009 12:26 schreef xibieanor het volgende:

[..]

Dat klopt natuurlijk wel, want hij zal die film eerst in moeten lezen in zijn eigen code(taal) en daaruit de juiste key moeten ontwikkelen, zodat het kastje het signaal uit kan rekenen.

Simpel gezegd
34861176:569832 =44184
34861176 = alle gegevens film
569832 = waarde aanwezig op het kastje
44184 = key
Key * waarde aanwezig op kastje = film
44184*569832 = 34861176
Nu gaan we voor de simpelheid van het voorbeeld er even vanuit dat het beeldscherm twee pixels breed is, twee lang en dat elk getal een specifieke kleur is.
Het kastje begin te rekenen en zijn data op het scherm te 'schrijven' van boven naar beneden van links naar rechts.
Dus
34
86
-verversing scherm
11
76
Als het bij 11 is kan hij zeg maar 34 verwijderen en uit het geheugen mikken, want dat heeft hij niet meer nodig.

Het is een leuk voorbeeld, maar je sleutel plus je waarde nemen meer data in beslag dan de film zelf.

quote:

Op vrijdag 27 november 2009 11:51 schreef Daniel1976 het volgende:

[..]

Dit is een beetje een bud opmerking.
Waarom? Nou in 1995 was iedereen er van overtuigd dat 56K6 het maximale was wat we uit een koperen telefoondraad konden persen. Nu persen we er 20Mbit doorheen.

Dat is niet vergelijkbaar met compresiemogelijkheden... er bestaat geen moment waarop je opeens veel eindelozer kunt comprimeren.

de reden dat DSL wel kan functioneren, is dat het gebruikt maakt van een veel hoger frequentie, terwijl tarditionele telefonie nog gebruik maakta van beperktere en lagere frequentie... daarvoor is wel een beter telefoonnetwerk nodig en aangepast leidingen.


zoals computers echteer een binair systeem is, bestaat er ook een duidelijke bovengrens aan compressie, bepaalde comprssiemogelijkheden zijn non-lossy, echter versien zeer gestructureerde data (bv texxt-compreesie die ook gebruik maakt van veelvoorkomende woorden, voor videocompresie is dat weinig geschikt) .. of je kunt bv lossy compressie gebruken als JPEG, welke op een bepal compressie-rate duidelijk artefacten naliet...
Naar ik meen claimde Sloot echter geen lossy compresie te gebruiken maar iets te doen dat 'superieur' daarover was....

Ecter, dat is weiig geloofswaardig, zeker als iemand geheim houd wat dat precies is en zelfs geen werkbaar patent erover kan aanvragen (wat namelijk, als het gepatenterd is een miljoenen of miljardenpatent zou zijn... zelfs met het idee de markt op te gaan zonder patent-aanvraag, is gewoon ronduit dom)

quote:

Op vrijdag 27 november 2009 11:51 schreef Daniel1976 het volgende:
Nou in 1995 was iedereen er van overtuigd dat 56K6 het maximale was wat we uit een koperen telefoondraad konden persen.

Was dat beredeneerd op basis van fysische limieten of wiskundige onmogelijkheden?

quote:

Op vrijdag 27 november 2009 12:33 schreef xibieanor het volgende:

[..]

Dat kan wel op basis van het analoge signaal. Daarvoor heb je voor kleur drie variabele waardes nodig de fase, amplitude en de uitslag van de helderheid, die in het analoge signaal op een andere frequentie 'eronder' loopt. De factor pi is namelijk een constante.

De sleutel is uniek, maar bevat geen informatie. Daaorm kan je geen film maken met alleen de sleutel.

Een voorbeeld: Als ik tegen jou zeg "Jurassic Park", kan jij daar een film mee maken. Dat komt omdat de naam "Jurassic Park" een unieke sleutel is. Echter, gebruik jij je herinneringen om aan de hand van die sleutel de film in elkaar te steken. In jouw herinnering staat dus de echte data, en is dus niet gecomprimeerd. De sleutel bevat geen data.

quote:

Op vrijdag 27 november 2009 12:35 schreef xibieanor het volgende:

[..]

Je kunt ook met machten werken, dat was voor dit voorbeeld beter geweest.

Een voorbeeld:

64^2 = 4096

Lijkt simpel he? Maar hoe doe je het met 4095? En 4094?

Zo'n wiskundige berekening is niets meer dan een index toekennen aan een herhalend patroon. In dit geval ken je de index 64 toe aan het patroon 4096. Om het patroon te vinden gebruik je een algoritme, namelijk de 2e macht.

Als je je verdiept in compressie herken je dit en weet je dat je hier niks mee zal opschieten, het is slechts een moeilijkere methode om minder te bereiken dan bijvoorbeeld het zip algoritme.

quote:

Op vrijdag 27 november 2009 11:51 schreef Daniel1976 het volgende:

[..]

Dit is een beetje een bud opmerking.
Waarom? Nou in 1995 was iedereen er van overtuigd dat 56K6 het maximale was wat we uit een koperen telefoondraad konden persen. Nu persen we er 20Mbit doorheen.

Dat was niet het maximum van de draad, maar van de centrale's en dergelijke. Die zijn dan ook allemaal aangepast om die 20Mbit te halen.

On Topic:
Een hoax waar, ook toen, alleen idioten in geloven.

Hoezo het werkte wel. Wat doe je nou toch allemaal voor aannamen. Je deed straks ook al de aanname dat 'hij waarschijnlijk de printercode gebruikte of iets wat daarvan was afgeleid'. En vervolgens ga je daar op door alsof dat dé waarheid is.

Je weet helemaal niet meer dan de rest van ons. Wist je dat wel, dan kwam je niet met dit soort verhalen aan, want ik heb je eigenlijk nog niks concreets zien zeggen. Sorry, maar het is zo. Er zijn hier tig topics over geweest in het verleden, waarin al wiskundig werd aangetoond dat het niet kon. Ik zou zeggen; gebruik eens de zoekfunctie van dit forum om je in die topics in te lezen.

quote:

Op vrijdag 27 november 2009 11:50 schreef xibieanor het volgende:

[..]

Hij rekende met de sleutel het analoge signaal uit.

Nee, het eindresultaat voor video op een computer is toch echt een digitale framebuffer.

quote:

Zolang het systeem sneller rekent dan hij voor- of achteruitspoelt heb je beeld en geen database nodig. De chipkaart was dus de sleutel.

Met alleen een sleutel heb je niks, je hebt ook nog de data nodig om die sleutel op toe te passen.
Het 'magische' van Sloot's systeem zou zijn dat hij een drietal statische tabellen zou hebben - die in elk afspeelkastje ingebouwd zouden zitten - waar hij met behulp van sleutels elke film uit zou kunnen halen.

quote:

Ook in die tijd kon je met een plotter een oscilloscoopsignaal printen. Hij gebruikte waarschijnlijk die printercode of iets wat daarvan was afgeleid. Sloeg die printercode op in een database, die hij thuis had staan.

Dit raakt echt kant nog wal.

quote:

Optimaliseerde de code in de database door dubbele waardes te vervangen.

Hoera, je hebt zojuist de meest eenvoudige vorm van compressie ontdekt die er is

quote:

Dan had hij in principe een enorm lang getal, dat getal werd teruggerekend tot een sleutel. Die sleutel ging op de chipkaart. Het kastje kon de sleutel terugrekenen tot het getal dat de waardes van het analoge signaal vertegenwoordigde.

Kortom, videocompressie.

Je versterkt met elke post mijn indruk dat je helemaal geen verstand hebt van hoe videocompressie in zijn werk gaat.
Je hebt nu een paar dingen bedacht - heel simpele zaken - die al in 1975 gebruikt werden voor simpele compressie - en denkt dat je het ei van columbus hebt uitgevonden,
terwijl je eigenlijk net aan het begin staat van het begrip van compressietechnieken.

quote:

Op vrijdag 27 november 2009 13:12 schreef xibieanor het volgende:

[..]

Dat heb ik gedaan, maar ik kwam daar geen verklaring tegen over hoe het wel zou kunnen werken. Ik kwam alleen verklaringen tegen dat het niet zou kunnen werken.

Daar is een reden voor.

quote:

Op vrijdag 27 november 2009 13:12 schreef xibieanor het volgende:

[..]

Dat heb ik gedaan, maar ik kwam daar geen verklaring tegen over hoe het wel zou kunnen werken. Ik kwam alleen verklaringen tegen dat het niet zou kunnen werken. Zoals ik het beschrijf moet het kunnen werken volgens mij.
Over wel werken. Ik heb altijd begrepen dat het allemaal wel werkte tijdens de demonstraties waarbij kastjes niet kapot vielen ed. In die tijd waren ontvangers en zenders mocht er een in het kastje hebben gezeten niet van die capaciteit dat de geclaimde prestaties mogelijk waren.
Het gebruik van printercode is gezien dat tijdperk de eenvoudigste manier, lijkt mij.
Dan blijft de mogelijkheid over dat het een L&H was wat ik ook niet ondenkbaar acht.

Er zijn nog tig mogelijkheden over, immers, hij had -volgens het verhaal- iets compleet nieuws bedacht, en dat zal dan misschien wel verder zijn gegaan dan wat jij mogelijk acht.

Nee, zoals jij het beschrijft kan het absoluut niet werken. Met alle respect, Ik ben het eens met _LeD_, je posts getuigen niet van enige kennis op dit gebied. Je denkt dat je met wat simpele redeneringen (die ook nog eens niet correct zijn) dit hele verhaal te kunnen verklaren, dan wel te kunnen zeggen 'hoe het waarschijnlijk ging'.

quote:

Op vrijdag 27 november 2009 13:19 schreef xibieanor het volgende:

[..]

De videocompressietechniek is niet het belangrijkste, dat is de manier van coderen op basis van het analoge signaal.

Ik denk dat dit een verloren zaak is.

quote:

Op vrijdag 27 november 2009 13:19 schreef xibieanor het volgende:

[..]

De videocompressietechniek is niet het belangrijkste, dat is de manier van coderen op basis van het analoge signaal.

Zucht....
wordt het 'gecodeerd' naar een digitaal signaal ?
Worden daarop technieken toegepast om de hoeveelheid data te verkleinen ? ja ?
Dan hebben we het over digitale videocompressie, heel goed.

Dat is altijd het gezeik, mensen denken altijd een briljant idee te hebben als ze weinig van de materie snappen. Hoe meer mensen over iets weten, hoe minder vaak ze denken briljant te zijn

quote:

Op vrijdag 27 november 2009 13:19 schreef xibieanor het volgende:

[..]

De videocompressietechniek is niet het belangrijkste, dat is de manier van coderen op basis van het analoge signaal.

inerdaad, het zijn de ultrakleine kaboutertjes in het kastje die eigenlijk het werk deden

Kijk, je kunt een hele hoop met libraries. Kijk bijvoorbeeld naar het spelletje kkrieger.exe. 96 Kb groot, maar wel met muziek, levels, textures en 3d effecten. Een heleboel word procudereel gegenereerd, en andere dingen worden uit bestaande libraries gehaald, waardoor de eigenlijke code van het spel niet erg groot is. Kost alleen gigantisch veel optimalisering en rekenkracht.

quote:

Op vrijdag 27 november 2009 14:32 schreef Bensel het volgende:
Kijk, je kunt een hele hoop met libraries. Kijk bijvoorbeeld naar het spelletje kkrieger.exe. 96 Kb groot, maar wel met muziek, levels, textures en 3d effecten. Een heleboel word procudereel gegenereerd, en andere dingen worden uit bestaande libraries gehaald, waardoor de eigenlijke code van het spel niet erg groot is. Kost alleen gigantisch veel optimalisering en rekenkracht.

Zucht, weer iemand die Farbrausch erbij haalt.
Het schrijven van een leuke softsynthesizer en wat functies die 3d-objecten en bitmaps genereren is heel wat anders en heeft hier vrij weinig mee te maken.
We hebben het hier niet over genereren, we hebben het over reduceren en weer opbouwen.

quote:

Op vrijdag 27 november 2009 14:32 schreef Bensel het volgende:
Kijk, je kunt een hele hoop met libraries. Kijk bijvoorbeeld naar het spelletje kkrieger.exe. 96 Kb groot, maar wel met muziek, levels, textures en 3d effecten. Een heleboel word procudereel gegenereerd, en andere dingen worden uit bestaande libraries gehaald, waardoor de eigenlijke code van het spel niet erg groot is. Kost alleen gigantisch veel optimalisering en rekenkracht.

rekenkracht zal er niet overdreven veel nodig zijn .... integendeel, het is waarschijnlijk eerder andersom, hoe zwaar de 'basis' is en de brondbestanden e gecomliceerde berekeningen die voorgegegeven zijn in het programma, des te meer rekenkracht is nodig...

het spel dat je als voorbeeld geeft is idd indrukwekkend qua grootte, maar is ook niet een gecomprimeerde video, maar juist een vanuit een minimaal model gegenereerd iets, zonder verder scenario of al te uitgebriede wereld ... voornamelijk een zeer basi 'engine'...

het is echter niet mogelijk vanuit een bestaande film deze zomaar 'om te zetten'...

als je bv kijkt naar muziek is het best mogelijk muziekbestanden een paar Kb groot te laten zijn voor meerdere minuten muziek, bv via MOD Files: http://en.wikipedia.org/wiki/Module_file .... echter het is niet mogelijk je bestaande muziekcollectie 1-op-1 om te zetten daarnaar..
een MOD file betekent eigenlijk dat enkel de compositie opgeslagen wordt, als ware het enkel de bladmuziek, soms met wat extra datasporen of extra instellingen