Het Jan Sloot Digital Coding mysterie, deel 3

quote:

Op maandag 20 september 2004 00:12 schreef Leshy het volgende:
Volgens Sloot gebruikte hij geen binair systeem, en geen vorm van compressie. Het verbaast me dat iedereen dan juist blijft bewijzen dat zo'n enorme compressie niet kan, met de wiskundige uitleg van het binaire formaat erbij. Wat juist dé twee dingen zijn die volgens Sloot zelf niet van toepassing zouden zijn in dit geval.

Wat erin ging was binair

quote:

Op maandag 20 september 2004 00:17 schreef livEliveD het volgende:
Een codering kan best uitgekiend zijn maar zoveel herhalingen of verbanden zitten er volgens mij niet in films dat je het ooit zo klein krijgt.

Wie zegt dat het klein moet zijn? Als er constant een signaal van 30 tot 100Mhz (bijvoorbeeld) gegenereerd wordt dan is 'grote' totaal niet meer van belang. Er hoeft namelijk niets opgeslagen te worden.

quote:

Een checksum kun je niet terugrekenen naar het origineel tenzij je een checksum gebruikt die bijna evengroot is als de film zelf. Zelfs iets oneindig vaak coderen net zolang het maar klein genoeg wordt kan niet tenzij je toevallig data hebt waarvoor het een keer opgaat. Das meer een toevalstreffer en geen techniek waarop we zitten te wachten lijkt me.

Waarom? Als ik aan het begin van een signaalketen een checksum zet en helemaal aan het eind nog een en ik laat daartussen een hoogfrequent signaal lopen waaruit ik de informatie decodeer, dan hoef ik alleen maar te zorgen dat het uiteindelijke signaal wat ik weer ga geven aan het eind gelijk is aan de checksum van in het begin. Ook dat heeft niets met de grote te maken.

Jullie wiskundige afwijzing gaat er van uit dat iedere toekomstige film in dat doosje te passen moet zijn, en dat de codering lossless was. Zijn die aannames allebei waar?

Stel dat je gewoon een apparaat op de markt wilt brengen dat alle 500.000 (gokje) tot nu toe gemaakte speelfilms bevat. Zou het dan wiskundig gezien kunnen?

En stel dat er wel een zekere mate van verlies mag optreden. Welke consequenties zou dat hebben?

Sloot had het over 'een nieuw alfabet' om beeld vast te leggen. Stel dat dit simpelweg bestond uit blokjes pixeldata die op een of andere razend knappe manier uit simpele formules te reproduceren zijn. Een heel eenvoudige besparing van bijna tweemaal 50% is al te halen door geen spiegelidentieke varianten op te slaan. Er zijn nog veel meer bewerkingen denkbaar. Het zou me niet verbazen als die bibliotheek van een paar honderd megabyte aan data en formules een vele, vele malen grotere hoeveelheid gegevens kon representeren.

Ik herinner me trouwens een artikel uit het blad Zone5300, zo'n 2 jaar geleden, waarin iemand uitlegde hoe Sloot's vinding gewerkt zou kunnen hebben. Het was een onwaarschijnlijk verhaal, maar ik kon er niet snel een speld tussen krijgen. Ik kan dat blad niet meer vinden, maar misschien heeft een van jullie het toevallig.

quote:

Op maandag 20 september 2004 00:18 schreef livEliveD het volgende:

[..]

Wat erin ging was binair

Yep een file van enkele k's...

quote:

Op maandag 20 september 2004 00:32 schreef dvr het volgende:

Ik herinner me trouwens een artikel uit het blad Zone5300, zo'n 2 jaar geleden, waarin iemand uitlegde hoe Sloot's vinding gewerkt zou kunnen hebben. Het was een onwaarschijnlijk verhaal, maar ik kon er niet snel een speld tussen krijgen. Ik kan dat blad niet meer vinden, maar misschien heeft een van jullie het toevallig.

Jammer, bestaat het blad nog? Dan is er misschien nog een oud exemplaar te bestellen bij de uitgever.

quote:

Op maandag 20 september 2004 00:31 schreef Nuoro het volgende:
Waarom? Als ik aan het begin van een signaalketen een checksum zet en helemaal aan het eind nog een en ik laat daartussen een hoogfrequent signaal lopen waaruit ik de informatie decodeer, dan hoef ik alleen maar te zorgen dat het uiteindelijke signaal wat ik weer ga geven aan het eind gelijk is aan de checksum van in het begin. Ook dat heeft niets met de grote te maken.

Kun je dit beter uitleggen? Een beperkt aantal checksums leverd namelijk een peperkt aantal hoogfrequentie signalen op dat je kan genereren. Of gebeurd dat random? Maar hoe weet je dan wanneer je het goede signaal hebt?

quote:

Op maandag 20 september 2004 00:32 schreef dvr het volgende:
Jullie wiskundige afwijzing gaat er van uit dat iedere toekomstige film in dat doosje te passen moet zijn, en dat de codering lossless was. Zijn die aannames allebei waar?

of het lossless was heb ik het expres niet over gehad, en dat dus compleet buiten beschouwing gelaten door alleen het aantal verschillende soorten films te bespreken op basis van de inhoud van de film. Dus niet op pixel niveau. Op deze manier is het voor iedereen wat duidelijker dacht ik.
Verder kon hij zelf een film opnemen en die coderen. Dat impliceert dus dat iedere toekomstige film in het doosje zou moeten passen. Waarom zou ik tenslotte niet ter plekke titanic 2 kunnen opnemen met mijn camera?

quote:

Stel dat je gewoon een apparaat op de markt wilt brengen dat alle 500.000 (gokje) tot nu toe gemaakte speelfilms bevat. Zou het dan wiskundig gezien kunnen?

En stel dat er wel een zekere mate van verlies mag optreden. Welke consequenties zou dat hebben?

Dit is mogelijk denk ik. Alleen zou je heel veel opslagruimte nodig hebben voor die 500k films. Heel veel beter dan coderingen gebruikt door divx zijn naar mijn mening niet te halen (meer dan 2 keer zo goed als divx acht ik onwaarschijnlijk (zonder exponentiele toename van benodigde rekenkracht). Laat staan 2 miljoen keer)

quote:

Sloot had het over 'een nieuw alfabet' om beeld vast te leggen. Stel dat dit simpelweg bestond uit blokjes pixeldata die op een of andere razend knappe manier uit simpele formules te reproduceren zijn. Een heel eenvoudige besparing van bijna tweemaal 50% is al te halen door geen spiegelidentieke varianten op te slaan. Er zijn nog veel meer bewerkingen denkbaar. Het zou me niet verbazen als die bibliotheek van een paar honderd megabyte aan data en formules een vele, vele malen grotere hoeveelheid gegevens kon representeren.

dit soort ideen zijn, ondanks wat sommige denken, zeker niet nieuw. Moderne compressie methoden zijn al behoorlijk geavanceerd en complexer dan wat sloot neerzette. Maar zoals ik al eerder aangaf zit er een grens aan codering/compresie. Een grens waar sloot niet een klein beetje onder zat. Maar gigantisch ver onder zat.

quote:

Ik herinner me trouwens een artikel uit het blad Zone5300, zo'n 2 jaar geleden, waarin iemand uitlegde hoe Sloot's vinding gewerkt zou kunnen hebben. Het was een onwaarschijnlijk verhaal, maar ik kon er niet snel een speld tussen krijgen. Ik kan dat blad niet meer vinden, maar misschien heeft een van jullie het toevallig.

Het idee wat er achter zit is geenszins nieuw. En voor zover ik het heb begrepen zou het ook in enige mate kunnen werken. De resultaten die je er mee kan halen zijn echter vergelijkbaar met andere compresie technieken.

een mischien domme ingeving...zou een 3D boleaans matrix uitkomst bieden ?

quote:

Op zondag 19 september 2004 23:23 schreef SCH het volgende:

[..]

Zo kan je het interpreteren als je het van de wantrouwende en zeer negatieve kant belicht. Je kan ook zeggen dat hij een paar presentaties heeft gehouden die niet zo gemakkelijk hoaxes konden zijn, voor zeer ervaren en hooggekwalificeerde mensen heeft gehouden die echt wel weten wat een hoax is, en die er toch enthousiast over waren. U zegt het maar.

Ik vind het nogal wat om je er niet echt in te verdiepen, zoals jij doet, maar wel zeker te weten dat het niet klopt. Ik ben geen believer, wel geinteresseerd en vind het een boeiend en merkwaardig verhaal en zou absoluut niet met zekerheid een uitspraak over het waarheidsgehalte durven doen. En ja, het irriteert me dat sommigen dat wel doen: louter omdat zij het vanuit hun kennis niet kunnen verklaren. Dat is de beperking van de wetenschap.

Dat ik het nog eens een keer met SCH eens zou zijn

* AchJa Bookmarked

Stel dat het een 'hybride' techniek was, een analoge bron (hoogfrequent signaal) en digitale technieken die alleen maar gebruikt werden voor de noodzakelijke snelle berekeningen? Die checksums zijn dan de vaste waarden waartegen het signaal gechecked moet worden.

Hoe? Dunno. Maar dat is iig de richting waarin ik denk. En zeker niet aan compressie en/of digitale opslag.

quote:

Op maandag 20 september 2004 00:32 schreef dvr het volgende:
Stel dat je gewoon een apparaat op de markt wilt brengen dat alle 500.000 (gokje) tot nu toe gemaakte speelfilms bevat. Zou het dan wiskundig gezien kunnen?

Ja je zou een datbase kunnen leveren aan klanten en dan is de sleutel groot genoeg om die film uit te zoeken. Probleem is dat de specificaties die bekend zijn nooit 500.000 films heeft kunnen bevatten. 16 stuks wel (mits niet al te goede kwaliteit) maar dan is het dus idd een oplichttruc geweest

quote:

En stel dat er wel een zekere mate van verlies mag optreden. Welke consequenties zou dat hebben?

Zie huidige encoders

quote:

Sloot had het over 'een nieuw alfabet' om beeld vast te leggen. Stel dat dit simpelweg bestond uit blokjes pixeldata die op een of andere razend knappe manier uit simpele formules te reproduceren zijn. Een heel eenvoudige besparing van bijna tweemaal 50% is al te halen door geen spiegelidentieke varianten op te slaan. Er zijn nog veel meer bewerkingen denkbaar. Het zou me niet verbazen als die bibliotheek van een paar honderd megabyte aan data en formules een vele, vele malen grotere hoeveelheid gegevens kon representeren.

Een formule kan een oneindig aantal gegevens opleveren idd. En ja sommige stukken data kun je samenvatten in een simpele formule. Alleen met een gangbare film kom je op formules uit die even groot zijn als de film doordat je bv enorme komma getallen krijgt. Films kleiner krijgen kan wel omdat het niet random data is en er zitten verbanden in maar niet zoals sloot beweerd. Dat is to much en zal nooit kunnen

quote:

Ik herinner me trouwens een artikel uit het blad Zone5300, zo'n 2 jaar geleden, waarin iemand uitlegde hoe Sloot's vinding gewerkt zou kunnen hebben. Het was een onwaarschijnlijk verhaal, maar ik kon er niet snel een speld tussen krijgen. Ik kan dat blad niet meer vinden, maar misschien heeft een van jullie het toevallig.

Probeer het te vinden. Lijkt me erg interessant

quote:

Op maandag 20 september 2004 00:57 schreef Nuoro het volgende:
Stel dat het een 'hybride' techniek was, een analoge bron (hoogfrequent signaal) en digitale technieken die alleen maar gebruikt werden voor de noodzakelijke snelle berekeningen? Die checksums zijn dan de vaste waarden waartegen het signaal gechecked moet worden.

Kleine checksums kun je niet gebruiken om random data terug te rekenen omdat dezelfde Checksums vaker voorkomen. Grote checksums kunnen wel maar dan heb je het over grotes die in buurt van de grote van de film komen te liggen.

quote:

Op maandag 20 september 2004 00:55 schreef merlin693 het volgende:
een mischien domme ingeving...zou een 3D boleaans matrix uitkomst bieden ?

Nee uiteindelijk wordt de cirkel weer rond en zorgt dat duivenprincipe er weer voor dat het niet kan. Kijk als je geluk hebt kun je een bepaalde film echt heel klein coderen. Maar das geen algehele techniek die voor een willekeurige film op zal gaan.

quote:

Op maandag 20 september 2004 00:50 schreef livEliveD het volgende:

[..]

Kun je dit beter uitleggen? Een beperkt aantal checksums leverd namelijk een peperkt aantal hoogfrequentie signalen op dat je kan genereren. Of gebeurd dat random? Maar hoe weet je dan wanneer je het goede signaal hebt?

om hier op door te gaan:
voorbeeld van hoe een checksum werkt:
checksum van de volgende reeks getallen is 0 als aantallen 0-en even is. Anders 1.
01010111 : checksum is 1
01010101 : checksum is 0
10111101 : checksum is 0

de checksum is maar 1 bit. Dus codeert voor 2 signalen.
signaal is 8 bits. Dus 256 mogelijke verschillende signalen.
stel ik heb de checksum 0. Welk signaal hoort daar nu bij?

de kleinste checksum (of key dus) die voor 256 signalen kan coderen is : verassing, verassing...precies 8 bits weer (net zo groot als signaal)!! Het werken met checksums levert je precies niks op.

Het checksum verhaal gaat inderdaad niet op; bij een checksum tel je alle data bijelkaar op, maar zo'n checksum geeft geen unieke datastream aan. De volgorde van de data staat namelijk helemaal niet vast: 2+3 = 5 en 3+2 = 5. Zelfs de waardes staan niet vast: 1+4 = 5.

Vaak laten ze een checksum ook nog eens 'wrappen', als hij boven de maximale waarde komt knalt hij gewoon weer voorbij nul.

De reden waarom een checksum werkt voor foutcorrectie is dat de kans klein is dat een fout in de data door een andere fout precies gecompenseerd wordt zodat het totaal (de checksum) weer klopt.

Verder werkt een checksum redelijk als uniek ID omdat de kans vrij klein is dat andere data dezelfde checksum heeft, maar dat wil niet zeggen dat het nooit voor kan komen. Die kans hangt in de eerste plaats van de grootte van de checksum en in tweede plaats van de grootte van de data af, maar de kans blijft relatief ruim.

Welke experts hebben nu eigenlijk echt een demo gezien?
Ik bedoel die pieper was een zakenman en verder was er een keukenhandelaar. Waren er ook IT'ers bij geweest?

quote:

Op maandag 20 september 2004 00:57 schreef Nuoro het volgende:
Stel dat het een 'hybride' techniek was, een analoge bron (hoogfrequent signaal) en digitale technieken die alleen maar gebruikt werden voor de noodzakelijke snelle berekeningen? Die checksums zijn dan de vaste waarden waartegen het signaal gechecked moet worden.

Hoe? Dunno. Maar dat is iig de richting waarin ik denk. En zeker niet aan compressie en/of digitale opslag.

Ja in een soortgelijke richting zit ik ook te denken. Het blijkt ook uit het boek dat het meeste werk van Sloot in de vertaling ging zitten richting de video-out. Hij moest drivers en weet ik veel wat voor software laten communiceren met de hardware in het kastje.

quote:

Op maandag 20 september 2004 01:02 schreef Malach het volgende:
de kleinste checksum (of key dus) die voor 256 signalen kan coderen is : verassing, verassing...precies 8 bits weer (net zo groot als signaal)!! Het werken met checksums levert je precies niks op.

quote:

Op maandag 20 september 2004 01:04 schreef Cynix ® het volgende:
Dat dacht ik in deel 2 ook.

Huh ja. Het leek te werken maar in de praktijk loopt het op niks uit.

quote:

Op maandag 20 september 2004 00:57 schreef livEliveD het volgende:

Een formule kan een oneindig aantal gegevens opleveren idd. En ja sommige stukken data kun je samenvatten in een simpele formule. Alleen met een gangbare film kom je op formules uit die even groot zijn als de film doordat je bv enorme komma getallen krijgt. Films kleiner krijgen kan wel omdat het niet random data is en er zitten verbanden in maar niet zoals sloot beweerd. Dat is to much en zal nooit kunnen
[..]

bovendien heeft sloot het er toch over dat er steeds heel kleine gedeeltes van de data afzonderlijk worden gecodeert? Hij kijkt dus zelfs niet naar evenuele samenhang in de data. Maar steeds naar een klein blok (een paak k toch maar?) tegelijk.

quote:

Op maandag 20 september 2004 01:00 schreef livEliveD het volgende:

[..]

Kleine checksums kun je niet gebruiken om random data terug te rekenen omdat dezelfde Checksums vaker voorkomen. Grote checksums kunnen wel maar dan heb je het over grotes die in buurt van de grote van de film komen te liggen.

En Pars dan? Laat Quikpar een set recovery files maken van een film van 2Gb, kijk dan naar het eerste file, dat is namelijk de checksum van de film. Okè, de data ontbreekt, maar dat doet voor mijn voorbeeld niet terzake. Het gaat er alleen maar om of data ergens tegen te checken is. En ja, dat kan dus wel degelijk met een heel klein file.

quote:

Op maandag 20 september 2004 00:36 schreef Nuoro het volgende:
Jammer, bestaat het blad nog? Dan is er misschien nog een oud exemplaar te bestellen bij de uitgever.

Blad bestaat zo te zien nog: http://www.zone5300.nl/

Zie in het archief zo gauw niets staan: http://www.zone5300.nl/archief

quote:

Op maandag 20 september 2004 01:03 schreef Lamer_Deluxe het volgende:
Het checksum verhaal gaat inderdaad niet op; bij een checksum tel je alle data bijelkaar op, maar zo'n checksum geeft geen unieke datastream aan. De volgorde van de data staat namelijk helemaal niet vast: 2+3 = 5 en 3+2 = 5. Zelfs de waardes staan niet vast: 1+4 = 5.

crc checks en dergelijke werken iets anders dan gewoon optellen

quote:

Vaak laten ze een checksum ook nog eens 'wrappen', als hij boven de maximale waarde komt knalt hij gewoon weer voorbij nul.

Zie bv crc 16,crc 32, etc.

quote:

Verder werkt een checksum redelijk als uniek ID omdat de kans vrij klein is dat andere data dezelfde checksum heeft, maar dat wil niet zeggen dat het nooit voor kan komen. Die kans hangt in de eerste plaats van de grootte van de checksum en in tweede plaats van de grootte van de data af, maar de kans blijft relatief ruim.

De grote van de data heeft geen invloed op de 'uniekheid' bij crc

quote:

Op maandag 20 september 2004 01:03 schreef livEliveD het volgende:
Welke experts hebben nu eigenlijk echt een demo gezien?
Ik bedoel die pieper was een zakenman en verder was er een keukenhandelaar. Waren er ook IT'ers bij geweest?

volgens de docu op tv waren er een paar technische mensen die het gezien hadden op een gegeven moment. Maar die waren er niet van onder de indruk.

Achteraf zeggen de betrokkenen dat dat juist de bedoeling was van de demonstratie (proberen ze misschien de legende bewust in leven te houden, of was het echt zo?).