------
Mogelijke werking broncode van Jan Sloot
Jan Sloot was volgens de overlevering een begenadigd televisiereparateur, die bovendien werkzaam was in de periode dat hoge kwaliteit analoog signaal overging in de digitale variant. Met name het analoge signaal van het Composiet Video (CVBS) is in deze kwestie interessant, een analoog beeldsignaal is namelijk erg eenvoudig. De fase bepaalt de kleur en de amplitude de verzadiging van die kleur. Het signaal dat de helderheid bevat loopt er parallel op een andere frequentie onder. Het signaal voor de helderheid was zeker in die tijd precies hetzelfde als voor de zwart-wittelevisie. In principe zijn er dus drie variabelen nodig om een kleur weer te geven namelijk de waarde van de fase, de waarde van de amplitude en de waarde van de helderheid. Aangezien er zes kleuren werden doorgegeven, te weten geel, rood, magenta, blauw, cyaan en groen en dat 1 volt voldoende was voor de amplitude is het aantal waarden beperkt.
Analoog signaal coderen
De analoge televisie was hoe je het ook bekijkt, een erg eenvoudig apparaat. Een elektronenkanon beschreef het beeldscherm van links naar rechts en van boven naar beneden. Het elektronenkanon wist dat het aan de volgende regel moest beginnen, omdat het signaal een lijnpuls gaf aan het eind van de regel. Aan het eind van het complete beeld gaf het signaal een rasterpuls, daardoor wist het elektronenkanon dat het weer bovenaan moest beginnen. Ook in die tijd was het mogelijk om dat analoge signaal om te zetten naar een digitaal signaal. Sloot was ongetwijfeld goed bekend met die techniek, want hij was reparateur in de overgangsmethode van analoog naar digitaal. Wat de vinding van Sloot vermoedelijk uniek maakte was dat hij de waarden die hij uitlas codeerde naar een codetaal, het Sloot Digital Coding System (SDCS) in plaats van het direct digitaal door te zenden. Deze lange rijen van codetaal sloeg hij op in een database, waarbij hij de waarden die achterelkaar hetzelfde bleven als hetzelfde links codeerde. Veel problemen gaf dit niet, want de lijnpuls gaf altijd het einde van de lijn aan en de rasterpuls het einde van het raster.
In principe had Sloot dus aan het einde van een film een database met een enorme hoeveelheid gegevens in de taal SDCS. Het is niet vreselijk moeilijk om een database verticaal uit te lezen, zodoende is het aannemelijk dat Sloot in zijn codetaal ook de mogelijkheid heeft gebruikt om hetzelfde als boven aan te geven, wat ook in opslagruimte bespaarde. Zolang de regel boven de schrijfregel maar in het geheugen staat komt dit goed.
Jan Sloot schreef data op het beeldscherm
Sloot had waarschijnlijk een simpel (beeld)besturingssysteem geschreven dat opgeslagen was in het befaamde kastje. Dit beeldbesturingssysteem had als kenmerk dat het het beeld niet als een compleet plaatje verzond, zoals digitaal gebruikelijk is, maar opbouwde volgens de structuur van het de beeldopbouw van een analoge televisie. Een contante stroom van data schreef het beeld op het scherm. Veel geheugencapaciteit hoefde dit niet te kosten, want eenmaal geschreven data kon na een paar regels al uit het geheugen verdwijnen. Ook het voor- en achteruitspoelen wijst op deze techniek, want het enige wat daarvoor moet gebeuren is versneld op het beeld schrijven.
Chipkaart van Jan Sloot bevatte sleutel
Blijft over het fenomeen van de chipkaart waarop de complete film zou staan. Ik vermoed dat de chipkaart slechts een sleutel bevatte. Sloot had immers de film in SDCS in een database staan. In principe is het mogelijk om naar de uitkomst van deze codetaal (SDCS) die de film weergeeft te rekenen.
De sleutel op de chipkaart bevatte de toegang tot de berekening naar de film in SDCS. Het befaamde kastje van Sloot bevatte in het besturingssysteem in elk geval de mogelijkheid om naar SDCS te rekenen aan de hand van de sleutel, plus de mogelijkheid om die op een scherm weer te geven. Het kastje van Jan Sloot hoefde niet de hele film te bevatten, want zolang het systeem maar sneller rekende als het voor- of achteruit kon ‘spoelen’ ging alles goed. Omdat het geheugen maar een paar regels codetaal hoefde te bevatten kon het geheel afspelen met relatief weinig geheugen. De stroom van gegevens was ook met de geclaimde zestien schermpjes niet zo groot dat het niet via een parallelle poort kon worden doorgeven.
Deze manier van werken verklaart ook waarom Jan Sloot alleen films kon vertonen die zijn systeem had gecodeerd en waarom hij volgens de overlevering opgenomen videobeeld kon vertonen. De uitgang van een analoge videocamera verschilt niet van het CVBS-signaal. Het is onwaarschijnlijk dat er als bewijs op een conferentie anderhalf uur gefilmd moest worden. Vermoedelijk was het geheugen groot genoeg om dat op te slaan en bezat het kastje op dat moment toch een codeerfunctie.
De films in de codetaal bewaarde Sloot in een database thuis. Al hoefde dat niet, want de hele film kon berekend worden aan de hand van de code op de chipkaart.
Dit verklaart ook waarom het zenden via een netwerk niet mogelijk was, zolang beide partijen niet een identieke sleutel naar de berekening van zijn taal en het besturingssysteem met weergaveprogramma bezaten.
Toch analoog en toch coderen
Mocht het systeem zo werken dan had Jan Sloot gelijk met de uitspraak dat het systeem niet in enen en nullen werkte. Hij had een manier gevonden om een digitaal apparaat als zijnde analoog te gebruiken. Hij comprimeerde niks, maar codeerde uiterst efficiënt.
[ Bericht 1% gewijzigd door remlof op 27-11-2009 11:40:17 (link weggehaald) ]
quote:
quote:Komt op hetzelfde neer, en het wordt digitaal gecomprimeerd/gecodeerd en opgeslagen.Op vrijdag 27 november 2009 11:18 schreef xibieanor het volgende:
Mocht het systeem zo werken dan had Jan Sloot gelijk met de uitspraak dat het systeem niet in enen en nullen werkte. Hij had een manier gevonden om een digitaal apparaat als zijnde analoog te gebruiken. Hij comprimeerde niks, maar codeerde uiterst efficiënt.
Volgens mij weet jij weinig van digitale videocompressie en streamingtechnieken.
Wat jij beschrijft is namelijk precies dat, niet meer, niet minder.
Ook lijk je geen onderscheid te maken tussen werkgeheugen en opslaggeheugen.
Dat je weinig werkgeheugen nodig hebt (omdat "geschreven stukken weer uit het geheugen kunnen verdwijnen") wil niet zeggen dat je weinig opslaggeheugen nodig hebt - de data moet nog steeds ergens vandaan komen.
Het belangrijkste in het verhaal - de statische tabellen en hoe de key daarmee samenwerkt (en gegenereerd wordt) - zie ik niet in het verhaal terug.
[ Bericht 8% gewijzigd door _Led_ op 27-11-2009 11:39:06 ]
quote:Yup, hij heeft special geregistreerd voor deze post.
quote:die gast meende een ontdekking te hebben gedaan dat je een complete film op 128 kb geheugen kon plaatsen.
Ik weet niet eens waar je het over hebt.
Hij is om een of andere rede dood gegaan(chip lobby) en nam het idee mee in zijn graf
quote:Het idee was dat ie een aantal grote statische data-tables had, waar hij elke film uit kon toveren mits je de juiste key had.
Maar waar komt de filmdata dan vandaan? De sleutel zat op de chip, het programma in dat kastje en de film??????
Alle instrumenten staan op de geluidskaart met een klein bestandje komt er een heel orkest uit je pc.
Zelfde geldt voor de vroegere trackers(mod/xm)
quote:Nee, in dit geval slaat dat nergens op omdat er niet met samples (audio/video) gewerkt wordt.
Volgens mij lijkt het een beetje op MIDI.
Alle instrumenten staan op de geluidskaart met een klein bestandje komt er een heel orkest uit je pc.
Zelfde geldt voor de vroegere trackers(mod/xm)
De datastream zou volledig gegenereerd worden uit de datatables en de key.
quote:zo'n zelfde verhals als Nicolai TeslaOp vrijdag 27 november 2009 11:34 schreef Re het volgende:
was dat die vent die ineens ergens dood neerviel voordat hij alles kon presenteren?
quote:Klinkt als een broodje aap verhaal to me. Maar ik heb dan ook geen verstand van IT.
[..]
die gast meende een ontdekking te hebben gedaan dat je een complete film op 128 kb geheugen kon plaatsen.
Hij is om een of andere rede dood gegaan(chip lobby) en nam het idee mee in zijn graf
Nee, nee geen spam.
Ik had een plek nodig om die tekst te posten en waar ik er grip op had wat ermee gebeurde. Als ik hem op een forum zet en de moderator is het er niet meer eens, dan gaat het verloren. Bovendien kun je niet overal lappen tekst posten. Waar absoluut wat voor te zeggen is, natuurlijk.
quote:GMTA.Op vrijdag 27 november 2009 11:27 schreef _Led_ het volgende:
[..]
Komt op hetzelfde neer, en het wordt digitaal gecomprimeerd/gecodeerd en opgeslagen.
Volgens mij weet jij weinig van digitale videocompressie en streamingtechnieken.
Wat jij beschrijft is namelijk precies dat, niet meer, niet minder.
Ook lijk je geen onderscheid te maken tussen werkgeheugen en opslaggeheugen.
Dat je weinig werkgeheugen nodig hebt (omdat "geschreven stukken weer uit het geheugen kunnen verdwijnen") wil niet zeggen dat je weinig opslaggeheugen nodig hebt - de data moet nog steeds ergens vandaan komen.
Hele tijd geleden zijn er tig topics geweest over dit onderwerp. Could it really be starting all over again?
Overigens, blijkbaar speciaal geregistreerd hiervoor. Is dit niet een verkapte vorm van spam dan?
quote:Als de OP van jouw hand is en daar lijkt het op is het prima om er hier over te discussiëren. Heb wel de link weggehaald en het topic naar W&T verplaatst.
@fruityloop
Nee, nee geen spam.
Ik had een plek nodig om die tekst te posten en waar ik er grip op had wat ermee gebeurde. Als ik hem op een forum zet en de moderator is het er niet meer eens, dan gaat het verloren. Bovendien kun je niet overal lappen tekst posten. Waar absoluut wat voor te zeggen is, natuurlijk.
Dus of Sloot zn megauitvinding zelf nou binair was of niet, uiteindelijk moest het wel kunnen communiceren met een binaire machine, en dus ben je dan weer aan wiskundige regels onderhevig, en die geven aan dat het niet kan.
Maar voor de geïnteresseerden wil ik het principe nog wel even uitleggen.
Men kwam er op een gegeven moment achter dat complexe schijnbaar chaotische figuren toch niet zo chaotisch zijn (de fractal) bijvoorbeeld het blad van een varen is terug te voeren tot een wiskundige formule.
(Voorbeeld fractal:)
(hier uitleg over de formules: http://www.coolmath.com/fractals/fractals_lesson.html)
Nu volgens de chaos theorie is er in elke chaos een patroon te herkennen en zo zou je een film kunnen zien als een hele grote fractal. En die valt dan weer in een wiskundige formule te beschrijven.
Door de wiskundige formule uit te voeren, reproduceerd men dus de film beelden.
Tot zover de theorie.
Aangezien Jan een electro monteur was en geen hoogbegaafde wiskundige is de kans dat hij dat zou hebben uitgevonden zeer klein.
Wel is hij er in geslaagd om een heleboel mensen te overtuigen (niet de minsten).
zeker als in de toepasing gewoon de velden linair uitgelezen worden is het een oplossing die eigenlijk veel minder effectief is dan een 'gewone' file-based oplossing (welke ook beter comprimeerbaar is)...
nee sorry, maar de gestelde oplossing klinkt als een codec-concept uit het jaar minus, zelfs de toen al beschikbare MPEG-1 codec werkt veel beter en optiomalr en was al sinds 1993 bekend...
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
quote:Op vrijdag 27 november 2009 11:31 schreef Deetch het volgende:
Maar waar komt de filmdata dan vandaan? De sleutel zat op de chip, het programma in dat kastje en de film??????
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.
quote:Dit is een beetje een bud opmerking.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
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.
quote:Je kan wel een sleutel maken op basis van een film, maar je kan geen film maken op basis van een sleutel.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.
quote:Op vrijdag 27 november 2009 11:33 schreef _Led_ het volgende:
[..]
Het idee was dat ie een aantal grote statische data-tables had, waar hij elke film uit kon toveren mits je de juiste key had.
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.
quote:Het is een leuk voorbeeld, maar je sleutel plus je waarde nemen meer data in beslag dan de film zelf.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.
quote:Dat is niet vergelijkbaar met compresiemogelijkheden... er bestaat geen moment waarop je opeens veel eindelozer kunt comprimeren.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.
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: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.Op vrijdag 27 november 2009 12:20 schreef rashudo het volgende:
[..]
Je kan wel een sleutel maken op basis van een film, maar je kan geen film maken op basis van een sleutel.
quote:Je kunt ook met machten werken, dat was voor dit voorbeeld beter geweest.Op vrijdag 27 november 2009 12:30 schreef rashudo het volgende:
[..]
Het is een leuk voorbeeld, maar je sleutel plus je waarde nemen meer data in beslag dan de film zelf.
quote:Was dat beredeneerd op basis van fysische limieten of wiskundige onmogelijkheden?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.
quote:De sleutel is uniek, maar bevat geen informatie. Daaorm kan je geen film maken met alleen de sleutel.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.
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:Een voorbeeld:Op vrijdag 27 november 2009 12:35 schreef xibieanor het volgende:
[..]
Je kunt ook met machten werken, dat was voor dit voorbeeld beter geweest.
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: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.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.
On Topic:
Een hoax waar, ook toen, alleen idioten in geloven.
quote:Op vrijdag 27 november 2009 12:48 schreef rashudo het volgende:
[..]
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.
Je hebt natuurlijk altijd dat kastje erbij nodig om de film uit die sleutel te berekenen. Dat is waarom het moeizaam werkte. Iedereen die een film wilde kijken met een sleutel had zo'n kastje (of dat besturingssysteem) nodig. Op dat kastje stonden de gegevens waarmee de data van de film gereconstrueerd kon worden. De vergelijking met nieuwe M$ is niet voor niks gemaakt.
Het werkte wel, maar vereiste aanpassingen over de hele breedte van de (film)industrie. Je moest de film op willen slaan in de code van Sloot. De sleutel berekenen en een kastje kopen.
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:Nee, het eindresultaat voor video op een computer is toch echt een digitale framebuffer.
[..]
Hij rekende met de sleutel het analoge signaal uit.
quote:Met alleen een sleutel heb je niks, je hebt ook nog de data nodig om die sleutel op toe te passen.Zolang het systeem sneller rekent dan hij voor- of achteruitspoelt heb je beeld en geen database nodig. De chipkaart was dus de sleutel.
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:Dit raakt echt kant nog wal.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.
quote:Hoera, je hebt zojuist de meest eenvoudige vorm van compressie ontdekt die er isOptimaliseerde de code in de database door dubbele waardes te vervangen.
quote:Kortom, videocompressie.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 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:03 schreef CoolGuy het volgende:
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.
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.
quote:Daar is een reden voor.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.
quote:Op vrijdag 27 november 2009 13:04 schreef _Led_ het volgende:
[..]
Nee, het eindresultaat voor video op een computer is toch echt een digitale framebuffer.
[..]
Een analoog signaal naar digitaal is een kwestie van hardware.
[..]
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.
[..]
Nou dat kan toch als de sleutel en de berekening naar de plaats in de tabel maar correct zijn.
[..]
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.
De videocompressietechniek is niet het belangrijkste, dat is de manier van coderen op basis van het analoge signaal.
quote: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.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.
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:Zucht....
[..]
De videocompressietechniek is niet het belangrijkste, dat is de manier van coderen op basis van het analoge signaal.
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:inerdaad, het zijn de ultrakleine kaboutertjes in het kastje die eigenlijk het werk dedenOp 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.
quote:Zucht, weer iemand die Farbrausch erbij haalt.
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.
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: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...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.
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
Roel Pieper, een topman van Philips, gaf zijn baan op om met de uitvinding van Jan Sloot miljoenen te verdienen.
Hij noemde de techniek van Jan Sloot The Fifth Force naar een mysterieuze vijfde kracht die in de natuur zou werken.
Het kastje van Sloot is in een laboratorium onderzocht maar mocht van Sloot niet opengemaakt worden,
Toen naderhand bleek dat er toch mee geknoeid was kreeg Sloot zowat een hartverlamming.
De hele zaak flopte toen Jan Sloot overleed en de werking niet achterhaald kon worden.
Heb me daar een aantal jaren geleden ook erg mee geamuseerd. Duidelijk een poging tot een coderingssysteem (afgeleid van z'n RepaBase om reparatiehandleidingen op een simpele wijze decentraal zichtbaar te kunnen maken via zeg een 28K8 lijntje) en absoluut geen (lossless) compressie. Je kunt er aan rekenen wat je wilt, maar er klopt (wiskundig) gewoon geen donder van zijn claims. Stond gewoon een code op de smartcard om een pre-coded database van 350Mbyte te kunnen decoderen. Tsja, daar heb je natuurlijk niet zoveel aan want je moet die 350Mb ook nog over het lijntje pompen naar het kastje om een filmpje te kunnen bekijken. En dan ook nog eens 350Mb per film. En dat was dan ook precies Piepers probleem met een "uitvinding die nog niet af was want er was een probleempje met het netwerk".
En weten jullie wat het gekke is...?
Het bedrijf dat toendertijd is opgericht om deze vinding te commercialiseren heette DAVOC (nu 'alive, but dormant') en hun website bestaat nog steeds!
http://www.davoc.com/indexnow.html
Klik op 'techniek' op de smart card en je leest waarom Jan Sloot bij zijn eerste bezoek aan deze website al bijna een hartaanval kreeg vanwege de details die werden vrijgegeven over zijn vinding (zie ook boek Eric Smit).
Met die geheime sleutel van Sloot moet ik altijd weer denken aan die geweldige grap van Freek de Jonge waarbij z'n zoontje zijn sleutel in een sloot gegooid had, want ze hadden hem verteld dat 'sleutels in sloten horen'
Toch ff het stukje techniek van die HTML 1.0, FLASH 0.1 "yesterday's web future" site geplukt en even een paar items gehighlight.
(...)
Techniques As you know calculation of the code for moving picture requires a complicated algorithm. In 1987 the development of a new system started, in order to store the enormous amount of data, which must be available for the Electronic Repair Branch.
For this purpose a unique database was developed, which contains millions of data available for every electronics repairman trough an ISDN network. Within seconds data and specifications can be obtained about almost any device. Like: components with specifications, cable frequencies, locations, suppliers, delivery periods, ZIPcodes, phone numbers, and so on.
Agno: Tsja. Maar da's makkelijker want de data van manuals is vrij statisch en eenvouding in codeblokken op te delen
On top of that, the system has unique error detection, using an IRIS code. That way a solution can be found for any device regardless the malfunction. At the same time one can search for the concerning scheme. All data concerning the repair can be found and printed out.
This "REPA BASE" is now operational for 2 years in the Netherlands and proved its value by an increase of costs and time of over 65%.
The system, used for "REPA BASE", was further developed and later used in Audio and Video appliances, using the basic principle to store unique data only once and add only new data. That way a number of databases were developed with different sorts of unique data. Processor systems create codes for all this data, which are finally put together in a so-called key-code. This code is offered to the workstation of the requester. On his workstation all the required data are shown on the screen as copy, pictures or schemes and can be send to the printer.
For many years people searched for ways to compress data, audio and video in order to store it on compact carriers. The compression techniques became better and better, but so far the best result still is only 45%.
The basic idea behind the development of the DAVOC system is that there should be no mechanical components, and that the carrier should be light and small. The microchip on a chipcard proved to be the right answer. Additional advantage of this carrier is the fact that one can print e.g. a logo on it.
The process of DAVOC analyses every videoframe in detail with a unique processor system. First in detail, later as a whole picture and finally as a complete clip or movie. It then creates a key-code of a few bits and stores it in the memory of the application.
That way lots of key-codes can be stored and users can make a choice of viewing a film now or (much) later. For this purpose a reader / writer is available.
In fact DAVOC did not try to improve existing systems, like VHS, but used existing techniques to develop a brand new system. Using key-codes in stead of compression.
Consequently the data is no longer stored in the way it is presented, but presented directly while the code is gradually processed. So from now on we just call it the DAVOC signal.
DAVOC is the new digital standard. It ends all traditional ways of data processing, which need enormous memory capacities. Which makes transport of data expensive and slow.
Making DAVOC the new standard offers the benefit, that applications made all over the world will have the same quality. Through telecommunications data, sound and pictures can be shown in real-time now. As the DAVOC system requires only a few bits for itself, it is now possible to store over ten hours of video on a single chipcard. Agno: klinkt als streaming waarbij de code op de smartcard gebruikt wordt als identifier voor de film, song of data die je wenst.
The system operates with a complete new way of digital processing in a DAVOC processor. It uses the tree basic colors red, green and blue plus an additional clearness factor. With the value of the colors, the clearness signal and the unique algorithm the processor can calculate any known color of the spectrum.
That way a perfect picture can be quaranteed, in which every detail is controlled by a reference code. No stripes, fading or other disturbance will be shown in the picture. Of every pixel only one pixel, if recognized as DDS, will be changed. Agno: DDS?And only if the pixel is different then the one before. Therefore the picture will stand like a photo on the screen. No flicker or any other disturbance will be shown. Because of the fact that the screen will be no longer refreshed 50 times a second it is not necessary have to line, grid or screen synchronization. Agno: dat klinkt in eerste instantie logisch. Gewoon bits en bytes in een videomemory achter het scherm dat je ziet. Zo werkt tegenwoordig iedere videokaart. Aan de andere kant: in Sloot's tijd bestonden er nog nauwelijks LCD/LED/Plasma schermen dus hoe ie dan van die die lijn en rastersynchronisatie afwilde is mij een raadsel. Een CRT (Cathode Ray Tube) werkt nu eenmaal met een verversingsmechanisme van twee rasters (even en oneven lijnen) die in elkaar 'dovetailen'. Door de verversingssnelheid wordt het beeld als het ware 'geïntegreerd' door het oog en zien we een vloeiende serie beelden (vergelijk met de matrix aansturing van LED displays).
From every frame the processor will calculate all pixels in to a color value, the frame is build with 976 pixels in a line and 640 per frame. So 640 x 976 = 624.640,00 pixels. To speed up the process the frame is divided in to matrixes from each 16 x 16 = 256 pixels. Thus horizontal the frame contains 64 matrix blocks (lines) and vertical only 40. A complete frame contains therefore only 2560 blocks, compare with 624.640,00 pixels en enormous reduction. Every matrix block is 1/2.560 part of the frame.
Agno: Hier wordt het erg vaag. Open vraag waar ik heel graag het antwoord op zou willen horen: hoeveel bits zijn er dan nodig voor de opslag van één van die 2560 blocks? 1 bit per block lijkt me wat weinig...
The signals are analyzed and processed to a DAVOC signal and divided for further processing by the algorithm. From fixed memory (ROM) the processor compares if there is a reference and a logic value is given. When the value is not in the reference a new value will be calculated and stored in ROM memory. This is a kind of bucket memory. Through the DAVOC coding it is possible to store an enormous amount of data. (Fi. A television broadcast for several weeks and more then a dozen channels)
Trough the algorithm the correct color value of every pixel will be calculated by a processor. In the same way a value will be calculated for a frame line. After calculating 40 frame lines the value of the entire picture will be calculated. Finally all data will be processed in the DAVOC Video processor in which a single code is calculated which is stored in the RAM memory.
Sound tracks are processed directly by the DAVOC Audio processor and also stored in the RAM memory. Pictures can be viewed "life" on any monitor or TV, but can also be stored on an external carrier like a chipcard. It can then be viewed later, on any DAVOC system on this planet. The sound can be locked to any amplifier or stored in the same way.
Because DAVOC needs just a few bits for pictures, sounds and data complete programs can be stored in a small package and send all over the world. Because it only needs a small bandwidth billions of this packages can be transmitted through the ether. The only thing you need is one frequency carrier. Agno: die laatste zinnen zijn weer uitermate cryptisch. Wat wordt bedoelt met die 'one frequency carrier'???"
Just think about the possibilities this new system will offer
Agno: No, I won't think about them. But thanks for the offer!
quote:Op zaterdag 28 november 2009 20:09 schreef Agno het volgende:
Inderdaad Marco. Eric's boek was mateloos intrigerend.
Because DAVOC needs just a few bits for pictures, sounds and data complete programs can be stored in a small package and send all over the world. Because it only needs a small bandwidth billions of this packages can be transmitted through the ether. The only thing you need is one frequency carrier. Agno: die laatste zinnen zijn weer uitermate cryptisch. Wat wordt bedoelt met die 'one frequency carrier'???"
Just think about the possibilities this new system will offer
Agno: No, I won't think about them. But thanks for the offer!
Frequentie drager, denk ik. Op een analoge golf kun je meer relaties aan gegevens kwijt dan op een digitale, omdat de analoge golf meer waarden kan bevatten, in principe oneindig. Digitaal is een of nul.
quote:Op zaterdag 28 november 2009 20:09 schreef Agno het volgende:
The system operates with a complete new way of digital processing in a DAVOC processor. It uses the tree basic colors red, green and blue plus an additional clearness factor. With the value of the colors, the clearness signal and the unique algorithm the processor can calculate any known color of the spectrum.
Dit lijkt een trinaire processor te zijn. Die zijn te koop, ook toen al. Het lijkt me stug dat hijzelf een trinaire processor op zijn zolderkamer heeft gebakken. Wie weet heeft hij via via geavenceerde 'analoge' (dus meer standen mogelijk) hardware in handen gehad. Dan zou hij een katvanger zijn geweest, kan ook best. Het boek is in elk geval machtig interessant.
Mijn inziens was het kernprobleem dat Sloot wilde oplossen het versturen van grote hoeveelheden data over een beperkte bandbreedte. Het principe van zijn vinding was gebaseerd op het slim coderen van een beeld, waarbij het code-boek (~350Mb) in een database stond en de code-sleutel (~4Kb) op een smart card.
In zijn demokastjes stond het code-boek in ROM, maar het idee was waarschijnlijk om dit eenmalig centraal op te slaan en alleen de sleutel(s) via een smartcard te versturen naar de decentrale gebruiker.
In dat geval zijn er drie mogelijkheden:
1. Het hele code-boek moest je over een lijntje binnenhalen en dat werd dan in het kastje opgeslagen (dat kan werken, maar je kunt dan net zo goed een MPEGje downloaden).
2. Het hele code-boek stond vooraf geprogrammeerd in ROM in het kastje (dit gaat niet werken, omdat je een code-boek per film nodig hebt).
3. Hij had een geavanceerde streamingtechniek bedacht waarmee de lokale sleutel de beeldlijnen als het ware uit het centrale code-boek 'trok'. Het opsturen van de smartcard is dan een soort 'voor' verzending van informatie naar de ontvanger.
Die laatste optie is interessant, want alhoewel er vele wiskundige theorieën zijn over de grenzen van compressie (of codering) en informatie-overdacht (bijv. Shannon), gaan ze voornamelijk uit van een domme ontvanger die niets weet en een zender die alle informatie bezit. Bij de Sloot-vinding lag dat anders omdat de smartcard 'voor' informatie voor de ontvanger bevatte. Deze werd daardoor 'slimmer' gemaakt en de zender (code-boek) kon daardoor 'nog slimmer' verzenden.
Daarom is de volgende vraag wellicht interessant:
Wat is, gegeven een bepaalde bandbreedte (stel 64Kbit), de optimale 'voor' verdeling van een blok informatie (stel 100Mb), tussen een zender en een ontvanger, om de informatie die in het bezit blijft van de zender het meest efficiënt te kunnen versturen naar die ontvanger?
quote:en hoe wilt de processor dat geweld allemaal berekenen binnen de aanvaardbare tijd dan?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.
quote:De uitvinding van Sloot was óf een DRM, óf een MD5. 16 films opslaan op een algemeen verkrijgbaar geheugenkaartje van 64kB heeft niks te maken met eigengebouwde trinaire chips.
[..]
en hoe wilt de processor dat geweld allemaal berekenen binnen de aanvaardbare tijd dan?
quote:Correct.Op vrijdag 27 november 2009 11:18 schreef xibieanor het volgende:
Wat vinden jullie van deze visie op de werking van het systeem van de 'broncode'van Jan Sloot?
------
Mogelijke werking broncode van Jan Sloot
Jan Sloot was volgens de overlevering een begenadigd televisiereparateur, die bovendien werkzaam was in de periode dat hoge kwaliteit analoog signaal overging in de digitale variant. Met name het analoge signaal van het Composiet Video (CVBS) is in deze kwestie interessant, een analoog beeldsignaal is namelijk erg eenvoudig. De fase bepaalt de kleur en de amplitude de verzadiging van die kleur.
quote:Niet helemaal juist, bij PAL zit het kleursignaal op een 4.43Mhz draaggolf gemoduleerd. Het Y-signaal (helderheidsinformatie) zit helemaal nergens op gemoduleerd.Het signaal dat de helderheid bevat loopt er parallel op een andere frequentie onder.
quote:Die was niet alleen precies hetzelfde, die IS zelfs tot op de dag van vandaag het oorspronkelijke signaal voor de zwart-wit televisie.Het signaal voor de helderheid was zeker in die tijd precies hetzelfde als voor de zwart-wittelevisie.
quote:Om een kleurenbeeld volgens de PAL standaard weer te geven heb je de volgende 3 variabelen nodig:In principe zijn er dus drie variabelen nodig om een kleur weer te geven namelijk de waarde van
de fase, de waarde van de amplitude en de waarde van de helderheid.
- De waarde van Y (helderheid)
- De relatieve waarde van 2 van de 3 kleuren. (Immers de waarde van de 3e kleur kun je dan berekenen.)
PAL verzend het Y signaal, B-Y signaal en R-Y signaal.
quote:Aangezien er zes kleuren werden doorgegeven, te weten geel, rood, magenta, blauw, cyaan en groen
Allen rood en blauw worden doorgegeven bij CVBS, groen wordt berekend, en waar je geel, magenta en cyaan vandaan haalt is mij een raadsel.
quote:en dat 1 volt voldoende was voor de amplitude is het aantal waarden beperkt.
Dit is natuurlijk volslagen onzin. Letterlijk.
De waarde van 1 Volt is voor de resolutie totaal onbelangrijk. Dat had net zo goed 1KV of 1 mV kunnen zijn. Het gaat voor de kwaliteit van het resultaat om het aantal stappen waarin je die waarde onderverdeelt, niet de maximale hoogte van die waarde.
De rest van je betoog ga ik niet op in, dat is een onsamenhangend samenraapsel van klepels.
[ Bericht 0% gewijzigd door Bijvlagenzinvol op 06-12-2009 15:21:53 ]